Kubernetes Requests: 8 % CPU, volle Rechnung

8 % durchschnittliche CPU-Auslastung wiesen unoptimierte Kubernetes-Cluster in Cast-AI-Analysen für 2025 aus – Memory lag bei 20 %, GPU nur bei 5 %. Der kube-scheduler platziert Pods nach deklarierten resource requests statt nach realer Nutzung. Er reserviert damit oft bezahlte Kapazität, die ungenutzt bleibt.

Das Wichtigste in Kürze

Verwandt:Edge ohne Träger? Starlink Business hält Cloud am Leben  /  Mistral füttert Microsoft mit europäischen GPUs

Resource Requests steuern Platzierung und Rechnung

Der Kubernetes-Scheduler entscheidet über die Pod-Platzierung anhand der deklarierten resource requests, nicht anhand der tatsächlichen CPU- oder Memory-Nutzung. Auf dem Node zählt die Summe dieser Requests: Sie darf dessen Kapazität nicht überschreiten, selbst wenn die reale Last weit darunter liegt. Requests reservieren Kapazität unabhängig davon, ob der Container sie abruft.

Was sind resource requests? Resource requests sind die CPU- und Speicherwerte, die ein Pod in seiner Definition anfordert. Der Scheduler entscheidet anhand dieser Zahlen über den passenden Knoten und reserviert die Menge fest. Die tatsächliche Auslastung spielt dabei keine Rolle; sie wirkt erst über Autoscaler auf die Zuteilung.

Das hat direkte Budgetwirkung. Überhöhte Requests gehören laut einem AWS-Containers-Blog-Beitrag von September 2025 zu den häufigsten Quellen von Ressourcenverschwendung in Kubernetes. Eine Beispielrechnung dort macht den Hebel greifbar: Request 1 CPU bei realer Nutzung 0,2 CPU lässt 0,8 CPU reserviert und bezahlt, aber ungenutzt. Für Plattform-Teams und IT-Einkauf im DACH-Raum heißt das: Die Manifest-Werte in spec.containers[].resources.requests bestimmen, wie viele Nodes nötig sind und was der Cluster kostet – lange bevor Monitoring die Idle-Zeiten zeigt.

Resource limits wirken ergänzend, aber anders. Memory-Limits setzt Linux über OOM-Kills durch, CPU-Limits über Throttling. Wer Limits weglässt, kann bei freien Ressourcen opportunistisch mehr Performance holen, senkt aber die Vorhersagbarkeit. Limits mit begrenztem Headroom über den Requests begrenzen Overcommit und halten das Verhalten planbarer. Beides gehört in dieselbe Architekturentscheidung: Requests steuern Scheduling und Kapazitätsrechnung, Limits steuern das Verhalten unter Druck.

Cast-AI-Zahlen zeigen anhaltend niedrige Auslastung

Im 2026 State of Kubernetes Optimization Report von Cast AI lag die durchschnittliche CPU-Auslastung in Analysen unoptimierter Cluster für 2025 bei 8 %. Memory kam auf 20 %, GPU im Mittel nur auf 5 %. Der Hersteller betont in der Pressemitteilung vom 21. April 2026, dass einmaliges Rightsizing beim Deployment nicht ausreicht, weil Workloads und Traffic sich ändern.

Der vorangegangene 2025 Kubernetes Cost Benchmark Report (Pressemitteilung vom 5. März 2025) stützte sich auf mehr als 2.100 Organisationen bei Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE) und Azure Kubernetes Service (AKS). Der Zeitraum war das Kalenderjahr 2024, Cluster mit unter 50 CPUs waren ausgeschlossen, die Daten stammten vor Cast-AI-Automation. Dort lag die mittlere CPU-Auslastung noch bei 10 % (Vorjahr 13 %), Memory bei 23 %. Die beiden Reports sind methodisch nicht als fortlaufende Zeitreihe belegt; die Größenordnungen bleiben für unoptimierte oder vor Automation erfasste Cluster dennoch ein klares Signal an FinOps und Plattformverantwortliche.

Wichtig für den Einkauf: Die Cast-AI-Mittelwerte beschreiben analysierte, oft non-optimized Cluster. Eine 1:1-Übertragung auf reife, bereits FinOps-gesteuerte DACH-Plattformen ist aus den öffentlichen Report-Angaben nicht belegbar. Wer die eigenen Request-to-Usage-Verhältnisse misst, ersetzt Hersteller-Benchmarks durch belastbare interne Steuergrößen.

QoS-Klassen regeln Verdrängung unter Node-Druck

Kubernetes ordnet Pods QoS-Klassen zu. Guaranteed verlangt für jeden Container Request = Limit bei CPU und Memory, jeweils größer als null. Burstable und BestEffort füllen die übrigen Fälle. Bei Node-Ressourcendruck werden zuerst BestEffort-Pods verdrängt, dann Burstable, zuletzt Guaranteed. Unter Memory- oder Disk-Pressure sind nur Pods Kandidaten, die über ihren Requests liegen.

Für Production-Architekturen ist das ein doppelter Hebel. Eng gesetzte Requests ohne passende Limits können Burstable-Pods unter Druck zuerst treffen. Guaranteed schützt stärker, bindet aber exakt die deklarierte Kapazität und verschärft die Reservierungslogik des Schedulers. Plattform-Teams sollten QoS deshalb gemeinsam mit Request- und Limit-Policies definieren: zu großzügige Guaranteed-Workloads blockieren Nodes, zu lockere BestEffort-Workloads sind die ersten Opfer bei Lastspitzen.

Die Unterscheidung von CPU- und Memory-Enforcement bleibt zentral. CPU-Throttling drosselt, Memory-OOM beendet. Aggressive Memory-Limits ohne Headroom erzeugen Ausfälle, aggressive CPU-Limits erzeugen Latenz. Rightsizing ohne QoS- und Limit-Konzept verschiebt das Risiko nur von der Rechnung in den Incident-Kanal.

Rightsizing braucht Zielnutzung statt Maximalverdichtung

Der AWS-Containers-Beitrag zu dynamischem Request-Right-Sizing mit Kubecost (IBM Kubecost im AWS-Kontext) vom 3. September 2025 warnt vor pauschal aggressivem Downsizing in Production. Für kritische Umgebungen nennt er eine konservativere Zielauslastung von 65 Prozent, damit Headroom für Lastspitzen bleibt. In weniger kritischen Umgebungen sind 80 Prozent Zielauslastung das genannte Beispiel. Rightsizing bedeutet damit: Requests an die reale Nutzung plus planbaren Puffer anpassen, nicht die Requests so niedrig wie möglich setzen.

Organisationen berichten laut demselben Beitrag von 20 bis 60 % Compute-Kostenreduktion in Non-Production durch Request-Sizing mit Kubecost-Features. Die Angaben sind anekdotisch und selbstberichtend, ohne in der Quelle ausgewiesene Methodik. Für DACH-Teams eignen sie sich als Größenordnung für Pilotbudgets, nicht als Garantie für den Produktionscluster.

Technisch liefert der VerticalPodAutoscaler (VPA) Target-, Lower- und Upper-Bound-Empfehlungen aus der Nutzungshistorie, inklusive Peaks und OOM-Ereignissen. VPA kommt als separat zu installierendes CRD/Add-on unter autoscaling.k8s.io/v1 und gehört damit nicht zum Kern-API der Control Plane. Die dokumentierten Update-Modi lauten Off, Initial, Recreate, InPlaceOrRecreate und InPlace; Auto ist seit VPA 1.4.0 deprecated. Parallel ist In-place-Resize von CPU- und Memory-Requests/Limits laufender Container in Kubernetes stabil (Feature State v1.35). Damit können Teams Empfehlungen umsetzen, ohne jeden Pod neu zu erzeugen – ein operativer Fortschritt für laufende Produktionsworkloads.

Spot-Anteil senkt Compute-Kosten im Benchmark-Datensatz

Im 2025 Kubernetes Cost Benchmark Report von Cast AI erreichten Cluster, die Spot Instances anteilig nutzten, im Mittel 59 % geringere Compute-Kosten. Bei reiner Spot-Nutzung lag der Wert bei 77 %. Die Vergleichsgrößen gelten innerhalb des Cast-AI-Datensatzes und setzen die Filter des Reports voraus: mehr als 2.100 Organisationen, AWS/GCP/Azure, Datenjahr 2024, Cluster ab 50 CPUs, vor Automation.

Für Architektur und Einkauf ist Spot kein Ersatz für saubere Requests. Unterauslastete Nodes mit überhöhten Requests bleiben teuer, auch wenn der Instanzpreis sinkt. Die sinnvolle Reihenfolge ist: Requests und Limits an Nutzung und QoS ausrichten, Headroom nach Umgebungstyp setzen, danach Spot-Anteile dort skalieren, wo Unterbrechungen fachlich verkraftbar sind – typischerweise stärker in Non-Production und batchnahen Workloads, vorsichtiger bei latenzkritischen Diensten.

Wer Amazon EKS, GKE oder AKS betreibt, sollte Request-Sizing, VPA-Empfehlungen und Spot-Policies als ein Steuerungsset behandeln. Cast AI argumentiert, dass einmaliges Rightsizing beim Deployment nicht genügt. Die Kubernetes-Mechanik bestätigt das: Solange der Scheduler nur Requests sieht und Workloads sich ändern, veraltet jedes manuelle Manifest. Kontinuierliche Messung der realen Nutzung gegen Requests bleibt die belastbare Steuergröße – herstellerunabhängig und budgetrelevant.

Häufige Fragen

Bildquelle: KI-generiert (August 2026)