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

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

Устойчивый скейлинг держится на четырех опорах:

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.

Пример HPA (latency-driven):

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).

KEDA ScaledObject (Kafka lag):

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

Ключевые SLI:

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. сгладить метрику экспоненциальным средним.

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

VPA (сбор рекомендаций):

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

Cluster Autoscaler (идеи флагов, концепт):


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

Topology spread (равномерность по зонам):

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

Итог

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