Ресурстарды жоспарлаушы және авто-скейлинг

Қысқаша түйіндеме

Тұрақты скейлинг төрт тірекке сүйенеді:

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 (CPU/Memory бойынша req = lim), 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 жүктемесі.

Анти-флаппинг және тұрақтылық

Метриктегі гистерезис, тегістеу (эксп. орташа).
HPA-да stabilization windows, үлкен '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.
Tracks: 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 ғана емес.
Ұсынымдарды жинау үшін 'Off' -ке VPA ('Auto' -ға жоспарлы көшу).
KEDA/оқиғалық жүктемелер үшін кезек.
CA + warm pools, кескіндер кэштеледі (image pre-pull).

Пайдалану

Тұрақтандыру windows және cooldowns орнатылған (флаппинг алынып тасталған).
pending/unschedulable, lag, p95, error-rate.
Runbooks: «нод жоқ», «сурет созылмайды», «OOM/evict», «ретраялардың дауылы».
Capacity-review ай сайын: факт скейл vs жоспар/құны.

Типтік қателер

HPA IO/БД лимиттері кезінде CPU → lat-регресс бойынша ғана.
PDB мен басымдықтардың жоқтығы → сын бірінші болып белгіленеді.
taints → «шу көршілері» жоқ бір пулда сын мен batch араластыру.
Нөлдік жылыту → шыңында суық бастау.
Агрессивті '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-қорды шыңдардың астында ұстаңыз - және платформа икемді, болжамды және үнемді болады.