Доступность приложений в AKS, включенная Azure Arc

Область применения: AKS в Azure Stack HCI 22H2, AKS в Windows Server

Служба Azure Kubernetes (AKS), включенная Azure Arc, предоставляет полностью поддерживаемую платформу контейнеров, которая может запускать ориентированные на облако приложения на платформе оркестрации контейнеров Kubernetes. Архитектура поддерживает выполнение виртуализированных рабочих нагрузок Windows и Linux.

Архитектура AKS создается с помощью отработки отказа кластеризация и динамической миграции, которая автоматически включается для целевых кластеров (рабочих нагрузок). Во время различных сбоев виртуальные машины, на которых размещены рабочие нагрузки клиентов, свободно перемещаются без предполагаемого простоя приложений. Эта архитектура означает, что традиционный корпоративный клиент, который управляет устаревшим приложением в качестве одноэлементного приложения AKS в Azure Stack HCI или Windows Server, получает аналогичное (или лучшее) время доступности, чем в настоящее время в устаревшем приложении виртуальной машины.

В этой статье описываются некоторые основные понятия для пользователей, которые хотят запускать контейнерные приложения в AKS Arc с включенной динамической миграцией, чтобы обеспечить доступность приложений во время сбоя. Терминология Kubernetes, например добровольное инепроизвольное прерывание, используется для обозначения простоя приложения, работающего в модуле pod.

Что такое динамическая миграция?

Динамическая миграция — это функция Hyper-V, которая позволяет прозрачно перемещать работающие виртуальные машины с одного узла Hyper-V на другой без предполагаемого простоя. Основное преимущество динамической миграции — гибкость; Запущенные виртуальные машины не привязаны к одному хост-компьютеру. Это позволяет пользователям выполнять такие действия, как очистка определенного узла виртуальных машин перед списанием или обновлением узла. В сочетании с отказоустойчивой кластеризации Windows динамическая миграция позволяет создавать высокодоступные и отказоустойчивые системы.

Текущая архитектура AKS в Azure Stack HCI и Windows Server предполагает, что вы включили динамическую миграцию в кластеризованной среде Azure Stack HCI. Таким образом, все виртуальные машины рабочих узлов Kubernetes создаются с настроенной динамической миграцией. Эти узлы можно перемещать по физическим узлам в случае сбоя, чтобы обеспечить высокую доступность платформы.

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

Сценарии нарушения работы приложений

Сравнительное исследование времени восстановления приложений, работающих на виртуальных машинах в AKS в Azure Stack HCI и Windows Server, ясно показывает, что при возникновении распространенных событий сбоя на приложение оказывается минимальное влияние. Ниже приведены три примера сценариев прерывания работы:

• Применение обновления, которое приводит к перезагрузке физического компьютера.
• Применение обновления, которое включает повторное создание рабочего узла.
• Незапланированный сбой оборудования физического компьютера.

Примечание

В этих сценариях предполагается, что владелец приложения по-прежнему использует параметры сходства и защиты от сходства Kubernetes, чтобы обеспечить правильное планирование модулей pod между рабочими узлами.

Событие прерывания	Запуск приложений на виртуальных машинах в Azure Stack HCI	Запуск приложений на виртуальных машинах в AKS в Azure Stack HCI или Windows Server
Применение обновления, которое приводит к перезагрузке физического компьютера	Нет влияния	Нет влияния
Применение обновления, которое включает в себя повторное создание рабочего узла (или перезагрузку виртуальной машины).	Нет влияния	Различается
Незапланированный сбой оборудования физического компьютера	6–8 минут	6–8 минут

Применение обновления, которое приводит к перезагрузке физического компьютера

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

Применение обновления, которое включает повторное создание рабочего узла

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

Примечание

Доступность приложения зависит от времени, необходимого для скачивания базового образа контейнера, особенно для больших образов, хранящихся в общедоступном облаке. Поэтому рекомендуется использовать небольшие базовые образы контейнеров, а для контейнеров Windows рекомендуется использовать базовый nano server образ.

Незапланированный сбой оборудования физического компьютера

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

Заключение

Технологии отработки отказа AKS кластеризация предназначены для обеспечения высокой доступности и отказоустойчивости вычислительных сред в Azure Stack HCI и Windows Server. Однако владельцу приложения по-прежнему необходимо настроить развертывания для использования функций Kubernetes, таких как Deployments, Affinity Mapping, , RelicaSets, чтобы обеспечить устойчивость модулей pod в сценариях прерывания работы.

Дальнейшие действия

Обзор AKS в Windows Server и Azure Stack HCI