#azure #docker #kubernetes #azure-aks #service-principal
#azure #docker #kubernetes #azure-aks #service-принципал
Вопрос:
По умолчанию при создании кластера AKS для этого кластера создается участник службы.
Затем этот принцип обслуживания может быть установлен на уровне какого-либо другого ресурса Azure (виртуальной машины?), Чтобы они могли устанавливать сетевое подключение и могли обмениваться данными (за исключением, конечно, общих сетевых настроек)
Я действительно не уверен и не могу понять, когда это требуется, а когда нет. Если, например, у меня есть БД на уровне виртуальной машины, нужно ли мне предоставлять основной доступ службы AKS к виртуальной машине, чтобы иметь возможность взаимодействовать с ней по сети или нет?
Может кто-нибудь предоставить мне некоторые рекомендации по этому вопросу, а не общую документацию. Когда это требуется для использования / установки на уровне этих других ресурсов Azure, а когда нет? Я не могу найти правильного объяснения этому. Спасибо
Ответ №1:
Что касается вашего вопроса о БД, вам не нужно предоставлять участнику службы какой-либо доступ к этой виртуальной машине. Учитывая, что база данных выполняется за пределами Kubernetes, нет необходимости каким-либо образом обращаться к этой виртуальной машине. База данных может даже находиться в другом центре обработки данных или полностью размещаться на другом облачном провайдере, приложения, работающие внутри kubernetes, все равно смогут взаимодействовать с ней, пока трафик разрешен брандмауэрами и т. Д.
Я знаю, что вы не запрашивали общую документацию, но документация по участникам службы Kubernetes описывает это хорошо:
Для взаимодействия с API Azure кластеру AKS требуется либо участник службы Azure Active Directory (AD), либо управляемое удостоверение. Для динамического создания других ресурсов Azure и управления ими, таких как средство балансировки нагрузки Azure или реестр контейнеров (ACR), требуется участник службы или управляемая идентификация.
Другими словами, участник службы — это идентификатор, с помощью которого кластер Kubernetes проверяет подлинность при взаимодействии с другими ресурсами Azure, такими как:
- Реестр контейнеров Azure: образы, из которых создаются контейнеры, должны поступать из somehwere. Если вы храните свои пользовательские изображения в частном реестре, кластер должен быть авторизован для извлечения изображений из реестра. Если частный реестр является реестром контейнера Azure, участник службы должен быть авторизован для этих операций
- Сеть: Kubernetes должен иметь возможность динамически настраивать таблицы маршрутизации и регистрировать внешние IP-адреса для служб в балансировщике нагрузки. Опять же, участник службы используется в качестве удостоверения, поэтому он должен быть авторизован
- Хранилище: для доступа к дисковым ресурсам и их монтирования в модули
- Экземпляры контейнеров Azure: в случае, если вы используете виртуальный kubelet для динамического добавления вычислительных ресурсов в свой кластер, Kubernetes должен быть разрешен для управления контейнерами в ACI.
Чтобы делегировать доступ к другим ресурсам Azure, вы можете использовать cli Azure для назначения роли правопреемнику в определенной области:
az role assignment create --assignee <appId> --scope <resourceScope> --role Contributor
Вот подробный список всех используемых разрешений на идентификацию кластера
Комментарии:
1. Спасибо за это отличное и очень подробное объяснение. Теперь я понимаю, что это больше относится ко всему использованию API Azure. Но когда вы говорите, что для работы в сети и хранения он должен использовать принцип обслуживания — это не значит, что мне нужно назначить его вручную, это означает, что он просто использует уже существующий принцип обслуживания для аутентификации при взаимодействии с этими ресурсами Azure … правильно?
2. Это полностью зависит от вашего варианта использования. Если вы используете настройки по умолчанию и базовую сеть, вы должны быть в порядке, не назначая вручную никаких разрешений участнику службы. С другой стороны, если вы, например, используете расширенную сеть, а подсети и общедоступные IP-адреса находятся в другой группе ресурсов, вам нужно будет назначить роль сетевого участника для этой подсети. Тот же принцип применяется для дисковых ресурсов или если у вас есть реестр контейнеров Azure, к которому вы хотели бы подключиться,
3. Спасибо, Дэниел, я отметил это как ответ. Я буду использовать CNI. Скорее всего, тот же VN, RG, но другая подсеть. Что в таком случае — должен ли я назначить участника службы той другой подсети, где находятся мои виртуальные машины вне AKS? Вот почему я в замешательстве — где определены эти «правила», чтобы я мог знать, должен ли я это обрабатывать или об этом позаботятся автоматически…
4.Нет, вам нужно будет назначить роль сетевого участника подсети, в которой находится виртуальная машина внутри кластера Kubernetes (т.Е. Узлы, На которых развернуты контейнеры) docs.microsoft.com/en-us/azure/aks /…
5. пожалуйста, извините, но просто для того, чтобы прояснить одну вещь: если я создам кластер AKS с выбранным по умолчанию vn / subnet или с существующим vn / subnet, почему роль не назначается автоматически этому vn / subnet? Я не могу этого понять .. ofc если вы создаете кластер AKS и ссылаетесь на какую-то подсеть или создаете новую — не кажется логичным, чтобы этот кластер НЕ имел доступа к этой подсети, поскольку вы создаете для этой виртуальной сети (зачем назначать впоследствии) Я не могу понять, почему это делегирование участника службы не делегируется автоматически??? не могли бы вы, пожалуйста, объяснить мне это ..:( спасибо