Бөлісу құралы:

Общие сведения о решении аварийного восстановления активного пассивного аварийного восстановления для Служба 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 Front Door и маршрутизирует трафик к экземпляру Шлюз приложений Azure в основном регионе (кластер должен быть помечен приоритетом 1). В случае сбоя региона служба перенаправляет трафик в следующий кластер в списке приоритетов.

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

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

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

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

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

Процесс отработки отказа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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