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

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

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

Архитектура

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

Компоненты

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

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

Альтернативы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вас есть множество вариантов для развертывания кластера в Azure Kubernetes Service. Портал 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. Эта конфигурация проста, так как каждый экземпляр кластера четко определен в конвейере развертывания. Эта конфигурация включает некоторые административные издержки при добавлении и удалении кластеров из развертывания.

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

После создания кластера его необходимо зарегистрировать во флоте в качестве участника. Этот шаг можно выполнить, развернув ресурс Resource Manager типа Microsoft.ContainerService/fleets/members, который ссылается на идентификатор ресурса кластера-члена. После регистрации кластера-члена в флоте его можно добавить для обновления запусков и использовать другие возможности флота, которые вы настроили.

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

Инициализация кластера

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

Аналогично развертыванию, конфигурации начальной загрузки могут стать сложными для управления несколькими экземплярами Kubernetes вручную. Если вы используете центральный кластер с Azure Kubernetes Fleet Manager, вы можете развернуть некоторые начальные конфигурации, такие как пространства имён, по всему флоту. Однако для других компонентов начальной загрузки требуется другой подход к развертыванию.

Следует рассмотреть один из следующих вариантов применения конфигурации и политики Bootstrap в масштабе.

GitOps

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

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

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

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

Политика Azure

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

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

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

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

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

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

Регистрация флота

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

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

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

Существует несколько подходов к развертыванию, которые можно рассмотреть, в том числе:

• Конвейеры: Для сценариев, имеющего только несколько кластеров и относительно простых развертываний, часто лучше всего использовать легкие специализированные конвейеры для непрерывной доставки (CD).

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

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

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

• GitOps: По мере дальнейшего развития инфраструктуры внедрение стратегии на основе GitOps становится все более полезной. GitOps позволяет использовать декларативные, аудируемые и механизмы развертывания на основе pull-запросов, обеспечивая масштабируемость, управление и командную работу. Переход к этой модели особенно рекомендуется при управлении большим и динамическим парком кластеров в нескольких регионах.

  Дополнительные сведения см. в статье GitOps для службы Azure Kubernetes.

Чтобы решить, какой подход подходит для решения, рассмотрите следующие вопросы:

• Вы ожидаете, что количество кластеров останется фиксированным или увеличится со временем? Если вы планируете расширить количество кластеров или настроить количество кластеров динамически, это может быстро усложнить поддержание конфигурации каждого кластера в конвейерах развертывания.
• Сколько единиц, готовых к развертыванию, вам нужно управлять? Если у вас есть только несколько монолитных приложений, вам потребуется только несколько внедрений. Если вы используете архитектуру распределенных микрослужб, имеете много рабочих нагрузок или и то, и другое, это число может быстро увеличиться до сотен единиц развертывания. Создание конвейера для каждого развертывания может стать нецелесообразным.
• Какие стратегии развертывания вам нужны? Распространенные стратегии включают постепенные обновления, сине-зеленые развертывания и канареечные развертывания. Некоторые подходы к развертыванию должны предусматривать "время стабилизации" между развертываниями, с тщательным мониторингом для выявления любых регрессий, вызванных развертыванием. Оцените каждый подход к развертыванию, чтобы определить, поддерживает ли она определенные требования.
• В рамках каких ограничений безопасности сети работают ваши кластеры? Диспетчер флотов Azure Kubernetes работает в топологии кластеров с концентраторами и периферийными устройствами, где кластеры-члены поддерживают исходящие подключения к центральному кластеру для выверки рабочих нагрузок и мониторинга пульса. Для стратегии на основе GitOps требуется, чтобы участвующие кластеры устанавливали исходящий доступ к репозиторию Git. При использовании конвейеров агент конвейера обычно требует подключения к каждому кластеру для выполнения операций развертывания.

Независимо от того, как вы будете управлять развертываниями, стремитесь обобщить каждое развертывание, например с диаграммой Helm, чтобы обеспечить возможность использования одной конфигурации развертывания в нескольких кластерах (меток). Кроме того, рассмотрите возможность настройки журналов диагностики приложений и распределенной трассировки для наблюдения на уровне приложений в каждом кластере.

Надёжность

Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Дополнительные сведения см. в контрольном списке проверки проекта на надежность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, имеет смысл совместно использовать некоторые ресурсы во всех регионах. Одним из способов является использование одного файла Bicep для развертывания всех общих ресурсов, а затем другого для развертывания каждой региональной метки. В этом разделе описаны эти общие ресурсы и рекомендации по использованию каждого из них в нескольких экземплярах AKS.

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

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

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

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

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

Изображение, показывающее несколько реплик реестра контейнеров Azure из портала Azure.

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

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

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

Azure Monitor

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

Azure Front Door (облачное сетевое решение от Microsoft)

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 для каждого шлюза приложений.

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

Безопасность

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

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

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

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

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

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

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

Безопасность ресурсов флота

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

Если ваш флот использует кластер концентратора, рассмотрите следующие дополнительные рекомендации.

• Оцените назначения ролей, которые вы создаёте в кластере концентратора (назначения ролей плоскости данных). Эти назначения ролей предоставляют доступ к ресурсам Kubernetes, создаваемым флотом. Ограничьте назначения ролей для отдельного пространства имен Kubernetes, где это возможно.
• Используйте кластер частного концентратора для ограничения подключения к Интернету. Однако убедитесь, что сетевая архитектура позволяет кластерам-членам обращаться к кластеру концентратора.

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

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

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

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

Эффективность работы

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

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

Мониторинг кластеров и рабочих нагрузок

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

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

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

Дополнительные сведения о настройке рабочих областей Azure Monitor в среде с несколькими кластерами см. в статье Azure Monitor.

Мониторинг операций флота

Когда диспетчер флота оркеструет запуск обновления, вы можете отслеживать ход выполнения обновления по мере его продвижения через кластеры. Данные хранятся в Azure Resource Graph и могут быть экспортированы в Azure Monitor для оповещения и хранения.

Если вы решили использовать Fleet Manager для распространения рабочей нагрузки, вы можете отслеживать развертывание с помощью портала Azure или kubectl.

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

Применение обновлений по всему флоту

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

Дополнительные сведения см. в статье Об обновлении образов Kubernetes и узлов в нескольких кластерах членов.

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

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

Эта оценка цен 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