Kubernetes is a popular container orchestration platform, which is constantly evolving and expanding. New features are regularly added to improve its capabilities and address the changing needs of its users.
So, how does a new feature make it into Kubernetes? Well, it all starts with a Kubernetes Enhancement Proposal (KEP). It is a document that outlines a proposed change or new feature for the Kubernetes platform. It serves as a combination of various elements, including:
- Feature description: Explains the new features that are being proposed.
- Effort-tracking document: Tracks the progress of the proposal. This includes work that was done in the past, and work that is ongoing, or needs to be done in the future.
- Product requirements document: Outlines the requirements that must be met in order for the proposed enhancement to be considered successful.
- Design document: Provides a detailed description of how the proposed enhancement will be implemented and integrated into the existing Kubernetes system.
The purpose of a KEP is to provide a structured process for proposing, evaluating, and implementing changes into the Kubernetes platform. The process helps to ensure that proposed changes are thoroughly discussed, evaluated, and considered in terms of their potential impact on the platform. The input and feedback from the wider Kubernetes community are taken into account to build consensus on the proposed changes and guide the development of the KEP document.
Note that the KEP is created incrementally, with the collaboration and input of one or more Special Interest Groups (SIGs).
Kubernetes Special Interest Group (SIG)
Special Interest Groups (SIGs) are made up of volunteer members from the Kubernetes community who have expertise and interest in a particular area of the platform. They are responsible for the ongoing development and maintenance of specific components or features within Kubernetes.
SIGs play a crucial role in the Kubernetes development process by providing technical guidance, making decisions about feature development, and ensuring the stability and compatibility of the platform. They also provide a forum for community members to discuss and collaborate on specific areas of the platform.
Examples of SIGs within the Kubernetes community include SIG Architecture, SIG Cluster Lifecycle, SIG Network, and SIG Storage, among others. Each SIG has its own charter, leadership, and processes, but they all work together to ensure the ongoing development and success of the Kubernetes platform.
How Do KEPs Work?
The process for creating and evaluating KEPs is structured and well-defined. KEPs must be properly documented to ensure that they are thorough and well-considered.
KEPs follow a standard naming convention, consisting of a four-digit number followed by a short, descriptive title. Each KEP must start with a summary that provides a high-level overview of the proposed change or feature. This is followed by a set of goals and non-goals, which clearly define the motivation behind the proposal and what it aims to achieve.
The KEP then includes a user story, which helps to illustrate how the proposed change or feature will impact the end user and what benefits it will bring. The proposal also includes an assessment of any risks associated with the change or feature, along with mitigation strategies to address these risks.
Finally, KEPs must include a test plan to ensure that the proposed change or feature is thoroughly tested and validated before it is implemented. The proposal must also include graduation criteria, which outline the conditions that must be met before the feature can be considered for inclusion in the platform.
The Kubernetes Enhancement Proposal (KEP) process involves several stages, and can be assigned one of the following statuses throughout its lifecycle:
- Provisional: A KEP has been suggested and is being discussed. The SIG responsible for it has agreed that the KEP needs to be done.
- Implementable: The KEP has been approved to move forward with implementation.
- Implemented: The KEP has been finished and is not being changed anymore.
- Deferred: The KEP has been suggested but is not being worked on at the moment.
- Rejected: The people in charge of the KEP have decided not to move forward with it.
- Withdrawn: The authors who suggested the KEP have withdrawn their proposal.
- Replaced: The KEP has been replaced by a new one.
GitHub Issues vs KEPs
While GitHub issues are a popular way to report bugs or request new features, they have some limitations when it comes to proposing changes to Kubernetes.
One of the main disadvantages of using GitHub issues for this scenario is the lack of a structured process for evaluating and implementing changes. Anyone can open a GitHub issue at any time, which makes it difficult for Special Interest Groups (SIGs) to signal their approval or rejection of a proposed change. Additionally, managing a proposed change across multiple releases can be cumbersome, as labels and milestones need to be updated for each release that the change spans.
Another limitation of GitHub issues is the challenge of searching for text within an issue. The flat hierarchy of issues can also make navigation and categorization tricky. These limitations make it difficult for SIGs to effectively manage and evaluate proposed changes to the Kubernetes platform using GitHub issues.
In contrast, KEPs provide a structured and well-defined process for proposing, evaluating, and implementing changes to the platform. KEPs are designed to promote transparency and collaboration within the Kubernetes community and help ensure that proposed changes are thoroughly discussed and evaluated before they are implemented. By using KEPs, SIGs can manage proposed changes to the platform much more efficiently.
Whether you're a Kubernetes user or a developer, understanding KEPs is essential to participating in the Kubernetes community and contributing to the evolution of the platform.
If you are interested in learning more about KEPs, check out this YouTube video: