Доступность приложений на Служба Azure Kubernetes в Azure Stack HCI и сервере Windows

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

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

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

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

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

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

Diagram showing AKS on Azure Stack HCI and Windows Server with Failover Clustering enabled

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

Diagram showing an example legacy application running as a singleton

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

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

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

Примечание

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

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

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

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

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

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

Примечание

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

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

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

Заключение

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