Службы Azure Kubernetes - когда требуется установить принцип службы AKS на других ресурсах Azure для подключения?

По умолчанию при создании кластера AKS для этого кластера создается субъект-служба.

Затем этот субъект-служба может быть установлен на уровне какого-либо другого ресурса Azure (виртуальной машины?), Чтобы они могли установить сетевое соединение и обмениваться данными (за исключением, конечно, общих сетевых настроек).

Я действительно не уверен и не могу понять, когда это необходимо, а когда нет. Если, например, у меня есть база данных на уровне виртуальной машины, мне нужно предоставить субъекту службы AKS доступ к виртуальной машине, чтобы иметь возможность общаться с ней через сеть или нет?

Может ли кто-нибудь дать мне какое-то руководство по этому поводу, а не общую документацию. Когда это необходимо для использования / настройки на уровне других ресурсов Azure, а когда нет? Я не могу найти этому объяснения. Спасибо


azure kubernetes docker azure-aks service-principal
person Veljko    schedule 29.01.2021    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Что касается вашего вопроса о БД, вам не нужно предоставлять субъекту службы доступ к этой виртуальной машине. Учитывая, что база данных работает за пределами Kubernetes, не требуется никакого доступа к этой виртуальной машине. База данных может даже находиться в другом центре обработки данных или полностью размещаться у другого облачного провайдера, приложения, работающие внутри кубернетов, по-прежнему смогут связываться с ней, если трафик разрешен межсетевыми экранами и т. Д.

Я знаю, что вы просили не общую документацию, а документацию по Принципы обслуживания Kubernetes хорошо об этом говорят:

Для взаимодействия с API Azure кластеру AKS требуется субъект-служба Azure Active Directory (AD) или управляемое удостоверение. Субъект-служба или управляемое удостоверение необходимы для динамического создания и управления другими ресурсами Azure, такими как балансировщик нагрузки Azure или реестр контейнеров (ACR).

Другими словами, субъект-служба - это идентификатор, с помощью которого кластер Kubernetes аутентифицируется при взаимодействии с другими ресурсами Azure, такими как:

  • Реестр контейнеров Azure: Образы, из которых создаются контейнеры, должны быть откуда-то. Если вы храните свои пользовательские образы в частном реестре, кластер должен иметь разрешение на извлечение образов из реестра. Если частный реестр является реестром контейнеров Azure, субъект-служба должен быть авторизован для этих операций.
  • Сеть: Kubernetes должен иметь возможность динамически настроить таблицы маршрутизации и зарегистрировать внешние IP-адреса для служб в балансировщике нагрузки. Опять же, субъект-служба используется в качестве идентификатора, поэтому он должен быть авторизован.
  • Хранилище: для доступа к дисковым ресурсам и монтирования их в стручки
  • экземпляры контейнера Azure: Если вы используете виртуальный кубелет для динамического добавления вычислительных ресурсов в кластер, Kubernetes должен иметь разрешение на управление контейнерами в ACI.

Чтобы делегировать доступ к другим ресурсам Azure, вы можете использовать Azure cli, чтобы назначить роль уполномоченному в определенной области:

az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor

Вот подробный список всех кластеров. идентификационные разрешения уже используются

person danielorn    schedule 29.01.2021
comment
Спасибо за это прекрасное и очень подробное объяснение. Теперь я понимаю, что это больше касается использования всех API-интерфейсов Azure. Но когда вы говорите, что для сети и хранилища он должен использовать субъект-службу - это не означает, что мне нужно назначать его вручную, это означает, что он просто будет использовать уже существующий субъект-службу для проверки подлинности при взаимодействии с этими ресурсами Azure ... верный? - person Veljko; 29.01.2021
comment
Это полностью зависит от вашего варианта использования. Если вы используете настройки по умолчанию и базовую сеть, у вас должно получиться хорошо, не назначая вручную какие-либо разрешения субъекту-службе. С другой стороны, если вы, например, используете расширенную сеть, а подсети и общедоступные IP-адреса находятся в другой группе ресурсов, вам необходимо назначить роль участника сети для этой подсети. Тот же принцип применяется к дисковым ресурсам или, если у вас есть реестр контейнеров Azure, к которому вы хотите подключиться, - person danielorn; 29.01.2021
comment
Спасибо, Дэниел, я отметил это как ответ. Я буду использовать CNI. Скорее всего, тот же VN, RG, но другая подсеть. Что в этом случае - должен ли я назначать принципала службы той другой подсети, где находятся мои виртуальные машины за пределами AKS? Вот почему я смущен - где эти правила определены, чтобы я мог знать, должен ли я справиться с этим, или это было сделано автоматически ... - person Veljko; 29.01.2021
comment
Нет, вам нужно будет назначить роль сетевого участника подсети, в которой находится виртуальная машина внутри кластера Kubernetes (т. Е. Узлы, на которых развернуты контейнеры) docs.microsoft.com/en-us/azure/aks/ - person danielorn; 29.01.2021
comment
пожалуйста, извините, но просто чтобы прояснить одну вещь - если я создаю кластер AKS с выбранным по умолчанию vn / subnet или с существующим vn / subnet, почему роль не назначается автоматически этому vn / подсети? Я не могу этого понять .. ofc, если вы создаете кластер AKS и ссылаетесь на какую-то подсеть или создаете новую - не кажется логичным, чтобы этот кластер НЕ имел доступа к этой подсети, поскольку вы создаете для этой vnet (зачем назначать потом) Я не могу понять, почему это делегирование принципала службы не делегируется автоматически ??? не могли бы вы объяснить мне это .. :( спасибо - person Veljko; 30.01.2021
comment
Также обратите внимание, что настройки по умолчанию и расширенная сеть с существующей виртуальной сетью - это два разных сценария, которые ведут себя по-разному в этом отношении: docs.microsoft.com/en-us/azure/aks/ Когда вы используете расширенные сетевые возможности, когда вы используете существующую виртуальную сеть и подсеть или общедоступным IP-адресам в другой группе ресурсов разрешения не назначаются автоматически. Думаю, именно так это разработала компания MS. - person danielorn; 01.02.2021