Planificateur de ressources et auto-skating

Résumé succinct

1. Requêtes/limites correctes et classes QoS.

2. Le bon empilement (topologie, affinité, priorités, préamplication).

3. Auto-skating à plusieurs niveaux : HPA/VPA/KEDA + Cluster/Node autoscaler + warm pools.

4. Logique orientée SLO (latency/queue depth) avec anti-flapping et budgets.

Modèle de ressources de base

Demandes/Limites et classes QoS

Requests = garanties pour le planificateur ; Limites = plafonds pour runtime.
QoS : Guaranteed (req = bou par CPU/Mémoire), Burstable (en partie), BestEffort (rien).
Services de production avec SLO rigide - Guaranteed/Burstable ; l'arrière-plan est Burstable/BestEffort.

CPU/Mémoire/IO/Réseau

Le CPU est élastique (time-sharing), la mémoire est dure (OOM-kill en cas de dépassement).
Sur un IO/réseau, fixez les limites/priorités séparément (cgroups/TC), sinon « voisins bruyants ».

GPU/accélérateurs

Demandez vectoriellement (GPU = 1, VRAM via les profils), utilisez nodeSelector/taints et PodPriority pour critiquer.
Pour l'inference - taille batch et modèles chauffants.

Règles d'empilement

Priorités, préemption et APB

PrioritéClasse pour les chemins critiques (paiements, login), préamplication autorisée.
PodDissolutionBudget protège les répliques minimales lors de l'évacuation/updates.

Affinity/Topologie

node/pod affinity pour la colocation/décolocation (par exemple, ne pas mettre de répliques sur un seul hôte).
topologySpreadConstraints alignent les pods sur les zones/AZ.
NUMA/topologie : pin-CPU/hugepages lorsque la latence faible est importante.

Les Teyints et les Tolérances

Scoop pools : 'prod', 'batch', 'gpu', 'system'. Les critiques sont moins tolérées par les voisins.

Auto-Skaling : niveaux et signaux

1) HPA (Horizontal Pod Autoscaler)

Scale les répliques de pods par métriques : CPU/Memory/Custom (Prometheus Adapter).
Bons signaux : latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti-flapping : stabilisation (stabilisationWindow), étape minimale, 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)

Tuning requests/limits à la consommation réelle (met à jour les recommandations).
Modes : 'Off' (collection), 'Auto' (redémarrage), 'Initial' (au démarrage seulement).
Pratique : activez 'Off' → collectez des statistiques → appliquez-les lors des sorties.

3) KEDA/file d'attente à base de skate

Réagit aux signaux externes : Kafka lag, SQS depth, Redis length, Prometheus.
Idéal pour les consumers d'événements/files d'attente (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 ajoute/retire les noeuds en cas de déficit/excès.
Warm pools : Nodes préchauffés/images préparées (accélèrent cold start).
Pour les pics - step-scaling et agrandi minNodes à l'avance.

Vitesse de réaction et échauffement

Le SLO-retard de la réaction : la couche de front ≤ 1-2 mines, bekendy/BD - séparément et d'avance.
Échauffement : TLS/DNS/connexions, chargement des modèles, échauffement du cache et JIT.
Charge shadow pour « pomper » le chemin de cold avant l'événement.

Anti-flapping et stabilité

Hystérésis sur les métriques, lissage (*. moyenne).
Windows de stabilisation dans HPA, grand dans 'scaleDown'.
Step-Skyling au lieu de « scie » ; rate-limit pour modifier les répliques.
Budget-Skaling : limitez le pourcentage de trafic/répliques ajoutés en une minute.

Observabilité et SLO

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

• Croissance pending pods, événements indestructibles, déficit IP/sous-réseaux, image pull long, événements.
• Tracés : tail-based sampling sur les queues p99 → voir les goulots d'étranglement dans le skate.

FinOps : le coût de l'élasticité

Métriques : $/1000 RPS, $/ms p95, $/heure de réserve.
Mix : on-demand + reserved + spot (pour les non-critiques).
Le seuil auto-skale est lié au coût de l'erreur : il est parfois avantageux de garder une réserve de warm.

Spécificité pour iGaming/fintech

Matchs/tournois : Soulevez 'minReplicas' et minNodes à l'avance, activez warm pools et réchauffez les caches/modèles.
Conseils de paiement : KEDA pour lag + idempotence, limites des fournisseurs (PSP) comme déclencheurs externes de dégradation.
Antibot : pool séparé, échelle rapide des règles, itinéraires « gris ».
Réglementation : L'APB a des services de conformité, des priorités supérieures à celles de batch.

Chèques-feuilles

Conception

• Demandes/limites données sur les données de profilage ; QoS est sélectionné.
• PriorityClass, PDB, taints/tolerations et topologySpread - personnalisés.
• HPA selon les métriques SLO, pas seulement CPU.
• VPA dans 'Off' pour recueillir des recommandations (la migration vers 'Auto'est planifiée).
• KEDA/files d'attente pour les charges d'événements.
• CA + warm pools, images en cache (image pre-pull).

Exploitation

• Paramétrage Windows et cooldowns spécifiés (flapping exclu).
• Alerties sur pending/unschedulable, lag, p95, error-rate.
• Runbooks : « pas de nodules », « l'image ne s'étend pas », « OOM/evict », « tempête de rétrograves ».
• Capacity-review mensuel : le fait de skale vs plan/coût.

Erreurs typiques

HPA uniquement par CPU → lat-régression sous IO/limites OBD.
L'absence d'APB et de priorités → les critiques sont les premières à s'exprimer.
Mélange de critiques et de batch sur un pool sans taints → « voisins bruyants ».
Chauffage à zéro → démarrage à froid au sommet.
L'agressif 'scaleDown' → bu et thrash conteneurs.
KEDA sans idempotence → messages dupliqués en cas de tempête.

Mini-plejbouki

1) Avant l'événement de pointe (T-30 min)

1. Agrandir 'minReplicas '/minNodes, activer warm pools.
2. Chauffer CDN/DNS/TLS/connexions, charger les modèles.
3. Inclure les itinéraires « gris »/limites pour les bots.
4. Vérifiez dashboards : pending/lag/p95.

2) Déficit de nodules (indestructible)

1. Vérifiez CA, quotas cloud, sous-réseaux/IP.
2. Abaissez temporairement les limites de batch, activez la préamplication pour les faibles priorités.
3. Soulevez temporairement une instance de type ou un deuxième pool.

3) Croissance lag dans la file d'attente

1. KEDA : scale up par déclencheur ; 2) augmenter les limites du consumer ;

2. activer les clés idempotency et backpressure des vendeurs.

4) Scie réplique

1. Augmenter la stabilisation/cooldown ; 2) passer au skating step ;

2. lisser la métrique avec la moyenne exponentielle.

Config-Spargalki

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

Total

Un planificateur efficace et un auto-skating sont des demandes/limites correctes + un empilement intelligent + un skating multi-niveaux (HPA/VPA/KEDA/CA) + un échauffement et un anti-flapping liés au SLO et au coût de la milliseconde. Fixez les politiques dans l'IaC, observez les mesures « correctes » (latency/lag), gardez la marge de warm sous les pics - et la plate-forme sera élastique, prévisible et économique.