Zusammenfassung

  • implementable hält die Entscheidung der Approver betroffener SIGs fest, ein KEP in die Implementierung zu geben; weder ein Commit, noch ein Release, noch ein aktivierter Cluster wird dadurch belegt.
  • Release-Meilenstein, Production Readiness Review, Tests, Feature Gate, nummeriertes Artefakt und Betreiber-Support sind getrennte Nachweise mit unterschiedlichen Entscheidungsträgern.
  • Ein knapper Beleg von der Vorlage bis zum Betrieb bewahrt diese Übergaben und verhindert, dass eine Designentscheidung als nicht gegebene Servicezusage erscheint.

Implementable bezeichnet eine begrenzte Designentscheidung

Der Kubernetes-Enhancement-Prozess ist kein bloßes Etikett für Wünsche. Er schafft ein nachvollziehbares Dokument für Motivation, Design, Zuständigkeiten, Stabilitätsziele und Fortschritt über mehrere Releases. Der öffentliche KEP-Prozess sagt, dass Approver aus den betroffenen SIGs kommen und entscheiden, wann ein KEP implementable wird. Er unterscheidet außerdem provisional, implemented, deferred, rejected, withdrawn und replaced. KEP-Prozess

Damit ist implementable kein leerer Status. Er zeigt an, dass Personen mit dem passenden technischen Mandat den Einstieg in die Umsetzung innerhalb dieses Designrahmens akzeptiert haben. Seine Aussage reicht aber nicht bis zu einem bestimmten Merge, einer bestimmten Release-Aufnahme oder einem konkreten Konfigurationswert eines apiserver, kubelet oder anderen Components. Erst recht ersetzt sie nicht die Entscheidung der Organisation, die Verfügbarkeit, Incident-Bearbeitung und Kundensupport tatsächlich tragen muss.

Diese Grenze wahrt die Arbeit der SIGs, statt sie abzuwerten. Design-Approver befassen sich mit Architektur, APIs und Abhängigkeiten zwischen SIGs. Betreiber befassen sich mit Kapazität, Add-ons, Version Skew, Telemetrie, Rücknahmefähigkeit und Servicevertrag. Nennt ein Bericht beides einfach „Genehmigung“, verschwindet aus ihm der Akteur, der die zweite Kategorie von Verlusten trägt.

Für ein Ziel-Release wird erneut geprüft

Das KEP-Template beschreibt den nächsten Übergang ausdrücklich. Soll ein Change für ein Ziel-Release betrachtet werden, muss das zum KEP gehörige Enhancement-Issue vor dem Enhancement Freeze auf den Meilenstein zeigen. Die Signoff-Checkliste enthält nicht nur implementable: Design-Details, Testplan, Graduation-Kriterien, eine abgeschlossene und genehmigte Production Readiness Review, Umsetzungshistorie, Nutzerdokumentation und weitere Materialien gehören dazu. Das Template verlangt, die Liste bei jeder Prüfung für einen Meilenstein erneut durchzugehen. KEP-Template

Das ist keine formale Wiederholung um ihrer selbst willen. Ein Design kann reif genug sein, um begonnen zu werden, und dennoch für den aktuellen Release-Zyklus keine ausreichende Evidenz haben: Tests fehlen, Dokumentation ist überholt oder ein Betriebsproblem aus einem früheren Zyklus verlangt eine neue Antwort. Umgekehrt beweist ein am Meilenstein sichtbares Issue nicht, dass jede Checklisten-Zeile abgeschlossen ist. Aus „angestrebt“ „veröffentlicht“ zu machen, ist derselbe Evidenzsprung wie aus „implementable“ „gemergt“ zu machen.

Die Production Readiness Review fügt eine weitere Entscheidungsfläche hinzu. Kubernetes beschreibt sie als Aufgabe eines Teams, das von SIG Leads getrennt ist und Observability, Skalierbarkeit, Supportability, sicheren Betrieb sowie Deaktivierung oder Rollback betrachtet. Seit Kubernetes 1.21 ist eine genehmigte PRR erforderlich, damit ein Enhancement Teil eines Releases werden kann. Production-Readiness-Review-Prozess

Das ist eine wichtige Upstream-Grenze für die Aufnahme in das Projekt, aber keine Zusicherung für jede Betriebsumgebung. Eine PRR entscheidet nicht, ob eine konkrete Kombination aus CNI, CSI, Admission Policy, Kapazität, Distribution oder Kundenvertrag tragfähig ist. Sie beweist, dass die unabhängige Prüfung ihren Auftrag erledigt hat; sie verlagert keine Betriebspflicht auf eine andere Institution.

Ein Feature Gate ist eine Komponentenoption, keine weltweite Adoption

Die Kubernetes-Referenz definiert ein Feature Gate als key=value-Konfiguration, die ein Kubernetes-Component über --feature-gates erhält. Jeder Component unterstützt nur Gates, die seine eigenen Funktionen betreffen; die Referenz trennt Alpha, Beta und stable sowie Einführungs- und Entfernungsversionen. Kubernetes Feature Gates

Das beantwortet „wie lässt es sich konfigurieren?“, nicht „wer hat es konfiguriert?“. Ein Gate in der Dokumentation sagt nichts darüber, ob es in einem bestimmten Cluster true ist. Ein Feature kann koordinierte Einstellungen mehrerer Components benötigen; eine Distribution kann zusätzliche Grenzen setzen; ein Betreiber kann die Option wegen Storage-Semantik, Monitoring-Signalen, Version Skew oder Rücknahmeweg bewusst deaktiviert lassen. Upstream stellt den Schalter bereit. Upstream legt ihn nicht für den Betreiber um.

Auch die Graduation-Beispiele im KEP-Template bleiben bei dieser Staffelung. Alpha verlangt Implementierung hinter einem Feature Flag und erste e2e-Tests. Beta verlangt funktionale, Sicherheits-, Monitoring- und Testanforderungen sowie die Bearbeitung bekannter Lücken. GA berücksichtigt reale Nutzung, Zeit für Feedback und die Auflösung von Beta-Rückmeldungen; nicht optionale Funktionen brauchen zusätzlich Conformance Tests. KEP-Template Das sind Nachweise für Projekt-Reife, nicht die Adoptionserlaubnis eines einzelnen Betreibers.

Auch ein nummeriertes Release spricht nicht für den Betreiber

Die Kubernetes-Release-Seite führt Release-Branches, x.y.z-Versionen, Patches und EOL-Daten als eigenständige öffentliche Aufzeichnung. Gegenüber einem Proposal-Status ist das ein stärkerer Beleg: Leser können vom Projekt veröffentlichte Artefakte und sein Supportfenster auf Projektebene bestimmen. Kubernetes Releases Dieses Fenster sagt jedoch nicht, was eine Managed Platform paketiert hat, ob ein Cluster kompatibel ist oder ob jemand Incident-Support zugesagt hat.

Das Enhancements-Repository ist eine wertvolle Karte für KEPs, Issues und Zyklen, aber kein Nachweis der Einführung. Kubernetes enhancements Wer unmittelbar vom KEP auf das Release, vom Release auf die Konfiguration und von der Konfiguration auf Support schließt, löscht bei jedem Schritt den einzigen Akteur, der den folgenden Schritt bestätigen könnte.

Sinnvoller ist ein kleiner Beleg von der Vorlage bis zum Betrieb: KEP-ID und unveränderliche Revision; verantwortliche und betroffene SIGs; Approver und Status; Meilenstein und Freeze; PRR-Antrag und Ergebnis; Code- und Testrevisionen; Gate, Component und Default; nummeriertes Release und Release Note; Distributionsgrenze; sowie die ausdrückliche Betreibererklärung zu Aktivierung, Support, Version Skew und Rollback. Der Beleg schafft keine neue Macht. Er ordnet jedes Urteil seinem tatsächlichen Autor zu.

Das folgt auch Lu Hengs Unterscheidung: Teilnahme und Expertise können Evidenz sein, erzeugen aber nicht automatisch ein Mandat für Abwesende; betriebliche Folgen sollten von denjenigen klar übernommen werden, die sie tragen. The Multi-Stakeholder Mirage Running-Code Primacy

Was dieser Nachweis nicht belegt

Die Quellen belegen weder den Status eines benannten KEP noch die Aufnahme eines Changes in ein bestimmtes Release, die Aktivierung eines Gates in einem bestimmten Cluster oder ein Kompatibilitäts- und Supportversprechen einer Distribution oder eines Betreibers. Sie bewerten keinen Anbieter, Kunden, Cluster oder Incident. Der vorgeschlagene Beleg ist eine redaktionelle Empfehlung von Daniel Kade, keine Kubernetes-Regel.

Quellen