Как правильно назначить роль участника сети кластеру AKS с помощью шаблона ARM/Bicep?

Я пытаюсь настроить балансировщик нагрузки для своего сервера AKS с помощью Bicep/ARM. Я использую NGinx Ingress Controller в kubernetes, и, похоже, он работает, но когда я впервые запускаю процесс, я сталкиваюсь с ошибкой.

В основном мне интересно, какой эквивалентный шаблон ARM или Bicep для этого шага в документации Azure?

https://docs.microsoft.com/en-us/azure/aks/static-ip#create-a-service-using-the-static-ip-address

az role assignment create \
    --assignee <Client ID> \
    --role "Network Contributor" \
    --scope /subscriptions/<subscription id>/resourceGroups/<resource group name>

Я использую Bicep и создал свой сервер AKS, например, вот так:

resource ExampleKubernetes 'Microsoft.ContainerService/managedClusters@2021-07-01' = {
  //...
}

Затем я добавляю назначение ролей к удостоверению kubelet вот так:

var NetworkContibutor = '4d97b98b-1d4f-4787-a291-c67834d212e7'
resource AssignNetworkContributorToKubelet 'Microsoft.Authorization/roleAssignments@2020-08-01-preview' = {
  name: guid(resourceGroup().id, ExampleKubernetes.id, NetworkContibutor)
  dependsOn: [
    ExampleKubernetes
  ]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', NetworkContibutor)
    principalType: 'ServicePrincipal'
    principalId: ExampleKubernetes.properties.identityProfile.kubeletidentity.objectId
  }
}

Похоже, что это работает, я вижу роль, назначенную для управляемый участник на панели инструментов... но служба в kubernetes, похоже, все еще дает сбой из-за проблемы с разрешениями :

  Error syncing load balancer: failed to ensure load balancer: Retriable: false,
  RetryAfter: 0s, HTTPStatusCode: 403, RawError: Retriable: false, RetryAfter:
  0s, HTTPStatusCode: 403, RawError:
  {"error":{"code":"AuthorizationFailed","message":"The client
  '<some guid A>' with object id
  '<some buid A>' does not have authorization to perform
  action 'Microsoft.Network/publicIPAddresses/read' over scope
  '/subscriptions/<subid>/resourceGroups/example/providers/Microsoft.Network/publicIPAddresses/example'
  or the scope is invalid. If access was recently granted, please refresh your
  credentials."}}

. Странно то, что позже в какой-то момент кажется, что она просто волшебным образом работает. В этой ошибке указано «retriable false», и похоже, что служба не повторяет попытку, но последующее развертывание NGinx в kubernetes , а затем заставит ее повторить попытку и внезапно взорвать ее работу.

Мне просто кажется, что сообщение об ошибке говорит мне о некоторой не-недетерминированной задержке распространения ролей... Итак, мои вопросы::

  • Верно? На самом деле это просто задержка, и мой код в основном правильный?
  • Правильно ли я использую PrincipalId? Или это действительно ненужно?
  • Есть ли способ принудительно распространить эти обновления ролей? Я мог бы сделать промежуточный шаг CLI, если бы мне было нужно. Как я могу дождаться установки моего входного контроллера, который подключается к LB после того, как разрешения будут готовы?
0
задан 17 September 2021 в 20:53
1 ответ

На ваш вопрос (хотя и не напрямую)ответ здесь .

Описываемое вами поведение обсуждается в этого раздела . Поскольку Azure Resource Manager иногда кэширует конфигурации и данные для повышения производительности, иногда может потребоваться до 30 минут, чтобы изменения вступили в силу при назначении ролей или удалении назначений ролей.

Используя Azure CLI, вы можете принудительно обновить изменения назначения ролей, выйдя и войдя .

0
ответ дан 24 September 2021 в 16:41

Теги

Похожие вопросы