Planificator de resurse și scalare automată

Scurt rezumat

1. Cereri/limite corecte și clase QoS.

2. Stivuire corectă (topologie, afinitate, priorități, preempțiune).

3. Scalare automată pe mai multe niveluri: HPA/VPA/KEDA + Cluster/Node autoscaler + bazine calde.

4. Logica orientată spre SLO (latență/adâncimea cozii) cu anti-flapping și bugete.

Modelul resurselor de bază

Cereri/limite și clase QoS

Cereri = garanții pentru planificator; Limite = plafoane pentru durata de funcționare.
QoS: Garantat (req = lim by CPU/Memory), Burstable (parțial), BestEfort (nimic).
Servicii de producție cu SLO-uri dure - garantate/burstabile; fundal - Burstable/BestEfort.

Procesor/memorie/IO/rețea

Procesor - elastic (partajarea timpului), memorie - greu (OOM-kill dacă este depășit).
Pe IO/rețea, stabiliți limite/priorități separat (cgrups/TC), în caz contrar „vecini zgomotoși”.

GPU/Acceleratoare

Întrebați vectorul (GPU = 1, VRAM prin profile), utilizați nodeSelector/cauciucuri și PodPriority pentru critici.
Pentru deducție - dimensiunea lotului și încălzirea modelului.

Politici de planificare

Priorități, preempțiune și PDB

PriorityClass pentru căi critice (plăți, conectare), este permisă preempțiunea.
PodDisruptionBudget protejează indicii minime în timpul evacuării/actualizărilor.

Afinitate/Topologie

nod/pod afinitate pentru colocare/decolocație (de exemplu, nu pune replici pe o gazdă).
topologieSpreadConstrângerile aliniază vatra la zonele/AZ.
NUMA/topologie: pin-CPU/hugepages în cazul în care latența scăzută este importantă.

Teyinths și toleranțe

Piscine separate: "prod'," lot "," gpu "," sistem ". Critica suportă mai puţini vecini.

Auto-scalare: niveluri și semnale

1) HPA (Autoscaler orizontal Pod)

Replici la scară de păstăi după valori: CPU/Memory/custom (Prometheus Adapter).
Semnale bune: latență p95/p99, lungime coadă/lag, RPS per pod, lag de consum.
Anti-clapare: stabilizare (stabilizareFereastră), pas minim, 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 (Autoscaler Pod vertical)

Tunes cereri/limite pentru consumul real (actualizări recomandări).
Moduri: 'Off', 'Auto' (restart), 'Initial' (numai la start).
Practică: activați „Off” → colectați statistici → se aplică la versiuni.

3) Scalarea bazată pe KEDA/coadă

Reacționează la semnalele externe: Kafka lag, adâncimea SQS, lungimea Redis, Prometheus.
Ideal pentru consumatorii de evenimente/cozi (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/Nod Autoscaler (CA) + Piscine calde

CA adaugă/elimină noduri la deficiență/exces.
Piscine calde: noduri preîncălzite/imagini pregătite (accelerarea pornirii la rece).
Pentru vârfuri - scalarea treptată și mărirea minNodes în avans.

Rata de reacție și încălzirea

Întârziere reacție SLO: strat frontal ≤ 1-2 minute, backends/DB - separat și în prealabil.
Warm-up: TLS/DNS/conexiuni, modele de încărcare, cache warm-up și JIT.
Umbra de încărcare pentru „pompare” calea rece la eveniment.

Anti-flapping și stabilitate

Histerezis pe metrică, netezire (exp. mediu).
Ferestre de stabilizare în HPA, mari în „scară în jos”.
Scalarea treptată în loc de „ferăstrău”; limită de rată pentru modificarea replicilor.
Scalarea bugetului: limitați% din trafic/replici adăugate pe minut.

Observabilitate și SLO

• p95/99 latență, rata de eroare, debit, adâncimea de coadă/lag, CPU/saturație de memorie, timpul de așteptare al capsulei, presiunea nodului.

• Păstăi de creștere în așteptare, evenimente neprogramabile, penurie IP/subrețea, tragere de imagine lungă, evacuări.
• Trasee: eșantionare pe bază de coadă pe cozi p99 → vedem blocaje la scalare.

FinOps: costul elasticității

Valori: $/1000 RPS, $/ms p95, $/oră rezervă.
Mix: la cerere + rezervat + spot (pentru non-critică).
Pragul la scară automată este legat de costul erorii: uneori este profitabil să păstrați stocul cald.

Specificitate pentru iGaming/fintech

Vârfuri de meci/turneu: ridicați 'minReplicas' și minNodes în avans, porniți piscine calde și încălziți caches/modele.
Consumatorii de plăți: KEDA prin lag + idempotență, limitele furnizorului (PSP) ca declanșatori externi ai degradării.
Antibot: o piscină separată, o scară rapidă de reguli, rute „gri”.
Reglementare: PDB pentru serviciile de conformitate, prioritățile sunt mai mari decât pentru lot.

Foi de verificare

Design

• Cereri/limite specificate de datele de profilare; QoS selectat.
• PriorityClass, PDB, cauciucuri/toleranțe și topologySpread - configurat.
• HPA de metrici SLO, nu doar CPU.
• VPA la 'Off' pentru a colecta recomandări (migrarea la 'Auto' este planificată).
• KEDA/Cozi de încărcare eveniment.
• CA + piscine calde, imaginile sunt cache (imagine pre-pull).

Funcționare

• Ferestrele de stabilizare și răcirea sunt setate (excluse din flapping).
• Alerte în așteptare/neprogramabile, lag, p95, error-rate.
• Runbooks: „fără noduri”, „imaginea nu se întinde”, „OOM/evacuare”, „furtună retrasă”.
• Capacitatea de revizuire lunară: faptul de scară vs plan/cost.

Greșeli comune

HPA numai prin CPU → lat-regresie cu IO/limite de baze de date.
Lipsa PDB și prioritățile → criticile vor fi primele.
Amestecarea criticii și a lotului pe aceeași piscină fără colanți → „vecini zgomotoși”.
Zero încălzire → frig începe la vârf.
Agresiv "ScaleDown' → văzut și thrash containere.
KEDA fără idempotență → duplicați mesajele într-o furtună.

Mini cărți de redare

1) Înainte de eveniment de vârf (T-30 min)

1. Creșteți 'minReplicas '/minNodes, activați piscine calde.
2. Încălziți conexiunile CDN/DNS/TLS/, modelele de încărcare.
3. Includeți rute gri/limite pentru roboți.
4. Verificați tablourile de bord: în așteptare/lag/p95.

2) Deficiență de nod (neprogramabilă)

1. Verificați CA, cote cloud, subrețele/IP.
2. Limitele lot temporar mai mici, permite preemption pentru priorități mici.
3. Ridicați un tip de instanță temporar mai mare sau un al doilea bazin.

3) Creșterea decalajului în coadă

1. KEDA: scalați prin declanșare; 2) ridicarea limitelor consumatorilor;

2. Activați tastele de idempotență și producătorii de backpressure.

4) A văzut replici

1. Creșterea stabilizării/reactivării; 2) comuta la pas-scalare;

2. netezește metrica cu o medie exponențială.

Pătuț config

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 } }

Rezultat

Programatorul eficient și auto-scalarea sunt cereri/limite corecte + stivuire inteligentă + scalare pe mai multe niveluri (HPA/VPA/KEDA/CA) + încălzire și anti-flapping, legate de costurile SLO și milisecunde. Fixați politicile în IaC, respectați prin măsurători „corecte” (latență/lag), păstrați stocul cald sub vârfuri - iar platforma va fi elastică, previzibilă și economică.