Модели развертывания с несколькими регионами для службы Azure Kubernetes (AKS)

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

AKS предоставляет ряд возможностей, поддерживающих как высокий уровень доступности, так и аварийное восстановление (АВАРИЙНОе восстановление) для кластера и приложений, работающих в AKS. Дополнительные сведения о том, как AKS поддерживает требования к надежности, см. в статье "Надежность" в AKS.

Соображения

Ниже приведены некоторые важные аспекты при реализации моделей развертывания с несколькими регионами в AKS:

Региональные и глобальные ресурсы

Региональные ресурсы подготавливаются в рамках метки развертывания в одном регионе Azure. Эти ресурсы не имеют общего доступа к ресурсам в других регионах, и они могут быть независимо удалены или реплицированы в другие регионы. Дополнительные сведения см. в разделе "Региональные ресурсы".

Глобальные ресурсы делятся временем существования системы, и они могут быть глобально доступны в контексте развертывания с несколькими регионами. Дополнительные сведения см. в разделе "Глобальные ресурсы".

Глобальная балансировка нагрузки

Глобальные службы балансировки нагрузки распределяют трафик между региональными внутренними серверами, облаками или гибридными локальными службами. Эти службы направляют трафик конечных пользователей на ближайший доступный сервер. Они также реагируют на изменения надежности службы или производительности, чтобы повысить доступность и производительность. Следующие службы Azure обеспечивают глобальную балансировку нагрузки:

• Azure Front Door
• Диспетчер трафика Azure
• Azure Load Balancer между регионами
• Диспетчер флота Azure Kubernetes

Определение роли

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

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

Реализации модели развертывания с несколькими регионами

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

Модель развертывания с высоким уровнем доступности active

В модели развертывания высокого уровня доступности (HA) активной активности у вас есть два независимых кластера AKS, развернутых в двух разных регионах Azure (как правило, в парных регионах, таких как Центральная Канада и Восточная Канада или восточная часть США 2 и Центральная ЧАСТЬ США), которые активно обслуживают трафик.

В этом примере архитектуры:

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

Чтобы создать модель развертывания active-active в AKS, выполните следующие действия.

1. Создайте два идентичных развертывания в двух разных регионах Azure.

2. Создайте два экземпляра веб-приложения.

3. Создайте профиль Azure Front Door со следующими ресурсами:

   • Конечная точка.
   • Две группы источников, каждая из которых имеет приоритет одного.
   • Маршрут.

4. Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door. 5 Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.

5. Развертывание кода в обоих веб-приложениях с непрерывным развертыванием.

Дополнительные сведения см. в обзоре рекомендуемого решения с высоким уровнем доступности active для AKS.

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

В модели развертывания аварийного восстановления активного пассивного восстановления (DR) у вас есть два независимых кластера AKS, развернутых в двух разных регионах Azure (как правило, в парных регионах, таких как Центральная Канада и Восточная Канада или восточная часть США 2 и центральная часть США), которые активно обслуживают трафик. Только один из кластеров активно обслуживает трафик в любое время. Другой кластер содержит те же данные конфигурации и приложения, что и активный кластер, но не принимает трафик, если не направляется диспетчером трафика.

В этом примере архитектуры:

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

Чтобы создать модель активно-пассивного развертывания в AKS, выполните следующие действия.

1. Создайте два идентичных развертывания в двух разных регионах Azure.

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

3. Создайте два экземпляра веб-приложения с одним на каждом кластере.

4. Создайте профиль Azure Front Door со следующими ресурсами:

   • Конечная точка.
   • Группа источников с приоритетом одного для основного региона.
   • Вторая группа источников с приоритетом двух для дополнительного региона.
   • Маршрут.

5. Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door.

6. Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.

7. Разверните код в обоих веб-приложениях с непрерывным развертыванием.

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

Модель развертывания отработки отказа пассивного холодного режима

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

В этом примере архитектуры:

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

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

1. Создайте два идентичных развертывания в разных зонах или регионах.
2. Настройте правила автомасштабирования для дополнительного приложения, чтобы оно масштабируется до того же числа экземпляров, что и основной, когда основной регион становится неактивным. В то время как неактивный, его не нужно масштабировать, что помогает сократить затраты.
3. Создайте два экземпляра веб-приложения с одним на каждом кластере.
4. Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.
5. Задайте условие при активации холодного кластера. При необходимости можно использовать подсистему балансировки нагрузки.

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

Дополнительные сведения см. в следующих статьях:

• Надежность в AKS
• Сведения о резервном копировании AKS с помощью Azure Backup (предварительная версия)
• Резервное копирование AKS с помощью Azure Backup (предварительная версия)
• Непрерывность бизнес-процессов, высокий уровень доступности и аварийное восстановление