Общие сведения о рекомендуемом решении высокого уровня доступности для Служба Azure Kubernetes (AKS)
При создании приложения в Служба Azure Kubernetes (AKS) и выборе региона Azure во время создания ресурсов это однорегионное приложение. В случае аварии, которая приводит к недоступности региона, приложение также становится недоступным. Если вы создаете идентичное развертывание в дополнительном регионе Azure, приложение становится менее подверженным аварии в одном регионе, что гарантирует непрерывность бизнес-процессов и любые данные реплика в регионах позволяют восстановить последнее состояние приложения.
Хотя существует несколько шаблонов, которые могут обеспечить возможность восстановления для решения AKS, в этом руководстве описано рекомендуемое решение для обеспечения высокого уровня доступности active для AKS. В этом решении мы развертываем два независимых и идентичных кластера AKS в двух парных регионах Azure с обоими кластерами, активно обслуживающими трафик.
Примечание.
Следующий вариант использования можно рассматривать как стандартную практику в AKS. Он был рассмотрен внутренне и проверен вместе с нашими партнерами Майкрософт.
Общие сведения о решении высокого уровня доступности active
Это решение основано на двух идентичных кластерах AKS, настроенных для активного обслуживания трафика. Вы размещаете глобальный диспетчер трафика, например Azure Front Door, перед двумя кластерами для распределения трафика между ними. Кластеры должны последовательно настраивать для размещения экземпляра всех приложений, необходимых для работы решения.
Зоны доступности — это еще один способ обеспечить высокий уровень доступности и отказоустойчивость кластера AKS в одном регионе. Зоны доступности позволяют распределять узлы кластера между несколькими изолированными расположениями в регионе Azure. Таким образом, если одна зона исчезнет из-за сбоя питания, сбоя оборудования или сетевой проблемы, кластер может продолжать работать и обслуживать приложения. Зоны доступности также повышают производительность и масштабируемость кластера, уменьшая задержку и состязание между узлами. Чтобы настроить зоны доступности для кластера AKS, необходимо указать номера зон при создании или обновлении пулов узлов. Дополнительные сведения см. в статье "Что такое зоны доступности Azure"?
Примечание.
Многие регионы поддерживают зоны доступности. Рассмотрите возможность использования регионов с зонами доступности для повышения устойчивости и доступности рабочих нагрузок. Дополнительные сведения см. в статье "Восстановление после нарушения работы службы на уровне региона".
Сценарии и конфигурации
Это решение лучше всего реализуется при размещении приложений без отслеживания состояния и (или) с другими технологиями, которые также развертываются в обоих регионах, например горизонтальное масштабирование. В сценариях, когда размещенное приложение зависит от ресурсов, таких как базы данных, которые активно находятся в одном регионе, рекомендуется вместо этого реализовать активно-пассивное решение для потенциальной экономии затрат, так как активный-пассивный имеет больше времени простоя, чем активный-активный.
Компоненты
Решение высокого уровня доступности active использует множество служб Azure. В этом разделе рассматриваются только компоненты, уникальные для этой архитектуры с несколькими кластерами. Дополнительные сведения о оставшихся компонентах см. в базовой архитектуре AKS.
Несколько кластеров и регионов. Развертывание нескольких кластеров AKS в отдельном регионе Azure. Во время обычных операций конфигурация Azure Front Door направляет сетевой трафик между всеми регионами. Если один регион становится недоступным, трафик направляется в регион с самым быстрым временем загрузки для пользователя.
Сеть концентратора на регион: для каждого регионального экземпляра AKS развертывается пара центральной сети. политики диспетчера Брандмауэр 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 и получать постоянный доступ к изображениям, даже если регион испытывает сбой.
Процесс отработки отказа
Если компонент службы или службы становится недоступным в одном регионе, трафик должен направляться в регион, где доступна эта служба. Архитектура с несколькими регионами включает множество разных точек сбоя. В этом разделе рассматриваются потенциальные точки сбоя.
Модули 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 предлагает возможность создания эксперимента хаоса в кластере.
Следующие шаги
Если вы рассматриваете другое решение, ознакомьтесь со следующими статьями: