# Ultimate Guide to contributing towards Kubernetes 2025
**OK!, So you are someone who wants to contribute to the Kubernetes but you don't have any clue where to Start.** The Kubernetes community is massive, and figuring out where to begin can feel a bit overwhelming.
But that’s exactly where this guide comes in. By the end, you’ll have a solid grasp of how the Kubernetes community works, where you can contribute, and how to take your first steps—minus the overwhelm.
**Let's Start from the Start**
## What is Kubenetes?
Kubernetes is an **open-source container orchestration** tool—but what does that really mean?
Being open-source means that Kubernetes is built and maintained by contributors from around the world. Some are paid to work on it, while many others volunteer their time.
The entire codebase is publicly available under an open-source license, which clearly defines how the software and its source code can be used, modified, and shared.
**Now, Let’s understands K8s with an Example**
Imagine a business that needs to run multiple applications—like a payroll system, logistics software, or a company website.

These applications require computing power, so the business has several servers to host them.

Now, instead of manually deciding which app should run on which server, the business can use Kubernetes.
**They simply say:**
“Hey Kubernetes! Here are my servers, and here’s the app we need to run.”
Kubernetes takes it from there. You can specify details like how the app should run, what resources it needs, and Kubernetes will ensure it runs efficiently on the right machine. But that’s not all—Kubernetes also helps manage the app while it’s running, making updates smoother, handling scaling automatically, and even recovering from failures.

This behind-the-scenes magic is what Kubernetes contributors work on every day—constantly improving and evolving the platform.
## Now Let's Meet Kubernetes Community
The Kubernetes community is a massive, collaborative group of people dedicated to building and maintaining the Kubernetes project.

To give you an idea of just how big this community is, here are some numbers from March 2024:
* 93,000+ contributors have helped shape Kubernetes.
* They’ve made over 4.4 million contributions to the project.
* And all these contributions are reviewed by just 7,500 people with reviewer privileges.

> We’ll dive deeper into what a “contribution” means and what a “reviewer” does later in this guide.
To put this growth into perspective, here’s a visualization from the 2023 Kubernetes Project Journey Report. It highlights how the Kubernetes community has expanded from zero to over 80,000 contributors in just its first 10 years—an incredible journey since Kubernetes launched in 2014!

Now that we’ve covered the stats, let’s explore the Kubernetes community itself!
## Kubernetes Community Structure
Let’s dive into how contributors build Kubernetes by understanding the community’s structure.
The Kubernetes Community Structure can be best understood with the help of the pyramid diagram shown here.

At the top, Kubernetes operates under the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/)—a non-profit organization with the mission to make cloud-native ubiquitous.
To achieve this, the CNCF supports a variety of open-source projects that help companies run applications in the cloud.
Beyond technical support, the CNCF provides:
* Legal assistance
* Codes of conduct
* Help with branding, logos, and copyrights
* Governance and operational guidance
At the heart of Kubernetes is a well-structured and collaborative community. The pyramid below the CNCF represents how Kubernetes governance is organized.
## Steering Committee
At the top of the community structure, interfacing directly with the CNCF and overseeing high-level decisions, is the Steering Committee.

* This committee consists of seven elected members, chosen by Kubernetes Org Members.
* Their role is to govern the overall project, preside over policy discussions, and ensure the community operates smoothly.
* We’ll go into more detail about what Org Membership means later.
While the Steering Committee oversees governance and high-level decision-making, the actual development and maintenance of Kubernetes happen at a more granular level.
To efficiently manage such a large project, the work is distributed across Special Interest Groups (SIGs) and Working Groups (WGs). These groups ensure that contributors can focus on specific areas while collaborating to drive the project forward.

Let’s take a closer look at how SIGs and WGs function within the Kubernetes ecosystem.
## Special Interest Groups (SIGs)
Kubernetes is a massive project, and different aspects require specialized expertise. To efficiently manage this complexity, contributors organize themselves into Special Interest Groups (SIGs).
A SIG is responsible for a particular domain within Kubernetes. For example:
* [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) focuses on how Kubernetes nodes (where workloads run) function.
* [SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) is responsible for writing and maintaining documentation.
These groups break down the work of building and maintaining Kubernetes into manageable, specialized areas.
## Working Groups (WGs)
Some topics are too broad to fit neatly into one SIG and instead require collaboration across multiple SIGs. That’s where Working Groups (WGs) come in.
* A Working Group is formed when a specific challenge requires focused effort across SIGs.
* Unlike SIGs, WGs are temporary—they exist only until the issue is addressed.
* WGs do not own any code or features long-term. Their work is either:
* Absorbed into one or more SIGs
* Or, in rare cases, evolves into a new SIG.
This structure ensures that Kubernetes remains flexible and adaptable, allowing contributors to focus on important cross-cutting issues without overloading any single SIG.
## Subprojects within SIGs

Even within a single SIG, the scope of work can be massive, with hundreds of contributors involved. To handle this, SIGs further break down their work into subprojects.
* A subproject is a smaller, well-defined unit of work within a SIG i.e, Subprojects focus on specific features, components, or initiatives within a SIG, allowing contributors to work in more specialized and manageable teams.
* Each subproject has its own maintainers and contributors, ensuring focused development.
Currently, the Kubernetes community has 24 Special Interest Groups, 7 Working Groups, and 3 committees.

## Scopes
We can further group SIGs and Working Groups based on their scope to better understand how they contribute to the Kubernetes project.

---
* Some groups operate at the **Project level**, meaning their work affects and supports the entire Kubernetes project. They collaborate with all other groups, and their contributions serve as the foundation on which the rest of the project is built. All other groups depend on them.
---
* **Horizontal groups** have a broad yet deep technical focus. They own core functionality from a project architecture perspective and ensure that fundamental features and systems remain stable and scalable. Their work directly depends on the Project-level groups.
---
* **Vertical groups** focus on specific technical areas that rely on the work of both Horizontal and Project groups. These groups refine and extend core Kubernetes functionality to address specialized use cases while maintaining compatibility with the broader architecture.
---
Here is a diagram of all the currently active SIGs and Working Groups in the Kubernetes project.

To highlight a few:
* **SIG Release** and **SIG Docs** operate at the Project level, meaning their work supports the entire Kubernetes ecosystem. You might already be familiar with their contributions.
---
* **SIG API Machinery** and **SIG Auth** fall under Horizontal groups—even if you weren’t aware of them, you’ve likely interacted with their work in Kubernetes.
---
* Vertical groups include familiar areas such as **Autoscaling**, **Scheduling**, **Networking**, and **Node**, which focus on specific technical domains built on top of Horizontal and Project-level efforts.
## Why Do You Want To Contribute ?
Now that you’ve learned the basics of how the Kubernetes community is structured, let’s start exploring where you fit into all this. But first, let’s take a moment to consider why you might want to contribute.
There are many reasons people choose to contribute to the Kubernetes community. For some, their job requires it, meaning they are paid to contribute as part of their role. Others work with the community on a purely volunteer basis, contributing in their free time. Many fall somewhere in between—where their work involves Kubernetes contributions, but they also go beyond their job to engage more deeply with the community.
So why do so many people contribute without getting paid?
* Some want to develop career-specific skills that strengthen their resume.
* Others see it as an opportunity to network and build connections with industry professionals.
* Many are fascinated by Kubernetes technology and want to dive deeper to help build and improve it.
* And some simply enjoy being part of a collaborative community, working together toward shared goals.

Whatever your reason, take a moment to `Think Carefully About Why YOU Want To Contribute.` The more engaged you become, the more valuable your contributions will be—especially if you can clearly communicate your interests. If others in the community know who you are, what you want, and what skills you bring, they’ll be able to connect you with relevant work, opportunities, and people that align with your goals.
Now, let’s move forward and explore how you can start contributing!
## What Does It Mean To Be A “Contributor” ?
Regardless of why you’re interested in contributing, you might be wondering—**What does it actually mean to be a “Contributor”?**
To answer that, let’s first explore what qualifies as a “contribution.”
The truth is, **ANY work you do to support the Kubernetes project is a valued contribution to the community.** That may sound broad, but it’s important to recognize that contributions go far beyond writing code or making pull requests on GitHub. There’s a lot of behind-the-scenes work that keeps the project running smoothly.

That said, examples can be helpful. Here are a few—some you might expect, and others that may surprise you:
* Did you introduce yourself in the `#kubernetes-new-contributors` channel on Kubernetes Slack? That’s a contribution!
* Have you commented on an issue or shared your thoughts on a proposal for a new feature? That’s a contribution!
* Even just reading this guide and learning about the community counts as a contribution!
So go ahead—give yourself credit for contributing today!
---
As a community, we make a conscious effort to recognize and appreciate contributions in all their forms.
But if contributions can be so varied and non-traditional, then what does it truly mean to be a “contributor”?
Let’s dive into that next
## The Contributor Ladder
There are multiple levels of being a Kubernetes contributor. You may recall our earlier discussion about contributors and reviewers—this section provides a more detailed breakdown of these roles.

### Getting Started: Non-Member Contributors
At the entry level, anyone can be a contributor! If you’ve done any of the things mentioned earlier—whether it’s introducing yourself in the community, engaging in discussions, or contributing in small ways—you’re already a contributor.
At this stage, you’re likely a “non-member contributor,” meaning you contribute occasionally but in a more ad-hoc or informal way. Your contributions might be small, scattered, or one-off, and you may not yet be deeply engaged with any specific SIG or subproject.
### Becoming a Kubernetes Org Member
If you want to engage more deeply with the community, you may want to become a [Kubernetes Org Member](https://github.com/kubernetes/community/blob/master/community-membership.md).
An Org Member is an official member of the Kubernetes GitHub organization. This role grants you additional privileges, such as interacting with contributor tools like the PROW bot, which helps manage GitHub issues and pull requests using commands in comments.
Being an Org Member signals that you are an active, consistent contributor who is developing expertise in a specific area of the project. You’re likely involved with one or more SIGs or subprojects and contributing in a structured, measurable way.
To become an Org Member, you need existing contributors to vouch for your work and sponsor your request. This usually happens once you’ve built a solid track record in the community and the contributors you work with regularly recognize and trust your contributions.
## Climbing the Ladder: Increasing Levels of Trust and Responsibility
Once you’ve been actively contributing for a while, you may be ready to take on greater responsibilities within the project.
### Reviewer
After gaining experience in a specific area, you may be trusted to help review contributions from others. Reviewers provide feedback, ensure quality, and help maintain consistency in their area of expertise.
Reviewers are able to review code/documentation for quality and correctness on some part of a subproject. They are knowledgeable about both the codebase and software engineering principles.
Reviewer status is scoped to a part of the codebase/ SIG
### Approver
As you build even more trust and expertise, you may reach the level of an Approver. Approvers have the authority to approve contributions for acceptance, meaning they can give the final go-ahead for merging changes into Kubernetes repositories.
### Subproject Owner
With significant expertise in a particular area, you might take on additional responsibilities, such as triaging issues, mentoring new contributors, and leading discussions about features and fixes. At this stage, you become a Subproject Owner, serving as a subject matter expert for a specific repository or directory.
### Subproject Lead
As a Subproject Lead, you oversee an entire subproject across all relevant repositories. You set priorities, approve proposals, and take on leadership responsibilities to ensure the success of the subproject.
### SIG Chair / Tech Lead
Leading a subproject is a significant role within a SIG (Special Interest Group). If you continue developing expertise and leadership skills, you may become a SIG Chair or Tech Lead. At this level, you:
• Set priorities and manage the SIG and its subprojects.
• Collaborate with other SIGs to ensure alignment across the broader Kubernetes ecosystem.
• Interface with the Steering Committee, influencing project-wide decisions.
### What About the Steering Committee?
If you recall the Kubernetes community structure, you might wonder whether the Steering Committee is the next step. However, unlike other roles on this ladder, the Steering Committee is an elected position.
Technically, you can run for Steering Committee at any point after becoming an Org Member. However, your chances of being elected improve as more contributors recognize your work and leadership within the community.
---
The Kubernetes Contributor Ladder reflects a progression of trust, expertise, and responsibility. Not everyone will move up the ladder, and that’s okay! Some contributors prefer to stay at the Org Member or Reviewer level, while others take on leadership roles in SIGs, subprojects, or even the Steering Committee.
No matter where you see yourself on this journey, every contribution matters, and there’s always room to grow!
---
Now you know the basics of how the community is structured and how you might fit into it. As we’ve established, you might already be a non-member contributor. But if you want to do more to contribute, let’s explore where you can start.
---
## How To Start Contributing
The fastest way to learn and start contributing effectively is to find a SIG that aligns with your interests and begin engaging with it. However, this doesn’t necessarily mean diving straight into coding or picking up an issue right away.
Getting involved often starts with attending SIG meetings, reviewing meeting notes, reading through existing issues, and understanding ongoing discussions. This helps you get a feel for how the group operates, what challenges they’re working on, and where you can best contribute.

Now Let's Learn How To Learn About SIGs
## SIG REPO Workthrough
Now that you know how SIGs function, let’s explore how you can learn more about them and find a group that aligns with your interests!
#### Where to Start?
A great starting point is the kubernetes/community repository on GitHub.
Within this repository, you’ll find folders dedicated to each Special Interest Group (SIG) and Working Group (WG). These folders contain essential details about the group’s focus, leadership, communication channels, and ongoing work.


### Understanding a SIG’s Focus
When you open a SIG’s folder, you’ll find a README file. This file typically contains:
* A brief summary of the SIG’s focus area.
* A link to the SIG’s charter, which provides a more detailed explanation of their responsibilities and goals.
Reading the charter and summary will help you get a high-level understanding of what the SIG does and whether it aligns with your interests.

### Attending SIG Meetings
Further down in the README, you’ll find information about the SIG’s meeting schedule. Attending these meetings is one of the best ways to learn about:
* Who is in the group
* What they are currently working on
* How they collaborate and make decisions
Meetings are also a great opportunity to introduce yourself and start building relationships with contributors. Over time, the group will get to know you, which can be helpful when you start contributing.

### Understanding SIG Leadership
Each SIG has designated leadership, typically consisting of:
* Chairs – Handle project management, coordination, and community engagement for the SIG.
* Technical Leads – Focus on architectural leadership, managing repositories, and making technical decisions.
These leadership roles help ensure smooth operation of the SIG, but their specific responsibilities can vary between groups.

### Where to Find SIG Communication Channels
Each SIG has multiple ways to communicate:
* Slack Channels – Most discussions happen asynchronously in dedicated SIG channels on Kubernetes Slack. You can join by visiting slack.k8s.io.
* Mailing Lists – Each SIG has a mailing list where important announcements and discussions take place. SIG meeting invites are also sent through this list.

### Finding SIG-Related Issues and PRs
The README file will also contain links to:
* Issues & Pull Requests (PRs) relevant to the SIG, helping you identify ongoing work.
* GitHub Teams associated with the SIG, which define contributor roles and responsibilities within the group.
By exploring these resources, you can gradually familiarize yourself with a SIG, understand its work, and find meaningful ways to contribute!
### K8s Community Calender
Exploring each SIG’s folder provides detailed information about that specific group, but what if you want to see all SIG meetings in one place?
The Kubernetes community maintains a contributor website at k8s.dev, which includes a dedicated page listing all public community meetings.
To access this, visit k8s.dev/calendar. Here, you’ll find a comprehensive list of all Kubernetes community meetings. Clicking on any meeting will open a new window, allowing you to add it to your personal calendar.
This is a great way to explore different groups, track their discussions, and find meetings that fit your schedule!

Now that you understand the community structure, where you fit in, and how to start learning more, you might be wondering—how can you find actively open work to contribute to?
To help with this, we reach out to SIG leads each month, asking them to share any current opportunities for prospective contributors. This ensures you have access to up-to-date work items that SIGs are actively looking for help with, making it easier to get involved and make meaningful contributions.
## Current Work Oppurtunities
### Evergreen Opportunities: Always-Available Ways to Contribute
In this section, you can see Evergreen Opportunities—these are ongoing or regularly available ways to contribute to Kubernetes. If you’re looking for ways to get involved, these roles are always open or recur on a predictable schedule.
#### Most SIGs
##### Meeting Note-Taking
* Always available
* Applies to most SIGs that hold meetings
* No prior experience required
* Check the meeting invite or attend a SIG meeting to get details
#### SIG Docs
* SIG Docs contributions are always welcome
##### PR Reviews – Anyone can review pull requests
* Join the PR Wrangler shadow program
##### New Contributor Meet & Greet
* Held on the first Tuesday of the month at 10:30 UTC
* More info: k/community/sig-docs
#### SIG ContribEx
##### SIG Spotlight Blog
* Always open for contributions
* Part of the Comms subproject
* No experience required
* More details: SIG Spotlight Blog Process
##### Kubernetes Contributor Summit Staff
* Occurs twice per year
* Part of the Events subproject
* Org Membership Required
* More details: Events Team
These evergreen opportunities are a great way to get started in the community, meet contributors, and build up your experience in a low-barrier, high-impact way.
---
However, not all contributions follow this recurring pattern. Many tasks in Kubernetes are one-time efforts, such as fixing issues or implementing new features. These tasks can vary in complexity and often require specific technical skills. While it might be tempting to pick up a task to learn a new skill, it’s important to carefully assess whether it’s the right fit. Let’s explore why.
---
Many of these tasks require specific skills to complete. You might come across an open request that aligns with a skill you want to develop and think, “This could be a great way to learn!”—but be cautious before jumping in.
If a task were simple for someone already active in the SIG, it likely wouldn’t still be open. Often, tasks with specific skill requirements remain open because:
* No one in the SIG currently has that expertise, meaning they may not be able to provide guidance.
* The people who do have the expertise are too busy, making it difficult for them to assist newcomers while also managing their workload.
That said, if you’re coming into the Kubernetes community with existing skills—such as proficiency in certain programming languages, Linux networking, or expertise in a specific cloud provider—these one-off tasks can be excellent opportunities to contribute in a meaningful way while leveraging your strengths!
Now that you understand the difference between evergreen opportunities and one-time tasks, let’s look at some current work opportunities where you can contribute based on your skills and interests.
### Current Call For Help
The following tasks require specific technical skills. If you’re familiar with the tools or technologies listed, consider reaching out in the relevant SIG’s Slack channel to get involved!
#### SIG Testing
##### Help with Prow
* Skills: Familiarity with Prow
##### Conformance Testing (Hydrophone)
* Provide feedback and support the adoption of new conformance testing tools for end users
#### SIG Docs
##### Blog Reviews
* Help review proposed blog PRs
* Skills: Familiarity with the style guide, content guide, submitting a blog page, and reviewing PRs
##### Localization
* Skills: Fluency in English and at least one other language
#### SIG ContribEx
##### Website Maintenance
* Help maintain k8s.dev
* Skills: Knowledge of Hugo Docsy
##### Mentoring Program Management
* Help set up, support, and execute the Kubernetes mentoring program
* Help track various mentoring programs, such as LFX, Google Summer of Code, etc.
* Skills: Organization, planning, and communication
#### Elektro
* Kubernetes’ homegrown election management software
* Skills: Python, Flask
#### SIG Arch
* General Call for Help
* Great way to learn a broad area of Kubernetes
* Skills: Willingness to dive in, learn, and engage over time
* How to Start: Join the SIG Slack channel and ask!
#### SIG Network
##### Gateway API
* Implementing Ingress Nginx Gateway API from scratch
* General call for help
* API Reviewers
* Skills: Deep familiarity with SIG Network and API processes
#### SIG Release
* Release Automation Assistance
* Skills: Coding/scripting, willingness to develop expertise in the release process
#### SIG Security
* Help address and understand CVEs (Common Vulnerabilities and Exposures)
* Skills: Knowledge of CVE tracking and security concepts
---
## Common Contribution Pitfalls
### The “Good First Issue” Trap
A common pitfall for new contributors is falling into the “Good First Issue” Trap—a scenario that often unfolds like this:
You’re excited to contribute to Kubernetes, so you find an issue labeled “Good First Issue” on GitHub. You think, “Great! I’ll claim this issue, write some code, and make my first contribution!”
But let’s take a step back. Once you pick up that Good First Issue, how are you going to see it through to completion?
#### Why “Good First Issues” Can Be Challenging
New contributors often underestimate the steps required to get a pull request merged:
* **Understanding Kubernetes workflows** – Have you used Prow bot to manage issues and PRs?
* **Navigating the review process** – Your PR will be assigned Reviewers, Approvers, and Owners, but they’re often busy with many other tasks.
* **Iterating on feedback** – You may need multiple revisions before your code is accepted.
If you’re unfamiliar with GitHub reviews, collaboration tools, and Kubernetes processes, it can be easy to get stuck. Many “Good First Issues” picked up by new contributors never get completed.
This creates stale PRs and issues, leading to additional work for maintainers who must triage abandoned contributions.
#### How to Avoid Getting Stuck
Instead of blindly picking up a “Good First Issue”, join a SIG and stick with it!
* Build relationships with SIG members, so you can ask for help when needed.
* Attend meetings to understand ongoing work and contributor expectations.
* Work towards a goal with a team, rather than attempting to solve a problem in isolation.
By integrating into a SIG’s workflow, you’ll not only contribute but also ensure your work gets merged and makes an impact!
### Embracing the Entropy & Finding Your Place in the Community
This was a lot of information—and this is just the beginner's Guide!
When you join your first SIG meeting, expect to feel overwhelmed. Many SIG meetings are designed for existing contributors actively working on in-progress tasks. But that shouldn’t discourage you from joining as a new contributor!
You’ll learn much faster by observing how discussions happen and how decisions are made. However, it’s completely normal to feel lost or left out in the beginning. Don’t be afraid to ask questions—whether by speaking up, using the meeting chat, or following up later in the SIG or subproject’s Slack channel.
### Navigating a Large & Diverse Community
The Kubernetes community is big, diverse, and full of opportunities. Diversity exists not just in people, but in skills, technologies, and contribution areas. It may take time to find the SIG or subproject that clicks with you.
* You might find certain SIGs or subprojects that align with the skills you want to develop or the connections you want to build.
* Many contributors explore multiple areas before settling into one.
* Some choose to go deep in a single area, while others enjoy working across different groups.
There’s no single right path—every contributor’s journey is unique. Keep exploring until you find where you can make the biggest impact.
No matter where you choose to contribute, we need your help, and we’re excited to have you here!
---
We covered a lot today. Getting started in the Kubernetes Community means learning a lot of basic tools, processes, structures, and more! Check out these links and refer to them often as you grow.
---
## Resources
* Join the Kubernetes Developer Google Group (k-dev): https://groups.google.com/a/kubernetes.io/g/dev
* Check out kubernetes/community for an overview of our community.
* Follow the New Contributor Guide (k8s.dev/guide) to get familiar with various contributor tools and processes.
* The First Contribution Guide(k8s.dev/guide/first-contribution/) will walk you through the process for your first Pull Request (PR)
* Check out the Resources List at https://bit.ly/kubernetes-resources
* Come join us in the Kubernetes slack: https://www.slack.k8s.io
* Join the #kubernetes-new-contributors channel
* Join the channels of 1 or more SIGs you’re interested in
It’s not always too easy to get started and its understandably frustrating, but if you can stick around, it’s vastly worth it. We would love to help you stick around, so please join us!
We look forward to working with you, learning from you, and welcoming you as future maintainers!