Kubernetes 1.37 und der 429: Wenn Ihre Automatisierung gegen den API-Server läuft

Ein Satz, den ich in Betriebs-Reviews oft höre: “Das Skript läuft seit zwei Jahren, das kann nicht das Problem sein.”

Am 26. August ist Kubernetes 1.37 unter dem Namen Garhwal erschienen, mit 67 Enhancements, davon 16 auf Stable. Interessanter als die Feature-Liste ist eine Regel, die vorher nur unter Last sichtbar war: Wenn der API-Server seine Watch-Caches aufbaut, beantwortet er nicht mehr jede Anfrage. Einen Teil weist er mit HTTP 429 und Retry-After ab.

Für den Cluster ist das eine Verbesserung. Für alles, was selbst gegen die API programmiert ist, ist es ein Testfall, den die meisten nie gefahren sind.

Die Annahme, die nie jemand aufgeschrieben hat

“Der API-Server antwortet.” Dieser Satz steht in keinem Runbook und in keinem Kommentar, und trotzdem steckt er in jedem Skript, jedem Exporter und jeder Pipeline, die mit dem Cluster redet. Er ist so selbstverständlich, dass er nie zur Entscheidung wurde.

Der 429 macht diese Annahme sichtbar. Der API-Server ist eine Komponente mit begrenzter Bedienkapazität. Er ist keine Datenbank, die immer liefert, und er ist auch kein Webserver, der unter Last einfach langsamer wird. Er hat jetzt einen definierten Weg, Nein zu sagen, und er benutzt ihn.

Was in 1.37 technisch passiert

Hinter der Änderung steht KEP-4568, Resilient Watchcache Initialization, verantwortet von SIG API Machinery. Vorher konnte der Aufbau der Watch-Caches eine Welle teurer list- und watch-Anfragen gegen etcd auslösen. Diese Welle konnte die API Priority and Fairness ausschöpfen und das Control Plane mitten in der Erholung erneut umwerfen. Genau dann also, wenn es ohnehin gerade angeschlagen ist.

Seit 1.37 delegiert der kube-apiserver in dieser Phase nur eine begrenzte Zahl von Anfragen weiter und lehnt den Rest mit HTTP 429 ab. Die offizielle Empfehlung im Release-Beitrag ist eindeutig: Clients, ausdrücklich auch eigene Controller und Operatoren, sollen 429-Antworten sauber behandeln, den Retry-After-Header respektieren und exponentielles Backoff verwenden.

Wichtig für die Einordnung ist die Historie der Feature Gates. ResilientWatchCacheInitialization erreichte bereits in v1.34 Stable. Das verbleibende Gate WatchCacheInitializationPostStartHook ist laut Upstream seit v1.36 standardmäßig aktiv und wird in v1.37 auf Stable gehoben und fest eingeschaltet.

Das verschiebt den Zeitpunkt der Hausaufgabe nach vorn. Wer heute 1.36 betreibt, hat das Verhalten bereits im Cluster. Es ist keine Frage für das nächste Upgrade, sondern diese Woche prüfbar.

Zwei ehrliche Einschränkungen gehören dazu. Kleine Cluster mit wenig Objekten und wenigen Clients bekommen das selten zu sehen. Und der Zeitpunkt lässt sich nicht planen, weil die Caches beim Start des API-Servers und in jeder Erholungsphase neu aufgebaut werden.

Warum das die eigenen Werkzeuge trifft

Die Distribution hat ihre Hausaufgaben gemacht. Was Sie selbst gebaut haben, bringt niemand mit.

Werkzeuge, die auf einer offiziellen Client-Bibliothek aufsetzen, sind meist unkritisch, weil Rate Limiting und Backoff dort eingebaut sind. Interessant wird die zweite Gruppe: Shell-Skripte mit kubectl und set -e, bei denen jeder Rückgabewert ungleich null das Skript beendet. Handgeschriebene HTTP-Aufrufe gegen die API, oft mit curl und ohne jede Auswertung des Statuscodes. Backup- und Zertifikats-Jobs im Cron. Kleine Exporter, die jede Minute Objekte listen. Pipelines, die im Deployment-Schritt den Cluster-Zustand abfragen. Und seit einiger Zeit Agenten, die über eine API oder MCP-Tools gegen den Cluster arbeiten.

Die Schadensmechanik ist in allen Fällen ähnlich. Der Client fragt sofort erneut an, ohne Wartezeit, und erhöht damit genau die Last, die der 429 abbauen soll. Oder er ignoriert den Retry-After-Header und wählt ein eigenes, zu kurzes Intervall. Oder er wertet den Statuscode gar nicht aus und liest eine abgelehnte Antwort als leeres Ergebnis. Der letzte Fall ist der unangenehmste, weil er keinen Alarm erzeugt. Ein Backup-Skript, das “keine Objekte gefunden” versteht, meldet einen erfolgreichen Lauf.

Dazu kommt der Nebeneffekt im Betrieb: CrashLoops bei Werkzeugen, die bei Fehlern beenden, und ein Alarm-Sturm in der Phase, in der Sie gerade Ruhe bräuchten.

Bei KI-gestützten Assistenten verschärft sich das noch. Ein Agent, der einen abgelehnten Aufruf nicht als Fehlerklasse erkennt, formuliert eine nicht verfügbare Datenquelle als Analyseergebnis. Er sagt nicht “ich konnte den Cluster nicht abfragen”, sondern liefert eine Einschätzung, die auf nichts beruht. Wie man diese Grenze sauber zieht, habe ich in Guardrails für AI-Troubleshooting auf Linux und in KI-Ticket-Triage beschrieben. Die Fehlerklassifizierung liegt eine Ebene unterhalb dieser Guardrails, und ohne sie tragen die Guardrails nicht.

Wie Sie das ohne Incident prüfen

Der übliche Weg wäre, auf den nächsten kontrollierten Neustart des Control Plane zu warten und dabei zuzusehen. Das ist ungünstig, weil Sie dann zwei Probleme gleichzeitig haben.

Der praktikable Weg ist ein kleiner Reverse Proxy vor dem API-Endpunkt, der einen definierten Anteil der Anfragen mit 429 und Retry-After: 1 beantwortet. Ihre Clients laufen dagegen, Sie beobachten das Verhalten.

Vier Fragen je Client, mehr braucht es zunächst nicht:

Erkennt er den 429 überhaupt als eigene Fehlerklasse?
Respektiert er Retry-After, oder wählt er ein eigenes Intervall?
Hat er ein Zeitlimit, oder läuft er in eine Endlosschleife?
Kommt er von selbst zurück, wenn der Proxy wieder normal antwortet?

Dazu die Beobachtung aus dem Betrieb: Anfragen pro Sekunde, Logvolumen, Neustarts und die Zahl der ausgelösten Alarme. Das ist ein halber Tag Arbeit und beantwortet eine Frage, die sonst erst in einem echten Incident beantwortet wird, unter Zeitdruck und mit Publikum.

Sinnvoller Einstieg ist die Inventur: Listen Sie auf, was bei Ihnen regelmäßig gegen die API spricht. Der Kandidatenkreis ist in aller Regel größer als erwartet, weil die kleinen Helfer über Jahre entstanden sind und nie in einer Übersicht gelandet sind.

Fehlerklassen im Monitoring

Aus dem Test folgt eine Regel, die auch ohne Kubernetes trägt. Retry-fähig mit Backoff und Zeitlimit sind 429, 5xx, Timeouts und 409. Nicht retry-fähig sind 401, 403 und 404, weil ein erneuter Versuch dort nie zu einem anderen Ergebnis führt.

Der 429 gehört als eigene Kennzahl ins Monitoring und nicht in einen generischen Fehleralarm. Upstream heißen die relevanten Metriken apiserver_request_total mit dem Label code sowie die Flow-Control-Metriken, etwa apiserver_flowcontrol_rejected_requests_total. Prüfen Sie die Namen gegen Ihre eigene Instanz, bevor Sie ein Dashboard darauf bauen, denn je nach Distribution und Scrape-Konfiguration unterscheiden sich Labels und Verfügbarkeit.

Zwei weitere Änderungen mit Stolperpotenzial

Neben dem 429 stecken in 1.37 zwei Punkte, die im Upgrade auffallen können, ohne dass sie in einer Feature-Übersicht besonders hervorstechen.

SELinux-Volume-Labeling. SELinuxMount und SELinuxChangePolicy sind in v1.37 Stable und standardmäßig aktiv. Volumes werden mit -o context=<label> gemountet statt rekursiv umgelabelt, allerdings nur, wenn der CSI-Treiber über .spec.seLinuxMount: true im CSIDriver-Objekt mitmacht. Ein Mount trägt genau einen SELinux-Kontext. Pods mit unterschiedlichen SELinux-Labels, die sich auf demselben Node ein Volume teilen und unter rekursivem Relabeling koexistiert haben, können nach dem Upgrade nicht mehr starten. Für einen einzelnen Workload stellt .spec.seLinuxChangePolicy: Recursive das alte Verhalten wieder her. Clusterweit abschalten lässt sich das Verhalten noch, gesperrt wird es erst in v1.38. Cluster ohne SELinux sind nicht betroffen.

Static Pods und API-Referenzen. Static Pods konnten über Felder wie configMapRef oder secretRef auf ConfigMaps und Secrets verweisen. Das war ein Fehler, nicht ein Feature, und er ist in v1.37 behoben. Die Referenzen sind jetzt strikt verboten, und das Feature Gate PreventStaticPodAPIReferences, über das man sich bisher ausnehmen konnte, ist entfernt. Ein grep über /etc/kubernetes/manifests/ nach den beiden Feldnamen kostet eine Minute und erspart im Zweifel eine unschöne Suche.

Als Perspektivpunkt für regulierte Umgebungen: Manifest-basierte Admission-Konfiguration ist in 1.37 Beta. Admission Webhooks und CEL-Policies lassen sich über staticManifestsDir in der AdmissionConfiguration von der Platte laden. Sie greifen ab dem Start des API-Servers, funktionieren auch bei nicht erreichbarem etcd und können die API-basierten Admission-Ressourcen selbst vor Änderungen schützen. Wer Nachweispflichten nach DORA oder NIS2 erfüllen muss, sollte sich das ansehen.

Was das für die Upgrade-Routine heißt

Die meisten Upgrade-Tests prüfen, ob die Control-Plane-Komponenten wieder laufen und ob die Workloads wieder hochkommen. Beides sagt nichts darüber aus, wie sich Ihre eigenen Clients verhalten haben, während der Cluster sich erholt hat.

Zwei Punkte gehören deshalb in die Checkliste. Erstens eine gepflegte Liste aller Werkzeuge, die regelmäßig gegen die API sprechen, mit dem Vermerk, ob sie retry-fähig sind. Zweitens der 429-Test aus dem vorigen Abschnitt als wiederkehrender Schritt vor jedem Minor-Upgrade, nicht als einmalige Aktion.

Wer tiefer einsteigen will: Das Release-Team von v1.37 veranstaltet am 23. September um 16:00 UTC ein Webinar zu den Highlights des Releases.

Wollen Sie wissen, wie Ihre Plattform darauf reagiert?

Die Frage, welche Werkzeuge in Ihrem Betrieb gegen die API sprechen und wie sie sich bei einer nicht verfügbaren Control Plane verhalten, lässt sich nicht aus der Dokumentation beantworten. Sie braucht einen Blick in das konkrete Setup.

Ich bin Björn Ohlrich und begleite seit über 20 Jahren Infrastruktur-Projekte, seit einigen Jahren mit Schwerpunkt Kubernetes On-Premise in mittelständischen und regulierten Umgebungen. Zertifiziert als CKA, RHCE und RHCSA.

Genau diese Inventur ist Teil des Kubernetes Review: eine strukturierte Bewertung Ihres Setups nach Sicherheit, Stabilität, Performance und Architektur, mit Ampelbewertung und konkreten Handlungsempfehlungen. Wie ich KI-gestützte Werkzeuge im Betrieb einordne, steht unter AI Ops im Betrieb.

Lassen Sie uns unverbindlich sprechen. Ein Gespräch reicht meist, um einzuschätzen, ob das Thema bei Ihnen ansteht.

Quellen

Kubernetes Blog, 26.08.2026: Kubernetes v1.37: Garhwal
KEP-4568: Resilient Watchcache Initialization
Kubernetes Blog, 22.04.2026: SELinux Volume Label Changes goes GA (and likely implications in v1.37)
CHANGELOG-1.37.md
Kubernetes Metrics Reference