обзор масштабирования Azure Kubernetes Service (AKS) — HPA, VPA, Автомасштабирование кластера и KEDA

При запуске приложений в Azure Kubernetes Service (AKS) можно масштабировать поды, ресурсы подов, узлы или рабочие нагрузки, управляемые событиями, в соответствии с изменениями нагрузки. AKS поддерживает ручное масштабирование, горизонтальное автомасштабирование модулей (HPA), вертикальное автомасштабирование модулей (VPA), автомасштабирование кластера, автомасштабирование Kubernetes на основе событий (KEDA), автоподготовку узлов и пиковое масштабирование с помощью Экземпляры контейнеров Azure (ACI).

Выбор правильного метода масштабирования

Метод масштабирования	лучше всего подходит для	Ключевая метрика	Guide
Горизонтальный автомасштабировщик подов (HPA)	Рабочие нагрузки без сохранения состояния или поддающиеся разделению, с изменяющимся спросом	Использование ЦП, RPS, глубина очереди	Когда следует использовать горизонтальное автомасштабирование подов (HPA) в Kubernetes?
Автомасштабирование вертикального модуля Pod (VPA)	Нераспараллеливаемые рабочие нагрузки; оптимальный подбор запросов ресурсов пода	Использование ресурсов ЦП и памяти	Используйте Vertical Pod Autoscaler в AKS
Автомасштабирование кластера	Ёмкость на уровне узла, когда поды остаются в состоянии Pending	Ожидающие поды	Используйте автомасштабирование кластера в AKS
Автоматическая подготовка узла (NAP)	Ожидающие рабочие нагрузки, требующие емкости виртуальной машины правильного размера	Ожидающие требования к ресурсам pod	Обзор автоматической подготовки узла
КЕДА	Событийные нагрузки; требуется масштабирование до нуля	Длина очереди, отставание обработки событий	Обзор надстройки KEDA
Масштабирование всплеска ACI	Нагрузки Linux с пиковым спросом, соответствующие ограничениям виртуальных узлов	Всплеск спроса	Создание виртуальных узлов с помощью Экземпляры контейнеров Azure

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

Используйте HPA, если ваша рабочая нагрузка может работать в нескольких идентичных репликах, а нагрузка меняется в зависимости от использования ЦП, памяти или частоты запросов.
Используйте VPA , если рабочая нагрузка не может масштабироваться горизонтально (не параллельно) или требуется правильного размера запросов ресурсов для лучшего планирования.
Используйте автомасштабирование кластера , если у вас есть предопределенные пулы узлов и необходимо добавить или удалить узлы на основе ожидающего запроса pod.
Используйте NAP, если вам нужны автоматический выбор SKU виртуальных машин и подготовка узлов без необходимости вручную настраивать пулы узлов.
Используйте KEDA , когда масштабирование должно реагировать на внешние события (очереди, потоки, сообщения) или требуется возможность масштабирования до нуля.
Используйте масштабирование ACI с резким увеличением ресурсов, когда требуется быстрое наращивание мощностей для рабочих нагрузок Linux без ожидания подготовки виртуальных машин (обычно 2–5 минут).

Быстрая рекомендация

Для большинства рабочих нагрузок начните с AKS Automatic, которая предварительно настраивает NAP, VPA и KEDA. В AKS Standard вы включаете и настраиваете эти функции явным образом.

Масштабирование элементов pod или узлов вручную.

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

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

Чтобы приступить к работе, ознакомьтесь со следующими разделами:

Автоматическое горизонтальное масштабирование подов

Используйте HPA, если ваша рабочая нагрузка может работать в нескольких одинаковых репликах, а спрос колеблется. Он масштабируется по загрузке ЦП или использованию памяти, метрикам приложения (числу запросов в секунду, задержке) либо метрикам внешней очереди и накопленного объёма необработанных задач. Если реплики могут превышать существующую емкость узла, используйте предварительно настроенную функцию NAP в AKS Automatic или настройте автомасштабирование кластера или NAP в AKS Standard.

Не используйте HPA и VPA в одних и том же метриках ЦП или памяти. Чтобы использовать оба автомасштабирования, используйте VPA в режиме рекомендаций или настройте HPA для использования различных пользовательских метрик.

Подробнее: Когда следует использовать автомасштабирование Pod по горизонтали (HPA) в Kubernetes?

См. также: Использование Vertical Pod Autoscaler в AKS, чтобы оптимально настроить запросы pod к ЦП и памяти.

Автомасштабирование вертикальных подов

Вертикальный модуль автомасштабирования pod анализирует использование ЦП и памяти pod и рекомендует или применяет соответствующие запросы ресурсов. Используйте VPA, чтобы подобрать оптимальный размер ресурсов для рабочих нагрузок, которые не могут эффективно масштабироваться за счёт добавления реплик, или чтобы улучшить планирование и использование ресурсов.

В зависимости от режима обновления VPA может применять рекомендации при создании pod’ов либо выселять и пересоздавать pod’ы с обновлёнными запросами ресурсов. Просмотрите требования к доступности рабочей нагрузки, прежде чем разрешить VPA автоматически применять изменения.

Чтобы приступить к работе, см. Использование Vertical Pod Autoscaler в AKS.

Автоматический масштабатор кластера

Cluster Autoscaler изменяет количество узлов в пуле узлов в соответствии с требованиями к размещению pod. Он добавляет узлы, когда не удается разместить поды из-за недостаточной емкости узлов, и удаляет недостаточно загруженные узлы, если их рабочие нагрузки можно перенести на другие узлы.

Cluster Autoscaler обычно используется вместе с HPA. HPA регулирует количество реплик подов в зависимости от нагрузки, а Cluster Autoscaler регулирует ёмкость узлов для размещения этих подов.

Чтобы приступить к работе, см. раздел "Использование автомасштабирования кластера" в AKS.

События горизонтального масштабирования

Если в пуле узлов недостаточно вычислительных ресурсов для пода, под остаётся в состоянии Pending. Когда Cluster Autoscaler обнаруживает поды, которые не удаётся разместить из-за ограничений ресурсов пула узлов, он увеличивает количество узлов в этом пуле. Kubernetes назначает поды, находящиеся в состоянии Pending, после подготовки новых узлов и их перехода в состояние Ready.

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

События масштабирования

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

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

Автомасштабирование на основе событий Kubernetes

Автомасштабирование на основе событий Kubernetes (KEDA) — это компонент с открытым исходным кодом, который масштабирует рабочие нагрузки на основе событий. KEDA расширяет Kubernetes с помощью пользовательских ресурсов, в том числе ScaledObject, которые описывают, как рабочая нагрузка должна реагировать на источник событий или метрику.

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

Не используйте KEDA ScaledObject вместе с отдельной HPA для одной и той же нагрузки. KEDA сама создает и использует HPA, поэтому автоскейлеры будут конкурировать друг с другом.

Чтобы приступить к работе, ознакомьтесь с обзором надстройки KEDA.

Автоподготовка узла

Автоматическая подготовка узла (NAP) использует проект Karpenter с открытым исходным кодом для подготовки узлов и управления ими в соответствии с ожидающими требованиями pod. NAP выбирает соответствующий номер SKU виртуальной машины и количество узлов для удовлетворения спроса на рабочую нагрузку в режиме реального времени.

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

Масштабирование и защита плоскости управления

AKS автоматически масштабирует компоненты уровня управления на основе размера кластера и использования ресурсов сервера API. Это руководство относится к AKS Automatic и AKS Standard. Используйте ценовую категорию "Стандартный" или "Премиум" для производственных или масштабируемых рабочих нагрузок.

Kubernetes имеет многомерный диапазон масштабируемости, в рамках которого каждый тип ресурсов предъявляет разные требования к контрольной плоскости. Например, секреты часто отслеживаются несколькими контроллерами и pod'ами, которые изначально выполняют вызов LIST, создавая большую нагрузку на плоскость управления, чем ресурсы, отслеживаемые реже. Сильное масштабирование по одному параметру может сократить ресурсы по другим параметрам. Например, запуск сотен тысяч подов может снизить скорость мутации подов, поддерживаемую плоскостью управления. Рекомендации см. в рекомендациях клиентов Kubernetes для крупномасштабных кластеров AKS.

Чтобы проверить, была ли масштабирована плоскость управления, проверьте объект ConfigMap large-cluster-control-plane-scaling-status:

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Наличие этой ConfigMap подтверждает, что AKS масштабирует плоскость управления.

Защита плоскости управления

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

Чтобы определить, применена ли защита управляемого сервера API, проверьте наличие aks-managed-apiserver-guardFlowSchema и PriorityLevelConfiguration:

kubectl get flowschemas
kubectl get prioritylevelconfigurations

Функция защиты активна, когда aks-managed-apiserver-guard отображается в выводе обеих команд.

Если эти ресурсы присутствуют, см. руководство по устранению неполадок сервера API и etcd для получения рекомендаций по устранению проблемы.

Масштабирование на экземпляры контейнеров Azure (ACI)

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

Виртуальные узлы (виртуальные узлы Kubernetes на базе ACI) поддерживают поды и узлы Linux и требуют кластер AKS, использующий сетевое взаимодействие Azure CNI. Они не поддерживают некоторые распространенные сценарии, включая авторизованные диапазоны IP-адресов для API-сервера, постоянные тома и запросы на постоянные тома, IPv6 и управляемые идентификаторы, назначенные виртуальным узлам. Ознакомьтесь с ограничениями виртуальных узлов перед использованием масштабирования всплеска ACI.

Компонент виртуальных узлов AKS основан на Virtual Kubelet и представляет ACI в качестве виртуального узла Kubernetes. Kubernetes может планировать размещение подходящих подов через виртуальный узел для запуска как экземпляры контейнеров ACI, а не непосредственно на узлах виртуальных машин AKS.

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

Используйте следующие ресурсы для реализации метода масштабирования, который соответствует рабочей нагрузке:

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-08-14