💻 HPA: автоскейлинг по метрикам
Horizontal Pod Autoscaler (HPA) — встроенный контроллер Kubernetes, который автоматически изменяет количество реплик Deployment, StatefulSet или ReplicaSet в зависимости от текущей нагрузки. Задача HPA — держать нагрузку на под в заданных рамках, не привлекая к этому человека.
🔺 HPA работает в цикле (по умолчанию — раз в 15 секунд):
— Получает текущие метрики из metrics-server (или внешнего адаптера метрик, если используются custom/external metrics)
— Сравнивает текущее значение метрики со значением, заданным в спецификации HPA
— Вычисляет желаемое количество реплик по формуле:
desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))
— Обновляет поле replicas у целевого объекта (Deployment/StatefulSet)
Контроллер не действует резко: изменения сглаживаются, а между операциями масштабирования выдерживается пауза (stabilization window), чтобы избежать «дребезга» — постоянных колебаний числа реплик туда-обратно.
🔺 Источники метрик
— Resource metrics — CPU и память пода, собираются через metrics-server. Базовый и самый распространённый вариант.
— Custom metrics — метрики приложения (например, число запросов в очереди), поставляются через Prometheus или аналогичный адаптер.
— External metrics — метрики внешних систем, не привязанные к объектам Kubernetes
Минимальная настройка
Предполагается, что для пода заданы resources.requests.cpu — без них HPA не сможет посчитать процент утилизации.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Частые ошибки
— Отсутствие requests у контейнеров — метрика Utilization считается относительно запроса ресурсов, без него HPA не сработает
— Слишком узкий диапазон minReplicas–maxReplicas — контроллеру физически негде масштабироваться
— Игнорирование stabilization window при настройке — резкие пики нагрузки могут вызывать частые колебания без её корректной настройки в behavior
— Использование HPA и VPA на одних и тех же метриках ресурсов одновременно — контроллеры начинают конфликтовать между собой
HPA закрывает базовый сценарий эластичности — реакцию на изменение нагрузки без ручного вмешательства. Для более тонких сценариев (масштабирование по внешним очередям, множественные метрики, кастомная логика) конфигурация расширяется, но принцип остаётся тем же: контроллер сравнивает текущее состояние с целевым и приводит систему к балансу.
#заметкиИнженера
Horizontal Pod Autoscaler (HPA) — встроенный контроллер Kubernetes, который автоматически изменяет количество реплик Deployment, StatefulSet или ReplicaSet в зависимости от текущей нагрузки. Задача HPA — держать нагрузку на под в заданных рамках, не привлекая к этому человека.
🔺 HPA работает в цикле (по умолчанию — раз в 15 секунд):
— Получает текущие метрики из metrics-server (или внешнего адаптера метрик, если используются custom/external metrics)
— Сравнивает текущее значение метрики со значением, заданным в спецификации HPA
— Вычисляет желаемое количество реплик по формуле:
desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))
— Обновляет поле replicas у целевого объекта (Deployment/StatefulSet)
Контроллер не действует резко: изменения сглаживаются, а между операциями масштабирования выдерживается пауза (stabilization window), чтобы избежать «дребезга» — постоянных колебаний числа реплик туда-обратно.
🔺 Источники метрик
— Resource metrics — CPU и память пода, собираются через metrics-server. Базовый и самый распространённый вариант.
— Custom metrics — метрики приложения (например, число запросов в очереди), поставляются через Prometheus или аналогичный адаптер.
— External metrics — метрики внешних систем, не привязанные к объектам Kubernetes
Минимальная настройка
Предполагается, что для пода заданы resources.requests.cpu — без них HPA не сможет посчитать процент утилизации.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Частые ошибки
— Отсутствие requests у контейнеров — метрика Utilization считается относительно запроса ресурсов, без него HPA не сработает
— Слишком узкий диапазон minReplicas–maxReplicas — контроллеру физически негде масштабироваться
— Игнорирование stabilization window при настройке — резкие пики нагрузки могут вызывать частые колебания без её корректной настройки в behavior
— Использование HPA и VPA на одних и тех же метриках ресурсов одновременно — контроллеры начинают конфликтовать между собой
HPA закрывает базовый сценарий эластичности — реакцию на изменение нагрузки без ручного вмешательства. Для более тонких сценариев (масштабирование по внешним очередям, множественные метрики, кастомная логика) конфигурация расширяется, но принцип остаётся тем же: контроллер сравнивает текущее состояние с целевым и приводит систему к балансу.
#заметкиИнженера