Как правильно назначить роль участника сети кластеру 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, вы можете принудительно обновить изменения назначения ролей, выйдя и войдя в систему .