Pianificazione delle risorse e skailing automatico

Breve riepilogo

1. Query/limiti e classi corrette.

2. Posa corretta (topologia, affiniti, priorità, preemmissione).

3. Skailing automatico su più livelli: HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. Logica orientata SLO (latency/queue depth) con anti-flapping e budget.

Modello di base delle risorse

Richiesti/Limits e classi di QoS

Richiesti = garanzie per il pianificatore; Limits = soffitti runtime.
QoS: Guaranteed (req = lim per CPU/Memory), Burstable (parzialmente), BestEffort (niente).
Servizi di produzione con SLO rigido - Guaranteed/Burstable; di sottofondo - Burstable/BestEffort.

CPU/Memoria/IO/Rete

CPU - elastico (time-sharing), memoria rigida (OOM-kill quando superata).
Su IO/rete fissare i limiti/priorità separatamente (cgrups/TC), altrimenti «vicini rumorosi».

GPU/acceleratori

Richiedi vettoriale (GPU = 1, VRAM attraverso i profili), usa nodeSelector/taints e PodPriority per criticare.
Per l'inferance - batch size e riscaldamento dei modelli.

Criteri di posa (Scheduling)

Priorità, preemmissione e PDB

PriorityClass per percorsi critici (pagamenti, login), preemmissione consentita.
PodDisruptionBudget protegge le battute minime in caso di evacuazione/update.

Affiniti/Topologia

node/pod affinity per la colocalizzazione/decolocalizzazione (ad esempio, non posizionare repliche per host).
I topologySpreadConstraints allineano le aree/AZ.
NUMA/topologia: pin-CPU/hugepages dove la bassa latitudine è importante.

Teinti e tolerans

Esplorate i pool «prod», «batch», «gpu», «system». Le critiche vengono meno dai vicini.

Scailing automatico: livelli e segnali

1) HPA (Horizontal Pod Autoscaler)

Skeylite delle repliche per metriche: CPU/Memory/Custom (Prometheus Adatter).
Buoni segnali: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti-flapping stabilizzazione (stabilizationWindow), passo minimo, 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)

Sintonizza i richiesti/limits per il consumo reale (aggiorna le linee guida).
Modalità: «Off» (raccolta), «Auto» (riavvio), «Iniziale» (solo all'avvio).
La prassi è di attivare «Off» per raccogliere le statistiche e usarle per i rilasci.

3) KEDA/coda-scailing basato

Risponde ai segnali esterni: Kafka lag, SQS depth, Redis length, Prometheus.
Ideale per i concussori di eventi/code (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 aggiunge/rimuove le noci in caso di deficit/eccesso.
Warm pools: nodi/immagini preparate pre-riscaldati (accelerano il cold start).
Per i picchi, step-scaling e ingrandimento in anticipo.

Velocità di reazione e riscaldamento

Ritardo di risposta SLO: livello frontale 1-2 min, backend/database, separatamente e in anticipo.
Riscaldamento: TLS/DNS/connettori, caricamento dei modelli, riscaldamento della cache e JIT.
Carica Shadow per «pompare» il percorso di cold prima dell'evento.

Anti-flapping e stabilità

Isteresi sulle metriche, antialiasing ( . medio).
Stabilization windows in HPA, grandi in «scaleDown».
Step-scailing invece di «sega»; rate-limit per la modifica delle repliche.
Budget - Limitare il% del traffico/replica aggiunto in un minuto.

Osservabilità e SLO

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

• Crescita pending pods, eventi unschedulabili, deficit IP/subnet, immagine pull lungo, evictions.
• Trailer: tail-based sampling sulla coda p99, vediamo i punti di bottiglia nello skale.

FinOps - Costo di elasticità

Metriche: $/1000 RPS, $/mc p95, $/ora di riserva.
Mix: on-demand + reserved + spot (per non-criticare).
La soglia dello skale auto è associata al costo dell'errore: talvolta è vantaggioso mantenere la riserva warm.

Particolare per iGaming/Fintech

Picchi di partite/tornei: sollevare «minReplicas» e «minNodes», attivare il warm pools e riscaldare la cache/modello.
Consulenti di pagamento: KEDA per lag + idampotenza, limiti di provider (PSP) come inneschi esterni di degrado.
Antibot: pool separato, scala rapida delle regole, percorsi grigi.
Regolazione: PDB dei servizi di compilazione, le priorità sono superiori a quelle del batch.

Assegno fogli

Progettazione

• I richiesti/limits sono impostati in base alla profilassi; QoS selezionata.
• PriorityClass, PDB, taints/tolerations e topologySpread sono configurati.
• HPA per metriche SLO, non solo CPU.
• VPA in «Off» per raccogliere raccomandazioni (migrazione a «Auto» pianificata).
• KEDA/code per carichi di eventi.
• CA + warm pools, le immagini vengono memorizzate nella cache (immagine pre-pull).

Utilizzo

• Stabilization windows e cooldowns sono stati impostati (flapping escluso).
• Alert su pending/unschedulable, lag, p95, error-rate.
• Runbooks: «niente nodi», «immagine non si allunga», «OOM/evict», «tempesta retraica».
• Capacity-review mensilmente: il fatto di uno skale vs piano/costo.

Errori tipici

L'HPA è solo per CPU- →-regress per IO/limiti di database.
La mancanza di PDB e di priorità delle critiche si preannuncia la prima.
Una miscela di critici e batch su un solo proiettile senza taints, «vicini rumorosi».
Riscaldamento zero, inizio freddo a picco.
L'aggressivo' ' e i contenitori thrash.
KEDA senza idepotenza ha duplicato i messaggi durante la tempesta.

Mini playbook

1) Prima dell'evento di punta (T-30 min)

1. Ingrandire «minReplicas »/ minNodes, attivare il warm pools.
2. Scaldare CDN/DNS/TLS/connettori, caricare i modelli.
3. Abilita percorsi/limiti grigi per i bot.
4. Controlla dashboards: pending/lag/p95.

2) Deficit di nodi (unschedulable)

1. Controlla CA, quote cloud, subnet/IP.
2. Ridurre temporaneamente i limiti di batch, attivare la preemmissione per le basse priorità.
3. Aumentare temporaneamente il tipo o il secondo pool.

3) Crescita di lag in coda

1. KEDA: scale up per trigger; 2) alzare i limiti della consumatrice;

2. abilitare idempotency-keys e backpressure dei produttori.

4) Bottiglie di repliche

1. Aumenta stabilization/cooldown; 2) Passare allo scale step;

2. Alleggerire la metrica con la media esponenziale.

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

Totale

Pianificatore efficiente e skailing automatico sono richieste/limiti corrette + posa intelligente + skailing su più livelli (HPA/VPA/KEDA/CA) + riscaldamento e anti-flapping collegati a SLO e valore di millisecondi. Fissate le regole nel IaC, osservate le metriche «corrette» (latency/lag), tenete il warm-stock sotto i picchi e la piattaforma sarà elastica, prevedibile e economica.