Обзор пассивного холодного решения для Служба Azure Kubernetes (AKS)
При создании приложения в Служба Azure Kubernetes (AKS) и выборе региона Azure во время создания ресурсов это однорегионное приложение. Когда регион становится недоступным во время аварии, приложение также становится недоступным. Если вы создаете идентичное развертывание в дополнительном регионе Azure, приложение становится менее подверженным аварии в одном регионе, что гарантирует непрерывность бизнес-процессов и любые данные реплика в регионах позволяют восстановить последнее состояние приложения.
В этом руководстве описывается пассивное холодное решение для AKS. В этом решении мы развертываем два независимых и идентичных кластера AKS в двух парных регионах Azure с только одним кластером, активно обслуживающим трафик, если приложение необходимо.
Примечание.
Следующая практика была рассмотрена внутренне и проверена в сочетании с нашими партнерами Майкрософт.
Обзор решения пассивного холодного режима
В этом подходе мы развертываем два независимых кластера AKS в двух регионах Azure. Когда приложение необходимо, мы активируем пассивный кластер для получения трафика. Если пассивный кластер выходит из строя, необходимо вручную активировать холодный кластер, чтобы взять на себя поток трафика. Это условие можно задать с помощью ручного ввода каждый раз или указать определенное событие.
Сценарии и конфигурации
Это решение лучше всего реализуется в качестве рабочей нагрузки "использование по мере необходимости", которая полезна для сценариев, требующих выполнения рабочих нагрузок в определенное время суток или запуска по запросу. Примеры вариантов использования для пассивного холодного подхода:
- Производственная компания, которая должна выполнять сложное и ресурсоемкое моделирование на большом наборе данных. В этом случае пассивный кластер расположен в облачном регионе, который предлагает высокопроизводительные вычисления и службы хранилища. Пассивный кластер используется только в том случае, если имитация активируется пользователем или по расписанию. Если кластер не работает при активации, холодный кластер можно использовать в качестве резервной копии, а рабочая нагрузка может выполняться на нем.
- Государственное агентство, которое должно поддерживать резервную копию своих критически важных систем и данных в случае кибератаки или стихийных бедствий. В этом случае пассивный кластер находится в безопасном и изолированном расположении, недоступном для общественности.
Компоненты
Решение для аварийного восстановления пассивного холодного режима использует множество служб Azure. В этом примере архитектуры используются следующие компоненты:
Несколько кластеров и регионов. Развертывание нескольких кластеров AKS в отдельном регионе Azure. Если приложение необходимо, пассивный кластер активируется для получения сетевого трафика.
Key Vault: вы подготавливаете Azure Key Vault в каждом регионе для хранения секретов и ключей.
Log Analytics: региональные экземпляры Log Analytics хранят региональные сетевые метрики и журналы диагностики. Общий экземпляр хранит метрики и журналы диагностики для всех экземпляров AKS.
Периферийная пара концентратора: пара "периферийный концентратор" развертывается для каждого регионального экземпляра AKS. политики диспетчера Брандмауэр Azure управляют правилами брандмауэра в каждом регионе.
Реестр контейнеров. Образы контейнеров для рабочей нагрузки хранятся в управляемом реестре контейнеров. В этом решении для всех экземпляров Kubernetes в кластере используется один экземпляр Реестр контейнеров Azure. Гео-реплика для Реестр контейнеров 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 предлагает возможность создания эксперимента хаоса в кластере.
Следующие шаги
Если вы рассматриваете другое решение, ознакомьтесь со следующими статьями: