Kubernetes-Startup-Spikes finden, bevor sie zum Incident werden

TL;DR

• Ein Startup-Spike ist der kurzzeitige CPU- und Speicherbedarf eines Containers während der Initialisierung (Class Loading, JIT-Kompilierung, Laden von Abhängigkeiten, Cache-Warming, Connection Pools), der abfällt, sobald der Prozess seinen Steady State erreicht.
• Durchschnittswerte und selbst das p99 über eine Woche verbergen ihn. Ein 45-Sekunden-Burst in einem 7-Tage-Fenster macht weniger als 0,01 % der Samples aus – jede Empfehlung auf Basis gemittelter Nutzung dimensioniert den Pod also für die falsche Phase.
• Der Spike zeigt sich als CPU-Throttling, OOM Kills mit Exit-Code 137, fehlgeschlagene Readiness Probes und zähe Rollouts, die sich alle in der ersten Minute eines Container-Lebens häufen und dann verschwinden.
• Erkennen lässt er sich, indem Sie die Nutzung über das Container-Alter statt über die Uhrzeit auftragen und Throttling- sowie OOM-Metriken auf junge Container filtern.
• Sobald Sie beide Phasen getrennt sehen, können Sie für jede einzeln dimensionieren, statt sich auszusuchen, welchen Incident Sie lieber hätten.

Ihr Service läuft einwandfrei. Die CPU liegt bei 15 % des Limits, der Speicher bei 60 %, keine Alerts. Dann ersetzt ein Rollout 40 Pods, die Hälfte davon wird 50 Sekunden lang gedrosselt, drei werden beim ersten Start per OOM Kill beendet, Readiness Probes schlagen fehl und der Rollout bleibt hängen. Zehn Minuten später sieht alles wieder gesund aus, und die Dashboards zeigen nichts Auffälliges.

Das ist ein Startup-Spike – und er bleibt unsichtbar, weil jede Metrik, mit der Sie Workloads dimensionieren, ihn wegmittelt.

Eine Erkennungs-Checkliste, die Sie noch diese Woche durchgehen können

1. Suchen Sie die Workloads mit den meisten Restarts. Fragen Sie increase(kube_pod_container_status_restarts_total[7d]) ab und sortieren Sie absteigend. Startup-Spikes tun dort am meisten weh, wo am häufigsten gestartet wird.
2. Prüfen Sie, ob das Throttling altersabhängig ist. Vergleichen Sie die obige Throttling-Query für junge Container mit denselben Workloads, sobald sie älter als zehn Minuten sind. Eine große Differenz bestätigt den Spike.
3. Prüfen Sie das OOM-Muster. Schauen Sie bei jedem Workload mit OOMKilled in last_terminated_reason auf restarts_total. Niedrige Zählerstände, gehäuft nach Deploys, bedeuten Startup-OOM.
4. Messen Sie die Time to Ready über einen Rollout. Stoßen Sie einen Rollout in Staging an, zeichnen Sie das Readiness-Histogramm auf, halbieren Sie dann das CPU-Limit und wiederholen Sie das Ganze. Das Delta ist der Preis Ihres Spikes in Sekunden.
5. Schauen Sie sich die ersten 300 Sekunden eines Pods an. Ein Grafana-Panel, ein Pod, Nutzung gegen Limit. Flacht die Linie am Limit ab, notieren Sie, wie lange.
6. Trennen Sie die beiden Zahlen. Notieren Sie für jeden Workload mit Spike den Startup-Peak und das Steady-State-p95. Das Verhältnis der beiden sagt Ihnen, wie viel Sie zu viel bezahlen, wenn Sie für den Peak dimensionieren – und wie stark Sie drosseln, wenn Sie für das Plateau dimensionieren.

Die Fixes, die das Problem unbemerkt verschlimmern

Einige verbreitete Reaktionen verstecken das Symptom, statt es zu lösen.

Eine startupProbe mit großzügigem failureThreshold stoppt die Restart-Schleife – aus Zuverlässigkeitssicht die richtige Entscheidung –, aber sie stoppt auch den Alert. Der Pod bootet weiterhin 90 Sekunden lang gedrosselt, und die Nutzer warten weiterhin darauf; Sie sehen es nur nicht mehr.

Den CPU-Request auf den Peak anzuheben behebt das Throttling und zementiert die Verschwendung über jede Replica für den Rest ihres Lebens. Bei einem Service mit 40 Replicas, einem 2-Core-Spike und einem 200m-Plateau reserviert diese Entscheidung 72 Cores, die zu 99,9 % der Zeit im Leerlauf sind. Sie schadet außerdem dem Bin-Packing: Der Scheduler platziert Pods nach Request, und aufgeblähte Requests bedeuten weniger Pods pro Node und mehr Nodes, als Sie brauchen.

CPU-Limits komplett zu entfernen – was PerfectScale für die meisten Workloads im Guide zu CPU-Limits empfiehlt – lässt den Start tatsächlich in die freie Node-Kapazität bursten. Das hilft, und es ist meistens der richtige Default. Aber es funktioniert nur, wenn der Node in dem Moment freie CPU hat, in dem der Pod startet. Während eines Rollouts, wenn 20 neue Pods auf demselben frischen Node landen und alle gleichzeitig zu kompilieren beginnen, gibt es keine freie CPU zum Bursten. Der Spike kommt zurück – als Contention statt als Throttling.

Jede dieser Maßnahmen ist für sich genommen vernünftig. Das Problem: Alle drei behandeln den Container weiterhin als eine einzige Zahl, obwohl seine Nutzung zwei klar unterschiedliche Formen hat.

Für zwei Phasen dimensionieren statt für eine

Kubernetes bringt inzwischen die Grundfunktion mit, die einen Zwei-Phasen-Ansatz möglich macht. In-Place Pod Resize – die Möglichkeit, Requests und Limits eines laufenden Containers ohne Neustart zu ändern – wurde in 1.35 stable und ist in 1.36 standardmäßig aktiviert (PerfectScale hat die Alpha-Version schon 2024 getestet, inklusive aller Bugs). GKE nutzt das Feature bereits für seinen Startup-CPU-Boost. Das Muster ist simpel: Geben Sie dem Pod, was er zum Booten braucht, und nehmen Sie es zurück, sobald er den Steady State erreicht.

Das funktioniert nur, wenn Sie die beiden Phasen überhaupt unterscheiden können – und genau dafür ist alles oben Beschriebene da.

FAQ

Was ist CPU-Throttling in Kubernetes? CPU-Throttling tritt auf, wenn ein Container innerhalb einer CFS-Scheduling-Periode (standardmäßig 100 ms) mehr CPU-Zeit nutzen will, als sein Limit erlaubt. Der Kernel pausiert den Container bis zum Beginn der nächsten Periode. Ein Limit von 500m lässt einen Container 50 ms von jeweils 100 ms laufen; ist das früh aufgebraucht, wartet der Container. Throttling verlangsamt die Anwendung, ohne sie zum Absturz zu bringen, und kann sogar auftreten, wenn der Node freie CPU hat.

Warum wird mein Pod nur beim Start per OOM Kill beendet? Die Initialisierung allokiert oft mehr Speicher als der Steady-State-Betrieb: Klassen laden, Caches aufbauen, Migrationen ausführen oder einen JVM-Heap dimensionieren, bevor die Anwendung ihr tatsächliches Working Set kennt. Wenn das Memory-Limit den Steady-State-Wert abdeckt, aber nicht den Startup-Peak, killt der Kernel den Container während des Boots mit Exit-Code 137. Übersteht der Container den Start, fällt die Nutzung unter das Limit und der Pod läuft normal – deshalb bleibt der Restart-Zähler meist bei eins oder zwei stehen.

Wie unterscheide ich einen Startup-Spike von einem Steady-State-Sizing-Problem? Filtern Sie Ihre Throttling- und OOM-Metriken nach Container-Alter. Konzentrieren sich die Probleme auf die ersten ein bis zwei Minuten eines Container-Lebens und verschwinden danach, ist es ein Startup-Spike. Treten sie an zufälligen Punkten im Lebenszyklus des Pods auf, ist der Steady-State-Request oder das Limit falsch.

Behebt das Entfernen von CPU-Limits das Startup-Throttling? Es entfernt die CFS-Quota, der Container kann also in die freie CPU des Nodes bursten. Das hilft, wenn Nodes Spielraum haben. Es hilft nicht während eines Rollouts, wenn viele Pods gleichzeitig auf demselben Node starten, weil dann keine freie CPU zum Bursten da ist. Der Request bestimmt weiterhin das Scheduling – ein zu klein gewählter Request kann also immer noch zu viele Pods mit Spikes auf einem Node landen lassen.

Beide Phasen jedes Workloads im Blick

Alles oben Beschriebene können Sie mit Prometheus, kube-state-metrics und ein paar Grafana-Panels selbst bauen. Der schwierige Teil ist, das für 400 Workloads zu tun und aktuell zu halten, während Code-Änderungen verschieben, wo der Spike landet.

PerfectScale by DoiT profiliert jeden Container auf Workload-Ebene, sodass Startup-Verhalten und Steady-State-Verhalten als getrennte Muster sichtbar werden statt als ein vermischter Durchschnitt. Bei Java-Workloads geht es eine Ebene tiefer: Sobald der Coroot-Agent aktiviert ist, erkennt es JVM-Container automatisch, verfolgt Heap, Non-Heap und GC-Zeit im Zeitverlauf, markiert Container, die ohne explizite Heap-Einstellungen laufen, und respektiert -Xms und -Xmx, wenn es eine Empfehlung ausspricht oder eine Änderung anwendet. Auf Clustern mit Kubernetes 1.33 oder neuer wendet die Automatisierung Right-Sizing direkt im laufenden Betrieb 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 machbar ist.

Sie möchten live sehen, wie der Startup-Spike geglättet wird? Kommen Sie zum Workshop zum JVM-Startup-Spike, in dem wir durchgehen, was beim Boot in der JVM passiert, und einen laufenden Pod ohne Neustart auf Steady-State-Werte verkleinern. Oder buchen Sie eine technische Session, und wir schauen uns gemeinsam Ihre Cluster an.