Ressourcenplaner und Auto-Scaling

Kurze Zusammenfassung

1. Korrekte Abfragen/Limits und QoS-Klassen.

2. Richtiges Styling (Topologie, Affinität, Prioritäten, Präemption).

3. Mehrstufiges Auto-Scaling: HPA/VPA/KEDA + Cluster/Node Autoscaler + Warmpools.

4. SLO-orientierte Logik (Latenz-/Queue-Tiefe) mit Anti-Flapping und Budgets.

Grundlegendes Ressourcenmodell

Requests/Limits und QoS-Klassen

Requests = Garantien für den Planer; Limits = Obergrenzen für die Laufzeit.
QoS: Garantiert (req = lim durch CPU/Speicher), Burstable (teilweise), BestEffort (nichts).
Produktionsdienstleistungen mit starren SLO - garantiert/Burstable; Hintergrund - Burstable/BestEffort.

CPU/Speicher/IO/Netzwerk

Die CPU ist elastisch (time-sharing), der Speicher ist steif (OOM-kill bei Überschreitung).
Im IO/Netzwerk Grenzen/Prioritäten separat setzen (cgroups/TC), sonst „laute Nachbarn“.

GPUs/Beschleuniger

Vektorabfragen (GPU = 1, VRAM über Profile), nodeSelector/taints und PodPriority für Kritik verwenden.
Für Inference - Batch-Größe und beheizte Modelle.

Stapelrichtlinien (Scheduling)

Prioritäten, Vorarbeiten und HVE

PriorityClass für kritische Pfade (Zahlungen, Login), Präemption erlaubt.
PodDisruptionBudget schützt minimale Replikate bei Evakuierung/Upgrades.

Affinität/Topologie

node/pod affinity für Glocke/Dekolokation (z.B. keine Replikate auf einen Host setzen).
topologySpreadConstraints richten die Pods nach Zonen/AZ aus.
NUMA/Topologie: pin-CPU/hugepages wo niedrige Latenz wichtig ist.

Teyints und Toleranzen

Trennen Sie die Pools: 'prod',' batch', 'gpu', 'system'. Kritik duldet weniger die Nachbarn.

Auto-Scaling: Pegel und Signale

1) HPA (Horizontal Pod Autoscaler)

Sceilit Replik Pods nach Metriken: CPU/Memory/Custom (Prometheus Adapter).
Gute Signale: latency p95/p99, queue length/lag, RPS per pod, consumer lag.
Anti-Flapping: Stabilisierung (stabilizationWindow), minimaler Schritt, 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 für den realen Verbrauch (aktualisiert die Empfehlungen).
Modi: 'Off' (Sammeln), 'Auto' (Neustart), 'Initial' (nur beim Start).
Praxis: Aktivieren Sie' Off '→ sammeln Sie Statistiken → wenden Sie sie auf Releases an.

3) KEDA/Warteschlangenbasiertes Scaling

Reagiert auf externe Signale: Kafka lag, SQS Tiefe, Redis Länge, Prometheus.
Ideal für Event/Queue Consumer (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 fügt Knoten hinzu/entfernt sie, wenn ein Mangel/Überschuss vorliegt.
Warmpools: vorgewärmte Knoten/vorbereitete Bilder (beschleunigen den Kaltstart).
Für Peaks - Step-Scaling und erhöhte minNodes im Voraus.

Reaktionsgeschwindigkeit und Aufwärmen

SLO-Reaktionsverzögerung: Frontschicht ≤ 1-2 Minuten, Backends/DB - separat und im Voraus.
Aufwärmen: TLS/DNS/Anschlüsse, Modelle laden, Cache und JIT aufwärmen.
Shadow-Load zum „Pumpen“ des Kollisionswegs vor dem Ereignis.

Anti-Flapping und Stabilität

Die Hysterese auf den Metriken, die Glättung (der Expunkt Durchschnitt).
Stabilisierungsfenster in HPA, groß in 'scaleDown'.
Step-Scaling statt „Säge“; rate-limit für die Änderung von Replikaten.
Budget-Scaling: Begrenzen Sie% des Datenverkehrs/der Replikate, die pro Minute hinzugefügt werden.

Beobachtbarkeit und SLO

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

• Das Wachstum der Pending-Pods, unschedulable Ereignisse, IP/Subnet-Mangel, Image-Pull lang, evictions.
• Traces: tailbasiertes Sampling auf p99-Schwänzen → sehen Engpässe beim Skale.

FinOps: Kosten der Elastizität

Metriken: $/1000 RPS, $/ms p95, $/Stunde Reserve.
Mix: on-demand + reserved + spot (für Nicht-Kritik).
Die Schwelle des Auto-Skale hängt mit den Kosten des Fehlers zusammen: Manchmal ist es vorteilhaft, einen warmen Vorrat zu halten.

Spezifität für iGaming/Fintech

Match/Turnier-Spitzen: Heben Sie' minReplicas' und minNodes im Voraus an, schalten Sie warme Pools ein und wärmen Sie Caches/Modelle auf.
Payment Consumers: KEDA durch lag + idempotency, Provider Limits (PSPs) als externe Auslöser der Degradation.
Antibot: separater Pool, schnelle Regelskala, „graue“ Routen.
Regulatory: PDBs bei Compliance Services, Prioritäten höher als bei Batch.

Schecks-Blätter

Projektierung

• Requests/Limits werden aus den Profiling-Daten ermittelt; QoS ist ausgewählt.
• PriorityClass, PDB, taints/tolerations und topologySpread - konfiguriert.
• HPA nach SLO-Metriken, nicht nur CPU.
• VPA in 'Off', um Empfehlungen zu sammeln (Migration zu 'Auto' geplant).
• KEDA/Warteschlangen für Ereignislasten.
• CA + warm pools, images werden zwischengespeichert (image pre-pull).

Betrieb

• Die Stabilisierung der Fenster und cooldowns ist gesetzt (Flapping ausgeschlossen).
• Alerts on pending/unschedulable, lag, p95, error-rate.
• Runbooks: „no nods“, „image not rectures“, „OOM/evict“, „storm retraits“.
• Capacity-Review monatlich: Fakt Skale vs Plan/Kosten.

Typische Fehler

HPA nur über CPU → lat-Regression bei IO/DB-Limits.
Das Fehlen von PDB und Prioritäten → Kritik wird zuerst vorgebracht.
Das Mischen von Kritik und Batch auf einem Pool ohne Taints → „laute Nachbarn“.
Null Erwärmung → Kaltstart auf dem Höhepunkt.
Aggressive' scaleDown '→ Säge und thrash Container.
KEDA ohne Idempotenz → doppelte Nachrichten im Sturm.

Mini-plejbuki

1) Vor dem Peak Event (T-30 Min)

1. Erhöhen Sie' minReplicas '/minNodes, aktivieren Sie warm pools.
2. CDN/DNS/TLS/Anschlüsse aufwärmen, Modelle laden.
3. Aktivieren Sie „graue“ Routen/Limits für Bots.
4. Dashboards prüfen: pending/lag/p95.

2) Mangel an Knoten (unschedulable)

1. Überprüfen Sie CA, Cloud-Kontingente, Subnetze/IP.
2. Zeitweilig Batch-Limits senken, Vorimplikation für niedrige Prioritäten ermöglichen.
3. Heben Sie vorübergehend einen größeren Instance-Typ oder einen zweiten Pool an.

3) Lag-Wachstum in der Warteschlange

1. KEDA: scale up durch Trigger; 2) Anhebung der Grenzen des Verbrauchers;

2. Aktivieren Sie idempotency-keys und backpressure producer.

4) Säge Repliken

1. Stabilisation/Cooldown erhöhen; 2) gehen Sie zu Step-Scaling;

2. glätten Sie die Metrik mit einem exponentiellen Durchschnitt.

konfig-Spickzettel

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

Ergebnis

Effizienter Planer und Auto-Scaling sind korrekte Abfragen/Limits + intelligentes Stapeln + mehrstufiges Scaling (HPA/VPA/KEDA/CA) + Aufwärmen und Anti-Flapping, gebunden an SLO und Millisekundenkosten. Fixieren Sie Richtlinien in IaC, beobachten Sie die „richtigen“ Metriken (Latenz/Verzögerung), halten Sie den Warmbestand unter Spitzen - und die Plattform wird elastisch, vorhersehbar und wirtschaftlich sein.