Базовые показатели AKS для кластеров с несколькими агрегатами

В этой эталонной архитектуре описано, как запускать несколько экземпляров кластера Служба Azure Kubernetes (AKS) в нескольких регионах в активной и активной и высокодоступной конфигурации.

Эта архитектура основана на базовой архитектуре AKS, рекомендуемой корпорацией Майкрософт отправной точкой для инфраструктуры AKS. Базовые функции инфраструктуры AKS, такие как Идентификация рабочей нагрузки Microsoft Entra, ограничения входящего трафика и исходящего трафика, ограничения ресурсов и другие безопасные конфигурации инфраструктуры AKS. Эти сведения о инфраструктуре не рассматриваются в этом документе. Рекомендуется ознакомиться с базовым показателем AKS, прежде чем перейти к содержимому в нескольких регионах.

Архитектура

Скачайте файл Visio для этой архитектуры.

Эталонная реализация этой архитектуры доступна на сайте GitHub.

Компоненты

Многие компоненты и службы Azure используются в эталонной архитектуре AKS в нескольких регионах. Ниже перечислены только эти компоненты с уникальностью этой архитектуры с несколькими кластерами. Для остальных см. архитектуру базовых показателей AKS.

• Развертываются несколько кластеров или нескольких регионов Несколько кластеров AKS, каждый из которых содержит отдельный регион Azure. Во время обычных операций сетевой трафик направляется между всеми регионами. Если один регион становится недоступным, трафик направляется в регион, ближайший к пользователю, который выдал запрос.
• Сеть с концентраторами на регионЕ Для каждого регионального экземпляра AKS развертывается региональная сетевая пара "периферийный концентратор". политики диспетчера Брандмауэр Azure используются для управления политиками брандмауэра во всех регионах.
• Региональное хранилище ключей Azure Key Vault подготавливается в каждом регионе для хранения конфиденциальных значений и ключей, относящихся к экземпляру AKS и вспомогательным службам, найденным в этом регионе.
• Azure Front Door Azure Front door используется для балансировки нагрузки и маршрутизации трафика в региональный экземпляр Шлюз приложений Azure, который находится перед каждым кластером AKS. Azure Front Door позволяет выполнить глобальную маршрутизацию уровня семь уровней, оба из которых необходимы для этой эталонной архитектуры.
• Экземпляры Log Analytics Для хранения региональных сетевых метрик и журналов диагностики используются экземпляры Log Analytics . Кроме того, общий экземпляр Log Analytics используется для хранения метрик и журналов диагностики для всех экземпляров AKS.
• Реестр контейнеров. Образы контейнеров для рабочей нагрузки хранятся в управляемом реестре контейнеров. В этой архитектуре для всех экземпляров Kubernetes в кластере используется один Реестр контейнеров Azure. Геоизбыточное реплика для Реестр контейнеров Azure позволяет реплика создавать изображения в выбранные регионы Azure и предоставлять постоянный доступ к изображениям, даже если регион испытывает сбой.

Конструктивные шаблоны

В этой эталонной архитектуре используются два шаблона проектирования облака. Географический узел (геодокументы), где любой регион может обслуживать любой запрос и метки развертывания, где развертываются несколько независимых копий приложения или компонента приложения из одного источника (шаблона развертывания).

Рекомендации по шаблону географического узла

При выборе регионов для развертывания каждого кластера AKS рассмотрите регионы, близкие к потребителю рабочей нагрузки или клиентам. Кроме того, рекомендуется использовать межрегионные реплика tion. Асинхронно реплика между регионами реплика выполняет те же приложения и данные в других регионах Azure для защиты от аварийного восстановления. По мере масштабирования кластера за пределами двух регионов продолжайте планировать межрегионные реплика для каждой пары кластеров AKS.

В каждом регионе узлы в пулах узлов AKS распределяются по нескольким зонам доступности, чтобы предотвратить проблемы из-за зональных сбоев. Зоны доступности поддерживаются в ограниченном наборе регионов, что влияет на размещение регионального кластера. Дополнительные сведения об AKS и зонах доступности, включая список поддерживаемых регионов, см. в разделе "Зоны доступности AKS".

Рекомендации по меткам развертывания

При управлении кластером AKS с несколькими регионами несколько экземпляров AKS развертываются в нескольких регионах. Каждый из этих экземпляров считается меткой. В случае регионального сбоя или необходимости добавить больше емкости и /или регионального присутствия для кластера может потребоваться создать новый экземпляр метки. При выборе процесса создания меток развертывания и управления ими важно учитывать следующие моменты:

• Выберите соответствующую технологию определений меток, которая позволяет использовать обобщенную конфигурацию, например инфраструктуру в виде кода.
• Укажите значения, относящиеся к экземпляру, с помощью механизма ввода развертывания, например переменных или файлов параметров
• Выбор средств развертывания, позволяющих гибкое, повторяемое идемпотентное развертывание
• В конфигурации активной и активной метки рассмотрите, как распределяется трафик по каждой метке.
• При добавлении и удалении меток из коллекции рассмотрите проблемы с емкостью и затратами.
• Рассмотрим, как получить видимость и (или) отслеживать коллекцию меток в виде одной единицы.

Каждый из этих элементов подробно описан в следующих разделах этой эталонной архитектуры.

Управление автотранспортным парком

Это решение представляет собой топологию с несколькими кластерами и несколькими регионами без включения расширенного оркестратора для обработки всех кластеров в составе единого парка. При увеличении числа кластеров рекомендуется зарегистрировать участников в Azure Kubernetes Fleet Manager для лучшего управления участвующими кластерами. Архитектура инфраструктуры, представленная здесь, не существенно изменяется при регистрации в Fleet Manager, но 2-дневные операции и аналогичные действия получают преимущества от плоскости управления, которая может одновременно ориентироваться на несколько кластеров.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Развертывание кластера и начальная загрузка

При развертывании нескольких кластеров Kubernetes в высокодоступных и географически распределенных конфигурациях важно учитывать сумму каждого кластера Kubernetes в виде связанного блока. Вам может потребоваться разработать стратегии на основе кода для автоматического развертывания и конфигурации, чтобы обеспечить, чтобы каждый экземпляр Kubernetes был максимально идентичным. Вы хотите рассмотреть стратегии масштабирования и в, добавив или удалив другие экземпляры Kubernetes. Вам потребуется, чтобы проект и план развертывания и конфигурации учитывались региональные сбои или другие распространенные сценарии.

Определение кластера

Существует множество вариантов развертывания кластера Служба Azure Kubernetes. Портал Azure, Azure CLI и модуль Azure PowerShell — это все достойные варианты развертывания отдельных или не связанных кластеров AKS. Однако эти методы могут представлять трудности при работе с множеством тесно связанных кластеров AKS. Например, при использовании портал Azure открывается возможность пропустить конфигурацию из-за пропущенных шагов или недоступных параметров конфигурации. Кроме того, развертывание и настройка многих кластеров с помощью портала является своевременным процессом, требующим фокуса одного или нескольких инженеров. Вы можете создать повторяемый и автоматизированный процесс с помощью средств командной строки. Однако ответственность за идемпотентность, управление сбоем развертывания и восстановление сбоев зависит от вас и скриптов, которые вы создаете.

При работе с множеством экземпляров AKS рекомендуется рассматривать инфраструктуру как решения кода, такие как шаблоны Azure Resource Manager, шаблоны Bicep или конфигурации Terraform. Инфраструктура как решения кода предоставляют автоматизированное, масштабируемое идемпотентное решение развертывания. Эта эталонная архитектура включает шаблон ARM для общих служб решений, а затем другой для кластеров AKS и региональных служб. Если вы используете инфраструктуру в качестве кода, то метку развертывания можно определить с обобщенными конфигурациями, такими как сеть, авторизация и диагностика. Файл параметров развертывания можно предоставить с региональными значениями. С помощью этой конфигурации можно использовать один шаблон для развертывания почти идентичной метки в любом регионе.

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

Развертывание кластера

После определения определения метки кластера у вас есть множество вариантов развертывания отдельных или нескольких экземпляров меток. Мы рекомендуем использовать современные технологии непрерывной интеграции, такие как GitHub Actions или Azure Pipelines. К преимуществам решений развертывания на основе непрерывной интеграции относятся следующие преимущества:

• Развертывания на основе кода, позволяющие добавлять и удалять метки с помощью кода
• Интегрированные возможности тестирования
• Интегрированные возможности среды и промежуточные возможности
• Интегрированные решения по управлению секретами
• Интеграция с кодом или системой управления версиями развертывания
• Журнал развертывания и ведение журнала

Так как новые метки добавляются или удаляются из глобального кластера, конвейер развертывания необходимо обновить, чтобы оставаться согласованным. В эталонной реализации каждый регион развертывается как отдельный шаг в рабочем процессе GitHub Action (пример). Эта конфигурация проста в том, что каждый экземпляр кластера четко определен в конвейере развертывания. Эта конфигурация включает некоторые административные издержки при добавлении и удалении кластеров из развертывания.

Другой вариант — использовать логику для создания кластеров на основе списка нужных расположений или других точек данных. Например, конвейер развертывания может содержать список требуемых регионов; Затем шаг в конвейере может выполнить цикл по этому списку, развернув кластер в каждом регионе, найденном в списке. Недостаток этой конфигурации заключается в сложности в обобщении развертывания, и что каждая метка кластера не подробно описана в конвейере развертывания. Положительное преимущество заключается в том, что добавление или удаление меток кластера из конвейера становится простым обновлением списка нужных регионов.

Кроме того, удаление метки кластера из конвейера развертывания не обязательно гарантирует, что она также будет выведена из эксплуатации. В зависимости от решения и конфигурации развертывания может потребоваться дополнительный шаг, чтобы убедиться, что экземпляры AKS были выведены из эксплуатации.

Начальная загрузка кластера

После развертывания каждого экземпляра или метки Kubernetes необходимо развернуть и настроить компоненты кластера, такие как контроллеры входящего трафика, решения удостоверений и компоненты рабочей нагрузки. Кроме того, необходимо рассмотреть возможность применения политик безопасности, доступа и управления в кластере.

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

Конфигурации

Вместо ручной настройки компонентов Kubernetes рекомендуется использовать автоматизированные методы для применения конфигураций к кластеру Kubernetes, так как эти конфигурации проверка в исходный репозиторий. Этот процесс часто называется GitOps, а популярные решения GitOps для Kubernetes включают Flux и Argo CD. Эта реализация использует расширение Flux для AKS, чтобы включить автоматическую загрузку кластеров и сразу после развертывания кластеров.

GitOps подробно описаны в базовой эталонной архитектуре AKS. Важной точкой здесь является то, что использование подхода на основе GitOps к настройке помогает убедиться, что каждый экземпляр Kubernetes настроен аналогичным образом без усилий. Это становится еще более важным, так как размер вашего флота растет.

Политика Azure

При добавлении нескольких экземпляров Kubernetes преимущество управления на основе политик, соответствия требованиям и конфигурации увеличивается. Использование политик, Политика Azure в частности, предоставляет централизованный и масштабируемый метод для управления кластером. Преимущества политик AKS подробно описаны в базовой эталонной архитектуре AKS.

Политика Azure включена в этой эталонной реализации при создании кластеров AKS и назначении ограничивающей инициативы в режиме аудита для получения видимости несоответствия. Реализация также задает дополнительные политики, которые не являются частью встроенных инициатив. Эти политики задаются в режиме запрета. Например, существует политика, чтобы убедиться, что в кластере выполняются только утвержденные образы контейнеров. Рассмотрите возможность создания собственных пользовательских инициатив. Объедините политики, применимые для рабочей нагрузки, в одно назначение.

Политика область относится к целевому объекту каждой инициативы политики и политики. Эталонная реализация, связанная с этой архитектурой, использует шаблон ARM для назначения политик группе ресурсов, в которой развертывается каждый кластер AKS. По мере роста объема глобального кластера она приводит к множеству повторяющихся политик. Вы также можете область политики в подписку Azure или группу управления Azure. Этот метод позволяет применять один набор политик ко всем кластерам AKS в область подписки и (или) всех подписок, найденных в группе управления.

При разработке политики для нескольких кластеров AKS рассмотрите следующие элементы:

• Политики, которые должны применяться глобально ко всем экземплярам AKS, можно применять к группе управления или подписке.
• Размещение каждого регионального кластера в собственной группе ресурсов позволяет политикам, применяемым к группе ресурсов для конкретного региона.

См . статью "Организация ресурсов Cloud Adoption Framework" для материалов, которые помогут вам создать стратегию управления политиками.

Развертывание рабочей нагрузки

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

При планировании развертывания рабочей нагрузки следует учитывать следующие элементы.

• Обобщайте развертывание, например диаграмму Helm, чтобы обеспечить возможность использования одной конфигурации развертывания в нескольких метках кластера.
• Используйте один конвейер непрерывного развертывания, настроенный для развертывания рабочей нагрузки во всех метках кластера.
• Укажите сведения о экземпляре с меткой в качестве параметров развертывания.
• Рассмотрим, как ведение журнала диагностики приложений и распределенная трассировка настроены для наблюдения на уровне приложений.

Доступность и отработка отказа

Важная мотивация выбора архитектуры Kubernetes с несколькими регионами — доступность служб. То есть, если компонент службы или службы становится недоступным в одном регионе, трафик должен направляться в регион, где доступна эта служба. Архитектура с несколькими регионами включает множество разных точек сбоя. В этом разделе рассматривается каждая из этих потенциальных точек сбоя.

Модули Pod приложений (региональные)

Объект развертывания Kubernetes используется для создания нескольких реплика pod (ReplicaSet). Если он недоступен, трафик направляется между оставшимися. Kubernetes ReplicaSet пытается сохранить указанное количество реплика и работает. Если один экземпляр выходит из строя, необходимо повторно создать новый экземпляр. Наконец, пробы активности можно использовать для проверка состояния приложения или процесса, выполняемого в модуле pod. Если служба не отвечает, проба активности удаляет модуль pod, который заставляет реплики Создать новый экземпляр.

Дополнительные сведения см. в разделе Kubernetes ReplicaSet.

Модули Pod приложений (глобальные)

Когда весь регион становится недоступным, модули pod в кластере больше не доступны для обслуживания запросов. В этом случае экземпляр Azure Front Door направляет весь трафик в оставшиеся здоровые регионы. Кластеры и модули pod Kubernetes в этих регионах будут продолжать обслуживать запросы.

Обратите внимание на эту ситуацию, чтобы компенсировать увеличение трафика или запросов к оставшемся кластеру. Несколько вещей, которые следует рассмотреть:

• Убедитесь, что сетевые и вычислительные ресурсы имеют правильный размер, чтобы поглощать любой внезапный рост трафика из-за отработки отказа региона. Например, при использовании Azure CNI убедитесь, что у вас есть подсеть, которая может поддерживать все IP-адреса pod с пиковой нагрузкой трафика.
• Использование горизонтального автомасштабирования pod для увеличения числа модулей pod реплика для компенсации повышенного регионального спроса.
• Используйте автомасштабирование кластера AKS, чтобы увеличить количество узлов экземпляров Kubernetes, чтобы компенсировать увеличение регионального спроса.

Дополнительные сведения см. в статье "Горизонтальное автомасштабирование pod" и автомасштабирование кластера AKS.

Пулы узлов Kubernetes (региональные)

Иногда локализованный сбой может возникать для вычислительных ресурсов, например, если питание становится недоступным для одной стойки серверов Azure. Чтобы защитить узлы AKS от создания единой точки регионального сбоя, используйте зоны доступности Azure. Использование зон доступности гарантирует, что узлы AKS в данной зоне доступности физически отделены от тех, которые определены в другой зоне доступности.

Дополнительные сведения см. в статье AKS и зоны доступности Azure.

Пулы узлов Kubernetes (глобальные)

В случае полного регионального сбоя Azure Front Door перенаправит трафик в оставшиеся и здоровые регионы. Опять же, обратите внимание на эту ситуацию, чтобы компенсировать увеличение трафика или запросов к оставшемся кластеру.

Подробные сведения см. в статье Azure Front Door.

Топология сети

Аналогично базовой эталонной архитектуре AKS, эта архитектура использует топологию сети с концентраторами. Помимо рекомендаций, указанных в базовой эталонной архитектуре AKS, рассмотрим следующие рекомендации.

• Реализуйте концентратор для каждого регионального экземпляра AKS, где одноранговые виртуальные сети концентратора.
• Перенаправь весь исходящий трафик через экземпляр Брандмауэр Azure, найденный в каждой региональной сети концентратора. Используйте политики диспетчера Брандмауэр Azure для управления политиками брандмауэра во всех регионах.
• Следуйте размеру IP-адресов, найденным в базовой эталонной архитектуре AKS, и укажите дополнительные IP-адреса для операций масштабирования узлов и модулей pod, если возникает региональный сбой.

Управление трафиком

С базовой эталонной архитектурой AKS трафик рабочей нагрузки направляется непосредственно в экземпляр Шлюз приложений Azure, а затем перенаправляется на ресурсы входящего трафика серверной части или AKS. При работе с несколькими кластерами клиентские запросы направляются через экземпляр Azure Front Door, который направляется в экземпляр Шлюз приложений Azure.

Скачайте файл Visio этой схемы.

1. Пользователь отправляет запрос на доменное имя (например https://contoso-web.azurefd.net), которое разрешается в экземпляр Azure Front Door. Этот запрос шифруется с помощью дикого сертификата карта (*.azurefd.net), выданного для всех поддоменов Azure Front Door. Экземпляр Azure Front Door проверяет запрос на соответствие политикам WAF, выбирает самую быструю серверную часть (на основе работоспособности и задержки) и использует общедоступный DNS для разрешения внутреннего IP-адреса (Шлюз приложений Azure экземпляра).

2. Front Door перенаправит запрос на выбранный соответствующий экземпляр Шлюз приложений, который служит точкой входа для региональной метки. Трафик передается через Интернет и шифруется Azure Front Door. Рассмотрим метод, чтобы убедиться, что экземпляр Шлюз приложений принимает трафик только из экземпляра Front Door. Одним из способов является использование группы безопасности сети в подсети, содержащей Шлюз приложений. Правила могут фильтровать входящий (или исходящий) трафик на основе таких свойств, как источник, порт, назначение. Свойство Source позволяет задать встроенный тег службы, указывающий IP-адреса для ресурса Azure. Эта абстракция упрощает настройку и обслуживание правила и отслеживание IP-адресов. Кроме того, рекомендуется использовать Front Door для внутреннего X-Azure-FDID заголовка, чтобы убедиться, что экземпляр Шлюз приложений принимает трафик только из экземпляра Front Door. Дополнительные сведения о заголовках Front Door см. в разделе "Поддержка протокола" для заголовков HTTP в Azure Front Door.

Рекомендации по общим ресурсам

Хотя основной целью этой эталонной архитектуры является наличие нескольких экземпляров Kubernetes, распределенных по нескольким регионам Azure, имеет смысл иметь некоторые общие ресурсы для всех экземпляров. Эталонная реализация AKS с несколькими регионами с помощью одного шаблона ARM для развертывания всех общих ресурсов, а затем другой для развертывания каждой региональной метки. В этом разделе описаны все эти общие ресурсы и рекомендации по использованию каждого из нескольких экземпляров AKS.

Реестр контейнеров

Реестр контейнеров Azure используется в этой эталонной архитектуре для предоставления служб образов контейнеров (pull). При работе с Реестр контейнеров Azure в развертывании кластера с несколькими регионами следует учитывать следующие элементы.

Географическая доступность 

Размещение реестра контейнеров в каждом регионе, в котором развернут кластер AKS, позволяет выполнять операции закрытия сети, обеспечивая быструю передачу надежных слоев изображений. Наличие нескольких конечных точек службы образов для обеспечения доступности при недоступности региональных служб. Использование функций георегистрации реестров контейнеров Azure позволяет управлять одним экземпляром реестра контейнеров реплика, реплика в нескольких регионах.

Эталонная реализация AKS с несколькими регионами создала один экземпляр реестра контейнеров и реплика этого экземпляра в каждом регионе кластера. Дополнительные сведения о Реестр контейнеров Azure реплика см. в Реестр контейнеров Azure геоза реплика Реестр контейнеров Azure.

Изображение с несколькими реплика ACR из портал Azure.

Доступ к кластеру

Для каждого экземпляра AKS требуется доступ для извлечения слоев изображений из Реестр контейнеров Azure. Существует несколько способов установления доступа к Реестр контейнеров Azure; эта эталонная архитектура использует управляемое удостоверение Azure для каждого кластера, которое затем предоставляет роль AcrPull в экземпляре реестра контейнеров. Дополнительные сведения и рекомендации по использованию управляемых удостоверений для доступа к реестру контейнеров см. в базовой эталонной архитектуре AKS.

Эта конфигурация определяется в шаблоне ARM с меткой кластера, чтобы каждый раз при развертывании новой метки новый экземпляр AKS был предоставлен доступ. Так как реестр контейнеров является общим ресурсом, убедитесь, что шаблон метки развертывания может использовать и использовать необходимые сведения, в этом случае идентификатор ресурса реестра контейнеров.

Azure Monitor

Функция аналитики контейнеров Azure Monitor — это рекомендуемое средство для мониторинга и понимания производительности и работоспособности рабочих нагрузок кластера и контейнеров. Аналитика контейнеров использует рабочую область Log Analytics для хранения данных журнала и метрик Azure Monitor для хранения числовых данных временных рядов. Метрики Prometheus также могут собираться Аналитика контейнера и отправлять данные в управляемую службу Azure Monitor для журналов Prometheus или Azure Monitor.

Вы также можете настроить параметры диагностики кластера AKS для сбора и анализа журналов ресурсов из компонентов уровня управления AKS и перенаправления в рабочую область Log Analytics.

Дополнительные сведения см. в базовой эталонной архитектуре AKS.

При рассмотрении мониторинга реализации между регионами, например этой эталонной архитектуры, важно учитывать связь между каждой меткой. В этом случае рассмотрим каждую метку компонента одной единицы (регионального кластера). Эталонная реализация AKS в нескольких регионах использует одну рабочую область Log Analytics, доступную каждому кластеру Kubernetes. Как и в других общих ресурсах, определите региональную метку для использования сведений об одной рабочей области Log Analytics и подключении каждого кластера к нему.

Теперь, когда каждый региональный кластер создает журналы диагностики в одну рабочую область Log Analytics, эти данные вместе с метриками ресурсов можно использовать для более простого создания отчетов и панелей мониторинга, представляющих всю часть глобального кластера.

Azure Front Door

Azure Front door используется для балансировки нагрузки и маршрутизации трафика в каждый кластер AKS. Azure Front Door позволяет выполнить глобальную маршрутизацию уровня семь уровней, оба из которых необходимы для этой эталонной архитектуры.

Конфигурация кластера

Как добавляются региональные экземпляры AKS, Шлюз приложений, развернутые вместе с кластером Kubernetes, должны быть зарегистрированы в качестве серверной части Front Door для правильной маршрутизации. Для этой операции требуется обновление инфраструктуры в качестве ресурсов кода. Кроме того, эту операцию можно отделить от конфигурации развертывания и управлять с помощью таких средств, как Azure CLI. В конвейере развертывания включенных ссылочных реализаций используется отдельный шаг Azure CLI для этой операции.

Сертификаты

Front Door не поддерживает самозаверяемые сертификаты даже в средах разработки и тестирования. Чтобы включить трафик HTTPS, необходимо создать СЕРТИФИКАТ TLS/SSL, подписанный центром сертификации (ЦС). Эталонная реализация использует Certbot для создания сертификата Центра шифрования X3. При планировании рабочего кластера используйте предпочтительный метод организации для приобретения сертификатов TLS.

Сведения о других центрах сертификации, поддерживаемых Front Door, см. в разделе "Разрешенные центры сертификации" для включения пользовательских HTTPS в Azure Front Door.

Доступ к кластеру и удостоверение

Как описано в базовой эталонной архитектуре AKS, рекомендуется использовать идентификатор Microsoft Entra в качестве поставщика удостоверений доступа к кластерам. Затем группы Microsoft Entra можно использовать для управления доступом к ресурсам кластера.

При управлении несколькими кластерами необходимо решить схему доступа. Возможные варианты:

• Создайте глобальную группу доступа на уровне кластера, где члены могут обращаться ко всем объектам в каждом экземпляре Kubernetes в кластере. Этот параметр обеспечивает минимальные потребности администрирования; однако она предоставляет значительные привилегии любому участнику группы.
• Создайте отдельную группу доступа для каждого экземпляра Kubernetes, который используется для предоставления доступа к объектам в отдельном экземпляре кластера. С помощью этого параметра административные издержки увеличиваются; однако он также обеспечивает более детализированный доступ к кластеру.
• Определите детализированные элементы управления доступом для типов объектов Kubernetes и пространств имен и сопоставляйте результаты со структурой группы каталогов Azure. С помощью этого параметра административные издержки значительно увеличиваются; однако он предоставляет подробный доступ не только к каждому кластеру, но и пространствам имен и APIS Kubernetes, найденным в каждом кластере.

При включенной эталонной реализации для доступа администратора создаются две группы Microsoft Entra. Эти группы указываются во время развертывания метки кластера с помощью файла параметров развертывания. Члены каждой группы имеют полный доступ к соответствующей метки кластера.

Дополнительные сведения об управлении доступом к кластеру AKS с помощью идентификатора Microsoft Entra см. в разделе интеграции Microsoft Entra AKS.

Данные, состояние и кэш

При использовании глобально распределенного кластера экземпляров AKS рассмотрите архитектуру приложения, процесса или других рабочих нагрузок, которые могут выполняться в кластере. Так как рабочая нагрузка на основе состояния распространяется по всему кластеру, ей потребуется доступ к хранилищу состояний? Если процесс повторно создан в другом месте кластера из-за сбоя, будет ли рабочая нагрузка или процесс продолжать иметь доступ к зависимому хранилищу состояний или решению кэширования? Состояние можно достичь различными способами; однако он может быть сложным в одном кластере Kubernetes. Сложность увеличивается при добавлении в несколько кластеризованных экземпляров Kubernetes. Из-за проблем с региональным доступом и сложностью рассмотрите возможность разработки приложений для использования глобально распределенной службы хранилища состояний.

Реализация ссылки на несколько кластеров не включает демонстрацию или конфигурацию для проблем с состоянием. Если вы запускаете приложения в кластеризованных экземплярах AKS, рассмотрите возможность разработки рабочей нагрузки для использования глобально распределенной службы данных, например Azure Cosmos DB. Azure Cosmos DB — это глобально распределенная система базы данных, которая позволяет считывать и записывать данные из локальных реплик базы данных. Дополнительные сведения см. в разделе Azure Cosmos DB.

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

Оптимизация затрат

Используйте калькулятор цен Azure для оценки затрат на службы, используемые в архитектуре. Другие рекомендации описаны в разделе "Оптимизация затрат" в Microsoft Azure Well-Architected Framework и конкретные параметры конфигурации оптимизации затрат в статье "Оптимизация затрат ".

Рассмотрите возможность включения анализа затрат AKS для распределения затрат на инфраструктуру детализированного кластера определенными конструкциями Kubernetes.

Следующие шаги

• Зоны доступности AKS
• Диспетчер флота Azure Kubernetes
• Подготовка геореплицированного реестра контейнеров Azure
• Сопряженные регионы Azure

Связанные ресурсы

• Обзор Azure Well-Architected Framework для Служба Azure Kubernetes (AKS)
• Базовая архитектура для кластера Служба Azure Kubernetes (AKS)
• Конвейер CI/CD для рабочих нагрузок на основе контейнера
• Интеграция Microsoft Entra с AKS
• Документация по Azure Front Door
• Документация по Azure Cosmos DB