Как работает HorizontalPodAutoscaler и какие ограничения нужно учитывать при его настройке?

Короткий ответ

HPA периодически опрашивает метрики (по умолчанию — средний процент использования CPU/памяти относительно requests, либо кастомные метрики через Metrics API) и изменяет число реплик Deployment/StatefulSet, чтобы приблизить фактическое значение метрики к целевому; ограничение в том, что HPA требует корректно заданных requests и не реагирует мгновенно — есть задержка на сбор метрик и период стабилизации.

Как это работает подробнее

формула масштабирования примерно такая — желаемые реплики = текущие реплики × (текущее значение метрики / целевое значение), с округлением и ограничениями minReplicas/maxReplicas. Для метрики CPU используется не абсолютное потребление, а процент от requests.cpu, поэтому без заданных requests автоскейлинг по CPU вообще не будет работать корректно.

Пример кода

manifest.yamlКопировать

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: { name: web-hpa }
spec:
  scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: web }
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource: { name: cpu, target: { type: Utilization, averageUtilization: 70 } }

Что использовать на практике

• Практика. для плавного масштабирования без "дребезга" (постоянных колебаний числа реплик) настраивают behavior.scaleDown.stabilizationWindowSeconds, чтобы не схлопывать реплики сразу после кратковременного снижения нагрузки. Для приложений с нагрузкой, не связанной с CPU (например, зависящей от длины очереди сообщений), нужны кастомные метрики через Prometheus Adapter или внешние метрики (External Metrics API).

Подводные камни

• Риски. настраивать HPA по CPU без заданных requests.cpu у контейнеров — метрика "процент от requests" в этом случае не определена; ставить слишком узкий диапазон minReplicas/maxReplicas, не учитывающий время, необходимое новым подам на прохождение readiness (между решением HPA и реальной готовностью пода к трафику есть задержка); не учитывать, что частое резкое масштабирование вниз может преждевременно убивать поды, всё ещё обрабатывающие длительные запросы.