Общедоступный 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.


azure azure-aks terraform terraform-provider-azure service-principal
person Derek    schedule 13.05.2019    source источник
comment
Вы можете отметить свой ответ, чтобы помочь другим участникам.   -  person Charles Xu    schedule 22.05.2019

Ответы (2)


arrow_upward
4
arrow_downward

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

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

ИЗМЕНИТЬ 23 мая 2019 г.

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

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

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

person Derek    schedule 13.05.2019
comment
это не совсем так, вы можете использовать IP-адрес из любой группы ресурсов в одной подписке при правильной настройке. - person 4c74356b41; 14.05.2019
comment
Да, @ 4c74356b41. Я последовал за MS, и для этого требуется аннотация балансировщика нагрузки или контроллера входящего трафика. Я отредактировал свой исходный пост, чтобы включить это решение. - person Derek; 23.05.2019
comment
Не сделал. Изменил свое мнение о голосовании, потому что вы не указали мне решение, а только сообщили, что оно есть, что не очень помогло. Я обратился в службу поддержки только в MS, потому что мы нашли вариант использования, который не был решен с помощью моего первоначального обходного пути. - person Derek; 23.05.2019
comment
ну, я не знаю, как вы настроили свои вещи, поэтому я не знаю, как это исправить, но совершенно очевидно, что все работает нормально, если настроено правильно, поэтому вам нужно исправить права SP - person 4c74356b41; 23.05.2019
comment
Права SP были в порядке с самого начала. Это было первое, что я исправил. Проблема заключалась в отсутствии аннотации. Я отредактировал свой ответ, включив аннотацию. Тем не менее, спасибо за повторное упоминание прав SP. Я тоже добавлю это к своему ответу. (Вы получите за это голос. :) - person Derek; 23.05.2019

arrow_upward
0
arrow_downward

Я пока не могу комментировать, поэтому помещаю это дополнение в качестве ответа.

Дерек прав, вы можете полностью использовать существующий IP из группы ресурсов, отличной от того, где был подготовлен кластер AKS. Есть страница документации. Просто убедитесь, что вы выполнили эти два шага ниже:

  1. Добавьте назначение роли участника сети для субъекта-службы AKS в группу ресурсов, в которой находится ваш существующий статический IP-адрес.

  2. Добавьте service.beta.kubernetes.io/azure-load-balancer-resource-group: myResourceGroup к контроллеру входящего трафика с помощью следующей команды:

kubectl annotate service ingress-nginx-controller -n ingress service.beta.kubernetes.io/azure-load-balancer-resource-group=datagate
person Gleb Teterin    schedule 09.03.2021