How Kubernetes reviews the operational cost of a feature

A Kubernetes feature can have a correct implementation and still create a difficult operational contract. Its API may require coordination between components that run different versions. Disabling it may leave state that older components cannot interpret. Those questions need answers while the design can still change, which is why the Kubernetes Enhancement Proposal process deserves attention from people who operate clusters.

The January 21 interview with Kirsten Garrison, lead of the Enhancements subproject, explains the coordination behind that process. Garrison describes SIG ownership and iterative review, including API and production readiness review. She also describes the move from spreadsheets to GitHub project boards for release tracking. The interview documents an existing process and work to improve it. It does not announce a new runtime capability or a replacement approval system.

I value Kubernetes most for the way its API machinery supports controllers and declared state. That makes the review of changes to those contracts particularly interesting. An implementation can change inside a component, but a contract adopted by other components becomes much harder to revise.

A proposal persists beyond a release

The KEP process document as it exists before this publication explains the underlying problem. Individual issues and pull requests do not adequately communicate a change across SIGs or preserve its purpose across releases. Decisions distributed among meetings and mailing lists are also difficult for a new participant to recover.

A KEP gives that discussion a persistent document with an owning SIG. Changes that affect multiple SIGs still have one owner, while approvers can represent the affected groups. This arrangement makes responsibility identifiable without assuming that one group can judge every consequence of the design.

The document also separates proposal status from implementation. A provisional proposal remains under discussion. An implementable proposal has approval to proceed. Keeping those states explicit matters when someone finds a design document through a search and assumes its presence means Kubernetes already provides the behavior it describes.

The contemporary KEP template makes that distinction more precise. Merging a KEP does not establish that it is complete or approved. Authors can merge an initial description and then develop it through focused changes. One KEP follows an enhancement through its lifecycle, including graduation, so the reasoning does not need to be recreated in a separate document for each stage.

That is useful to an operator reading about a proposed feature. The motivation explains the problem, while the current status explains what commitment the project has actually made. Neither alone establishes that an installed cluster supports the feature.

Production readiness changes the design questions

The template includes upgrade and downgrade strategy alongside version skew strategy. It explicitly asks how older kubelets or other components behave when the feature is used. This puts mixed-version operation into the proposal itself, where the answer can affect the API and implementation plan.

The production readiness questionnaire goes further. Authors must explain how to enable or disable the feature in a live cluster and whether doing so requires downtime. It asks whether enablement changes default behavior. Rollback questions include the consequences for existing workloads, so a feature gate is not treated as sufficient evidence that reversing a rollout is safe.

A flag can stop new behavior without explaining what happens to state created while that behavior was active. That distinction follows directly from the questionnaire. A convincing design needs to describe the state transition as well as the control that initiates it.

The 2023 interview with production readiness lead Wojciech Tyczynski explains why these questions belong at this stage. A nonscalable implementation can be repaired, but a nonscalable API or contract is harder to change. He describes the review as a way to make reliability the responsibility of feature authors throughout the project.

I agree with putting this work into the design document. It gives reviewers a chance to reject an operational assumption before users build automation around it. For Kubernetes, the interactions between components make that review part of the engineering work itself.

Evidence changes as a feature matures

The template distinguishes the test information expected at different stages. An alpha proposal can describe planned integration and end-to-end coverage. Later stages require links to implemented tests and their results. Graduation therefore requires evidence beyond the original intent to test something.

Troubleshooting receives similar treatment. The questionnaire asks what happens when the API server or etcd is unavailable. Its failure-mode guidance asks for detection and mitigation information, as well as useful diagnostics and testing. These questions connect the behavior promised by a feature to the evidence an operator can obtain when it fails.

The process has a real cost. The KEP process document acknowledges review bandwidth and the burden of additional documentation. That objection deserves a concrete response. Requiring another document is justified when it exposes a consequential design assumption or preserves reasoning that later contributors need. Repeating information without improving a decision would consume the same scarce reviewer time.

Garrison describes process-oriented templates and KEP versioning as work still underway. Their proposed purpose is to make process changes easier to document and template changes easier to communicate. Those intentions should be read as ongoing work, without assuming that publication of the interview completes either effort. For someone evaluating a feature today, the useful material remains the proposal at the relevant revision, its approvals, and the evidence recorded for its current stage.