Community and governance
How the CNCF is run (Governing Board, TOC, the five TAGs), how Kubernetes is run (Steering Committee, SIGs, working groups, KEPs), the release cycle, and the open standards that keep the ecosystem pluggable.
Exam tasks: 4.3 (cloud native community and collaboration: governance, open standards, contributing)
The decision: who decides what (the CNCF TOC, a TAG, a Kubernetes SIG), how does a change get into Kubernetes, and which open standard lets you swap one component for another?
Two levels of governance
- CNCF bodies set direction and decide project levels. They don't run a project's day-to-day work. Each project has its own maintainers and governance, documented in its repository.
- Decisions in both places lean on open meetings, public mailing lists, recorded calls and lazy consensus: a proposal passes unless someone objects in the review window.
The CNCF side
| Body | What it does |
|---|---|
| Governing Board | Business side: budget, marketing, events, trademarks |
| Technical Oversight Committee (TOC) | Technical vision; votes on projects joining and moving between sandbox, incubating and graduated. Currently 11 voting members, elected or appointed by several constituencies |
| Technical Advisory Groups (TAGs) | Domain experts who help the TOC: review projects, write white papers and best practices, run time-bound initiatives |
| End User community | Companies that use cloud native tech (not vendors) and feed back what they need |
| Ambassadors | Community members who teach and advocate at events and online |
In 2025 the TOC consolidated the eight older TAGs into five:
| Current TAG | Covers | Absorbed |
|---|---|---|
| Developer Experience | Building, testing and delivering applications | App Delivery |
| Infrastructure | Networking, storage, compute, edge | Network, Storage |
| Operational Resilience | Observability, reliability, cost, energy, day-2 operations | Observability, Environmental Sustainability |
| Security and Compliance | Supply chain, policy as code, threat modeling, audits | Security |
| Workloads Foundation | Workload runtimes and lifecycle | Runtime |
Contributor Strategy became a TOC subproject rather than a TAG.
Legacy: use the five 2025 TAGs instead
Older material lists TAG Security, TAG Storage, TAG Network, TAG Runtime, TAG App Delivery, TAG Observability, TAG Contributor Strategy and TAG Environmental Sustainability, and before that "SIGs" at the CNCF level. If a question uses an old name, map it to the current TAG above.
TAG vs SIG
TAGs belong to the CNCF and advise across all projects. SIGs belong to Kubernetes and own Kubernetes code. "Which group owns the kubelet?" is SIG Node, not a CNCF TAG.
The Kubernetes side
- The Steering Committee (seven elected members) owns Kubernetes governance as a whole: charters, SIG creation, and resolving escalations. It doesn't approve individual features.
- Special Interest Groups (SIGs) own areas of the code and its long-term direction. Each has chairs, technical leads and public meetings, and may have subprojects.
- Working groups (WGs) bring several SIGs together on a cross-cutting topic for a limited time. They own no code; their output lands in the SIGs that sponsor them.
- Committees handle sensitive topics privately: the Security Response Committee handles vulnerability reports, and the Code of Conduct Committee handles conduct issues.
| SIG | Owns (examples) |
|---|---|
| SIG Architecture | Overall design principles, API conventions, production readiness reviews |
| SIG Node | kubelet, container runtime interface, Pod lifecycle |
| SIG Network | Services, kube-proxy, DNS, network policy, Gateway API |
| SIG Storage | Volumes, PV and PVC, CSI integration |
| SIG Apps | Workload controllers: Deployments, StatefulSets, Jobs |
| SIG Auth | Authentication, authorization, ServiceAccounts, Pod Security |
| SIG Scheduling | kube-scheduler |
| SIG Autoscaling | HPA, VPA, Cluster Autoscaler, Karpenter |
| SIG Instrumentation | Metrics, logs and events of Kubernetes components, metrics-server |
| SIG Release | The release process and release team |
| SIG Docs | kubernetes.io documentation |
| SIG Contributor Experience | Contributor processes, tooling and community health |
- The contributor ladder goes from member to reviewer to approver to subproject owner.
OWNERSfiles in each directory list who can review (/lgtm) and approve (/approve) changes there.
KEPs and the release cycle
- A Kubernetes Enhancement Proposal (KEP) is the design document for any user-visible change. It lives in the
kubernetes/enhancementsrepository, is owned by a sponsoring SIG, and records motivation, design, test plan, graduation criteria and a production readiness review. - Features move alpha, beta, stable, usually across several releases, behind feature gates. Alpha is off by default. New beta APIs are also off by default; older beta features may be on.
- Kubernetes ships about three minor releases a year, each cycle roughly 15 weeks, run by a volunteer release team with a shadow program for newcomers.
- Key milestones in a cycle: Enhancements Freeze (KEPs that missed it wait for the next release), Code Freeze, then release candidates and the release.
- The project supports the three most recent minor releases with patches, about a year each (14 months including an upgrade window).
- The deprecation policy promises GA APIs aren't removed within a major version, and that deprecated beta APIs keep working for a minimum period (several releases) before removal.
Open standards that make Kubernetes pluggable
| Standard | Defines | Lets you swap |
|---|---|---|
| OCI (image, runtime, distribution specs) | Image format, how a container runs, how registries serve images | Build with one tool, run with another, store in any compliant registry |
| CRI (Container Runtime Interface) | gRPC API between the kubelet and a runtime | containerd, CRI-O |
| CNI (Container Network Interface) | How a runtime asks a plugin to wire up Pod networking | Cilium, Calico, Flannel |
| CSI (Container Storage Interface) | How orchestrators provision and attach storage | Any vendor's storage driver, outside the Kubernetes codebase |
| OpenTelemetry and OTLP | Telemetry APIs, semantic conventions and the wire protocol | Any observability backend |
| CloudEvents | Common envelope for event data | Event producers and consumers across platforms |
| SMI / Gateway API | Gateway API is the Kubernetes standard for traffic routing; SMI (Service Mesh Interface) is archived | Ingress controllers, gateways, meshes |
Exam signal
Open standards move vendor code out of tree. That's why storage drivers moved to CSI and runtimes connect through the CRI: Kubernetes releases no longer wait on vendor code, and vendors ship on their own schedule.
Taking part
- KubeCon + CloudNativeCon is the flagship CNCF conference, held in several regions each year. Kubernetes Community Days (KCDs) are local, community-organized events.
- Conversations happen in the Kubernetes and CNCF Slack workspaces, mailing lists and recorded public meetings.
- Mentorship runs through programmes such as LFX Mentorship and Google Summer of Code; the release team shadow programme is a common first step into Kubernetes.
- Every project follows the CNCF Code of Conduct.
Scenarios
User-visible changes need a KEP owned by a SIG (SIG Node or SIG Apps for Pod fields, with SIG Architecture reviewing the API). SIG Release runs the release process but doesn't approve features. The TOC and TAGs work at the CNCF level and don't approve individual Kubernetes features.
The TOC decides project maturity levels, often with a TAG's review as input. The Governing Board handles business matters. The Kubernetes Steering Committee governs only Kubernetes. TAGs advise but don't vote on levels.
A CSI driver runs outside the Kubernetes codebase, so the vendor ships it on its own schedule. CNI is for networking, CRI connects the kubelet to container runtimes, and the OCI runtime spec defines how a container is run, not how storage attaches.