---

Junior уровень

Простое объяснение

Масштабирование — это изменение количества ресурсов, выделенных приложению. В Kubernetes можно масштабировать на двух уровнях:

1. Больше копий приложения (горизонтальное) — запустить дополнительные Pod’ы
2. Больше ресурсов для Pod’а (вертикальное) — дать больше CPU/RAM

Горизонтальное масштабирование (больше копий)

1 копия:    [App]          ← 100 запросов/сек → тормозит
3 копии:    [App] [App] [App]  ← 100 запросов/сек → работает быстро

Это самый частый способ. Больше копий = больше запросов обрабатывается.

Вертикальное масштабирование (больше ресурсов)

Мало RAM:   [App: 256MB]   ← OutOfMemoryError
Много RAM:  [App: 1GB]     ← работает нормально

Менее частый способ. Не все приложения умеют эффективно использовать больше ресурсов.

Ручное масштабирование

# Увеличить число реплик до 5
kubectl scale deployment myapp --replicas=5

# Проверить
kubectl get deployment myapp

Автоматическое масштабирование

Kubernetes может сам менять число реплик:

• HPA (Horizontal Pod Autoscaler) — по CPU или другим метрикам
• Cluster Autoscaler — добавляет серверы (Node), когда не хватает ресурсов

Что запомнить Junior-разработчику

• Горизонтальное = больше копий (самый частый способ)
• Вертикальное = больше ресурсов на Pod
• Ручное: kubectl scale deployment --replicas=N
• Автоматическое: HPA по CPU, Cluster Autoscaler по Node
• Для HPA нужно указать Requests (минимальные ресурсы)

---

Middle уровень

Типы масштабирования

HPA — Horizontal Pod Autoscaler

HPA плохо работает с stateful workload (базы данных) — новые Pod’ы не имеют данных. Для stateful используйте StatefulSet + ручное масштабирование.

Изменяет число реплик Pod’ов:

# HPA: поддерживать CPU загрузку ~50%
kubectl autoscale deployment myapp --cpu-percent=50 --min=2 --max=10

Источники метрик:

• Resource metrics: CPU, Memory (из Metrics Server)
• Custom metrics: бизнес-метрики из Prometheus
• External metrics: внешние очереди (AWS SQS, RabbitMQ)

VPA — Vertical Pod Autoscaler

VPA (Vertical Pod Autoscaler) — автоматически подбирает CPU/RAM запросы для Pod’ов.

Изменяет CPU/RAM запросы и лимиты Pod’а:

• Требует перезапуска Pod’а для применения
• Полезен для подбора оптимальных ресурсов
• Не рекомендуется использовать одновременно с HPA по CPU

Cluster Autoscaler

Добавляет/удаляет Node в кластере:

• Если Pod’ы в Pending (не хватает ресурсов) → добавляет Node
• Если Node недогружены → удаляет для экономии

Как HPA принимает решения?

Формула:

desiredReplicas = ceil[currentReplicas × (currentMetricValue / desiredMetricValue)]

Пример:

• Желаемая CPU: 50%
• Текущая CPU: 100%
• Текущие реплики: 2
• Решение: ceil[2 × (100/50)] = 4 реплики

Требования для HPA

1. Metrics Server должен быть установлен
2. Requests должны быть указаны в Pod’е (HPA считает процент от Requests)

resources:
  requests:
    cpu: "500m"     # Обязательно для HPA
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

Проблема “Race Condition”

Если HPA слишком быстро реагирует на скачки, система входит в осцилляцию:

• Скачок CPU → HPA добавляет Pod’ы → нагрузка падает → HPA удаляет Pod’ы → скачок снова

Решение: Настроить cooldown периоды (behavior в HPA).

Что запомнить Middle-разработчику

• HPA — основной способ масштабирования
• VPA — для подбора ресурсов (не с HPA вместе)
• Cluster Autoscaler — для управления ёмкостью кластера
• HPA требует Metrics Server и Resources Requests
• Настраивайте cooldown для предотвращения осцилляции

---

Senior уровень

Масштабирование как архитектурная стратегия

Масштабирование в Kubernetes — это не просто “добавить Pod’ы”, а многоуровневая стратегия, которая влияет на архитектуру приложения, инфраструктурные затраты и SLA.

Полная картина масштабирования

Уровень приложения:
├── HPA (горизонтально): больше реплик
└── VPA (вертикально): больше ресурсов

Уровень кластера:
├── Cluster Autoscaler: больше Node
└── Karpenter: оптимизация типов инстансов

Уровень нагрузки:
├── Resource-based: CPU, Memory
├── Custom metrics: RPS, queue length, latency
└── External: бизнес-метрики

HPA: продвинутая конфигурация

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: AverageValue
        averageValue: 512Mi
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 1
        periodSeconds: 120

Custom Metrics для HPA

metrics:
- type: Pods
  pods:
    metric:
      name: http_requests_per_second
    target:
      type: AverageValue
      averageValue: "100"

Требует Prometheus Adapter для проброса метрик в K8s API.

KEDA: Event-Driven Autoscaling

KEDA — масштабирование на основе событий:

triggers:
- type: kafka
  metadata:
    bootstrapServers: kafka:9092
    consumerGroup: mygroup
    topic: mytopic
    lagThreshold: "100"

Поддерживает: Kafka, RabbitMQ, Redis, AWS SQS, Azure Service Bus и др.

Scale to Zero

Knative + Kourier:

• При отсутствии трафика → 0 реплик
• При запросе → быстрый старт (холодный старт ~100ms-2s)
• Идеально для event-driven, serverless workloads

Требует:

• Быстрого старта приложения (GraalVM Native Image)
• Queue Proxy для буферизации запросов при scale up

VPA: ограничения и конфликты

Не использовать с HPA по CPU:

• HPA хочет больше Pod’ов при высоком CPU
• VPA хочет больше CPU на Pod
• Конфликт → непредсказуемое поведение

Рекомендация:

• HPA для stateless workloads (горизонтально)
• VPA для stateful/монолитных workloads (вертикально)
• VPA в режиме Off для рекомендаций (что задать в requests)

Cluster Autoscaler vs Karpenter

Характеристика	Cluster Autoscaler	Karpenter
Скорость	Медленно (минуты)	Быстро (секунды)
Выбор инстанса	Ограниченный	Оптимизированный
Spot instances	Да	Да (лучше)
Провайдер	Cloud-specific	AWS (мульти-облако в разработке)

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

Без автоскейлинга:
- Пиковая нагрузка: 100 реплик (2 часа в день)
- Остальное время: 10 реплик простаивают
- Cost: 100 × 24h

С автоскейлингом:
- Пик: 100 реплик (2 часа)
- Off-peak: 10 реплик (22 часа)
- Cost: 100×2h + 10×22h = ~30% экономии

Troubleshooting

HPA не масштабирует:

kubectl describe hpa myapp
# Conditions:
#   AbleToScale    False   SucceededRescale  (last transition: ...)
#   ScalingActive  False   FailedGetResourceMetric

Проверьте:

1. Metrics Server работает?
2. Requests указаны?
3. Метрики доступны?

Pod’ы в Pending при масштабировании:

• Не хватает ресурсов на Node → Cluster Autoscaler должен сработать
• Проверьте лимиты quota: kubectl describe resourcequota

Резюме для Senior

• HPA — для обработки нагрузки, VPA — для подбора ресурсов, CA — для ёмкости.
• Не используйте HPA и VPA одновременно по одной метрике.
• Custom metrics (Prometheus Adapter) для бизнес-ориентированного скейлинга.
• KEDA для event-driven масштабирования (Kafka, RabbitMQ, SQS).
• Scale-to-zero (Knative) для serverless workloads.
• Behavior policies контролируют скорость scale up/down, предотвращают осцилляцию.
• Karpenter быстрее и умнее Cluster Autoscaler (AWS).
• Всегда настраивайте Resources Requests & Limits, иначе автоскейлинг не работает.

---

🎯 Шпаргалка для интервью

Обязательно знать:

• HPA — горизонтальное (больше Pod’ов), VPA — вертикальное (больше CPU/RAM), CA — больше Node
• HPA формула: desiredReplicas = ceil[current × (currentMetric / desiredMetric)]
• HPA требует Metrics Server и Resources Requests в Pod spec
• Не используйте HPA и VPA одновременно по одной метрике (конфликт)
• Custom metrics (Prometheus Adapter) для бизнес-ориентированного скейлинга
• Behavior policies (stabilization window) предотвращают осцилляцию
• KEDA — event-driven scaling (Kafka, RabbitMQ, SQS); Knative — scale-to-zero

Частые уточняющие вопросы:

• «Почему HPA не работает без requests?» — HPA считает процент от requests; без них нет baseline
• «Масштабирование по памяти — хорошая идея?» — Нет для Java (JVM не сразу возвращает память ОС)
• «Что такое KEDA?» — Kubernetes Event-driven Autoscaling; scaling по событиям (очереди, стримы)
• «Karpenter vs Cluster Autoscaler?» — Karpenter быстрее, умнее выбирает типы инстансов

Красные флаги (НЕ говорить):

• «HPA и VPA вместе для CPU» (конфликтуют, непредсказуемое поведение)
• «Масштабирую Java-приложение по памяти» (JVM memory management ломает метрику)
• «Cluster Autoscaler заменяет HPA» (CA добавляет Node, HPA добавляет Pod’ы — разные уровни)
• «Ставлю maxReplicas = 1000 без контроля» (риск огромных затрат)

Связанные темы:

• [[Что такое HorizontalPodAutoscaler (HPA)]] — детально об HPA
• [[Что такое ReplicaSet]] — механизм репликации
• [[Что такое Node в Kubernetes]] — Cluster Autoscaler