Kubernetes Community Annual Report 2020

Published: December 1, 2020

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

Terminology

This report uses the following terminology:

For more on SIG and WG governance, see:

For a list of all SIGs and WGs, their charters, meet times, ownership, and more, see:

Data Collection

The Kubernetes Steering Committee sent out a survey to all contributor group chairs and leads to collect data for this report.

For more, see:

Contributor Snapshot

As recorded in devstats and sigs.yaml changes, in 2020 the Kubernetes project had:

52K

Contributors

24

Special Interest Groups (SIGs)*

9

Working Groups (WGs)*

30

New Leaders (Chairs, Tech Leads, Organizers, and Committee Members)

14

Emeritus Members of various roles

* Welcome SIG Security and Working Groups: API Expression, Naming, and Reliability!

Community Milestones

Governance

At the time of this survey, all WGs and SIGs have:

Accolades

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:

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.

Fostering Inclusivity

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.

#shoutouts

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.

Themes

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

Areas of Research

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.

Membership drives:

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

Sustainable Membership

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

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

Areas of Research

Growth Areas

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:

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.

/help-wanted

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:

SIG Architecture:

SIG Auth:

SIG Autoscaling:

SIG CLI:

SIG Cloud Provider:

SIG Cluster Lifecycle: Code contributors to:

SIG Contributor Experience:

SIG Instrumentation:

SIG Node:

SIG Scalability:

SIG Scheduling:

SIG Security:

SIG Storage:

SIG Testing:

SIG UI:

SIG Usability:

SIG Windows:

WG K8s Infra

WG Multitenancy

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.

Current Initiatives

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.

Appendices

Appendix A: Program documentation

Program Documentation

Appendix B: Survey questions

Operational

Membership

Current initiatives and project health