Ein Kubernetes-Cluster wird effizienter, wenn die bezahlte Node-Kapazität näher an das heranrückt, was die Workloads tatsächlich brauchen, und der Hebel dafür sind die Resource Requests, nicht die gemessene Nutzung. Der Scheduler platziert Pods nach ihren Requests, und die Node-Autoscaler legen Nodes nach Requests an und bauen sie nach Requests ab. Fordern Pods mehr an, als sie verbrauchen, belegt der Cluster mehr Nodes, als die Last verlangt. Die Arbeit hat drei Schritte in fester Reihenfolge: Requests an die Nutzung anpassen, Pods dichter packen, überzählige Nodes entfernen. Die Verteilung auf Teams behandelt Kubernetes-Kostenzuordnung, die Preise von Control Plane und Nodes Container und Kubernetes.
So funktioniert es
Ein Pod landet nur auf einem Node, auf dem die Summe der Requests unter der Kapazität bleibt, auch wenn die tatsächliche Nutzung dort niedrig ist. Maßgeblich ist die Allocatable-Kapazität, also das, was nach den Reservierungen für Systemdienste für Pods übrig bleibt; der Scheduler überbucht sie nicht. Ein Container darf mehr nutzen, als er angefordert hat, solange der Node Platz hat, und ist nur ein Limit gesetzt, übernimmt Kubernetes es als Request. Bezahlte Kapazität ohne Arbeit entsteht dadurch auf vier Ebenen:
| Ebene | Was bezahlt wird, ohne Arbeit zu leisten | Hebel | Zuständig |
|---|---|---|---|
| Requests über der Nutzung | angeforderte, ungenutzte CPU und Speicher | Requests nach Messung senken, Vertical Pod Autoscaler | Team der Workload |
| Replikas über der Last | Replikas für die Spitzenlast rund um die Uhr | Horizontal Pod Autoscaler, niedrigere Mindestzahl | Team der Workload |
| Nicht angeforderte Node-Kapazität | Allocatable abzüglich der Summe der Requests, der Leerlauf | Bin Packing, Konsolidierung, passendere Node-Typen | Betreiber des Clusters |
| System-Overhead | Reservierungen für Systemdienste, DaemonSets auf jedem Node | Zahl der DaemonSets, Node-Größe | Betreiber des Clusters |
Pod-Autoscaler
Der Horizontal Pod Autoscaler gehört zum Kern von Kubernetes und passt die Zahl der Replikas an. Eine Zielauslastung rechnet er als Prozentsatz des Requests; fehlt einem Container der Request, ist die CPU-Auslastung des Pods undefiniert, und für diese Metrik geschieht nichts. Der Vertical Pod Autoscaler ist dagegen ein Add-on, das separat installiert wird. Er berechnet Requests aus der bisherigen Nutzung. Im Modus Off bleiben die Empfehlungen im Status des Objekts, Initial setzt sie nur beim Anlegen eines Pods, Recreate verdrängt Pods, deren Requests deutlich abweichen, und InPlaceOrRecreate ändert sie im laufenden Pod, wo das möglich ist. Off liefert die Zahlen, ohne einen Pod anzufassen. Microsoft rät bei AKS davon ab, VPA und HPA auf denselben CPU- und Speichermetriken zu kombinieren; GKE nennt dafür eigene Wege.
Node-Autoscaler
Die Kubernetes SIG Autoscaling betreut zwei Node-Autoscaler, Cluster Autoscaler und Karpenter. Beide legen Nodes für nicht platzierbare Pods an, konsolidieren schlecht ausgelastete Nodes und entscheiden nach Requests, nicht nach Nutzung. Zu hohe Requests können deshalb verhindern, dass ein Node konsolidiert wird.
Der Cluster Autoscaler vergrößert und verkleinert vorab definierte Node-Gruppen. Er hält einen Node für entbehrlich, wenn die Summe der CPU-Requests und die der Speicher-Requests unter 50 % seiner Allocatable-Kapazität liegen (einstellbar) und alle Pods anderswo Platz finden; nach zehn Minuten in diesem Zustand entfernt er ihn. Pods mit restriktivem PodDisruptionBudget, Pods ohne Controller, Pods mit lokalem Speicher und kube-system-Pods ohne PodDisruptionBudget verhindern das, ebenso die Annotation cluster-autoscaler.kubernetes.io/safe-to-evict: "false". Karpenter wählt einzelne virtuelle Maschinen passend zu den wartenden Pods, statt Gruppen zu skalieren. Seine Konsolidierung löscht einen Node, dessen Pods auf freie Kapazität anderer Nodes passen, oder ersetzt ihn durch einen günstigeren; consolidationPolicy legt fest, welche Nodes infrage kommen: nur leere (WhenEmpty), solche, bei denen die Ersparnis die Störung laufender Pods überwiegt (Balanced), oder, als Standard, alle, die sich entfernen oder günstiger ersetzen lassen (WhenEmptyOrUnderutilized).
AWS
Mit Amazon EKS Auto Mode betreibt AWS die Node-Skalierung auf Basis von Karpenter selbst: Nicht platzierbare Pods bekommen neue Nodes, nicht mehr benötigte Nodes werden wegkonsolidiert. Ohne Auto Mode ist Karpenter Open-Source-Software, die der Kunde selbst installiert, konfiguriert und betreibt; der Cluster Autoscaler arbeitet bei EKS über Auto Scaling Groups.
Azure
Der Cluster Autoscaler von AKS arbeitet mit den Standardwerten 0,5 für scale-down-utilization-threshold und zehn Minuten für scale-down-unneeded-time; beide lassen sich im Autoscaler-Profil ändern. Node Auto-Provisioning betreibt Karpenter für den Cluster und wählt VM-Größen nach den Requests wartender Pods; in AKS Automatic ist es vorkonfiguriert, in AKS Standard wird es eingeschaltet.
Google Cloud
In GKE Standard entscheidet der Cluster Autoscaler ebenfalls nach Requests und ändert die Größe der verwalteten Instanzgruppe hinter dem Node-Pool. balanced, der Standard, hält Reserven vor, damit neue Pods schneller starten; optimize-utilization gibt diese Reserve zugunsten der Auslastung auf, baut früher und stärker ab und lenkt Pods auf Nodes mit hoher Belegung. Auf Wunsch legt GKE für wartende Pods eigene Node-Pools an. Autopilot rechnet allgemeine Workloads nach den Requests ihrer Pods ab, nicht nach Nodes (das Modell erklärt Container und Kubernetes). Fehlen Requests, setzt Autopilot in der allgemeinen Compute-Klasse 0,5 vCPU und 2 GiB; Werte unter dem Minimum oder außerhalb des zulässigen CPU-Speicher-Verhältnisses hebt es an.
Was es für Ihre Kosten bedeutet
Bei Clustern, die nach Nodes abgerechnet werden, sinkt die Rechnung erst, wenn ein Node verschwindet. Kleinere Requests allein vergrößern den Leerlauf; erst die Konsolidierung spart Instanzstunden. Bei pod-basierter Abrechnung wie in GKE Autopilot gibt es keinen Node zu konsolidieren, und der Request selbst ist der Hebel. Die FinOps Foundation ordnet diese Arbeit ihrer Capability Usage Optimization zu. Eine Diagnose läuft in dieser Reihenfolge:
- Den Leerlauf je Cluster als eigene Zeile ausweisen, statt ihn auf die Teams zu verteilen (Kosten eines Clusters sichtbar machen).
- Requests je Workload mit der Nutzung vergleichen, etwa mit einem VPA im Modus
Off, und mit dem Team entscheiden, wie beim Rightsizing von Instanzen. - Prüfen, ob ein Node-Autoscaler läuft und warum Nodes bleiben; Karpenter meldet den Grund als Ereignis am Node.
- Erst danach Node-Typen, Spot-Anteil und Commitments angehen.
Nodes sind gewöhnliche virtuelle Maschinen, und ein Commitment, das auf den Cluster vor der Optimierung bemessen wurde, bleibt danach teilweise ungenutzt (Commitment-Abdeckung und Auslastung). Spot-Nodes eignen sich für Workloads, die Unterbrechungen vertragen (Spot-Kapazität); Karpenter ersetzt einen Spot-Node nur dann durch einen anderen, wenn das Feature-Flag SpotToSpotConsolidation eingeschaltet ist, und auch dann nur mit mindestens 15 Instanztypen zur Auswahl. Belegt ist die Einsparung erst, wenn die Instanzstunden der Nodes oder die abgerechneten Pod-Ressourcen in den Abrechnungsdaten sinken (von der geschätzten zur belegten Einsparung).
Wo es schiefgeht
- Requests gesenkt, Rechnung unverändert. Symptom: Die VPA-Empfehlungen sind umgesetzt, die Instanzstunden der Nodes bleiben gleich. Ursache: Kein Node-Autoscaler konsolidiert, oder die Mindestgröße des Node-Pools hält die Nodes.
- Node bleibt trotz geringer Belegung. Symptom: Nodes mit wenigen Requests laufen wochenlang weiter. Ursache: Einer der unter Node-Autoscaler genannten Pod-Typen blockiert den Abbau.
- HPA skaliert nicht. Symptom: Die Replikazahl bleibt trotz Lastwechsel konstant. Ursache: Einem Container fehlt der CPU-Request, damit ist die Auslastung undefiniert.
- VPA und HPA gegeneinander. Symptom: Der VPA senkt die Requests, und der HPA startet bei gleicher Last mehr Replikas. Ursache: Beide reagieren auf dieselben CPU- und Speichermetriken, und der HPA misst die Auslastung am Request.
- Autopilot teurer als erwartet. Symptom: Pods werden mit mehr Ressourcen abgerechnet, als im Manifest stehen. Ursache: Fehlende Requests werden mit Standardwerten gefüllt, zu kleine auf das Minimum oder das zulässige Verhältnis angehoben.
- Spot-Pool blockiert die Skalierung. Symptom: Nach Verdrängungen scheitern Skalierung oder Upgrade des AKS-Clusters. Ursache: Mit der Verdrängungsrichtlinie
Deallocatezählen gestoppte Spot-Nodes weiter gegen das Compute-Kontingent.
Quellen
Gelesen am 2026-10-16. Kubernetes Ressourcenverwaltung für Pods und Container, Rechenressourcen für System-Daemons reservieren, Horizontal Pod Autoscaling, Vertical Pod Autoscaling, Node-Autoscaling, Cluster Autoscaler FAQ und Karpenter Disruption; FinOps Foundation Usage Optimization (CC BY 4.0); AWS Cluster-Compute mit Karpenter und Cluster Autoscaler skalieren und EKS Auto Mode; Microsoft Cluster Autoscaler in AKS, Node Auto-Provisioning, Vertical Pod Autoscaler in AKS und Spot-Node-Pools; Google Cloud GKE Cluster Autoscaler, automatische Erstellung von Node-Pools, Resource Requests in Autopilot, vertikales Pod-Autoscaling und GKE-Preise.