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

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

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

Архитектура

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

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

Компоненты

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

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

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

В этой эталонной архитектуре используются два шаблона облачного проектирования:

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

Рекомендации по шаблону геодокумов

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

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

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

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

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

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

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

Это решение представляет собой топологию с несколькими кластерами и несколькими регионами без включения расширенного оркестратора для обработки всех кластеров в составе единого парка. При увеличении числа кластеров рекомендуется зарегистрировать участников в 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 открывается возможность неправильной настройки из-за пропущенных шагов или недоступных параметров конфигурации. Развертывание и настройка многих кластеров с помощью портала — это длительный процесс, требующий фокуса одного или нескольких инженеров. При использовании Azure CLI или Azure PowerShell можно создать повторяемый и автоматизированный процесс с помощью средств командной строки. Однако ответственность за идемпотентность, управление сбоем развертывания и восстановление сбоев зависит от вас и скриптов, которые вы создаете.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Политика Azure

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

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

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

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

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

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

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

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

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

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

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

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

Сбои модуля pod приложения

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

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

Сбои оборудования центра обработки данных

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

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

Сбои региона Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure Monitor

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

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

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

Azure Front Door

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

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

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

Сертификаты

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

Эталонная реализация использует Certbot для создания сертификата Центра шифрования X3 для каждого шлюза приложений. Процесс создания сертификатов требует развертывания некоторых временных ресурсов Azure. Дополнительные сведения о том, как эталонная реализация создает сертификаты TLS, см. в разделе " Создание сертификатов для общедоступного IP-адреса Azure" с примером префикса DNS.

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

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

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

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

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

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

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

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

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

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