Группы доступности в AKS, включенные Azure Arc
Группы доступности — это логические группы виртуальных машин, которые имеют слабые связи защиты от сопоставления друг с другом, чтобы обеспечить равномерное распределение между доступными доменами сбоя в физическом кластере. Домен сбоя в этом контексте — это физический узел или группа физических узлов. С помощью групп доступности AKS Arc может повысить доступность и распределение рабочих нагрузок Kubernetes. Группы доступности могут избежать сценариев, в которых сбой одного узла может привести к снижению или сбою нескольких виртуальных машин.
Обзор
Группы доступности предлагают несколько преимуществ для AKS для локальных пользователей Azure, таких как:
- Повышает доступность и устойчивость приложений, избегая сценариев, в которых несколько виртуальных машин в одном пуле узлов или плоскости управления идут вниз или становятся несбалансированных из-за сбоя одного узла.
- Оптимизирует использование ресурсов и производительность кластера, обеспечивая равномерное распределение виртуальных машин между доступными узлами и не сосредоточено на одном узле или подмножестве узлов.
- Соответствует рекомендациям и ожиданиям клиентов и партнеров, которые ищут надежный и согласованный локальный интерфейс Kubernetes.
Включение групп доступности
С помощью AKS в Azure Local версии 23H2 функция групп доступности включена по умолчанию при создании пула узлов. С помощью AKS в Windows Server можно включить функцию групп доступности, добавив -enableAvailabilitySet параметр при создании кластера AKS, например New-AksHciCluster -Name <name> -controlPlaneNodeCount 3 -osType Linux -kubernetesVersion $kubernetesVersion -enableAvailabilitySet.
Как работают группы доступности в AKS, включенные Azure Arc
При создании нового кластера AKS Arc AKS Arc автоматически создает группы доступности, одну для виртуальных машин плоскости управления и другую для каждого пула узлов в кластере Kubernetes. Каждый пул узлов имеет собственный набор доступности. С помощью этого макета AKS Arc гарантирует, что виртуальные машины одной роли (плоскости управления или пула узлов) никогда не находятся на одном физическом узле и что они распределяются по доступным узлам в кластере.
После создания групп доступности и назначения виртуальных машин система автоматически помещает их на соответствующие физические узлы. Если узел завершается ошибкой, система также автоматически выполняет отработку отказа виртуальных машин на другие узлы и перебалансирует их при восстановлении узла. Таким образом, вы можете обеспечить высокий уровень доступности и оптимальное распределение рабочих нагрузок Kubernetes без вмешательства вручную.
Рассмотрим akS в локальном кластере Azure версии 23H2 с двумя физическими компьютерами узла, узлом А и узлом B, тремя виртуальными машинами уровня управления и двумя виртуальными машинами рабочего узла, Nodepool1VM1 и Nodepool1VM2. Чтобы обеспечить высокий уровень доступности приложений Kubernetes, виртуальные машины пула узлов никогда не должны совместно использовать один узел, если один из узлов временно недоступен для планового обслуживания или проблемы с емкостью, что может привести к временному размещению виртуальной машины (виртуальной машины) на альтернативном узле.
На следующей схеме каждый цвет представляет группу защиты от сходства:
Если узел B исчезает из-за перезагрузки, главного уровня управления VM2, уровня управления VM3 и Nodepool1VM2 отработка отказа на узел A , как показано на следующем рисунке. Если приложение выполняет модули pod в NodePoolVM1, эта перезагрузка не влияет на ваше приложение:
В старой архитектуре, если узел B вернулся в сеть после перезагрузки, не было никакой гарантии, что виртуальные машины вернутся с узла A на узел B (перебалансировка), таким образом заставляя рабочие нагрузки оставаться на одном узле и создавать одну точку сбоя, как показано на следующей схеме:
Группы доступности для AKS Arc могут помочь перебалансировать виртуальные машины после восстановления узла после временного сбоя. В этом примере ControlPlaneVM2, ControlPlaneVM3 и Nodepool1VM2 автоматически перемещаются на узел B, как показано ниже:
Внимание
Группы доступности в AKS Arc — это новая функция, которая по-прежнему развивается и улучшается. Мы еще не поддерживаем ручную настройку доменов сбоя или групп доступности. Вы не можете изменить домены сбоя группы доступности после его создания. Виртуальные машины назначаются группе доступности при создании кластера и не могут быть перенесены в другую группу доступности.
Добавление или удаление компьютеров
В сценарии удаления узлов узел больше не считается частью кластера. Это удаление обычно происходит при замене компьютера из-за проблем с оборудованием или уменьшения масштаба локального кластера Azure по другим причинам. Во время сбоя узла узел остается частью локального кластера Azure, но отображается как "Вниз".
Если физический компьютер (домен сбоя) окончательно удаляется из кластера, конфигурация группы доступности не изменяется, чтобы уменьшить количество доменов сбоя. В этом сценарии группа доступности вводит неработоспособное состояние. Рекомендуется повторно развернуть кластеры Kubernetes, чтобы группа доступности была обновлена с соответствующим количеством доменов сбоя.
При добавлении нового физического компьютера (домена сбоя) в кластер конфигурация группы доступности автоматически расширяется, чтобы включить новый компьютер. Однако существующие виртуальные машины не перебалансируются для применения этой новой конфигурации, так как они уже назначены группам доступности. Рекомендуется повторно развернуть кластеры Kubernetes, чтобы группа доступности была обновлена с соответствующим количеством доменов сбоя.