So beheben Sie Kubernetes-Resource-Policies, die für die falsche Phase optimieren

TL;DR

• Eine Kubernetes-Resource-Policy umfasst jede Ebene, die festlegt, mit welchen Requests und Limits ein Container am Ende läuft: ResourceQuota, LimitRange, Admission-Regeln (Kyverno, Gatekeeper, ValidatingAdmissionPolicy), Helm-Chart-Defaults und der Recommender, der die Werte einträgt.
• Jede dieser Ebenen geht von einer einzigen Zahl pro Container aus – für dessen gesamte Lebensdauer. Container haben zwei Phasen, Startphase und Steady State, und der Abstand zwischen beiden kann das 3- bis 10-Fache betragen.
• Policies, die auf den Steady State abgestimmt sind, drosseln Pods in der Startphase und lassen sie per OOM-Kill sterben. Policies, die auf die Startphase abgestimmt sind, reservieren Kapazität, die niemand nutzt, füllen Namespace-Quotas mit brachliegenden Requests und lassen Pods im Status Pending hängen, während der Cluster halb leer ist.
• Die Lösung ist strukturell: Quota auf Requests statt auf Limits; eine LimitRange, die Bursts zulässt, statt sie abzuwürgen; Admission-Regeln, die Requests und Memory-Limits verlangen, aber keine CPU-Limits mehr vorschreiben; und ein Recommender, der Startphase und Steady State als getrennte Zahlen betrachtet.
• In-Place Pod Resize macht den letzten Schritt praktikabel. Die Startphase bekommt, was sie braucht, dann schrumpft der Pod ohne Neustart auf sein Plateau – und die Quota wird im selben Moment freigegeben.

Im letzten Beitrag ging es darum, wie man einen Startup-Spike sichtbar macht: Throttling- und OOM-Metriken nach Container-Alter filtern, und der Burst, den Durchschnittswerte verstecken, zeigt sich in den ersten 60 Sekunden im Leben jedes Containers. In diesem Beitrag geht es darum, was zu tun ist, sobald man ihn sieht – denn der schwierige Teil ist nicht, ein einzelnes Deployment anzupassen. Es ist die Policy-Ebene rund um dieses Deployment, die für eine Phase geschrieben wurde und jeden Workload immer wieder dorthin zurückdrängt.

Fix 4: Memory für die Startphase bemessen, CPU für den Steady State

Sobald die Policy-Ebene keine Einheitsantwort mehr erzwingt, wird die Entscheidung pro Workload einfacher – und sie fällt für jede Ressource anders aus.

Das Memory-Limit muss über dem Startup-Peak liegen. Bei Memory gibt es keine sanfte Degradierung. Allokiert die Initialisierung 900Mi und das Limit liegt bei 768Mi, stirbt der Container mit Exit-Code 137, bevor er je sein 400Mi-Plateau erreicht. Nehmen Sie max_over_time(container_memory_working_set_bytes[5m]) über ein Zeitfenster, das einen Rollout enthält, und setzen Sie das Limit mit Puffer über diesen Wert. Denken Sie bei JVM-Workloads daran, dass der Heap nur ein Teil des Bildes ist: Metaspace, Code Cache und Thread-Stacks liegen allesamt außerhalb von -Xmx.

Der Memory-Request liegt auf dem Plateau. Der Request ist, was der Scheduler reserviert und was die Quota zählt. Ihn auf das Steady-State-Working-Set mit moderatem Puffer zu setzen, hält das Bin-Packing realistisch. Die Lücke zwischen Request und Limit bringt den Pod in die Burstable-QoS-Klasse – bei Memory-Druck auf dem Node ist er damit vor Guaranteed-Pods ein Kandidat für die Eviction. Für die meisten zustandslosen Services ist das ein akzeptabler Kompromiss; wo nicht, setzen Sie den Request bewusst gleich dem Limit und akzeptieren die Reservierung.

Der CPU-Request liegt auf dem Plateau, ein CPU-Limit fehlt. Ohne CFS-Quota leiht sich die Startphase freie Zyklen vom Node und gibt sie eine Minute später zurück. Der Request bleibt wichtig: Karpenter und der Scheduler platzieren den Pod danach, und der HPA teilt die Auslastung dadurch. Bemessen Sie ihn nach dem Steady-State-p95, nicht nach dem Burst.

Der einzige Fall, in dem das nicht aufgeht: ein Rollout, bei dem viele Spike-lastige Pods gleichzeitig auf demselben frischen Node landen. Ohne freie CPU zum Ausleihen läuft die Startphase durch Contention langsam statt gedrosselt. Begrenzen Sie maxSurge, damit neue Pods in Wellen statt auf einen Schlag eintreffen, und erwägen Sie eine topologySpreadConstraint auf kubernetes.io/hostname, damit sich die neuen Pods eines Rollouts nicht auf einem Node stapeln. Eine startupProbe mit einem failureThreshold, der auf den langsamen Fall bemessen ist, hält das Kubelet davon ab, einen Pod neu zu starten, der lediglich unter Last bootet.

Fix 5: Dem Recommender zwei Phasen zeigen – und den Pod die Größe wechseln lassen

Alles oben Genannte verhindert, dass die Policy die falsche Zahl erzwingt. Die richtige Zahl liefert das noch nicht. Dafür muss der Recommender wissen, dass Startphase und Steady State verschieden sind – und der Pod muss sich zwischen beiden bewegen können.

Der Vertical Pod Autoscaler baut mit seinem Standard-Recommender ein abklingendes Histogramm über rund acht Tage an Samples. Ein 45-Sekunden-Burst ist dafür Rauschen, also empfiehlt er das Plateau – und der nächste Rollout drosselt. Sie können ihn mit minAllowed einschränken, damit er nie unter eine Untergrenze fällt, die den Start übersteht – doch damit schreiben Sie den Startup-Wert nur auf anderem Weg wieder als dauerhafte Reservierung fest.

In-Place Pod Resize verändert die Ausgangslage. Das Feature ist seit Kubernetes 1.35 stabil, in 1.36 standardmäßig aktiv und erlaubt, Requests und Limits eines laufenden Containers ohne Neustart zu ändern. Das Muster: Der Pod startet mit genug CPU und Memory, um sauber zu booten, und wird nach dem Readiness-Signal auf Steady-State-Werte verkleinert. Der Startup CPU Boost von GKE macht für Autopilot etwas Ähnliches. Die Pod-Spec muss nur deklarieren, dass eine CPU-Änderung keinen Neustart auslösen soll:

containers:
- name: app
  resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: NotRequired   # oder RestartContainer, wenn die Runtime den Heap nicht live verkleinern kann
  resources:
    requests:
      cpu: "2"          # Startwert; nach Readiness auf ~200m verkleinert
      memory: 1Gi
    limits:
      memory: 1Gi

Hier zahlt sich die Quota-Arbeit aus Fix 1 aus. Ein Resize wird wie jede andere Request-Änderung gegen die ResourceQuota geprüft – schrumpft der Pod also von 2 Cores auf 200m, bekommt der Namespace sofort 1,8 Cores Quota zurück. Vierzig Replikas booten in Wellen, jede hält ihre Startup-Reservierung etwa eine Minute, und der Steady-State-Footprint des Namespace pendelt sich bei 8 statt 80 Cores ein. Pods hängen nicht mehr im Status Pending hinter Reservierungen, die eine Phase beschreiben, in der längst niemand mehr steckt.

Eine Einschränkung, die Sie einplanen müssen: Ein Resize kann die QoS-Klasse eines Pods nicht ändern. Ein Pod, der als Burstable gestartet ist, bleibt Burstable, und ein Guaranteed-Pod muss durch jedes Resize hindurch Requests gleich Limits halten. Ein Grund mehr, Guaranteed nicht per Policy für Workloads vorzuschreiben, die es nicht brauchen.

Eine Checkliste für die Policy-Überarbeitung

1. Ebenen inventarisieren. Pro Namespace: kubectl get resourcequota,limitrange -o yaml, plus jede Kyverno-/Gatekeeper-/VAP-Regel, die resources berührt. Notieren Sie, was jede davon erzwingt.
2. Die angenommene Phase jeder Ebene finden. Jedes limits.cpu in einer Quota, jedes max.cpu oder niedrige maxLimitRequestRatio.cpu in einer LimitRange, jede Admission-Regel mit "CPU-Limit ist Pflicht" ist eine Steady-State-Policy. Jeder defaultRequest über ein paar hundert Millicores oder jede Vorgabe "Requests gleich Limits" ist eine Startup-Policy.
3. Die Lücke messen. Führen Sie die Requests-zu-Nutzung-Query pro Namespace aus. Alles über 3 bis 4 ist Quota, die von der falschen Phase belegt wird.
4. Quota auf Requests umstellen. limits.cpu aus der ResourceQuota entfernen; requests.* und limits.memory behalten.
5. Die LimitRange öffnen. default.cpu entfernen, max.cpu anheben oder entfernen, maxLimitRequestRatio nur auf Memory anwenden.
6. Admission neu schreiben. CPU- und Memory-Requests sowie ein Memory-Limit verlangen. Kein CPU-Limit mehr vorschreiben.
7. Die zehn größten Restarter neu dimensionieren. Memory-Limit auf den Startup-Peak, Memory- und CPU-Requests auf den Steady-State-p95, kein CPU-Limit. maxSurge und Spread-Constraints ergänzen, falls Rollouts um Ressourcen konkurrieren.
8. Zwei-Phasen-Sizing aktivieren, wo der Cluster es unterstützt. Ab 1.33 mit verfügbarem In-Place Resize: resizePolicy deklarieren und einen Controller die Pods nach Readiness verkleinern lassen.
9. Schritt 3 eine Woche später wiederholen. Das Verhältnis sollte Richtung 1,5 bis 2 fallen und die Throttling-Rate junger Container gleichzeitig gegen null gehen. Bewegt sich nur eines von beiden, haben Sie eine Ressource korrigiert – und die andere nicht.

FAQ

Was ist eine Kubernetes Resource Quota? Eine ResourceQuota ist ein Namespace-gebundenes Objekt, das die Gesamtressourcen deckelt, die alle Pods in diesem Namespace anfordern oder als Limit haben dürfen, dazu Objektzahlen wie Pods, Services und PVCs. Sie wird bei der Admission durchgesetzt: Ein Pod, dessen Requests oder Limits den Namespace über seine hard-Werte heben würden, wird abgelehnt. Quotas zählen die Zahlen in der Pod-Spec, nicht die tatsächliche Nutzung – darum kann eine Quota erschöpft sein, während die Nodes dahinter leer laufen.

Sollte eine ResourceQuota Limits oder Requests deckeln? Deckeln Sie requests.cpu und requests.memory, denn Requests sind das, was der Scheduler reserviert und was Sie an Node-Kapazität bezahlen. Deckeln Sie auch limits.memory, denn das ist eine echte Sicherheitsgrenze dagegen, dass ein Namespace den gesamten Node-Speicher verbraucht. Vermeiden Sie limits.cpu in Quotas: Es drängt Teams dazu, CPU-Limits zu verkleinern, damit alles passt – das drosselt Pods in der Startphase, ohne den Node zu schützen.

Was ist der Unterschied zwischen ResourceQuota und LimitRange? ResourceQuota setzt eine Namespace-weite Gesamtsumme. LimitRange setzt pro Container (oder pro Pod bzw. pro PVC) Defaults, Minima, Maxima und das zulässige Verhältnis zwischen Limit und Request. Die Quota beantwortet "wie viel darf dieses Team insgesamt nutzen"; die LimitRange beantwortet "was bekommt ein Container, der nichts angibt, und wie viel darf er höchstens verlangen". Beide werden bei der Admission durchgesetzt.

Werden In-Place Pod Resizes auf die ResourceQuota angerechnet? Ja. Ein Resize, das Requests erhöht, wird gegen die Namespace-Quota validiert und abgelehnt, wenn es sie überschreiten würde. Ein Resize, das Requests senkt, gibt die Differenz sofort an die Quota zurück. Genau das ermöglicht es dem Muster "groß starten, dann schrumpfen", den Steady-State-Quota-Footprint eines Namespace nahe an der tatsächlichen Nutzung zu halten.

Warum werden meine Pods beim Start gedrosselt, obwohl der Node freie CPU hat? Weil ein CPU-Limit vom Kernel über die CFS-Quota pro Container durchgesetzt wird – unabhängig von der Node-Last. Bei einem Limit von 500m bekommt der Container 50ms von jeder 100ms-Periode, egal wie leer der Node ist. Startup-Arbeit wie JIT-Kompilierung oder das Laden von Modulen schöpft diese Quota früh in jeder Periode aus und wartet. Das CPU-Limit zu entfernen – oder maxLimitRequestRatio so anzuheben, dass das Limit deutlich über dem Request liegen kann – lässt die Startphase die freie Kapazität nutzen.

Policies, die zum tatsächlichen Verhalten von Containern passen

Alles oben Beschriebene lässt sich von Hand erledigen: Quota umschreiben, LimitRange öffnen, Admission-Policy aktualisieren, die auffälligsten Workloads neu dimensionieren – und das Ganze wiederholen, sobald sich der Code ändert. Der schwierige Teil ist der letzte Halbsatz. Startup-Profile verschieben sich mit jedem Dependency-Update und jeder geänderten JVM-Flag, und eine Policy, die Sie im März korrekt abgestimmt haben, ist im Juni schon wieder falsch.

PerfectScale by DoiT profiliert jeden Container auf Workload-Ebene, sodass Startup- und Steady-State-Verhalten als getrennte Muster sichtbar werden, statt in einem Durchschnitt zu verschwimmen – und die Empfehlungen bemessen Memory so, dass der Boot-Peak abgedeckt ist, während die Requests auf dem Plateau bleiben. Bei Java-Workloads erkennt es JVM-Container automatisch, sobald der Coroot-Agent aktiviert ist, verfolgt Heap, Non-Heap und GC über die Zeit, markiert Container ohne explizite Heap-Einstellungen und respektiert -Xms und -Xmx, wenn es eine Änderung empfiehlt oder anwendet. Auf Clustern mit Kubernetes 1.33 oder neuer wendet die Automatisierung Right-Sizing in-place an, ohne den Pod neu zu starten, und greift nur dann auf einen Rolling Restart zurück, wenn ein Resize auf dem aktuellen Node nicht möglich ist – damit die Namespace-Quota widerspiegelt, was die Workloads jetzt nutzen, und nicht, was sie 45 Sekunden nach dem letzten Deploy brauchten.

Sie möchten sehen, wie ein Pod mit 2 Cores bootet und sich ohne Neustart und ohne blockierte Quota bei 200m einpendelt? Nehmen Sie am Workshop zum JVM-Startup-Spike teil, oder buchen Sie eine technische Session – dann schauen wir uns gemeinsam die Quota- und LimitRange-Policies in Ihren eigenen Clustern an.