Learn Cloud Native & CNCF - Kubernetes Governance & SIGs

#Introduction

Throughout this series, Kubernetes has been called the heart of the CNCF ecosystem. Episode 15 will dissect how that heart is managed: not by a single company, but by a global community with highly structured governance. Understanding Kubernetes governance is the key to understanding why a project this large can keep developing stably.

Kubernetes' governance structure consists of several layers: the Steering Committee at the top, dozens of Special Interest Groups (SIGs) handling every technical field, and the KEPs mechanism for designing major changes. All work with a consistent release rhythm.

By the end of this episode you will understand Kubernetes' governance structure, know the important SIGs, and understand the release cadence and version support policy in effect.

#How Kubernetes Is Managed

#The Steering Committee at the Top of Governance

At the top of Kubernetes governance is the Steering Committee — a small group elected by contributors holding specific roles. Its job is to oversee project direction, resolve conflicts, and ensure community values are upheld.

The Steering Committee doesn't handle day-to-day technical details; that's the SIGs' job. Its role is more about maintaining the overall health of the project: ensuring fair processes, transparent decisions, and a healthy community.

#A Structure Designed to Scale

Kubernetes governance was designed with one question in mind: how do you manage thousands of contributors without chaos? The answer is clear division of responsibility. Every field has an owner, every change has a process, and every decision has a trace.

This pattern resembles national governance: there's an executive body, bodies handling fields, and a legal mechanism for proposing changes. The project's scale has indeed reached that level.

#SIGs: Special Interest Groups

#What a SIG Is

A Special Interest Group (SIG) is a group that handles one technical field of Kubernetes on an ongoing basis. Every SIG has a clear scope, elected leaders, and regular open meetings. These are the main working units of Kubernetes development.

The number of SIGs is substantial and keeps growing with the project's needs. There are SIGs handling security, networking, storage, scheduling, and user experience. Each operates independently yet under the shared governance umbrella.

#Notable SIG Examples

Here are some SIGs whose names you'll often come across:

• SIG Auth — authentication, authorization, and security policy.
• SIG Network — networking, services, and network policy.
• SIG Storage — storage and volumes for stateful workloads.
• SIG Scheduling — how pods are placed onto nodes.
• SIG Apps — application and workload management.
• SIG CLI — command-line tools like kubectl.
• SIG Windows — Windows node support.

When you read Kubernetes documentation and ask "who manages this part?", the answer is almost always found in one of the SIGs.

#Working Groups and KEPs

#Working Groups for Cross-SIG Problems

Alongside SIGs, there are working groups (WG) formed to handle problems that cut across many SIGs. Because the problem crosses fields, solving it requires coordination between SIGs — and WGs are the forum for that.

WGs are more temporary than SIGs: once a problem is solved or its direction is clear, the WG can be disbanded. This structure gives flexibility to handle new problems without changing the permanent structure.

#KEP: Kubernetes Enhancement Proposal

KEPs, or Kubernetes Enhancement Proposals, are the official mechanism for proposing major changes to Kubernetes. Before a feature is built, it must be written as a KEP: the problem it solves, the solution design, and the implementation plan.

KEPs are one of Kubernetes' stability secrets. By requiring a written proposal before code is written, the project avoids impulsive decisions and ensures every major feature is thoroughly considered by the community.

#Kubernetes Releases

#Three Releases per Year

Kubernetes follows a cadence of three releases per year — about one release every four months. This cadence is stable and predictable, so users and vendors can plan upgrades comfortably without surprises.

Kubernetes releases also run consistently with sequential codenames and support for all major platforms. The release process is run by community volunteers through a release team formed specifically for each cycle.

#The Current Version and N-3 Support Policy

As of this series' writing, the stable Kubernetes version is 1.36, released in April 2026, with the latest patch 1.36.2 in June 2026. The support policy follows the N-3 pattern: the last three minor releases remain supported, roughly one year per minor version.

The N-3 pattern is important to understand: it determines how long you can stay on one version before you must upgrade. To check your version and support policy, use the commands below:

kubectl version --short
curl -sS https://endoflife.date/api/kubernetes.json | jq '.[0:4] | .[] | {cycle, latest, latestReleaseDate}'

The kubectl version --short command shows the client and server versions, while curl -sS to endoflife.date shows the release cycles still supported. Understanding versions and their support is an important part of an operator's responsibility.

#Why Understanding Kubernetes Governance Matters

#Reading Where the Project Is Heading

Understanding governance lets you read the project's direction: which KEPs are being discussed, which SIGs are most active, and what decisions were just made. This is a far richer source of information than mere release news.

For those who want to contribute, this structure also provides a roadmap: pick a SIG that matches your interest, follow its meetings, then start with small tasks. The path to being a full Kubernetes contributor is very clear — you just need to choose which door to enter through.

#Big Projects Don't Manage Themselves

The most important message of this episode: a project as large as Kubernetes can't be managed chaotically. The success of a project that lasts decades comes from good governance, not just good code. This pattern also applies to other projects you'll encounter in the future.

#Closing

Episode 15 dissected Kubernetes governance: the Steering Committee at the top, dozens of SIGs handling every technical field, working groups for cross-field problems, KEPs as the proposal mechanism, and the three-releases-a-year cadence with N-3 support.

Key takeaways:

• The Steering Committee is the community-elected peak of Kubernetes governance.
• SIGs handle one technical field on an ongoing, open basis.
• SIG Auth, Network, Storage, Scheduling, Apps, and CLI are notable examples.
• Working groups handle problems that cut across many SIGs.
• KEPs are the written proposal mechanism for major changes.
• Kubernetes releases three times a year; version 1.36 with N-3 support.

In episode 16 we'll discuss security in depth: open source best practices and security — the Best Practices Badge, security audits, SBOM, and how CNCF projects handle CVE and supply chain issues.