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

Я пытаюсь настроить балансировщик нагрузки для своего сервера AKS с помощью Bicep/ARM. Я использую контроллер входа NGinx в 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 после того, как разрешения будут готовы?

1 ответ

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

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

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

Другие вопросы по тегам