Планувальник ресурсів і авто-скейлінг

Коротке резюме

1. Коректні запити/ліміти і класи QoS.

2. Правильне укладання (топологія, афініті, пріоритети, передемпція).

3. Багаторівневий авто-скейлінг: HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. SLO-орієнтована логіка (latency/queue depth) з анти-флапінгом і бюджетами.

Базова модель ресурсів

Requests/Limits і класи QoS

Requests = гарантії для планувальника; Limits = стелі для runtime.
QoS: Guaranteed (req = lim по CPU/Memory), Burstable (частково), BestEffort (нічого).
Виробничі сервіси з жорсткими SLO - Guaranteed/Burstable; фонові - Burstable/BestEffort.

CPU/Пам'ять/IO/Мережа

CPU - еластичний (time-sharing), пам'ять - жорстка (OOM-kill при перевищенні).
На IO/мережу закладайте ліміти/пріоритети окремо (cgroups/TC), інакше «галасливі сусіди».

GPU/акселератори

Запитуйте векторно (GPU = 1, VRAM через профілі), використовуйте nodeSelector/taints і PodPriority для критики.
Для інференсу - batch size і підігрів моделей.

Політики укладання (Scheduling)

Пріоритети, передемпція та PDB

PriorityClass для критичних шляхів (платежі, логін), передемпція дозволена.
PodDisruptionBudget захищає мінімальні репліки при евакуації/апдейтах.

Аффініті/Топологія

node/pod affinity для колокації/деколокації (наприклад, не класти репліки на один хост).
topologySpreadConstraints вирівнюють поди по зонах/AZ.
NUMA/топологія: pin-CPU/hugepages там, де важлива низька латентність.

Тейїнти і толеранси

Розведіть пули: `prod`, `batch`, `gpu`, `system`. Критика терпить менше сусідів.

Авто-скейлінг: рівні та сигнали

1) HPA (Horizontal Pod Autoscaler)

Скейліт репліки подів за метриками: CPU/Memory/кастомні (Prometheus Adapter).
Хороші сигнали: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Анти-флапінг: стабілізація (stabilizationWindow), мінімальний крок, cooldown.

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
minReplicas: 6 maxReplicas: 120 behavior:
scaleUp:
stabilizationWindowSeconds: 60 policies: [{ type: Percent, value: 100, periodSeconds: 60 }]
scaleDown:
stabilizationWindowSeconds: 300 policies: [{ type: Percent, value: 20, periodSeconds: 60 }]
metrics:
- type: Pods pods:
metric:
name: http_server_request_duration_seconds_p95 target:
type: AverageValue averageValue: "0.25" # 250ms

2) VPA (Vertical Pod Autoscaler)

Тюнінгує requests/limits під реальне споживання (оновлює рекомендації).
Режими: 'Off'( збір),'Auto'( перезапуск),'Initial'( тільки при старті).
Практика: увімкнути «Off» → зібрати статистику → застосовувати при релізах.

3) KEDA/черга-заснований скейлінг

Реагує на зовнішні сигнали: Kafka lag, SQS depth, Redis length, Prometheus.
Ідеальний для консьюмерів подій/черг (EDA).

yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: { name: consumer-scale }
spec:
scaleTargetRef: { name: txn-consumer }
minReplicaCount: 2 maxReplicaCount: 200 cooldownPeriod: 120 pollingInterval: 5 triggers:
- type: kafka metadata:
bootstrapServers: broker:9092 consumerGroup: tx-cg topic: payments lagThreshold: "10000"

4) Cluster/Node Autoscaler (CA) + Warm Pools

CA додає/прибирає ноди при дефіциті/надлишку.
Warm pools: заздалегідь розігріті ноди/підготовлені образи (прискорюють cold start).
Для піків - step-scaling і збільшений minNodes заздалегідь.

Швидкість реакції і прогрів

SLO-затримка реакції: фронтовий шар ≤ 1-2 хв, бекенди/БД - окремо і заздалегідь.
Прогрів: TLS/DNS/коннекти, завантаження моделей, прогрів кешу і JIT.
Shadow-навантаження для «прокачування» колд-шляху до події.

Анти-флапінг і стабільність

Гістерезис на метриках, згладжування. середні).
Stabilization windows в HPA, великі в'scaleDown'.
Step-скейлінг замість «пила»; rate-limit на зміну реплік.
Budget-скейлінг: обмежити% трафіку/реплік, що додаються за хвилину.

Спостережуваність і SLO

• p95/99 latency, error rate, throughput, queue depth/lag, CPU/Memory saturation, pod pending time, node pressure.

• Зростання pending pods, unschedulable події, дефіцит IP/підмереж, image pull довгий, evictions.
• Трейси: tail-based sampling на хвости p99 → бачимо вузькі місця при скейлі.

FinOps: Вартість еластичності

Метрики: $/1000 RPS, $/мс p95, $/година резерву.
Мікс: on-demand + reserved + spot (для не-критики).
Поріг авто-скейла пов'язаний з вартістю помилки: іноді вигідно тримати warm-запас.

Специфіка для iGaming/фінтех

Піки матчів/турнірів: заздалегідь підняти'minReplicas'і minNodes, включити warm pools і прогрів кешів/моделей.
Платіжні консьюмери: KEDA по lag + ідемпотентність, ліміти провайдерів (PSP) як зовнішні тригери деградації.
Антибот: окремий пул, швидкий масштаб правил, «сірі» маршрути.
Регуляторика: PDB у комплаєнс-сервісів, пріоритети вищі, ніж у batch.

Чек-листи

Проектування

• Requests/limits задані за даними профілювання; QoS вибрана.
• PriorityClass, PDB, taints/tolerations і topologySpread - налаштовані.
• HPA по SLO-метрикам, не тільки CPU.
• VPA в'Off'для збору рекомендацій (міграція до'Auto'планово).
• KEDA/черги для подієвих навантажень.
• CA + warm pools, образи кешуються (image pre-pull).

Експлуатація

• Stabilization windows і cooldownы задані (флапінг виключений).
• Алерти на pending/unschedulable, lag, p95, error-rate.
• Runbooks: «немає нод», «image не тягнеться», «OOM/evict», «шторм ретраїв».
• Capacity-review щомісяця: факт скейла vs план/вартість.

Типові помилки

HPA тільки по CPU → lat-регрес при IO/лімітах БД.
Відсутність PDB і пріоритетів → критика передемптиться першою.
Змішання критики і batch на одному пулі без taints → «галасливі сусіди».
Нульовий прогрів → холодні старти на піку.
Агресивний'scaleDown'→ пила і thrash контейнерів.
KEDA без ідемпотентності → дублікати повідомлень при штормі.

Міні-плейбуки

1) Перед піковою подією (T-30 хв)

1. Збільшити'minReplicas '/minNodes, активувати warm pools.
2. Прогріти CDN/DNS/TLS/коннекти, завантажити моделі.
3. Включити «сірі» маршрути/ліміти для ботів.
4. Перевірити dashboards: pending/lag/p95.

2) Дефіцит нод (unschedulable)

1. Перевірити CA, квоти хмари, підмережі/IP.
2. Тимчасово знизити ліміти batch, включити передемпцію для низьких пріоритетів.
3. Підняти тимчасово більший інстанс-тип або другий пул.

3) Зростання lag в черзі

1. KEDA: scale up по тригеру; 2) підняти ліміти консьюмера;

2. включити idempotency-keys і backpressure продьюсерів.

4) Пила реплік

1. Збільшити stabilization/cooldown; 2) перейти на step-скейлінг;

2. згладити метрику експоненціальним середнім.

Конфіг-шпаргалки

yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: { name: api-vpa }
spec:
targetRef: { apiVersion: "apps/v1", kind: Deployment, name: api }
updatePolicy: { updateMode: "Off" } # собираем рекомендации

--balance-similar-node-groups
--expander=least-waste
--max-empty-bulk-delete=10
--scale-down-utilization-threshold=0.5
--scale-down-delay-after-add=10m

yaml topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }

Підсумок

Ефективний планувальник і авто-скейлінг - це коректні запити/ліміти + розумне укладання + багаторівневий скейлінг (HPA/VPA/KEDA/CA) + прогрів і анти-флаппінг, прив'язані до SLO і вартості мілісекунди. Зафіксуйте політики в IaC, спостерігайте за «правильними» метриками (latency/lag), тримайте warm-запас під піки - і платформа буде еластичною, передбачуваною і економною.