Общие сведения о рекомендуемом решении высокого уровня доступности для Azure Kubernetes Service (AKS)

Когда вы создаёте приложение в Azure Kubernetes Service (AKS) и при создании ресурса выбираете регион Azure, приложение является однорегиональным. В случае аварии, которая приводит к недоступности региона, приложение также становится недоступным. Если вы создадите идентичное развертывание во вторичном регионе Azure, ваше приложение станет менее уязвимым к сбою или катастрофе в одном регионе, что поможет обеспечить непрерывность бизнеса, а репликация данных между регионами позволит восстановить последнее состояние приложения.

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

Примечание

Следующий вариант использования можно рассматривать как стандартную практику в AKS. Он был рассмотрен внутренне и проверен вместе с нашими Microsoft партнерами.

Обзор решения высокой доступности по схеме активный-активный

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

Зоны доступности — это еще один способ обеспечить высокий уровень доступности и отказоустойчивость кластера AKS в одном регионе. Зоны доступности позволяют распределять узлы кластера по нескольким изолированным местоположениям в пределах региона Azure. Таким образом, если одна зона исчезнет из-за сбоя питания, сбоя оборудования или сетевой проблемы, кластер может продолжать работать и обслуживать приложения. Зоны доступности также повышают производительность и масштабируемость кластера, уменьшая задержку и состязание между узлами. Чтобы настроить зоны доступности для кластера AKS, необходимо указать номера зон при создании или обновлении пулов узлов. Дополнительные сведения см. в разделе "Что такое зоны доступности Azure"?

Примечание

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

Сценарии и конфигурации

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

Компоненты

Решение архитектуры «активный — активный» для высокой доступности использует множество служб Azure. В этом разделе рассматриваются только компоненты, уникальные для этой архитектуры с несколькими кластерами. Дополнительные сведения о оставшихся компонентах см. в базовой архитектуре AKS.

Несколько кластеров и регионов: Вы развертываете несколько кластеров AKS, каждый в отдельном регионе Azure. Во время обычных операций конфигурация Azure Front Door направляет сетевой трафик между всеми регионами. Если один регион становится недоступным, трафик направляется в регион с самым быстрым временем загрузки для пользователя.

Сеть типа «hub-and-spoke» для каждого региона: для каждого регионального экземпляра AKS развертывается пара сетей типа «hub-and-spoke». Диспетчер брандмауэра Azure политики управляют политиками брандмауэра во всех регионах.

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

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

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

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

Процесс переключения на резервный сервер

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

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

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

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

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

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

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

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

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

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

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

Стратегия тестирования аварийного переключения

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

Дальнейшие действия

Если вы рассматриваете другое решение, ознакомьтесь со следующими статьями:

  • Последнее обновление: