Kubernetes v1.36:

Wie Staleness-Mitigation Controller endlich deterministischer macht

Kubernetes ist eine Open-Source-Plattform zur Orchestrierung containerisierter Anwendungen. Sie übernimmt die Automatisierung von Deployment, Skalierung und Betrieb und bildet damit das Fundament moderner, cloud-nativer Infrastrukturen. Im Kern basiert Kubernetes auf einem deklarativen Modell: Der gewünschte Zustand wird beschrieben – und Controller sorgen kontinuierlich dafür, dass dieser Zustand erreicht und gehalten wird.

Mit Version 1.36 rückt ein Thema in den Fokus, das lange unterschätzt wurde, aber tief in die Zuverlässigkeit von Kubernetes eingreift: Staleness in Controllern. Die Neuerungen sind technisch unspektakulär auf den ersten Blick – aber konzeptionell ein großer Schritt in Richtung robuster, nachvollziehbarer Systeme.

Das eigentliche Problem: Controller entscheiden auf Basis eines möglicherweise falschen Weltbilds

Um zu verstehen, warum diese Änderungen relevant sind, muss man sich kurz vor Augen führen, wie Controller arbeiten.

Ein Controller beobachtet den Zustand von Ressourcen über sogenannte Informer. Diese wiederum halten einen lokalen Cache vor, der über Watch-Events vom API-Server aktualisiert wird. Dieses Design ist bewusst gewählt: Es reduziert Last auf dem API-Server und ermöglicht schnelle Reaktionen.

Der Preis dafür ist jedoch offensichtlich – und wurde lange akzeptiert:

Der Controller arbeitet nicht auf der Realität, sondern auf einer möglicherweise veralteten Repräsentation dieser Realität.

In vielen Fällen ist das unproblematisch. Kubernetes ist schließlich auf eventual consistency ausgelegt. Doch in hochdynamischen Umgebungen beginnt genau hier das Problem.

Wenn ein Controller beispielsweise gerade eine Änderung durchgeführt hat – etwa Pods skaliert oder ersetzt – kann es passieren, dass sein eigener Cache diese Änderung noch gar nicht widerspiegelt. Der Controller „weiß" also nicht, dass er selbst gerade gehandelt hat.

Das führt zu subtilen, aber realen Problemen: Entscheidungen werden doppelt getroffen, notwendige Aktionen bleiben aus oder erfolgen zu spät. Besonders kritisch wird das bei stark frequentierten Ressourcen wie Pods, die unter hoher Änderungsrate stehen.

Warum Staleness oft erst in Produktion sichtbar wird

Das Tückische an Staleness ist nicht nur ihre Existenz, sondern ihre Unsichtbarkeit im normalen Entwicklungsprozess.

In Testumgebungen sind Cluster meist klein, Latenzen gering und Event-Flüsse überschaubar. Unter diesen Bedingungen funktionieren Controller scheinbar korrekt. Erst in produktiven Setups mit:

• hoher Parallelität
• vielen konkurrierenden Updates
• Netzwerk- oder API-Latenzen

zeigt sich, dass implizite Annahmen nicht mehr gelten.

Typische Symptome sind schwer zu reproduzieren: ein Controller reagiert „manchmal falsch", skaliert „gelegentlich zu spät" oder verhält sich „inkonsistent unter Last". Ohne tiefergehende Observability war es bisher nahezu unmöglich, diese Effekte sauber zu analysieren.

Kubernetes v1.36: Ein pragmatischer Ansatz für ein systemisches Problem

Die Neuerungen in Kubernetes 1.36 setzen genau an dieser Stelle an. Statt zu versuchen, das zugrunde liegende Konsistenzmodell zu verändern – was in einem verteilten System kaum praktikabel wäre – wird ein pragmatischer Ansatz verfolgt:

Controller sollen erkennen können, wann ihr Weltbild veraltet ist – und in diesem Fall bewusst nicht handeln.

Das ist ein wichtiger Paradigmenwechsel. Bisher galt implizit: Event empfangen → Reconcile ausführen. Jetzt gilt: Event empfangen → Konsistenz prüfen → ggf. Reconcile aussetzen.

Technische Grundlage: Konsistenz über Resource Versions

Im Zentrum dieser Logik steht die Nutzung von Resource Versions.

Jede Änderung an einem Kubernetes-Objekt erzeugt eine neue Resource Version. Diese kann als eine Art monotone Zeitachse verstanden werden. Kubernetes 1.36 macht sich diese Eigenschaft gezielt zunutze.

Durch Erweiterungen in client-go können Controller nun:

• den aktuellen Stand ihres lokalen Caches bestimmen
• diesen mit der zuletzt von ihnen selbst geschriebenen Version vergleichen

Die entscheidende Frage lautet:

Hat mein Cache mindestens den Stand, den ich selbst zuletzt geschrieben habe?

Wenn die Antwort „nein" ist, arbeitet der Controller mit veralteten Daten – und sollte keine weiteren Entscheidungen treffen.

Atomic FIFO: Konsistenz beginnt bereits beim Event-Handling

Ein oft übersehener Aspekt ist, dass Inkonsistenz nicht erst beim Lesen entsteht, sondern bereits bei der Verarbeitung von Events.

Vor Kubernetes 1.36 wurden Events in der Reihenfolge verarbeitet, in der sie eintrafen. Das klingt logisch, ist aber in verteilten Systemen problematisch, da Reihenfolgen nicht garantiert sind. Insbesondere beim initialen Aufbau eines Caches (List + Watch) konnten Zustände entstehen, die so im Cluster nie existiert haben.

Mit der Einführung von Atomic FIFO wird dieses Problem adressiert. Events – insbesondere aus initialen List-Operationen – werden atomar verarbeitet. Dadurch wird sichergestellt, dass der Cache zu jedem Zeitpunkt einen konsistenten Zustand repräsentiert.

Diese Änderung wirkt im Hintergrund, ist aber entscheidend: Ohne einen konsistenten Cache ist jede darauf aufbauende Staleness-Erkennung wertlos.

Vom Mechanismus zur Praxis: Wie Controller ihr Verhalten ändern

Die eigentliche Stärke der Neuerung zeigt sich in ihrer Anwendung im kube-controller-manager.

Controller wie der ReplicaSet-, StatefulSet- oder Job-Controller prüfen nun vor jeder Reconciliation, ob ihr Cache aktuell genug ist. Ist das nicht der Fall, wird der Durchlauf übersprungen.

Das bedeutet konkret: Der Controller wartet aktiv darauf, dass sein eigenes Weltbild „aufholt", bevor er erneut handelt.

Dieses Verhalten entspricht einem Konzept, das in vielen anderen Systemen selbstverständlich ist, in Kubernetes aber bisher gefehlt hat:

Read your own writes

Die Fähigkeit, eigene Änderungen zuverlässig wiederzusehen, bevor weitere Entscheidungen getroffen werden.

Eigene Controller: Mehr Kontrolle, aber auch mehr Verantwortung

Für Entwickler eigener Controller stellt Kubernetes 1.36 mit dem ConsistencyStore ein Werkzeug bereit, um diese Logik selbst umzusetzen.

Das Prinzip ist dabei bewusst einfach gehalten: Der Controller merkt sich, welche Resource Version er zuletzt geschrieben hat, und prüft vor jeder weiteren Aktion, ob der Cache diesen Stand bereits erreicht hat.

Interessant ist dabei, dass Kubernetes hier keinen Zwang einführt, sondern ein Muster etabliert. Das bedeutet: Die Verantwortung für korrektes Verhalten liegt weiterhin beim Entwickler – aber die notwendigen Werkzeuge sind nun vorhanden.

Gerade im Kontext von Operatoren und individuellen Automatisierungen ist das ein wichtiger Schritt. Viele selbst geschriebene Controller leiden heute unter genau den beschriebenen Staleness-Problemen, ohne dass dies den Autoren bewusst ist.

Observability: Staleness wird messbar

Neben der eigentlichen Mitigation ist die zweite große Neuerung die verbesserte Beobachtbarkeit.

Mit der neuen Metrik stale_sync_skips_total lässt sich erstmals quantifizieren, wie oft ein Controller aufgrund eines veralteten Caches bewusst nicht gehandelt hat. Das ist mehr als nur eine Debug-Hilfe – es ist ein Indikator für die „Gesundheit" der Kontrollschleifen.

Zusätzlich liefern Informer nun ihre aktuelle Resource Version als Metrik aus. Dadurch lässt sich sichtbar machen, wie weit ein Cache dem tatsächlichen Clusterzustand hinterherhinkt.

In der Praxis eröffnet das neue Möglichkeiten:

• Erkennen von API-Server-Latenzen
• Analyse von Bottlenecks in Event-Pipelines
• Bewertung der Reaktionsfähigkeit von Controllern

Was bisher ein Blackbox-Verhalten war, wird damit erstmals transparent.

Strategische Einordnung: Mehr Determinismus in einem bewusst inkonsistenten System

Kubernetes bleibt ein System, das auf Eventual Consistency setzt – und das aus gutem Grund. Starke Konsistenz würde die Skalierbarkeit massiv einschränken.

Die Neuerungen in v1.36 versuchen nicht, dieses Modell zu ersetzen. Stattdessen schaffen sie einen Mechanismus, um innerhalb dieses Modells bewusster mit Inkonsistenz umzugehen.

Das Ergebnis ist kein vollständig deterministisches System, aber ein deutlich besser kontrollierbares.

Gerade in Szenarien mit:

• hoher Änderungsfrequenz
• vielen parallel arbeitenden Controllern
• komplexen Abhängigkeiten zwischen Ressourcen

wird dieser Unterschied spürbar.

Ausblick: Der nächste logische Schritt für Controller-Frameworks

Ein besonders wichtiger Punkt ist der geplante Transfer dieser Mechanismen in controller-runtime. Damit würden auch alle darauf basierenden Operatoren automatisch von Staleness-Mitigation profitieren.

Das wäre ein bedeutender Schritt in Richtung Standardisierung: Nicht mehr jeder Controller implementiert eigene – oft fehleranfällige – Logik, sondern Konsistenz wird Teil des Frameworks.

Fazit

Kubernetes v1.36 liefert keine spektakulären neuen APIs, sondern adressiert ein fundamentales Problem im Betrieb verteilter Systeme: Entscheidungen auf Basis veralteter Informationen.

Die eingeführten Mechanismen sorgen dafür, dass Controller ihr eigenes Verhalten besser einordnen können. Sie handeln nicht mehr blind auf Events, sondern berücksichtigen den Zustand ihrer eigenen Wahrnehmung.

Für Betreiber bedeutet das stabilere Systeme. Für Entwickler bedeutet es klarere Leitplanken. Und für Kubernetes insgesamt ist es ein Schritt in Richtung mehr Reife – dort, wo es wirklich zählt: im Verhalten unter realen Bedingungen.