---

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