This is a summary of the Kubernetes project’s contributor community and activities. This report documents both quantitative measures of community health (project milestones and snapshot) as well as qualitative measures of the community as reported by community leaders and contributors to the project. Please see Appendices for full reports and program goals.
This report is a snapshot of the community as of December 2020.
Table of Contents
This report uses the following terminology:
- Special Interest Group (SIG): a body of contributors, responsible on an ongoing basis for an area of work in the Kubernetes project. They own code, docs, and/or policy.
- Working Group (WG): a body of contributors, responsible for an area of work in the project. Unlike SIGs, WGs dissolve once the scoped work is complete. Working groups are cross-functional efforts sponsored by a SIG.
- Chair and/or Tech Lead: a contributor who organizes and leads a community group.
- KEP: Kubernetes Enhancement Proposal
- OWNER/maintainer: a GitHub user who reviews, approves, and/or merges commits.
For more on SIG and WG governance, see:
For a list of all SIGs and WGs, their charters, meet times, ownership, and more, see:
The Kubernetes Steering Committee sent out a survey to all contributor group chairs and leads to collect data for this report.
For more, see:
As recorded in devstats and sigs.yaml changes, in 2020 the Kubernetes project had:
Special Interest Groups (SIGs)*
Working Groups (WGs)*
New Leaders (Chairs, Tech Leads, Organizers, and Committee Members)
Emeritus Members of various roles
* Welcome SIG Security and Working Groups: API Expression, Naming, and Reliability!
100,000Issues/pull requests in the
75%of API Endpoints included in Conformance
43Subproject additions or movements
35Stable graduations (KEPs that moved from beta to stable and were completed)
66KEPs reviewed by the new Production Readiness Review team
At the time of this survey, all WGs and SIGs have:
- Up to date READMEs available in the
- Up to date group charters
- Publicly listed meeting times and minutes
The Kubernetes project has achieved major goals and milestones every year. As we look back, the following accolades paint a picture of our journey in 2020:
Consistent Feature Graduation to Stable Status
Kubernetes had an issue with features remaining in beta for far longer than planned. During 2020, many SIGs started driving these long- standing beta features to completion, and collectively paying down some of their associated technical debt.
A few features of note that graduated to stable status or made significant progress include:
kubectlto a staging repo (SIG CLI)
- containerd and Cluster API support for Windows (SIG Windows)
- Ingress API (SIG Network)
SIG Architecture implemented a new policy, and this resulted in many SIGs pushing features to completion. As a result, the project now has less tech debt and is more stable for end consumers.
Issue Triage Improvements
The kubernetes/kubernetes repository has over 100,000 issues and pull requests at any time. To manage this, the community adopted new triage workflows. Several SIGs, such as SIG Node, SIG Network, and SIG API Machinery established their own triage processes and structure. This resulted in a noticeable reduction in Inactive Issues and Inactive Pull Requests open for 30 days or more.
As SIGs improve their processes with the new workflow, many are having dedicated triage meetings. Those who have started triage meetings noted they serve as an excellent engagement point for new contributors.
Testing, Continuous Integration, and Scalability
SIG Testing improved the project’s testing frameworks and infrastructure. Along with improvements to scalability tests and other test suites, the Kubernetes project has experienced significant improvements in CI Signal and general contributor experience. For example, the 5,000 node scalability test went from 14 hours to completion to less than 5 hours, roughly 3x faster. The new test suite and infrastructure is less burdensome on maintainers, ensuring ongoing project stability.
In addition to the speed improvements, this reduces the compute cost for testing Kubernetes patches and releases drastically. Thank you to Google Cloud for both funding and staffing such a critical piece of the project.
Localization and Globalization
The Kubernetes project community is distributed around the world, and there the end user community is the same. Over the past year, the number of international contributors has grown, as have initiatives to support localizations of the project.
SIG Docs hosts all localizations of the documentation, but each localization has its own group of maintainers and leads. To manage the growing number of localizations, SIG Docs started the Localization subproject. Aditionally, SIG UI added support for several new localizations of the Kubernetes dashboard.
The Kubernetes core values are critical to the success of project. In 2020 we reinforced our focus on inclusivity by requiring our community leaders to further their education on recognizing unconscious bias and working towards creating a more welcoming environment for every contributor. In addition to requiring our current leaders to take these steps, it is now a prerequisite for any future leads before they take a leadership position.
Our talented moderation teams continue to ensure that all our communication channels are safe and inclusive spaces for our contributor base.
During the Black Lives Matter protests in 2020, the project was introspective in how it’s values intersected with a global movement around equality. We decided to make a statement about the importance of inclusivity to where the Kubernetes project is today, and how racism doesn’t have a place in our project.
A meta accolade.
The #shoutouts channel on the Kubernetes slack and highlights on @k8scontributors in the last year has kept us going. Thank a member of the community here and read the past achievements of many.
Remembering Dan Kohn
In November of 2020, Dan Kohn, the former director of the CNCF sadly passed away from complications with Colon Cancer. Dan was instrumental in shaping both the Kubernetes project, the CNCF, and the Cloud Native community as a whole. He understood that a foundation built on a vibrant and diverse community was a requirement to be successful, and the project would not be what it is today without him.
The following themes emerged from multiple community groups reporting in with similar experiences – whether positive or challenging – and areas of research to explore more in the future.
Project Communication Strategy
During periods of significant contributor growth, community groups were reporting internally and externally regularly with the group’s members, the project at large, and at KubeCons. This made sense as the project scaled ten thousand casual and active contributors, but it’s resulted in duplicate meetings and too many update slides. The COVID-19 pandemic and an increase in contributors outside of the North America Pacific Timezone made regular meetings difficult. Chairs and other project leads asked for a more streamline and consistent reporting and feedback mechanism.
What We’ve Done
- Changed Community Meeting cadence from weekly to monthly, and changed meeting style from a “read out” of updates to more discussion oriented.
- Encouraged groups to use asychronous methods for delivering updates and gathering feedback. For example: Slack “standup” theads which feed into larger scale reporting to a group on a mailing list.
- Created an internal marketing group under SIG Contributor Experience to help facilitate community communication.
Areas of Research
- Review SIG charters to re-focus goals of each group at the current state of maturity
- Expand on async meeting adoption and establish best practices
- Improving subproject communication and connective glue back to the sponsoring SIG
- Clarify conditions for archiving or putting a subproject in maintenance mode
- Connecting with the end user community and understanding what they want to hear from upstream
Refining the Contributor Lifecycle
There are a number of ways to define membership to the Kubernetes project and its community groups. The project’s community groups must define their own membership terms and any other roles within their group.
- Kubernetes GitHub Organization membership
The project defines membership as contributors added to to one of the four GitHub organizations. Membership grants a contributor access to test their pull requests, among other benefits. Membership also defines a member’s role within the project based on their place on the Contributor Ladder. Membership does not grant voting rights for Steering Committee and governance matters; there is a separate set of criteria for elections.
These are guidelines for the project as a whole but do not translate to SIG or WG based membership, with each group defining membership in their own way. These methods vary widely and are often founded in the group’s specific workflows. However, there is a common pattern throughout all of them, and that is the two types of members that are considered early membership (onboarding) and sustainable membership (ongoing contributor activity).
Voting and Consensus with Members
Voting typically doesn’t happen in the project unless it’s for a Committee role. Technical and nontechnical decisions are driven mostly by consensus of the maintainers in OWNERs files in the code, doc, or policy area of maintenance. However, in some cases, particularly SIG leadership transitions, there have been cases were voting was elected but defining membership and reaching out to those members outside of GitHub is difficult.
What we’ve done
While onboarding new contributors is a critical part of a sustainable open source project, contributors shift focus, change jobs, or step away from the project for a variety of other reasons. In late 2019, Steering Committee updated the project’s guidelines to introduce an emeritus status. Emeritus community members have stepped away from the project, but are still recognized for their work. Giving people the ability to step away gracefully helps ensure an overall healthy and active community.
In 2020, 185 members stepped down or were removed for inactivity (18 months with 0 activity across any GitHub organization). The Kubernetes project has around 1300 active members at any given time.
Areas of Research
- Automation around suggesting when contributors may be ready to move to the next step in the lifecycle
- Ways to promote a sustainable flow through the various stages of the lifecycle
- Clarifying and/or simplifying definitions around the stages of the lifecycle
- Prompts to assist contributors in knowing what they need to do to ‘level up’ to the next stage in the lifecycle (e.g. prompts when you join a mailing list)
- Joining the project’s GitHub organizations is celebrated, but there are no regular means of celebration or recognition for those that join a SIG, community group, or achievement for climbing the ladder.
Growing a Diverse Group of OWNERs
Moving up the contributor ladder – from contributor, to reviewer, to approver – involves work on the part of the contributor. Building trust is a key part of our values and is a step in the “contributor journey”, called the Kubernetes contributor ladder.
The Kubernetes project needs more diverse, trusted people from all backgrounds to grow as contributors. Balancing being welcoming and identifying contributors to encourage to stick around at scale is difficult, especially with tens of thousands of casual contributors, and many cultures that come together. 30 new leaders have stepped up to Chair and other roles in 2020, but bandwidth for the reviewers and approvers in many subprojects remains a challenge as does the diversity of those contributing.
What We’ve Done
- Applied consistent labeling of issues with
help-wanted. This was reported as the most successful way of landing new contributors.
- Intentionally creating space at meetings for new contributors to get involved and/or a dedicated triage meeting that provide an overview of current priorities
- Continued programs such as:
- Meet Our Contributors, an Office hours like space where aspiring and experienced contributors can ask questions live
- Contributor Summits with new contibutor workshops, or Maintainer focused sessions at KubeCon.
- Facilitated One-on-One sessions for dedicated contributors that have demonstrated a vested interest in contributing and climbing the contributor ladder and sticking around.
- Created Group study groups for reviewers, approvers, and Chairs
Areas of Research
- Specific outreach to new contributors from backgrounds that are underrepresented in the community, such as BIPOC contributors
- GitHub automation that will suggest contributors to SIG leadership who are making steady contributions to the project that may not have visibility, direct access to OWNERs, or may feel ackward asking about maintainership
- Encouraging regular review of who is actively reviewing in subprojects
- Scaling the group contributor ladder program
Focus on Reliability
The community is excited to welcome the new lens on reliability through Production Readiness Reviews, KEPs, and the new Working Group for Reliability. This effort continues to increase confidence for end users use Kubernetes to manage production workloads by ensuring the core is stable and reliable.
This means the features are:
- Observable: you can tell that it is in use and working properly, and are able to define reasonable service level objectives for the feature.
- Supportable: the feature is well documented with a playbook covering failure modes, dependencies and what happens when those fail or degrade, and a troubleshooting guide.
- Scalable: the feature does not introduce scaling issues.
- Recoverable: the feature can be disabled or rolled back easily and without data loss
The Words We Use
The Naming Working Group was spun up to undergo research and create decision making frameworks around the terminology we use in the technical components and the documentation.
GitHub has also stepped up to help the open source community at large create a smooth path for
master->main branch renaming. We discovered some gaps in our tooling and automation around this as well, but now have a clear path. A number of repos have already started this migration, and we will continue to roll it out to the remainder of the org.
Not only is this a WG Naming initiative, but several parts of the project reported in ways they are examining the words we use. For example, SIG Contributor Experience’s slack-infra team implemented a new bot for inclusive language. SIG Testing has made a significant effort to eliminate
blacklist from the code base.
There is still plenty of work however in evaluating further language, implementing changes to code and documentation, as well as the testing and validation that related code changes don’t introduce unexpected regressions.
All eyes on SECURITY.md
This year brought the creation of SIG Security, in response to the greater community and industry focus on the security of critical pieces of software like Kubernetes. This new SIG grew out of the previous Security Audit Working Group, and is designed to be a clear home for security-focused discussions across the project.
This new group, partnering with the existing Product Security Committee, will focus on horizontal security initiatives for the Kubernetes project, including regular security audits, the vulnerability management process, cross-cutting security documentation, and security community management.
The Product Security Committee is also currently discussing a name change to “Security Response Committee” to better reflect the role they play in security response.
Improving Kubernetes Enhancements
Kubernetes Enhancement Proosals, the process by which the community proposes and approves new features, continues to evolve and mature. As we use and iterate on the process, we are consistently learning better ways to communicate, debate, and ultimately grow ideas within the project.
In 2020, KEPs around process and policies have become a focus, and an area of future growth for KEPs themselves. For example, a KEP changing the release cadence of the Kubernetes project garnered attention from the community.
The community groups report that they need to grow more contributors into maintainer-like roles of Reviewers, Approvers, and Subproject OWNERs.
Below is list of specific contribution needs, special projects, roles available, and more. Building trust is key and we need folks to stick around. There are other ways of contributing outside of commits and you’ll see those in the Other Types of Upstream Contributions section.
Check out the contributor guide for a comprehensive guide to getting started: https://k8s.dev/guide.
SIG API Machinery:
- Performing triage (go to a triage meeting and you’ll see it first hand)
- Contributors to the Client Libraries like client-go, python-client
- Site Reliability Engineers to review KEPs, Production Readiness Reviews, and API Reviewers
- Contributors to help curate a mentoring program for people to work across SIGs
- Audit logging and testing contributors
- KMS-Plugin contributors
- Creating and running of a triage program
- A Product/Feature Manager
SIG Cloud Provider:
- More contributors from every cloud to form teams for triage and support,
- Cloud Engineers at service providers to help run the cloud provider extraction working group: kubernetes/kubernetes “cluster” directory and resolving how we properly test kubernetes/kubernetes in the absence of a cloud provider
SIG Cluster Lifecycle: Code contributors to:
SIG Contributor Experience:
- Full-time (or part-time) community managers
- Automation Engineers: zoom to youtube automation, github automation, slack infrastructure, and more
- Program Manager types for recognition and contributor ladder mentoring programs
- Structured logging
- promq contributors
- Sustaining CI
- Scalability Test Frameworks and Scalability and Performance tests and validation with a deep understanding of Kubernetes
- Docs for scheduler internals, cluster-admin best practices; standardize triage process
- Future Tech Leads
- Issue triage (creating and running a program)
- Feature work for things that are co-owned by sig-node, sig-apps, and sig-scheduling (ContainerNotifier, Volume expansion for stateful set, and more)
- Many more companies to invest in this area heavily and bring steady contributors to grow the contributor ladder in areas that are crucial to the projects infrastructure
- Contributors who will stick around with AngularJS, golang, and knowledge of Kubernetes client-go package
- We are currently working on a jobs to be done study and an effort to define universal personas for the upstream project.
- Any one is welcome to join and participate in these efforts, especially any user researchers, designers, and new contributors
- e2e test coverage and API reviewers
WG K8s Infra
- Help with migrating resources from Google owned infrastructure to community owned
- At the time of this report, only 288 of the current 1780 prow jobs have been migrated
- We have three main projects: Hierarchical Namespace, Virtual Cluster Project, and Multi-tenancy Profiles (think conformancy but for secure multi-tenant clusters). Contributors and interested parties welcome!
Other Types of Upstream Contributions
The above list is good for contributors who have the time or support from their employer to submit patches and participate in other upstream activities. Below are areas of the project that need help but require less dedicated time.
- Comment on KEPs with your use case (this is helpful from end users too!)
sig/securityon issues and pull requests that you review and have security concerns
- SIG Multicluster needs use cases and validating our approaches for different environments and deployment models
- SIG Usability would like more participants for their Job Study and many other studies that are going on.
- SIG Contributor Experience would welcome part-time and full time contributor community managers; will mentor and grow dedicated contributors in a large environment
- SIG Architecture would like cluster operators to take a production readiness survey
This section summarizes current initiatives from each SIG and WG. Click on the group for reported projects completed in 2020 and granular information for each initiative with supporting links to KEPs and more.
- SIG API-Machinery
- Mitigating the impact of removing beta APIs in 1.22
- Server-side-apply to stable
- Server-side-apply client
- Optionally skip backend TLS verification
- Namespace labels
- CRD and admission webhook v1beta1 API removal: reminder on kubernetes-dev.
- Immutable fields API
- API unions
- Warnings to stable
- apiserver network proxy to beta
- Priority and fairness to stable
- SIG Apps
- Promoting CronJobs to GA
- Promoting PodDisruptionBudgets to GA
- SIG Architecture
- Increased coverage of stable endpoints by conformance tests
- Coordinating dependency updates across projects
- Production Readiness Review process was made mandatory in 1.21, improving scalability, supportability, monitoring, and correct feature enablement
- Set up cross-project policies to move features towards stable (conformance without beta, preventing “permabeta”)
- Enhancements subproject is working with sig-release to assist SIGs in taking greater ownership of their KEPs during the release cycle
- SIG Auth
- CSR v1
- Token Request / bound SA token admission
- client-go auth plugins
- external kubelet credential providers
- New features in Secrets Store CSI driver
- Pod Security Policy Replacement
- Several other KEPs going to General Availability on the report
- SIG Autoscaling
- Promoting HPA v2 to stable
- Promoting HPAScaleToZero to beta
- Vertical pod autoscaler adding support for customized recommenders
- Cluster autoscaler adding support for gRPC custom cloud providers
- SIG CLI
- Moving kubectl package code to staging
- Our multi-year effort to split out of the main kubernetes repository.
- kubectl debug (beta)
- Several smaller efforts to unify code across all the commands, and removing technical debt
- SIG Cloud Provider
- Feature: implement the BackendManager list
- Fix flag passing in CCM
- Extending Apiserver Network Proxy to handle traffic originated from Node network
- SIG Cluster Lifecycle
- Standard for communicating a local registry
- Several KEPs in a separate KEP process https://github.com/kubernetes-sigs/cluster-api/tree/master/docs/proposals
- SIG Contributor Experience
- Community Management
- Contributor Documentation
- Contributor Comms
- GitHub Management
- Slack Infra
- KEP for revamping the prow approval plugin
- Migrating the default branch on GitHub from master to main
- SIG Docs
- Coordination with WG naming for things like removing the word “slave” (and other problematic terms) from docs
- Publishing better information about releases
- Docsy theme work as well as the reference documentation generation
- Doc policies for third party content
- SIG Instrumentation
- Reducing metrics exposed by the kubelet
- Structured Logging
- and many other KEPs listed in the report
- SIG Multicluster
- Cluster ID for ClusterSet identification
- Multi Cluster Services API
- Kubefed – support for pull-based reconciliation
- Work API – road to alpha
- SIG Network
- No report
- SIG Node
- cgroups v2
- Topology manager/device alignment
- Many KEPs listed in their report
- SIG Release
- Release cadence
- North Star Vision Roadmap
- Enhancing tooling
- New Program Manager role
- SIG Scalability
- SIG Scheduling
- Continuing to refactor the core code around the scheduling framework
- Graduating the scheduler’s ComponentConfig to stable
- Scheduler into a pluggable framework outside of the main repo
- More alpha and beta features listed in the report
- SIG Security
- Kubernetes Hardening Guide
- Third Party Security Audit
- PodSecurityPolicy replacement: PodSecurity admission
- Support for Windows privileged containers
- Run control-plane as non-root in kubeadm
- Defend against logging secrets via static analysis
- More KEPs listed in their report
- SIG Service Catalog
- No report
- SIG Storage
- Container Object Storage Interface
- Generic Ephemeral Volumes
- CSI Support for Windows
- Volume Snapshots stable
- and other beta, alpha, road to alpha, and stable KEPs listed in the report
- SIG Testing
- No report
- SIG UI
- Ongoing maintenance
- Real time dashboard
- New language translations
- SIG Usability
- Jobs-to-be-done research proposal
- SIG Windows
- Privileged containers
- Network Policy Support
- WG API Expression
- Server Side Apply landing stable in 1.21; will complete the groups mission
- WG Component Standard
- WG Data Protection
- Volume Backups
- Backup Repositories
- Data Populator
- Quiesce and Unquiesce Hooks
- Volume Group and Group Snapshot
- Application Snapshots and Backups
- WG IoT/Edge
- WG K8s Infra
- Ensure SIG ownership of all infra and services
- Migrate .deb/.rpm package building/hosting to community
- stop using google-containers, k8s-prow, k8s-prow-build, k8s-gubernator, kubernetes-jenkins, GCP project
- Migrate images used by CI jobs and test-infra components
- WG Multitenancy
Appendix A: Program documentation
Appendix B: Survey questions
- How are you doing with operational tasks in SIG-governance.md?
- Is your README accurate? have a CONTRIBUTING.md file?
- All subprojects correctly mapped and listed in sigs.yaml?
- What’s your meeting culture? Large/small, active/quiet, learnings? Meeting notes up to date? Are you keeping recordings up to date/trends in community members watching recordings?
- How does the group get updates, reports, or feedback from subprojects? Are there any springing up or being retired? Are OWNERS.md files up to date in these areas?
- Same question as above but for working groups.
- When was your last public community-wide update? (provide link to deck and/or recording)
- Are all listed SIG leaders (chairs, tech leads, and subproject owners) active?
- How do you measure membership? By mailing list members, OWNERs, or something else?
- How does the group measure reviewer and approver bandwidth? Do you need help in any area now? What are you doing about it?
- Is there a healthy onboarding and growth path for contributors in your SIG? What are some activities that the group does to encourage this? What programs are you participating in to grow contributors throughout the contributor ladder?
- What programs do you participate in for new contributors?
- Does the group have contributors from multiple companies/affiliations? Can end users/companies contribute in some way that they currently are not?
Current initiatives and project health
- What are some initiatives that should be highlighted, lauded, shoutouts, that your group is proud of? Currently underway? What are some of the longer tail projects that your group is working on?
- Year to date KEP work: What’s now stable? Beta? Alpha? Road to alpha?
- What initiatives are you working on that aren’t being tracked in KEPs?
- What areas and/or subprojects does the group need the most help with?
- What metrics/community health stats does your group care about and/or measure? Examples?