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

При создании приложения в Служба Azure Kubernetes (AKS) и выборе региона Azure во время создания ресурсов это однорегионное приложение. Когда регион становится недоступным во время аварии, приложение также становится недоступным. Если вы создаете идентичное развертывание в дополнительном регионе Azure, приложение становится менее подверженным аварии в одном регионе, что гарантирует непрерывность бизнес-процессов и любые репликации данных в регионах позволяют восстановить последнее состояние приложения.

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

Примечание.

Следующая практика была рассмотрена внутренне и проверена в сочетании с нашими партнерами Майкрософт.

Общие сведения о активно-пассивном решении

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

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

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

Компоненты

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

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

Настроенная приоритетность кластера: вы задаете уровень приоритета между 1–5 для каждого кластера (с 1 приоритетом и 5 — самым низким приоритетом). Можно задать для нескольких кластеров один и тот же уровень приоритета и указать вес для каждого кластера. Если основной кластер становится недоступным, трафик автоматически направляется в следующий регион, выбранный в Azure Front Door. Весь трафик должен пройти через Azure Front Door, чтобы эта система работала.

Azure Front Door: балансирует нагрузку и маршрутизирует трафик к экземпляру Azure Application Gateway в основном регионе (кластер должен быть помечен приоритетом 1). В случае сбоя региона служба перенаправляет трафик в следующий кластер в списке приоритетов.

Дополнительные сведения см. в разделе "Маршрутизация трафика на основе приоритета".

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

Key Vault: вы подготавливаете Azure Key Vault в каждом регионе для хранения секретов и ключей.

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

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

Процесс отказоустойчивости

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

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

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

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

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

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

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

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

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

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

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

Стратегия тестирования отработки отказа

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

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

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

  • Last updated on