GOOGLE ADS

воскресенье, 1 мая 2022 г.

Общедоступный IP-адрес Azure AKS в нестандартной группе ресурсов

Я пытался управлять экземпляром службы Azure Kubernetes (AKS) через Terraform. Когда я создаю экземпляр AKS через Azure CLI в соответствии с этим руководством MS, а затем устанавливаю контроллер входящего трафика со статическим общедоступным IP-адресом в соответствии с этим руководством MS, все работает нормально. Этот метод неявно создает субъект-службу (SP).

Когда я создаю точную копию кластера AKS с помощью Terraform, я вынужден явно указать субъект-службу. Я предоставил этому новому SP "Contributor" доступ ко всей группе ресурсов кластера, однако, когда я дошел до шага по созданию входного контроллера (используя ту же команду, что и в учебнике 2 выше helm install stable/nginx-ingress --set controller.replicaCount=2 --set controller.service.loadBalancerIP="XX.XX.XX.XX":), входная служба появляется, но никогда не получает свой публичный IP. Статус IP остается «<ожидание>» на неопределенный срок, и я ничего не могу найти в любом журнале о том, почему. Есть ли журналы, которые должны сообщить мне, почему мой IP-адрес все еще находится на рассмотрении?

Опять же, я совершенно уверен, что, за исключением SP, кластер Terraform AKS является точной копией кластера, созданного на основе учебника MS. Бег terraform planне находит различий между ними. Кто-нибудь знает, какое разрешение может потребоваться моему AKS SP или что еще мне здесь не хватает? Как ни странно, я не могу найти НИКАКИХ разрешений, назначенных неявно созданному участнику через портал Azure, но я не могу придумать ничего другого, что могло бы вызвать такое поведение.

Не уверен, что это отвлекающий маневр или нет, но другие пользователи жаловались на аналогичную проблему в контексте проблем, открытых во втором учебнике. Их исправление всегда выглядит так: «снести кластер и повторить попытку», но в данном контексте это неприемлемое решение. Мне нужен воспроизводимый рабочий кластер, а azurerm_kubernetes_cluster в настоящее время не позволяет создавать экземпляр AKS с неявно созданным SP.


Решение проблемы

Я собираюсь ответить на свой вопрос, для потомков. Оказывается, проблема заключалась в группе ресурсов, в которой я создал статический общедоступный IP-адрес. Кластеры AKS используют две группы ресурсов: группу, в которой вы явно создали кластер, и вторую группу, которая неявно создается кластером. Эта вторая неявная группа ресурсов всегда получает имя, начинающееся с «MC_» (остальная часть имени является производной от явного RG, имени кластера и региона).

В любом случае конфигурация AKS по умолчанию требует, чтобы общедоступный IP-адрес был создан в этой неявной группе ресурсов. Если вы создали кластер AKS с помощью Terraform, его имя будет экспортировано в формате ${azurerm_kubernetes_cluster.NAME.node_resource_group}.

РЕДАКТИРОВАТЬ 2019-05-23

С момента написания этой статьи мы обнаружили вариант использования, для которого обходной путь использования группы ресурсов MC_* оказался недостаточно хорошим. Я открыл билет поддержки с MS, и они направили меня на это решение. Добавьте следующую аннотацию в свой LoadBalancer (или контроллер Ingress) и убедитесь, что AKS SP имеет как минимум Network Contributorправа в целевой группе ресурсов ( myResourceGroupв приведенном ниже примере):

metadata:
annotations:
service.beta.kubernetes.io/azure-load-balancer-resource-group: myResourceGroup

Это решило это полностью для нас.

Комментариев нет:

Отправить комментарий

Laravel Datatable addColumn returns ID of one record only

Я пытаюсь использовать Yajra Datatable для интеграции DataTable на свой веб-сайт. Я смог отобразить таблицу, но столкнулся с проблемой. В по...