AI
KEPs: The Formal Gate for Kubernetes Features
KEPs (Kubernetes Enhancement Proposals) track every new feature and deprecation entering a Kubernetes release. Introduced in 2017 by Caleb Miles and modeled on Rust’s RFC and Python’s PEP, each KEP lives in the kubernetes/enhancements GitHub repo as a kep.yaml metadata file plus a design document. The project under SIG Architecture holds bi-weekly meetings. Three releases ship per year, each running 15 weeks. Any significant change to Kubernetes must go through this process before code merges.
From Idea to Tracked Enhancement: The Contributor Path
A contributor can’t open a PR to Kubernetes and expect it reviewed without a KEP. First, identify which SIG owns the change. For a container runtime interface change, that’s SIG Node. Attend their meetings, get the SIG to sponsor the KEP, then open a PR to kubernetes/enhancements with a kep.yaml (milestone, target stage) and the full design doc. New features always enter at alpha, turned off by default. The KEP must also pass Production Readiness Review before any code PR opens.
The 15-Week Release Timeline
Week 0: the team builds the tracking board and cleans stale issues. Weeks 1 through 4 cover a call for enhancements sent to the dev mailing list and tracking which KEPs have PRR-related PRs open. PRR freeze lands around week 4. Enhancement freeze follows about a week later, requiring final requirements declared and kep.yaml merged. Code freeze, near week 13, is the last deadline for code, docs, and tests. Week 15 is release day, after which only bug fixes and cherry-picks land.
Hard Deadlines and Growing Throughput
Two and a half years ago the team tracked enhancements in a Google Sheet and needed three more sub-teams than it does today. PRR freeze shifted from a soft deadline owned by SIG Architecture’s production readiness sub-project to a hard deadline owned by the release team starting with v1.35. The old arrangement caused KEPs to be dropped late because PRR hadn’t been completed, or contributors used templates two years out of date. An exception is still available: an email with four questions, filed in advance.
Q&A
Why did enhancements tracking originally use Google Sheets instead of GitHub? The release team’s tracking approach predates the existence of GitHub’s issue tracker. ▶ 28:54
Is there automation behind kep.yaml that drives the tracking board? The board builds automatically from milestone and lead-opted-in labels, but no automation validates whether a KEP template is current. ▶ 29:31
Notable Quotes
Google sheet. Okay. It was nightmarish Kat Cosgrove · ▶ 20:24
people can make money off of us. Kat Cosgrove · ▶ 27:07
it is basically just the release board. Kat Cosgrove · ▶ 31:30
Key Takeaways
- Every Kubernetes feature must go through a KEP: SIG sponsorship, PRR, then code merge.
- The 15-week release cycle runs four sequential freezes: PRR, enhancements, code, and docs.
- PRR freeze became a hard deadline in v1.35, growing per-release KEP throughput from roughly 40 to 60.
About the Speaker(s)
Rayan Das is a Senior Platform Engineer on the Storage Platforms team at DigitalOcean. He has been involved with Kubernetes SIG Release since v1.29 and has led the Release Docs and Enhancements teams.
Kat Cosgrove is Head of Developer Advocacy at Minimus, focused on growing open source through authentic contribution. Her specialties include approachable 101-level content and deep dives on the history of technology, with a focus on DevOps and cloud native.
Subhasmita Swain is an R&D Engineer with Civo, active in the Kubernetes Release Signal team and Cluster-API release team. Her experience includes internships with the Linux Foundation’s Kubernetes project and Outreachy.
Sreeram Venkitesh is a Senior Software Engineer at DigitalOcean on the managed Kubernetes team, contributing primarily to SIG Release, SIG Contribex Comms, and SIG Node. He was part of the Kubernetes release team from v1.29 to v1.35.