Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) — это компонент системы управления контейнеризированными приложениями Kubernetes, предназначенный для автоматического изменения количества реплик (экземпляров) подов в рамках одного контроллера (например, Deployment, ReplicaSet, StatefulSet) в зависимости от текущей нагрузки на приложение. HPA позволяет динамически масштабировать вычислительные ресурсы, обеспечивая баланс между производительностью и затратами.

Принцип работы

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

1. Сбор метрик: HPA периодически (по умолчанию каждые 15 секунд) запрашивает данные из системы мониторинга Kubernetes, такой как Metrics Server, или из внешних источников (например, Prometheus). Метрики могут быть как встроенными (загрузка CPU, использование памяти), так и пользовательскими (количество запросов в секунду, длина очереди сообщений).

1. Расчёт желаемого количества реплик: На основе текущего среднего значения метрики и целевого порога HPA вычисляет необходимое количество подов. Формула расчёта для метрики, основанной на использовании ресурсов (например, CPU), выглядит следующим образом:

\[ \text{desiredReplicas} = \left\lceil \text{currentReplicas} \times \frac{\text{currentMetricValue}}{\text{desiredMetricValue}} \right\rceil \]

Где:

• currentReplicas — текущее количество подов.
• currentMetricValue — среднее значение метрики на всех подах.
• desiredMetricValue — целевое значение метрики, заданное в конфигурации HPA.

Для метрик, не связанных с ресурсами (например, количество запросов), расчёт может быть более сложным и включать деление общего значения метрики на целевое значение на под.

1. Применение изменений: Если вычисленное количество реплик отличается от текущего, HPA отправляет запрос на изменение масштаба контроллеру (например, через API Kubernetes). Изменение происходит постепенно, чтобы избежать резких скачков нагрузки (механизм «коэффициента стабилизации»).

1. Ограничение частоты изменений: Для предотвращения «тряски» (oscillation) — частых изменений количества реплик — HPA использует параметры задержки (cooldown) и коэффициенты стабилизации. По умолчанию масштабирование вверх происходит не чаще одного раза в 3 минуты, а вниз — не чаще одного раза в 5 минут.

Конфигурация

HPA определяется через объект API autoscaling/v2 (или более старую версию autoscaling/v1). Основные параметры конфигурации включают:

• ScaleTargetRef: ссылка на контроллер, который будет масштабироваться (например, Deployment или StatefulSet).
• MinReplicas и MaxReplicas: минимальное и максимальное количество реплик, которые может создать HPA.
• Metrics: список метрик, на основе которых принимается решение. Каждая метрика может быть:
• ResourceMetricSource: встроенная метрика (CPU, память). Для CPU обычно задаётся целевое использование в процентах от запрошенного ресурса (например, 50%).
• PodsMetricSource: пользовательская метрика, агрегированная по подам (например, среднее количество запросов на под).
• ObjectMetricSource: метрика, связанная с объектом Kubernetes (например, количество запросов к Ingress).
• ExternalMetricSource: метрика из внешнего источника (например, длина очереди RabbitMQ).
• Behavior: настройки поведения масштабирования, включая коэффициенты стабилизации, задержки и политики выбора реплик.

Пример конфигурации HPA на YAML:

```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: example-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: example-deployment minReplicas: 1 maxReplicas: 10 metrics:

• type: Resource

resource: name: cpu target: type: Utilization averageUtilization: 50

• type: Pods

pods: metric: name: requests-per-second target: type: AverageValue averageValue: 100 behavior: scaleUp: stabilizationWindowSeconds: 60 policies:

• type: Pods

value: 2 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies:

• type: Percent

value: 10 periodSeconds: 60 ```

Требования к окружению

Для работы HPA необходимо наличие в кластере Kubernetes компонента Metrics Server, который собирает метрики использования ресурсов (CPU и память) с узлов и подов. Metrics Server не устанавливается по умолчанию в большинстве дистрибутивов Kubernetes и требует отдельной установки. Для пользовательских метрик требуется дополнительная система мониторинга, такая как Prometheus, и адаптер (например, Prometheus Adapter), который преобразует данные в формат, понятный HPA.

Виды метрик

Встроенные метрики ресурсов

• CPU: измеряется в милликорах (mCPU). Целевое значение задаётся в процентах от запрошенного ресурса (например, 50% от 100m означает, что HPA будет стремиться к средней загрузке 50m на под).
• Память: измеряется в байтах. Целевое значение может быть задано как процент от запрошенного или как абсолютное значение.

Пользовательские метрики

• Pods: метрики, агрегированные по подам (например, среднее количество HTTP-запросов в секунду на под).
• Object: метрики, связанные с объектом Kubernetes (например, количество запросов к Ingress, длина очереди в сервисе).
• External: метрики из внешних систем (например, количество сообщений в очереди RabbitMQ, загрузка базы данных).

Преимущества и ограничения

Преимущества

• Автоматизация: снижает необходимость ручного вмешательства для регулирования количества реплик.
• Эффективность ресурсов: позволяет экономить вычислительные ресурсы в периоды низкой нагрузки и обеспечивать производительность при пиках.
• Гибкость: поддержка различных метрик и настраиваемое поведение масштабирования.

Ограничения

• Зависимость от метрик: HPA не может предсказывать будущую нагрузку, а реагирует только на текущие данные. Это может приводить к задержкам при резких скачках трафика.
• Ограниченная поддержка StatefulSet: для StatefulSet масштабирование может быть проблематичным, так как изменение количества реплик может нарушить порядок и идентичность подов.
• Необходимость настройки: неправильная конфигурация метрик (например, слишком низкий порог) может привести к частому масштабированию и нестабильности.
• Отсутствие поддержки для DaemonSet: HPA не может масштабировать DaemonSet, так как количество подов в нём привязано к количеству узлов.

Альтернативы

• Vertical Pod Autoscaler (VPA): автоматически изменяет запросы ресурсов (CPU и память) для подов, не изменяя их количество. Часто используется в паре с HPA.
• Cluster Autoscaler: масштабирует количество узлов в кластере, а не подов. Используется для обеспечения достаточного количества вычислительных ресурсов для HPA.
• Custom Autoscalers: сторонние решения, такие как KEDA (Kubernetes Event-Driven Autoscaling), которые поддерживают более широкий спектр триггеров (например, события из очередей, баз данных, HTTP-запросов).

Примеры использования

• Веб-приложения: HPA может автоматически увеличивать количество подов при росте числа запросов к серверу и уменьшать их при спаде трафика.
• Микросервисы: для сервисов с неравномерной нагрузкой (например, обработка изображений, генерация отчётов) HPA позволяет динамически выделять ресурсы.
• Пакетная обработка: при обработке очередей сообщений HPA может масштабировать количество подов в зависимости от длины очереди.

Интересные факты

• HPA был введён в Kubernetes версии 1.1 (2015 год) как экспериментальная функция. В версии 1.8 (2017 год) он стал стабильным.
• В версии 1.23 (2021 год) была добавлена поддержка метрик на основе пользовательских ресурсов (custom.metrics.k8s.io).
• HPA может работать с несколькими метриками одновременно, но решение о масштабировании принимается на основе максимального желаемого количества реплик, вычисленного по каждой метрике.

Источники

• Kubernetes Documentation. «Horizontal Pod Autoscaling». Официальная документация.
• Kubernetes GitHub. «Autoscaling Design Proposal». Репозиторий проекта.
• Брендан Бернс, Джо Беда, Келси Хайтауэр. «Kubernetes: Up and Running». O'Reilly Media, 2019.
• Документация Metrics Server. Официальный репозиторий.