Поделиться через

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

  • Статья

При создании приложений и управлении ими в облаке всегда возникает риск сбоя и аварий. Чтобы обеспечить непрерывность бизнес-процессов (BC), необходимо спланировать высокий уровень доступности (HA) и аварийное восстановление (аварийное восстановление).

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

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

Обзор технологий

Кластер Kubernetes разделяется на два компонента:

  • Уровень управления, предоставляющий основные службы Kubernetes и оркестрацию рабочих нагрузок приложений, и
  • Узлы , которые выполняют рабочие нагрузки приложения.

Схема компонентов уровня управления Kubernetes и узлов.

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

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

Чтобы запускать приложения и вспомогательные службы, вам нужен узел Kubernetes. Кластер AKS содержит как минимум один узел, а именно виртуальную машину Azure, которая выполняет компоненты узла Kubernetes и среду выполнения контейнера. Размер виртуальной машины Azure для узлов определяет ЦП, память, размер и доступный тип хранилища (например, высокопроизводительный SSD или обычный HDD). Спланируйте размер виртуальной машины и хранилища, независимо от того, требуются ли приложения большие объемы ЦП и памяти или высокопроизводительного хранилища. В AKS образ виртуальной машины для узлов кластера основан на Ubuntu Linux, Azure Linux или Windows Server 2022. Когда вы создаете кластер AKS или масштабируете количество узлов, платформа Azure создает и настраивает необходимое количество виртуальных машин.

Дополнительные сведения о компонентах кластера и рабочей нагрузки в AKS см . в основных понятиях Kubernetes для AKS.

Важные замечания

Региональные и глобальные ресурсы

Региональные ресурсы подготавливаются в рамках метки развертывания в одном регионе Azure. Эти ресурсы не имеют общего доступа к ресурсам в других регионах, и они могут быть независимо удалены или реплицированы в другие регионы. Дополнительные сведения см. в разделе "Региональные ресурсы".

Глобальные ресурсы делятся временем существования системы, и они могут быть глобально доступны в контексте развертывания с несколькими регионами. Дополнительные сведения см. в разделе "Глобальные ресурсы".

Целевые показатели восстановления

Полный план аварийного восстановления должен указывать бизнес-требования для каждого процесса, реализуемого приложением:

  • Цель точки восстановления (RPO) — это максимальная длительность допустимой потери данных. RPO измеряется в единицах времени, таких как минуты, часы или дни.
  • Цель времени восстановления (RTO) — это максимальная продолжительность допустимого простоя, с временем простоя , определенным спецификацией. Например, если допустимое время простоя в аварии составляет восемь часов, то RTO составляет восемь часов.

Зоны доступности

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

Зональная устойчивость

Кластеры AKS устойчивы к зональным сбоям. Если зона завершается ошибкой, кластер продолжает работать в оставшихся зонах. Плоскость управления кластера и узлы распределяются по зонам, а платформа Azure автоматически обрабатывает распределение узлов. Дополнительные сведения см. в статье о зональной устойчивости AKS.

Балансировка нагрузки

глобальная балансировка нагрузки.

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

Региональная балансировка нагрузки

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

Наблюдаемость

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

Определение роли

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

  • планировать кластеры AKS в нескольких регионах;
  • Маршрутизация трафика между несколькими кластерами с помощью Диспетчер трафика Azure.
  • использовать георепликацию для реестров образов контейнеров;
  • планировать состояния приложений в нескольких кластерах;
  • реплицировать хранилище в нескольких регионах.

Реализации модели развертывания

Модель развертывания Плюсы Минусы
Шаблон "активный — активный" • Нет потери данных или несоответствия во время отработки отказа
• Высокая устойчивость
• Улучшение использования ресурсов с более высокой производительностью		 • Сложная реализация и управление
• Более высокая стоимость
• Требуется подсистема балансировки нагрузки и форма маршрутизации трафика
Активный пассивный • Упрощенная реализация и управление
• Более низкая стоимость
• Не требуется подсистема балансировки нагрузки или диспетчер трафика		 • Потенциал потери данных или несоответствия во время отработки отказа
• Более длительное время восстановления и время простоя
• Недостаточное использование ресурсов
Пассивный холодный • Наименьшая стоимость
• Не требует синхронизации, репликации, подсистемы балансировки нагрузки или диспетчера трафика
• Подходит для низкоприоритетных некритических рабочих нагрузок		 • Высокий риск потери данных или несоответствия во время отработки отказа
• Максимальное время восстановления и время простоя
• Требуется ручное вмешательство для активации кластера и активации резервного копирования

Модель развертывания с высоким уровнем доступности active

В модели развертывания высокого уровня доступности (HA) активной активности у вас есть два независимых кластера AKS, развернутых в двух разных регионах Azure (как правило, в парных регионах, таких как Центральная Канада и Восточная Канада или восточная часть США 2 и Центральная ЧАСТЬ США), которые активно обслуживают трафик.

В этом примере архитектуры:

  • Вы развертываете два кластера AKS в отдельных регионах Azure.
  • Во время обычных операций маршруты сетевого трафика между обоими регионами. Если один регион становится недоступным, трафик автоматически направляется в регион, ближайший к пользователю, который выдал запрос.
  • Для каждого регионального экземпляра AKS существует развернутая пара "периферийный концентратор". политики диспетчера Брандмауэр Azure управляют правилами брандмауэра в регионах.
  • Azure Key Vault подготавливается в каждом регионе для хранения секретов и ключей.
  • Баланс нагрузки Azure Front Door и маршрутизирует трафик в региональный экземпляр Шлюз приложений Azure, который находится перед каждым кластером AKS.
  • Региональные экземпляры Log Analytics хранят региональные сетевые метрики и журналы диагностики.
  • Образы контейнеров для рабочей нагрузки хранятся в управляемом реестре контейнеров. Для всех экземпляров Kubernetes в кластере используется один Реестр контейнеров Azure. Георепликация для Реестр контейнеров Azure позволяет реплицировать образы в выбранные регионы Azure и обеспечивает постоянный доступ к изображениям, даже если регион испытывает сбой.

Чтобы создать модель развертывания active-active в AKS, выполните следующие действия.

  1. Создайте два идентичных развертывания в двух разных регионах Azure.

  2. Создайте два экземпляра веб-приложения.

  3. Создайте профиль Azure Front Door со следующими ресурсами:

    • Конечная точка.
    • Две группы источников, каждая из которых имеет приоритет одного.
    • Маршрут.

  4. Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door. 5. Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.

  5. Развертывание кода в обоих веб-приложениях с непрерывным развертыванием.

Дополнительные сведения см. в обзоре рекомендуемого решения с высоким уровнем доступности active для AKS.

Модель развертывания аварийного восстановления с активным пассивным восстановлением

В модели развертывания аварийного восстановления активного пассивного восстановления (DR) у вас есть два независимых кластера AKS, развернутых в двух разных регионах Azure (как правило, в парных регионах, таких как Центральная Канада и Восточная Канада или восточная часть США 2 и центральная часть США), которые активно обслуживают трафик. Только один из кластеров активно обслуживает трафик в любое время. Другой кластер содержит те же данные конфигурации и приложения, что и активный кластер, но не принимает трафик, если не направляется диспетчером трафика.

В этом примере архитектуры:

  • Вы развертываете два кластера AKS в отдельных регионах Azure.
  • Во время обычных операций сетевой трафик направляется в основной кластер AKS, который устанавливается в конфигурации Azure Front Door.
    • Приоритет должен быть задан в диапазоне от 1 до 5 с 1 самым высоким и 5 самым низким.
    • Можно задать для нескольких кластеров один и тот же уровень приоритета и указать вес каждого из них.
  • Если основной кластер становится недоступным (происходит авария), трафик автоматически направляется в следующий регион, выбранный в Azure Front Door.
    • Весь трафик должен пройти через диспетчер трафика Azure Front Door, чтобы эта система работала.
  • Azure Front Door направляет трафик в шлюз приложение Azure в основном регионе (кластер должен быть помечен приоритетом 1). Если этот регион завершается ошибкой, служба перенаправляет трафик в следующий кластер в списке приоритетов.
    • Правила приходят из Azure Front Door.
  • Пара концентраторов развертывается для каждого регионального экземпляра AKS. политики диспетчера Брандмауэр Azure управляют правилами брандмауэра в регионах.
  • Azure Key Vault подготавливается в каждом регионе для хранения секретов и ключей.
  • Региональные экземпляры Log Analytics хранят региональные сетевые метрики и журналы диагностики.
  • Образы контейнеров для рабочей нагрузки хранятся в управляемом реестре контейнеров. Для всех экземпляров Kubernetes в кластере используется один Реестр контейнеров Azure. Георепликация для Реестр контейнеров Azure позволяет реплицировать образы в выбранные регионы Azure и обеспечивает постоянный доступ к изображениям, даже если регион испытывает сбой.

Чтобы создать модель активно-пассивного развертывания в AKS, выполните следующие действия.

  1. Создайте два идентичных развертывания в двух разных регионах Azure.

  2. Настройте правила автомасштабирования для дополнительного приложения, чтобы оно масштабируется до того же числа экземпляров, что и основной, когда основной регион становится неактивным. Хотя он неактивен, его не нужно масштабировать. Это помогает сократить затраты.

  3. Создайте два экземпляра веб-приложения с одним на каждом кластере.

  4. Создайте профиль Azure Front Door со следующими ресурсами:

    • Конечная точка.
    • Группа источников с приоритетом одного для основного региона.
    • Вторая группа источников с приоритетом двух для дополнительного региона.
    • Маршрут.

  5. Ограничить сетевой трафик веб-приложениями только из экземпляра Azure Front Door.

  6. Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.

  7. Разверните код в обоих веб-приложениях с непрерывным развертыванием.

Дополнительные сведения см. в обзоре рекомендуемого решения для аварийного восстановления с активным пассивным восстановлением для AKS.

Модель развертывания отработки отказа пассивного холодного режима

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

В этом примере архитектуры:

  • Вы создаете два кластера AKS, предпочтительно в разных регионах или зонах, чтобы повысить устойчивость.
  • Когда необходимо выполнить отработку отказа, вы активируете развертывание для передачи потока трафика.
  • В случае падения основного пассивного кластера необходимо вручную активировать холодный кластер, чтобы взять на себя поток трафика.
  • Это условие необходимо задать вручную каждый раз или определенное событие, указанное вами.
  • Azure Key Vault подготавливается в каждом регионе для хранения секретов и ключей.
  • Региональные экземпляры Log Analytics хранят региональные сетевые метрики и журналы диагностики для каждого кластера.

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

  1. Создайте два идентичных развертывания в разных зонах или регионах.
  2. Настройте правила автомасштабирования для дополнительного приложения, чтобы оно масштабируется до того же числа экземпляров, что и основной, когда основной регион становится неактивным. В то время как неактивный, его не нужно масштабировать, что помогает сократить затраты.
  3. Создайте два экземпляра веб-приложения с одним на каждом кластере.
  4. Настройте все другие серверные службы Azure, такие как базы данных, учетные записи хранения и поставщики проверки подлинности.
  5. Задайте условие при активации холодного кластера. При необходимости можно использовать подсистему балансировки нагрузки.

Дополнительные сведения см. в обзоре рекомендуемого решения отработки отказа пассивного холодного режима для AKS.

Квоты и ограничения службы

AKS задает ограничения и квоты по умолчанию для ресурсов и функций, включая ограничения использования для определенных номеров SKU виртуальных машин.

Ресурс Ограничение
Максимальное количество кластеров на одну подписку глобально 5,000
Максимальное количество кластеров для каждой подписки на регион 1 100
Максимальное количество узлов на кластер с Масштабируемыми наборами виртуальных машин и номером SKU Load Balancer категории "Базовый" 5 000 во всех пулах узлов
Примечание. Если вы не можете масштабировать до 5000 узлов на кластер, ознакомьтесь с рекомендациями по крупным кластерам.
Максимальное количество узлов на пул узлов (пулы узлов Масштабируемые наборы виртуальных машин) 1000
Максимальное количество пулов узлов на кластер 100
Максимальное количество модулей pod на узел: с подключаемым модулемсети Kubenet 1 Максимум: 250
Azure CLI по умолчанию: 110
По умолчанию шаблон Azure Resource Manager: 110
По умолчанию для развертывания портала Azure: 30
Максимальное количество модулей pod на узел: с сетевым интерфейсом контейнеров Azure (Azure CNI)2 Максимум: 250
Максимально рекомендуется для контейнеров Windows Server: 110
По умолчанию: 30
Надстройка AKS Open Service Mesh (OSM) Версия кластера Kubernetes: поддерживаемые версии AKS
Контроллеров OSM на кластер: 1
Pod на контроллер OSM: 1600
Учетные записи службы Kubernetes под управлением OSM: 160
Максимальное количество служб Kubernetes с балансировкой нагрузки на кластер с Load Balancer (цен. категория SKU 300
Максимальное количество узлов на кластер с группами доступности виртуальных машин и номером SKU Load Balancer категории "Базовый" 100

1 Больше разрешено по запросу.
2 контейнера Windows Server должны использовать подключаемый модуль сети Azure CNI. Kubenet не поддерживается для контейнеров Windows Server.

Уровень управления Kubernetes Лимит
Уровень служб "Стандартный" Автоматически масштабирует сервер API Kubernetes на основе нагрузки. Более крупные ограничения компонентов уровня управления и экземпляры сервера API и т. д.
Уровень служб "Бесплатный" Ограниченные ресурсы с ограничением в 50 вызовов без изменений и 100 вызовов только для чтения. Рекомендуемое ограничение на 10 узлов на кластер. Лучше всего экспериментировать, учиться и простое тестирование. Не рекомендуется использовать рабочие и критически важные рабочие нагрузки.

Дополнительные сведения см. в статье о квотах и ограничениях службы AKS.

Резервное копирование

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

Дополнительные сведения см. в следующих статьях: