Как работает Horizontal Pod Autoscaler, и как он связан с Cluster Autoscaler?

Question

IT Interview Practice · Accepted Answer

**Horizontal Pod Autoscaler (HPA)** добавляет или удаляет **реплики Pod** на основе наблюдаемых метрик (CPU, память или пользовательские). **Cluster Autoscaler (CA)** добавляет или удаляет **node**, когда Pod невозможно запланировать или node недоиспользуются. Они работают на разных уровнях и действуют вместе.

## Два автоскейлера, два уровня

```text
HPA  → масштабирует PODS  (больше/меньше реплик Deployment)     — реагирует на НАГРУЗКУ
CA   → масштабирует NODES (растит/сжимает машины кластера)       — реагирует на PENDING Pod
VPA  → (бонус) подстраивает requests/limits Pod                  — реагирует на подбор размера

Типичный поток: нагрузка растёт → HPA добавляет Pod → Pod не влезают → CA добавляет node →
              Pod планируются. Нагрузка падает → HPA удаляет Pod → node простаивает → CA удаляет его.
```

## Как работает цикл управления HPA

```text
Каждые ~15с контроллер HPA:
  1. читает текущую метрику (например, средний CPU по Pod) из metrics-server / custom API
  2. вычисляет:  desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)
  3. масштабирует Deployment к этому (в границах minReplicas/maxReplicas)
Пример: 4 Pod при 80% CPU, цель 50% → 4 * 80/50 = 6.4 → 7 реплик.
Окна стабилизации (stabilization windows) гасят дребезг (особенно при уменьшении).
```

## Manifest HPA

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60      # держать средний CPU ~60% от REQUEST
  behavior:                           # опционально: настроить скорость увеличения/уменьшения
    scaleDown:
      stabilizationWindowSeconds: 300
```

```bash
kubectl get hpa                       # текущая/целевая метрика, число реплик
kubectl top pods                      # требует metrics-server
```

## Важные зависимости и оговорки

```text
• HPA по CPU/памяти ТРЕБУЕТ установленного metrics-server; утилизация относительна REQUESTS
  → если requests не заданы/неверны, математика HPA бессмысленна. Задавайте requests правильно.
• Пользовательские/внешние метрики (RPS, глубина очереди) нужен адаптер (Prometheus Adapter, KEDA).
• HPA и ручной `replicas` конфликтуют — пусть HPA владеет числом реплик.
• Cluster Autoscaler тоже нужны корректные requests: он смотрит на REQUESTS Pending Pod, чтобы
  решить масштабирование node. Увеличение node занимает минуты (провижининг), поэтому держите запас.
```

## Почему это важно

Автоскейлинг — это то, что позволяет Kubernetes автоматически подгонять ёмкость под спрос, и понимание двух уровней — знание уровня senior, отличающее экономически эффективные, устойчивые кластеры от переподготовленных или недообеспеченных. Ключевая ментальная модель в том, что **HPA масштабирует Pod** в ответ на нагрузку (подстраивая число реплик по наблюдаемым CPU, памяти или пользовательским метрикам), тогда как **Cluster Autoscaler масштабирует node** в ответ на давление планирования (добавляя машины, когда Pod в Pending, удаляя их, когда node простаивают) — они работают на разных уровнях и кооперируются: HPA может добавлять Pod, только если есть место, а CA это место предоставляет. Понимание цикла управления HPA — формулы `desiredReplicas = ceil(currentReplicas * currentMetric / targetMetric)`, периодического согласования и окон стабилизации, предотвращающих дребезг, — позволяет настраивать и отлаживать его, а не относиться к нему как к магии. Оговорки — там, где проявляется суждение senior: HPA по CPU/памяти **требует metrics-server** и вычисляет утилизацию **относительно requests**, поэтому неверные или отсутствующие requests делают его математику бессмысленной; пользовательским метрикам (запросы в секунду, глубина очереди) нужен адаптер вроде Prometheus Adapter или KEDA; а увеличение node занимает минуты, поэтому запас важен. Поскольку правильный подбор ёмкости напрямую влияет на надёжность при всплесках трафика и облачные расходы в тихие периоды, и поскольку оба автоскейлера зависят от корректно заданных resource requests, овладение HPA и Cluster Autoscaler фундаментально для эффективной и надёжной эксплуатации production Kubernetes.

Два автоскейлера, два уровня

Как работает цикл управления HPA

Manifest HPA

Важные зависимости и оговорки

Почему это важно

Похожие вопросы