Сценарии доступности для Служба Azure Kubernetes (AKS), включенные Azure Arc на двух узлах Azure Local
Область применения: Azure Stack HCI версии 22H2
В этой статье описывается архитектура развертывания кластера Kubernetes в двухузловом локальном кластере Azure. В этой статье описываются различные сценарии сбоя, которые могут возникнуть, их влияние на кластер и возможность восстановления из этих сценариев сбоев.
Архитектура
Для традиционных развертываний Kubernetes требуется три физических компьютера, чтобы устранить один сбой. Это требование обычно означает более высокую общую стоимость владения (TCO). Для развертывания с учетом затрат AKS с поддержкой Arc можно развернуть в двухузловой локальной системе Azure, как показано ниже, с несколькими компромиссами в доступности. Эти компромиссы описаны в сценариях доступности и их влиянии на кластер AKS с двумя узлами.
Дополнительные сведения об архитектуре, стратегиях развертывания кластера, рекомендациях по надежности и оптимизации затрат для AKS см. в Служба Azure Kubernetes базовой архитектуре (AKS).
Терминология
В этой статье используется следующая терминология:
| Термин | Определение |
|---|---|
| Локальный узел Azure | Физический узел локального кластера Azure, на котором размещены виртуальные машины, необходимые для запуска AKS, включенного Arc. |
| Гостевая ОС | Операционная система, запущенная в виртуальной машине уровня управления, виртуальной машине подсистемы балансировки нагрузки или виртуальных машинах пула узлов. |
| Отказоустойчивая кластеризация | Отказоустойчивая кластеризация для Локальной среды Azure и Windows Server предоставляет функции инфраструктуры, поддерживающие высокий уровень доступности виртуальных машин и приложений. Если узел кластера или служба завершаются сбоем, виртуальные машины или приложения, размещенные на этом узле, можно автоматически или вручную перенести на другой доступный узел в процессе, известном как отработка отказа. |
| Кластер рабочей нагрузки | Кластер Kubernetes, развернутый Служба Azure Kubernetes (AKS) для размещения контейнерного приложения или рабочей нагрузки, также известного как целевой кластер. |
| Кластер управления (узел AKS) | Предоставляет основной механизм оркестрации и интерфейс для развертывания и управления одним или несколькими кластерами рабочей нагрузки. Кластер управления содержит одну виртуальную машину уровня управления. |
| Подсистема балансировки нагрузки | Отдельная выделенная виртуальная машина Linux с правилом балансировки нагрузки для сервера API. |
| Сервер API | Позволяет взаимодействовать с кластером Kubernetes, обеспечивая взаимодействие с такими средствами управления, как Windows Admin Center, модули PowerShell и kubectl. |
| CRUD | Операции создания, чтения, обновления и удаления. |
Сценарии доступности и их влияние на кластер AKS с двумя узлами
Масштабируемая архитектура в локальном развертывании Azure с двумя физическими узлами включает некоторые компромиссы доступности. В этом разделе описывается поведение узла во время следующих режимов сбоя и во время обновлений:
- Обновления
- Сбой оборудования узла
- Сбой ОС узла
- Сбой виртуальной машины уровня управления
- Сбой виртуальной машины уровня управления
- Сбой пула узлов (рабочий узел)
- Сбой виртуальной машины подсистемы балансировки нагрузки
Обновления
Используйте следующую таблицу, чтобы определить потенциальное влияние обновлений Azure Local и AKS на рабочие нагрузки:
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
| Нет нарушений | Нет нарушений | Нет нарушений | Нет нарушений |
| Обновление с поддержкой кластера в локальной сети Azure переносит рабочие узлы на другой узел перед перезагрузкой. Приложения не нарушаются во время этой миграции. | Обновление с поддержкой кластера в локальной сети Azure переносит виртуальную машину уровня управления кластера рабочей нагрузки на другой узел перед перезагрузкой. Существующие рабочие нагрузки можно масштабировать без нарушений во время обновления. | Обновление с поддержкой кластера в локальной сети Azure переносит виртуальную машину уровня управления кластера на другой узел перед перезагрузкой. Новые рабочие нагрузки можно создавать без прерывания во время обновления. | Обновление с поддержкой кластера в локальной сети Azure переносит виртуальную машину уровня управления кластера рабочей нагрузки на другой узел перед перезагрузкой. Кластер сервера API остается доступным во время обновления. |
Сбой оборудования на узле
Физический узел, на котором выполняются виртуальные машины, на которых размещены узлы Kubernetes, может перестать функционировать из-за проблем с оборудованием или может стать секционированием сети.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоев оборудования узла на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
|
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
| Существующие рабочие нагрузки продолжают работать без сбоев до тех пор, пока: — рабочие узлы находятся на отдельных узлах. — приложение определило по крайней мере две реплики с podAntiAffinity указанными.Если у приложения есть зависимость от внешнего виртуального IP-адреса (VIP) сервера API, возникает нарушение. |
Если виртуальная машина уровня управления кластера рабочей нагрузки находится на узле, который снизился, рабочие нагрузки не будут масштабироваться. Добавление новых рабочих узлов и масштабирование модулей pod не будет работать. | Если виртуальная машина уровня управления кластера управления находится на узле, который снизился, создание новых кластеров невозможно. Масштабирование существующих кластеров не будет работать. | Если виртуальная машина уровня управления кластера рабочей нагрузки или виртуальная машина подсистемы балансировки нагрузки находится на узле, который снизился, сервер API недоступен. |
| Если рабочие узлы находятся на одном физическом узле, отказоустойчивая кластеризация выполняет отработку отказа рабочих узлов на выживших узлах. Если приложение не было создано с анти-сходством, Kubernetes перемещает модуль pod на существующий рабочий узел. Если приложение зависит от сервера API, а виртуальная машина уровня управления или виртуальная машина подсистемы балансировки нагрузки кластера рабочей нагрузки исчезнет, отказоустойчивая кластеризация перемещает эти виртуальные машины на выживший узел, а приложение возобновляет работу. В зависимости от того, как приложение обрабатывает потерю сервера API, модули pod могут быть перезапущены на новом узле. |
Отказоустойчивая кластеризация выполняет отработку отказа виртуальной машины уровня управления кластера рабочей нагрузки на здоровый узел. После отработки отказа рабочие нагрузки можно масштабировать. | Отказоустойчивая кластеризация выполняет отработку отказа виртуальной машины уровня управления кластера на работоспособном узле. После отработки отказа операции CRUD в новых целевых кластерах работают. | Отказоустойчивая кластеризация выполняет отработку отказа виртуальной машины уровня управления кластера рабочей нагрузки на работоспособном узле. После отработки отказа сервер API доступен. |
Сбой ОС узла
Физический узел, на котором выполняются виртуальные машины, на которых размещаются узлы Kubernetes, может возникнуть проблема с программным обеспечением в операционной системе и вызвать сбой.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоев ОС узла на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
|
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
Потенциальное нарушение + Автоматическое восстановление |
| Существующие рабочие нагрузки продолжают работать без сбоев до тех пор, пока: — рабочие узлы находятся на отдельных узлах. — приложение определило по крайней мере две реплики с podAntiAffinity указанными.Если у приложения есть зависимость от внешнего ВИРТУАЛЬНОго IP-адреса сервера API, возникает нарушение. |
Если виртуальная машина уровня управления в целевом кластере находится на узле с ошибками ОС, добавление новых рабочих узлов и масштабирование модулей pod не будет работать. | Если виртуальная машина уровня управления кластера управления находится на узле с ошибками ОС, новые кластеры не будут созданы, а существующие кластеры нельзя масштабировать. | Если виртуальная машина уровня управления находится на узле с ошибками ОС, сервер API не будет доступен. |
| Если рабочие узлы находятся на одном физическом узле, отказоустойчивая кластеризация выполняет отработку отказа рабочих узлов на выживших узлах. Если приложение не было создано с анти-сходством, Kubernetes переместит модуль pod на существующий рабочий узел. Если приложение зависит от сервера API, а виртуальная машина уровня управления или виртуальная машина подсистемы балансировки нагрузки кластера рабочих нагрузок завершает работу, отказоустойчивая кластеризация перемещает эти виртуальные машины на выживший узел, а приложение возобновляется. В зависимости от того, как приложение обрабатывает потерю сервера API, модули pod могут быть перезапущены на новом узле. |
Отказоустойчивая кластеризация выполняет отработку отказа виртуальной машины уровня управления кластера рабочей нагрузки на работоспособном узле. После отработки отказа рабочие нагрузки можно масштабировать. | Отказоустойчивая кластеризация выполняет отработку отказа виртуальной машины уровня управления кластера на работоспособном узле. После отработки отказа операции CRUD в новых целевых кластерах будут работать. | Отказоустойчивая кластеризация перезапускает виртуальную машину уровня управления кластера рабочей нагрузки на работоспособном узле. После этого сервер API доступен. |
Сбой виртуальной машины уровня управления
Виртуальная машина уровня управления кластера управления может неожиданно удалиться, загрузочный диск может быть поврежден или виртуальная машина уровня управления кластера управления может не загружаться из-за проблем с ОС.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоя виртуальной машины уровня управления кластера управления на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
| Нет нарушений |
Пробой + Восстановление вручную |
Пробой + Восстановление вручную |
Нет нарушений |
| Существующие рабочие нагрузки продолжают выполняться, если виртуальная машина кластера управления завершается сбоем. | Рабочие узлы нельзя добавить для масштабирования приложения. | Создание новой рабочей нагрузки не выполнено, пока кластер управления не работает. | Сервер API должен оставаться доступным в случае сбоя виртуальной машины кластера управления. |
| Нет данных | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину плоскости управления на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, кластер управления должен быть перестроен вручную. Дополнительные сведения см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину плоскости управления на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, кластер управления должен быть перестроен вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". | Нет данных |
Сбой виртуальной машины уровня управления
Виртуальная машина уровня управления кластера рабочей нагрузки может неожиданно удалиться, загрузочный диск может быть поврежден или виртуальная машина может не запуститься из-за проблем с ОС.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоя виртуальной машины уровня управления кластера рабочей нагрузки на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
| Нет нарушений |
Пробой + Восстановление вручную |
Нет нарушений |
Пробой + Восстановление вручную |
| Существующие рабочие нагрузки продолжают работать без сбоев до тех пор, пока: — рабочие узлы находятся на отдельных узлах. — приложение определило по крайней мере две реплики с podAntiAffinity указанными.Если у приложения есть зависимость от внешнего ВИРТУАЛЬНОго IP-адреса сервера API, возникает нарушение. |
Рабочие нагрузки нельзя масштабировать, пока виртуальная машина уровня управления находится в состоянии сбоя. Добавление новых рабочих узлов и масштабирование модулей pod не будет работать. | Создание новой рабочей нагрузки завершается успешно. | Сервер API недоступен, если виртуальная машина уровня управления находится в состоянии сбоя. |
| Нет данных | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину уровня управления на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, виртуальная машина уровня управления должна быть перестроена вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". | Нет данных | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину уровня управления на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, виртуальная машина уровня управления должна быть перестроена вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". |
Сбой виртуальной машины пула узлов (рабочих узлов)
Виртуальные машины, на которые размещаются узлы Kubernetes, могут неожиданно удалиться, загрузочный диск может быть поврежден или виртуальные машины могут не загружаться из-за проблем с ОС.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоя виртуальной машины в пуле узлов Kubernetes на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
|
Потенциальное нарушение + Восстановление вручную |
Нет нарушений | Нет нарушений | Нет нарушений |
| Существующие рабочие нагрузки продолжают работать без сбоев до тех пор, пока: — рабочие узлы находятся на отдельных узлах. — приложение определило по крайней мере две реплики с podAntiAffinity указанными. |
Рабочие узлы можно добавить. Планирование pod завершается успешно, если оставшиеся узлы имеют достаточную емкость. |
Создание новой рабочей нагрузки завершается успешно. | Сервер API остается доступным в случае сбоя одной рабочей виртуальной машины. |
| Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину уровня управления на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, необходимо повторно создать рабочие узлы вручную. | Нет данных | Нет данных | Нет данных |
Сбой виртуальной машины подсистемы балансировки нагрузки
Виртуальная машина подсистемы балансировки нагрузки может неожиданно удалиться, загрузочный диск может быть поврежден или виртуальная машина может не загружаться из-за проблем с ОС.
Используйте следующую таблицу, чтобы определить потенциальное влияние сбоя виртуальной машины подсистемы балансировки нагрузки на рабочие нагрузки.
| Существующие рабочие нагрузки | CRUD в кластерах рабочей нагрузки | Новый жизненный цикл кластера рабочей нагрузки | Доступность сервера API |
|---|---|---|---|
|
Потенциальное нарушение + Автоматическое восстановление |
Пробой + Восстановление вручную |
Нет нарушений |
Пробой + Восстановление вручную |
| Существующие рабочие нагрузки продолжают работать без сбоев до тех пор, пока: — рабочие узлы находятся на отдельных узлах. — приложение определило по крайней мере две реплики с podAntiAffinity указанными.Если приложение имеет зависимость от внешнего ВИРТУАЛЬНОго IP-адреса сервера API, возникает нарушение. |
Рабочие нагрузки нельзя масштабировать, пока виртуальная машина подсистемы балансировки нагрузки находится в состоянии сбоя. Добавление новых рабочих узлов и масштабирование модулей pod не будет работать. | Создание рабочей нагрузки завершается успешно. | Сервер API остается недоступным при отключении виртуальной машины подсистемы балансировки нагрузки. |
| Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину подсистемы балансировки нагрузки на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, необходимо перестроить виртуальную машину уровня управления вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину подсистемы балансировки нагрузки на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, необходимо перестроить виртуальную машину уровня управления вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". | Нет данных | Если отказоустойчивая кластеризация может восстановиться после ошибки, она пытается перезапустить виртуальную машину подсистемы балансировки нагрузки на другом узле. Если отказоустойчивая кластеризация не может восстановить виртуальную машину, необходимо перестроить виртуальную машину уровня управления вручную. Инструкции см. в статье "Резервное копирование и восстановление кластеров рабочих нагрузок". |