Capacity Planning und Skalierungs-Architektur

Lernziele

Nach dieser Lektion kannst du Capacity Planning auf Plattform-Ebene strukturieren: die drei Autoscaling-Schichten (HPA, VPA, Cluster Autoscaling) und was sie nicht lösen, Headroom als bewusste Geschäftsentscheidung, Forecasting aus Nutzungsdaten und Tenant-Pipeline, sowie Cluster-Sizing-Grenzen. Du kannst erklären, warum „die Cloud skaliert doch unendlich” als Kapazitätsstrategie scheitert.

Das Problem: Elastisch ist nicht dasselbe wie geplant

Die verlockende These lautet: Autoscaling existiert, also ist Kapazität ein gelöstes Problem. Drei Realitäten widerlegen das. Erstens Latenz: Eine neue Node braucht je nach Cloud und Image-Größe Minuten — ein Traffic-Spike braucht Sekunden. Was in diesen Minuten passiert, entscheidet Headroom, nicht der Autoscaler. Zweitens Verfügbarkeitsgrenzen: Instanztypen sind in Availability Zones regelmäßig ausverkauft, Cloud-Konten haben Quotas (vCPU-Limits pro Region!), und Reservierungen brauchen Vorlauf. Drittens Ökonomie: Wer rein reaktiv skaliert, kauft alles zum On-Demand-Preis und verschenkt Reserved-Instance-/Savings-Plan-Rabatte, die Planung vorausgesetzt hätten.

Für eine Plattform mit fünfzig Tenants kommt die Governance-Dimension dazu: Kapazität ist geteilt, also ist ihre Erschöpfung ein Multi-Tenant-Incident. Capacity Planning ist die Disziplin, die aus „hoffentlich reicht’s” eine überprüfbare Aussage macht: Wir können Last X mit Wahrscheinlichkeit Y bedienen und wissen Z Wochen vorher, wenn das kippt.

Die drei Autoscaling-Schichten — und ihre Lücken

Bevor du planst, musst du wissen, was die Automatik leistet:

HPA (Horizontal Pod Autoscaler) skaliert Pod-Replicas nach Metriken (CPU-Auslastung, Custom Metrics wie Queue-Länge). Er löst das Problem innerhalb vorhandener Node-Kapazität — sind die Nodes voll, erzeugt er nur Pending Pods.

VPA (Vertical Pod Autoscaler) passt Requests/Limits einzelner Workloads an die gemessene Nutzung an — primär ein Rightsizing-Werkzeug (Lektion 21): Er macht die Requests ehrlich, auf denen alle weitere Planung aufbaut. HPA und VPA auf derselben Metrik (CPU) zu kombinieren ist konfliktträchtig und braucht Sorgfalt.

Cluster Autoscaler / Karpenter fügt Nodes hinzu, wenn Pods pending sind, und räumt leere Nodes ab. Karpenter wählt dabei Instanztypen flexibel pro Workload-Anforderung — gut gegen das Bin-Packing-Problem. Aber auch diese Schicht ist reaktiv: Sie handelt, wenn der Mangel schon da ist, und sie scheitert an Quota- und Verfügbarkeitsgrenzen genau dann, wenn alle anderen in der Region dasselbe tun.

Die Lücken der Automatik definieren den Planungsbedarf: Headroom für die Minuten, die Scaling dauert; Forecast für die Wochen, die Quota-Erhöhungen und Reservierungen dauern; Limits für die Dinge, die gar nicht skalierbar sind — etwa die Control Plane: etcd-Objektzahl, API-Server-Last und die praktischen Grenzen pro Cluster (Kubernetes nennt als getestete Obergrenzen u. a. 5.000 Nodes und 150.000 Pods, reale Plattformen splitten weit früher). Ab einer gewissen Größe ist die Antwort nicht „größerer Cluster”, sondern „mehr Cluster” (Lektion 10).

Headroom: Versicherung mit Preisschild

Headroom ist bewusst vorgehaltene, ungenutzte Kapazität. Er hat drei Treiber, die du getrennt beziffern solltest:

1. Spike-Puffer: Wie viel Lastanstieg muss sofort — schneller als Node-Provisioning — bedienbar sein? Datenbasis: historische Spitzen (P99 über P50 der Tageskurve), bekannte Events (Marketing-Kampagnen, Saisonspitzen).
2. Ausfall-Puffer: Beim Verlust einer Availability Zone müssen die verbleibenden Zonen die Last tragen. Bei drei Zonen heißt das: jede Zone darf höchstens zu ⅔ ausgelastet sein, sonst ist der Zonenausfall ein Kapazitäts-Incident.
3. Betriebs-Puffer: Rolling Upgrades (Lektion 26) brauchen Surge-Kapazität, um Nodes zu drainen, ohne Workloads zu verdrängen.

Headroom kostet linear Geld — deshalb ist seine Höhe eine Geschäftsentscheidung, keine rein technische: „15 % Puffer kosten N €/Monat und decken Spikes bis X ab; 30 % kosten 2N und decken zusätzlich Y” ist die Vorlage, die ein Platform-Team dem Management schuldet. Senken lässt sich der Preis durch Workload-Klassen: Wenn Batch- und Best-Effort-Lasten (PriorityClasses, Lektion 21) im Spike-Fall verdrängbar sind, ist ihre Kapazität dein Headroom — bezahlter Puffer, der im Normalfall produktiv arbeitet. Spot-Instanzen für diese Klassen drücken die Kosten weiter.

Forecasting: Trend plus Pipeline plus Stress-Test

Plattform-Forecasting hat zwei Quellen, die du kombinierst:

Organisches Wachstum aus Telemetrie: Verlauf von Requests-Summe (nicht Usage — Requests treiben das Scheduling, Lektion 21), Node-Anzahl und Auslastung über Monate, extrapoliert als Trend mit Saisonalität. Eine simple lineare Regression über die letzten zwei Quartale schlägt in der Praxis die meisten Bauchgefühle.

Diskrete Ereignisse aus der Organisation: Die Tenant-Pipeline (drei neue Teams onboarden in Q3 — multipliziert mit dem empirischen Durchschnittsbedarf pro Team), angekündigte Produkt-Launches, Migrationswellen. Diese Information steht in keinem Dashboard — Capacity Planning braucht deshalb einen Kommunikationskanal zur Organisation, etwa eine Frage im Onboarding-Prozess („erwartete Größenordnung in 6 Monaten?”).

Aus beidem entsteht ein Bericht mit Ampel-Logik pro Cluster/Pool: aktuelle Auslastung gegen Kapazität, prognostizierter Zeitpunkt des Erreichens definierter Schwellen (z. B. „80 % der Quota-Grenze in 9 Wochen”), empfohlene Aktion mit Vorlaufzeit (Quota-Request bei der Cloud, Reservierungskauf, neuer Cluster). Quartalsweise erstellt, monatlich geprüft — und ergänzt um Lasttests gegen Staging (Lektion 23), die verifizieren, dass die theoretische Kapazität praktisch erreichbar ist, bevor der Forecast sie verspricht.

Praxis: Kapazitäts-Snapshot und Headroom-Rechnung

1. Ist-Aufnahme im Cluster (kind oder echter Cluster):

# Kapazität und reservierte Anteile pro Node:
kubectl describe nodes | grep -A 8 "Allocated resources"

# Summe der Requests aller Pods (jq vorausgesetzt):
kubectl get pods -A -o json | jq -r '
  [.items[].spec.containers[].resources.requests.cpu // "0"] | length'
# Aussagekräftiger mit kubectl-view-allocations (krew-Plugin):
kubectl view-allocations -g resource

Vergleiche drei Zahlen pro Ressource: Kapazität, Requests-Summe, tatsächliche Nutzung (kubectl top nodes). Die Lücke Requests→Nutzung ist dein Rightsizing-Potenzial; die Lücke Kapazität→Requests dein realer Headroom.

2. Headroom-Rechnung (Papier): Gegeben: 30 Nodes à 16 vCPU über 3 Zonen, Requests-Summe 280 vCPU, gemessene Spike-Spitze +20 % binnen einer Minute, Node-Provisioning dauert 4 Minuten. Berechne: (a) Reicht der Headroom für den Spike, bevor neue Nodes da sind? (b) Überlebt die Plattform einen Zonenausfall ohne Verdrängung von Produktions-Workloads? (c) Was änderst du, wenn (b) scheitert — mehr Nodes oder verdrängbare Batch-Klasse?

3. Forecast-Skizze: Nimm eine fiktive Wachstumsreihe (Requests-Summe der letzten 6 Monate: 180, 195, 205, 230, 250, 280 vCPU) und bestimme, wann die aktuelle Kapazität (480 vCPU abzüglich Zonen-Puffer) erreicht ist — und welcher Bestellvorlauf daraus folgt.

Typische Stolperfallen

Autoscaling als Planungsersatz: Reaktive Skalierung scheitert an Provisioning-Latenz, Cloud-Quotas und Instanz-Verfügbarkeit — gerade bei regionsweiten Ereignissen, wenn alle gleichzeitig skalieren. Die Automatik exekutiert; planen musst du.

Auf Usage statt Requests planen: Der Scheduler platziert nach Requests. Ein Cluster mit 30 % CPU-Nutzung kann voll sein — Pending Pods bei leer wirkenden Dashboards sind das klassische Symptom. Erst Rightsizing (VPA-Daten), dann Sizing.

Zonen-Mathematik ignorieren: „Wir haben 33 % Headroom” klingt komfortabel — verteilt über drei Zonen ist es exakt die Grenze, bei der ein Zonenausfall keinerlei Reserve mehr lässt. Headroom immer pro Ausfall-Domäne rechnen.

Forecast ohne Organisations-Input: Telemetrie extrapoliert die Vergangenheit; das Onboarding von drei Großteams steht nicht in Prometheus. Ohne Pipeline-Sicht wird jeder größere Tenant zur Überraschung.

Interview-Vorbereitung

Auf „Wie machst du Capacity Planning für eine Plattform?” antwortest du in vier Schichten: Automatik einordnen (HPA/VPA/Cluster-Autoscaler lösen Sekunden- bis Minuten-Elastizität innerhalb von Grenzen) → Headroom (bewusst bezifferter Puffer für Spikes, Zonenausfall und Upgrades — als Geschäftsentscheidung mit Preisschild, gesenkt durch verdrängbare Workload-Klassen) → Forecast (Trend aus Requests-Telemetrie plus diskrete Ereignisse aus der Tenant-Pipeline, mit Vorlaufzeiten für Quotas und Reservierungen) → Grenzen (Control-Plane- und Cluster-Limits → ab Schwelle horizontal in mehr Cluster).

Wahrscheinliche Follow-ups:

• „Warum reicht der Cluster Autoscaler nicht?” — reaktiv (handelt bei Mangel), limitiert durch Node-Startzeit, Cloud-Quotas und Instanz-Verfügbarkeit; ökonomisch blind gegenüber Reservierungsrabatten.
• „Wie viel Headroom ist richtig?” — keine Universalzahl: aus Spike-Historie, Zonen-Rechnung (n-1) und Upgrade-Surge herleiten, als Kosten-Optionen ans Management; Batch-Verdrängung als billiger Headroom.
• „Woran erkennst du, dass ein Cluster zu groß wird?” — API-Server-Latenz und etcd-Größe/Objektzahl als Frühindikatoren, Blast-Radius-Überlegung als Governance-Grund; Antwort ist Cluster-Split, nicht unbegrenztes Wachstum.
• „Wie planst du für einen neuen Großtenant?” — empirischer Bedarf vergleichbarer Tenants als Schätzbasis, Quota/Reservierung mit Vorlauf, Lasttest vor Go-Live, gestuftes Onboarding statt Big Bang.

Zusammenfassung

Capacity Planning füllt die Lücken der Elastizität: Headroom überbrückt die Minuten, die Autoscaling braucht, und die Ausfall-Domänen, die es nicht versteht — bewusst beziffert und bepreist; Forecasting kombiniert Requests-Trends mit der Tenant-Pipeline und schafft den Vorlauf für Quotas, Reservierungen und neue Cluster; Sizing-Grenzen der Control Plane beantwortet man horizontal mit mehr Clustern. Grundlage von allem sind ehrliche Requests — Rightsizing aus Lektion 21 ist der erste Planungsschritt, nicht der letzte.

Mehr Cluster, mehr Umgebungen, mehr Tenants — das alles konsistent zu halten schafft kein Mensch per Hand. Die nächste Lektion zeigt das Betriebsmodell dafür: GitOps als Rückgrat der Plattform, von der Repo-Struktur bis zum Fleet-Management.