llmdocsсправочник разработчика

Автомасштабирование (HPA)

Материал из llmdocs — справочник разработчика
Портал: Контейнеры и Kubernetes
Автомасштабирование (HPA)
ОбъектHorizontalPodAutoscaler (autoscaling/v2)
Источник метрикmetrics-server, Prometheus Adapter, внешние метрики
Цикл проверки15 секунд (по умолчанию)
МасштабируетDeployment, StatefulSet, ReplicaSet
ВертикальноеVertical Pod Autoscaler (VPA)
По событиямKEDA (проект CNCF)
УзлыCluster Autoscaler, Karpenter

Автомасштабирование в Kubernetes — набор механизмов, которые подстраивают мощность приложения под нагрузку без участия человека. Главный из них — Horizontal Pod Autoscaler (HPA): он увеличивает или уменьшает число реплик Deployment в зависимости от загрузки процессора, памяти или прикладных метрик. Днём, когда пользователей много, работает десять подов, ночью — два. Дополняют его вертикальное масштабирование подов (VPA) и масштабирование самих узлов кластера.

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

Что меняется Инструмент Пример
Число подов HPA, KEDA 2 → 10 реплик при росте RPS
Ресурсы пода VPA запросы памяти 256 → 512 МиБ
Число узлов Cluster Autoscaler, Karpenter добавить ВМ, когда поды не помещаются

Обычно они работают вместе: HPA добавляет поды, им не хватает места на узлах, и Cluster Autoscaler заказывает у облака новую машину.

Как работает HPA

Контроллер HPA раз в 15 секунд запрашивает метрики и вычисляет нужное число реплик по формуле:[1]

желаемые = ceil(текущие × текущее_значение / целевое_значение)

Если цель — 60% CPU, а четыре пода загружены в среднем на 90%, нужно ceil(4 × 90 / 60) = 6 реплик. Загрузка процессора считается относительно запросов ресурсов (resources.requests) — без них HPA по CPU работать не может. Источником базовых метрик служит metrics-server; прикладные метрики (запросы в секунду, длина очереди) подключают через Prometheus Adapter или KEDA.[3]

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: {type: Utilization, averageUtilization: 60}
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - {type: Percent, value: 50, periodSeconds: 60}

Блок behavior защищает от «дребезга»: уменьшение реплик откладывается на 5 минут (окно стабилизации по умолчанию) и ограничивается по скорости. Быстрое создание HPA — kubectl autoscale deployment api --cpu-percent=60 --min=2 --max=20; состояние — kubectl get hpa и kubectl describe hpa api (см. kubectl).[2]

Метрики

  • Resource — CPU и память контейнеров. Память — плохой сигнал для масштабирования: многие среды выполнения (JVM, Python) не возвращают её системе после пика.
  • Pods / Object — прикладные метрики из Prometheus: RPS на под, задержки, число активных соединений.
  • External — метрики вне кластера: длина очереди в облачном брокере, лаг потребителя Kafka.

Лучший сигнал — тот, что напрямую отражает нагрузку: для веб-API — запросы в секунду или задержка, для обработчиков — длина очереди.

KEDA

KEDA (Kubernetes Event-driven Autoscaling) расширяет HPA десятками источников событий — Kafka, RabbitMQ, Redis, SQS, cron, запросы к Prometheus — и умеет масштабировать до нуля: если очередь пуста, подов нет вообще, а при появлении сообщений они создаются.[4] Это удобно для фоновых обработчиков и задач по расписанию.

VPA и масштабирование узлов

Vertical Pod Autoscaler анализирует фактическое потребление и рекомендует или выставляет запросы CPU и памяти. Применение новых значений обычно требует пересоздания пода; совмещать VPA и HPA по одной и той же метрике CPU нельзя — они будут мешать друг другу.[5] Часто VPA используют в режиме рекомендаций, чтобы правильно задать запросы.

Cluster Autoscaler добавляет узлы, когда поды висят в Pending из-за нехватки ресурсов, и удаляет недогруженные узлы. Karpenter (AWS, теперь проект Kubernetes SIG) подбирает тип и размер машины под конкретные ожидающие поды и быстрее реагирует.[6]

Практика

  • Всегда задавайте resources.requests — от них считается и загрузка, и размещение подов.
  • minReplicas не меньше 2 для сервисов, которые должны переживать сбой узла; добавьте PodDisruptionBudget.
  • Учитывайте время старта: если под готов через минуту, HPA не спасёт от резкого всплеска — нужен запас или предварительное масштабирование по расписанию.
  • Приложение должно быть без состояния и корректно завершаться по SIGTERM, иначе уменьшение реплик обрывает запросы.
  • Проверяйте поведение нагрузочным тестом и следите за событиями масштабирования в мониторинге.

См. также

Источники

  1. Kubernetes Docs — Horizontal Pod Autoscaling
  2. Kubernetes Docs — HorizontalPodAutoscaler Walkthrough
  3. Kubernetes Docs — Resource Management for Pods and Containers
  4. KEDA — Kubernetes Event-driven Autoscaling
  5. Kubernetes Autoscaler — Cluster Autoscaler and VPA
  6. Karpenter Documentation
Категории: