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

> Механизмы Kubernetes, меняющие число подов (HPA), их ресурсы (VPA) и число узлов (Cluster Autoscaler, Karpenter) в зависимости от нагрузки.

Источник: https://llmdocs.ru/wiki/hpa/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Объект**: HorizontalPodAutoscaler (autoscaling/v2)
- **Источник метрик**: metrics-server, Prometheus Adapter, внешние метрики
- **Цикл проверки**: 15 секунд (по умолчанию)
- **Масштабирует**: Deployment, StatefulSet, ReplicaSet
- **Вертикальное**: Vertical Pod Autoscaler (VPA)
- **По событиям**: KEDA (проект CNCF)
- **Узлы**: Cluster Autoscaler, Karpenter
**Автомасштабирование** в [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md) — набор механизмов, которые подстраивают мощность приложения под нагрузку без участия человека. Главный из них — **Horizontal Pod Autoscaler** (HPA): он увеличивает или уменьшает число реплик [Deployment](https://llmdocs.ru/wiki/deployment-replicaset.md) в зависимости от загрузки процессора, памяти или прикладных метрик. Днём, когда пользователей много, работает десять подов, ночью — два. Дополняют его вертикальное масштабирование подов (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]

```yaml
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](https://llmdocs.ru/wiki/kubectl.md)).[2]

## Метрики

- **Resource** — CPU и память контейнеров. Память — плохой сигнал для масштабирования: многие среды выполнения (JVM, Python) не возвращают её системе после пика.
- **Pods / Object** — прикладные метрики из [Prometheus](https://llmdocs.ru/wiki/prometheus.md): 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, иначе уменьшение реплик обрывает запросы.
- Проверяйте поведение нагрузочным тестом и следите за событиями масштабирования в [мониторинге](https://llmdocs.ru/wiki/monitoring-alerting.md).

## См. также

- [Kubernetes](https://llmdocs.ru/wiki/kubernetes.md)
- [Deployment и ReplicaSet](https://llmdocs.ru/wiki/deployment-replicaset.md)
- [Prometheus](https://llmdocs.ru/wiki/prometheus.md)
- [k3s и лёгкие дистрибутивы](https://llmdocs.ru/wiki/k3s.md)

## Источники

1. [Kubernetes Docs — Horizontal Pod Autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)
2. [Kubernetes Docs — HorizontalPodAutoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
3. [Kubernetes Docs — Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)
4. [KEDA — Kubernetes Event-driven Autoscaling](https://keda.sh/docs/latest/concepts/)
5. [Kubernetes Autoscaler — Cluster Autoscaler and VPA](https://github.com/kubernetes/autoscaler)
6. [Karpenter Documentation](https://karpenter.sh/docs/)