Как автоматически регулировать количество Pod в зависимости от нагрузки в Kubernetes?

Для автоматического горизонтального масштабирования (увеличения/уменьшения количества реплик) Pod'ов в Kubernetes используется контроллер Horizontal Pod Autoscaler (HPA).

Принцип работы: HPA периодически опрашивает Metrics Server (или другой адаптер метрик, например, Prometheus Adapter) о текущей нагрузке на Pod'ы целевого Deployment, StatefulSet или другого масштабируемого ресурса. На основе полученных метрик и заданного целевого значения он вычисляет необходимое количество реплик и обновляет спецификацию целевого ресурса.

Пример HPA, масштабирующегося по CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-api-hpa
  namespace: production
spec:
  # На какой объект ссылаемся
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend-api
  # Минимальное и максимальное количество Pod'ов
  minReplicas: 3
  maxReplicas: 15
  # Метрики, по которым принимается решение
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization # Целевой тип - процент утилизации
        averageUtilization: 70 # Поддерживать среднюю утилизацию CPU на уровне 70%
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  # Политика масштабирования (опционально, для тонкой наки)
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300 # Ждать 5 минут перед уменьшением реплик
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # За один шаг можно уменьшить не более 50% реплик за 60 секунд

Ключевые компоненты и настройки:

• Metrics Server: Должен быть установлен в кластере для предоставления метрик cpu и memory.
• Кастомные метрики: Для масштабирования по RPS, длине очереди сообщений и т.п. необходимо настроить Prometheus Adapter и определить правила для custom.metrics.k8s.io API.
• Поведение (behavior): Позволяет настроить "агрессивность" масштабирования вверх и вниз, чтобы избежать "дребезга" реплик при кратковременных всплесках нагрузки.

Практический пример: Наш сервис обработки очереди сообщений масштабируется по кастомной метрике queue_messages_per_pod. HPA настроен так, чтобы каждый Pod обрабатывал в среднем не более 1000 сообщений, что позволяет динамически реагировать на приток задач.