Das Kostenproblem überhöhter Requests

Viele Kubernetes-Cluster reservieren deutlich mehr CPU und Speicher, als ihre Pods tatsächlich nutzen. Eine häufige Ursache ist der Start eines Java-Services. Eine JVM braucht in den ersten Sekunden viel CPU, also setzen Teams einen hohen Request, um diesen Moment abzusichern. Der Request bleibt dann für die gesamte Lebensdauer des Pods hoch – lange nachdem die Startarbeit abgeschlossen ist.

Die Cloud-Rechnung richtet sich nach der Reservierung, nicht nach der Nutzung. Ein Pod, der 2 CPUs reserviert, aber nur einen kleinen Teil davon nutzt, blockiert trotzdem 2 CPUs auf seinem Node. Über viele Replicas hinweg wird diese ungenutzte Reservierung zu einem erheblichen Teil der Clusterkosten.

Die naheliegende Lösung ist, die Requests zu senken – doch genau das ist riskant. Senken Sie einen Request, ohne das Startproblem zu lösen, startet die JVM langsam, Probes schlagen fehl, und der Autoscaler fügt Replicas hinzu, die der Service gar nicht braucht. Kosten und Zuverlässigkeit ziehen in entgegengesetzte Richtungen. Dieser Artikel erklärt, warum Requests wachsen, was sie kosten und wie sie Scheduling und Node-Skalierung beeinflussen. Anschließend zeigt er, wie Sie überhöhte Requests aufspüren und beheben, ohne die Zuverlässigkeit zu gefährden.

Risiken, wenn Sie Requests senken, ohne das Startproblem zu lösen

Ein niedrigerer Request ohne Startkorrektur verursacht drei Probleme:

a. Throttling und verzögerte Readiness: Senken Sie das CPU-Limit zusammen mit dem Request, drosselt der Kernel die JVM beim Start. Der Pod wird spät Ready, Rollouts dauern länger, und die Startup Probe kann fehlschlagen. Wiederholt sich der Fehler, startet das Kubelet den Container neu, und der neue Container wiederholt dieselbe Arbeit. Senken Sie nur den Request und behalten ein hohes oder gar kein Limit, bekommt der Pod auf einem ausgelasteten Node einen kleineren CPU-Anteil – der Start ist auf stark genutzten Nodes also langsam.

b. HPA-Scale-out durch Start-CPU: Der Horizontal Pod Autoscaler (HPA) misst die CPU-Nutzung als Prozentsatz des Requests. Er verwendet diese Formel:

desiredReplicas = ceil[ currentReplicas x ( currentMetricValue / desiredMetricValue ) ]

Ein kleinerer Request lässt dieselbe CPU-Nutzung prozentual größer wirken. Ein Start-Peak kann daher wie hohe Last aussehen, und der HPA fügt Replicas hinzu. Neue Replicas starten, und jeder Start erzeugt einen weiteren Peak. Standardmäßig beträgt die initiale Readiness-Verzögerung 30 Sekunden (--horizontal-pod-autoscaler-initial-readiness-delay), und der HPA kann CPU-Samples während der CPU-Initialisierungsphase von 5 Minuten überspringen (--horizontal-pod-autoscaler-cpu-initialization-period). Diese Defaults reduzieren das Risiko, können es aber nicht beseitigen, wenn der Start lange dauert.

c. OOMKilled Java-Container: Standardmäßig setzt die JVM ihren maximalen Heap auf 25 % des Container-Speichers (-XX:MaxRAMPercentage). Eine JVM nutzt außerdem Speicher außerhalb des Heaps, etwa Metaspace, Thread-Stacks und den Code-Cache. Senken Sie das Memory-Limit, ohne diese Anteile zu prüfen, kann der Container es überschreiten und einen OOM-Kill erhalten.

Ist der Memory-Request niedriger als das Limit, kann der Node außerdem zu viele Pods aufnehmen, und das Kubelet kann Pods verdrängen, wenn dem Node der Speicher knapp wird. Setzen Sie für JVM-Container den Memory-Request gleich dem Memory-Limit:

resources:
  requests:
    memory: 2Gi
  limits:
    memory: 2Gi

So finden Sie überhöhte Requests

Drei Prüfungen helfen Ihnen, das Problem zu finden:

a. Requests vs. Nutzung: Für einen ersten Blick nutzen Sie kubectl top. Der Befehl benötigt den Metrics Server und zeigt die aktuelle Nutzung pro Container:

kubectl top pod --containers -n <namespace>

Vergleichen Sie das Ergebnis mit den Requests in der Pod-Spezifikation. Für ein vollständiges Bild nutzen Sie Prometheus. Die Metrik kube_pod_container_resource_requests aus kube-state-metrics enthält die Requests. Die cAdvisor-Metrik container_cpu_usage_seconds_total enthält die CPU-Nutzung. Diese Query zeigt das CPU-Request-Gap pro Container, basierend auf dem 95. Perzentil der Nutzung über 7 Tage:

expr: |
  sum by (namespace, pod, container) (
    kube_pod_container_resource_requests{resource="cpu", container!=""}
  )
  - max by (namespace, pod, container) (
    quantile_over_time(0.95,
      rate(container_cpu_usage_seconds_total{container!~"POD|"}[5m])[7d:5m]
    )
  )

b. Startfenster vs. Steady State: Die Request-Gap-Query mischt beide Phasen, und die Start-Samples heben das 95. Perzentil an, sodass das Gap kleiner aussieht als das wahre Steady-State-Gap. Um die Phasen zu trennen, nutzen Sie die Metrik kube_pod_start_time, die die Startzeit jedes Pods enthält. Diese Query behält nur die Samples aus den ersten 10 Minuten eines Pods und liefert den Spitzenwert:

max by (namespace, pod, container) (
  max_over_time(
    (
      rate(container_cpu_usage_seconds_total{container!~"POD|"}[1m])
      and on (namespace, pod) (time() - kube_pod_start_time < 600)
    )[7d:1m]
  )
)

Diese Query behält nur die Samples nach den ersten 10 Minuten und liefert das 95. Perzentil. Sie zeigt den Steady State:

max by (namespace, pod, container) (
  quantile_over_time(0.95,
    (
      rate(container_cpu_usage_seconds_total{container!~"POD|"}[5m])
      and on (namespace, pod) (time() - kube_pod_start_time > 600)
    )[7d:5m]
  )
)

Diese Queries gehen davon aus, dass der Start innerhalb von 10 Minuten endet. Ersetzen Sie 600 durch die Startzeit Ihres Services. Die Pod-Startzeit ändert sich nicht, wenn ein Container innerhalb desselben Pods neu startet – ein solcher Neustart zählt also als Steady State. Die Start-Query nutzt außerdem einen Schritt von 1 Minute und kann daher etwas unter dem wahren Peak liegen, wenn der Peak kurz ist.

Vergleichen Sie drei Werte pro Container: den Request, den Start-Peak und die Steady-State-Nutzung. Ein Container mit großem Abstand zwischen Request und Steady-State-Nutzung und einem Start-Peak nahe am Request ist der klassische überdimensionierte JVM-Service.

c. Workloads nach Request-Gap priorisieren: Beheben Sie die größten Gaps zuerst. Sortieren Sie nach dem absoluten Gap in CPUs, summiert über alle Replicas, nicht nach dem Verhältnis. Ein Faktor zehn bei einem winzigen Container spart wenig. Diese Queries sind rechenintensiv – speichern Sie das Gap deshalb in einer Recording Rule und sortieren Sie das Ergebnis:

groups:
  - name: request-gap
    rules:
      - record: container:cpu_request_gap:cores
        expr: |
          clamp_min(
            sum by (namespace, pod, container) (
              kube_pod_container_resource_requests{resource="cpu", container!=""}
            )
            -
            max by (namespace, pod, container) (
              quantile_over_time(0.95,
                rate(container_cpu_usage_seconds_total{container!~"POD|"}[5m])[7d:5m]
              )
            ),
          0)

Wenn Sie den Prometheus Operator verwenden, legen Sie dieselbe Rule Group unter spec.groups eines PrometheusRule-Objekts an – mit dem Label, über das Ihr Prometheus Rules auswählt.

topk(20, sum by (namespace, container) (container:cpu_request_gap:cores))

Führen Sie dieselbe Prüfung für Speicher mit der Metrik container_memory_working_set_bytes durch.

So zahlen Sie nicht ein Pod-Leben lang für den Start

Das Ziel: Der Pod bekommt beim Start Ressourcen auf Start-Niveau und danach Ressourcen auf Steady-State-Niveau. Diese Optionen wirken zusammen:

a. Startkosten reduzieren: Weniger Startarbeit braucht weniger CPU beim Start, und das senkt den Peak, der den Request bestimmt. Spring Boot kann Beans mit spring.main.lazy-initialization=true erst bei der ersten Nutzung erzeugen. Class Data Sharing und der AOT-Cache können einen Teil des Class-Loadings einsparen. Der AOT-Cache kam mit JDK 24 (JEP 483). Das Spring Framework unterstützt sowohl CDS als auch den AOT-Cache. Profiling zeigt, wohin Ihre eigene Startzeit fließt.

b. Startup-Boost und VPA: Der Vertical Pod Autoscaler (VPA) hat einen InPlaceOrRecreate-Update-Modus. Dieser Modus versucht zuerst einen In-Place-Resize und erstellt den Pod neu, wenn ein In-Place-Resize nicht möglich ist. Auf GKE arbeitet der CPU Startup Boost mit dem VPA zusammen. Er erhöht den CPU-Request beim Erstellen des Pods und behält den höheren Request für durationSeconds, nachdem der Pod Ready wird. Danach setzt GKE den Request in place auf den Basiswert zurück. Der Boost greift nur beim Erstellen des Pods – ein Container-Neustart innerhalb desselben Pods bekommt keinen Boost. Das Feature ist zum Zeitpunkt des Verfassens dieses Artikels im Preview-Status und benötigt GKE 1.36.0-gke.4447000 oder neuer.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

In diesem Beispiel verdoppelt der Boost den CPU-Request (factor: 2) und behält ihn für 10 Sekunden, nachdem der Pod Ready wird. Mit updateMode auf Off wendet der VPA nur den Boost an und nimmt keine weiteren Änderungen vor. Wenn Sie einen HPA zusammen mit dem Boost nutzen, definieren Sie eine Readiness Probe und setzen Sie durationSeconds auf 0. So verhindern Sie, dass der HPA wegen des CPU-Peaks beim Start Replicas hinzufügt.

c. Zweiphasiger In-Place-Resize: Der In-Place Pod Resize ändert CPU und Speicher eines laufenden Pods ohne Neustart. Das Feature erreichte in Kubernetes 1.33 den Beta-Status und wurde in Kubernetes 1.35 stabil. Ein Pod kann mit hohem CPU-Request und -Limit starten, und ein Controller kann beide nach dem Start absenken. Die Standard-Resize-Policy für CPU ist NotRequired, und Sie können sie im Manifest explizit angeben:

containers:
  - name: app
    resizePolicy:
      - resourceName: cpu
        restartPolicy: NotRequired

Sie ändern die Ressourcen über die resize-Subresource. Dieser Befehl benötigt kubectl 1.32 oder neuer:

kubectl patch pod <pod-name> --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"300m"},"limits":{"cpu":"500m"}}}]}}'

Dieses Beispiel geht von einem Burstable-Pod aus, bei dem der Request niedriger ist als das Limit. Ein Guaranteed-Pod muss den Request gleich dem Limit halten, weil ein Resize die QoS-Klasse nicht ändern kann. Windows-Pods und Pods unter der statischen CPU- oder Memory-Manager-Policy können den In-Place-Resize nicht nutzen. Außerdem muss jemand den Resize auslösen. Eine Person kann den Patch manuell ausführen, aber bei vielen Pods muss ein Controller das übernehmen.

Ändern Sie bei JVM-Containern nur die CPU und lassen Sie das Memory-Limit unverändert, denn ein niedrigeres Memory-Limit kann einen OOM-Kill verursachen.

d. startupProbe und HPA-Tuning: Eine Startup Probe setzt die Liveness- und Readiness-Probes aus, bis die Anwendung gestartet ist. Sie verhindert Neustart-Schleifen bei einem langsamen Start. Richten Sie sie auf denselben Endpoint wie die Liveness Probe. Die Gesamtzeit, die die Probe erlaubt, ist failureThreshold x periodSeconds.

startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 5
  failureThreshold: 24   # wartet bis zu 24 x 5 = 120 Sekunden

Dieser Pfad benötigt die Spring-Boot-Actuator-Dependency. Spring Boot aktiviert die Liveness- und Readiness-Endpoints automatisch, wenn die Anwendung auf Kubernetes läuft. Eine Startup Probe macht den Start nicht schneller, aber sie macht einen niedrigeren Request sicherer.

Auch der HPA braucht Aufmerksamkeit. Das behavior-Feld der autoscaling/v2-API begrenzt, wie schnell der HPA Replicas hinzufügt, sodass ein kurzer Start-Peak keinen Schwall neuer Pods auslöst:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: example
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60

In diesem Beispiel zielt der HPA auf 70 Prozent CPU-Auslastung. Das Scale-up-Fenster von 60 Sekunden verzögert Scale-up-Entscheidungen, sodass ein kurzer Start-Peak keine Replicas hinzufügt. Der HPA fügt höchstens 2 Pods pro 60-Sekunden-Intervall hinzu.

e. Automatisierung mit PerfectScale: PerfectScale behebt Start-Verschwendung automatisch. Eine JVM braucht nur beim Start viel CPU. Eine einzige durchschnittsbasierte Empfehlung funktioniert nicht für beide Phasen. PerfectScale erkennt Services mit hohem Ressourcenbedarf beim Start automatisch und liefert zwei Empfehlungen pro Workload: eine für den Start und eine für den Steady-State-Betrieb.

PerfectScale wendet die Start-Empfehlung beim Erstellen eines Pods an und passt die Ressourcen anschließend in place an die Laufzeit-Empfehlung an, sobald der Pod den Steady State erreicht. So optimieren Sie die Ressourcenzuteilung für beide Phasen, ohne die Anwendungsleistung zu beeinträchtigen – und das ganz ohne Pod-Neustart oder manuellen Eingriff. Der Pod behält die Requests auf Start-Niveau nicht mehr für seine gesamte Lebensdauer. PerfectScale dimensioniert die Start-Empfehlung auf den höheren Bedarf der beiden Phasen, sodass der Node während des Starts genug Kapazität hat. PerfectScale weist Start- und Steady-State-Ressourcen getrennt aus, sodass die Kosten- und Verschwendungszahlen widerspiegeln, was der Workload in jeder Phase tatsächlich brauchte. PerfectScale nutzt In-Place-Resize, wenn der Cluster es unterstützt. Unterstützt werden Deployments, StatefulSets, DaemonSets und Argo Rollouts. Unterstützt der Cluster keinen In-Place-Resize, nutzt PerfectScale stattdessen seinen sicheren Standardansatz.

PerfectScale respektiert außerdem Ihre JVM-Heap-Grenzen: Empfehlungen überschreiten nie Ihre konfigurierte maximale Heap-Größe und unterschreiten nie Ihr konfiguriertes Minimum. Für Java-Container erfasst es die Heap- und Non-Heap-Speichernutzung sowie Garbage-Collection-(GC)-Metriken, darunter GC-Zeit, Anzahl aktiver Prozessoren und GC-Typ. Die Erfassung der JVM-Metriken lässt sich bei der Installation des PerfectScale-Agents aktivieren – ohne zusätzlichen Einrichtungsaufwand. Dieses Feature wird nur auf Linux-Nodes unterstützt.

Auch Node-Autoscaler profitieren. PerfectScale gleicht Ihre Karpenter-Einstellungen mit den Requests der laufenden Workloads ab und empfiehlt, zuerst das Right-Sizing der Workloads durchzuführen. Danach passen die Karpenter-Empfehlungen zur realen Nutzung statt zu überhöhten Requests.

Ein Vorher-Nachher für einen Service. Dieses Beispiel nutzt die Zahlen aus dem Rechenbeispiel oben. Vorher passt der Request zum Start-Peak:

resources:
  requests:
    cpu: "2"
    memory: 2Gi
  limits:
    cpu: "2"
    memory: 2Gi

Nachher passt der Request zum Steady State, das Limit lässt Spielraum für den Start, und eine Startup Probe sichert den langsamen Start ab:

resources:
  requests:
    cpu: 300m
    memory: 2Gi
  limits:
    cpu: "2"
    memory: 2Gi
startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 5
  failureThreshold: 24

Das Zuverlässigkeitsrisiko: Der Node braucht beim Start freie CPU, weil der Request nur 300m beträgt. Boosten oder resizen Sie den Pod, wenn der Node ausgelastet sein könnte.

Fazit

Überhöhte Requests entstehen schnell und werden teuer, wenn sie bestehen bleiben. Der Scheduler, die Node-Autoscaler und manche Cloud-Rechnungen richten sich nach Requests und nicht nach der Nutzung – jede ungenutzte CPU in einem Request kostet also weiterhin Geld.

Der JVM-Start ist eine häufige Ursache. Der Request passt zu den ersten Sekunden und bleibt die gesamte Lebensdauer des Pods bestehen. Den Request allein zu senken löst das Problem nicht, denn das führt zu Throttling, zusätzlichen HPA-Replicas und OOM-Kills. Reduzieren Sie zuerst die Startarbeit, oder dimensionieren Sie Start und Steady State getrennt. PerfectScale erledigt das automatisch, in place und ohne Neustart.

Seien Sie beim Workshop dabei. Vikram Seshadri von DoiT zeigt im Hands-on-Workshop "Java on K8s: The Startup vs. Steady-State Sizing Dilemma" am 28. Oktober 2026 um 11 Uhr ET, wie Sie einen JVM-Pod für den Start dimensionieren und ihn ohne Neustart auf den Steady State umstellen. Jetzt Platz sichern.

Möchten Sie sehen, wie PerfectScale das Right-Sizing Ihrer Java-Workloads übernimmt? Kostenlos starten oder Demo buchen.