How to get started with K8s contributions

You're looking at the K8's repo (short for Kubernetes) and nothing makes sense to you. There are all these different folders and files. You visit the Issues page and see all the different labels and you have no idea what it all means.

Let me tell you that it's alright to feel overwhelmed because to understand all this, you need to take a step back and look at it in a step-by-step approach as that's how you're supposed to. K8s is a large project and to manage it there needs to be a proper structure.

The structure wouldn't make sense if you're looking at it as a whole and hence you'll have to understand it component-wise. This btw is a beginner's guide but be sure to stick around even if you're an expert. You might learn something new 😊.

Note: This blog is largely inspired by Nikhita Raghunath's video on K8's contributions

Community Groups

The entire K8s governance structure is divided into 4 parts:

1. SIGs: SIGs are tasked with advancing K8s wrt a specific topic such as CLI, Networking etc. The entire codebase is divided into these SIGs and each SIG has a governing body. Eg: kubectl falls under the sig cli. SIGs are further divided into more types:

• Vertical: Network, Storage, Node, Scheduling (Feature level concerns)

• Horizontal: Scalability, Architecture (Project level concerns)

• Project: Testing, Release, Docs, PM, Contributor Experience

So, if you're thinking of working on Kubernetes, you'll be looking to work under a SIG. Pick your poison.

1. Working Groups: A Working Group is set up to discuss certain topics that reference different SIGs

2. User Groups: Set up to discuss topics that might not have clear deliverables but have relevance to a large group of users. UGs can collaborate with SIGs to address usability issues or improve docs.

3. Committees: Set up around topics that require discretion. Compared to SIGs, these do not work in the open and are formed involving community members.

This here is the SIG diagram available on the kubernetes/community repository. You're highly advised to visit this repository to know a lot more about contributing to K8s and to browse through the available SIGs.

SIGs

Picking a SIG

So, you got to know about the different community groups and understood that you'll have to pick a SIG to get started. How do you do that? Here are a few tips:

• Choose a SIG that interests you. There are a lot of different SIGs under Kubernetes and you'll be sure to find one that you'd want to work upon. If you can't decide on a SIG, then try to find the SIG that the project you want to work on falls under. That'll be the SIG for you.

  If you're still confused, join #sig-contribex and mention your interests and what you'd like to work on. They're there to help contributors.

• Check out the documentation in the SIGs. Go through the docs available and see which SIG has docs that help you clearly understand what the SIG is all about. This involves well defined expectations and what work you'll be expected to perform at each stage. How the SIG specific code is structured internally. Proper definition for the different labels. Well defined meeting timelines. I could go on and on but you get the point.

When you do choose a SIG, get to know the SIG members. Introduce yourself on the slack channel, try to attend the meetings and when not possible, refer to the meeting notes, join the mailing lists and in general, try to have fun.

Sidenote: The amount of content available can be overwhelming. How do you help combat that feeling? Lurk around and take a look at the conversations going on. SIG members might be working on tasks. Try to offer your help over there. Say that you're a beginner and you're interested in the work going on and would like to work alongside them.

Join meetings and try to understand what's going on. Maybe even observe who's working on what. All of these can help you get an idea of the SIG in general.

Participating in a SIG

Check out the docs. I can't emphasize how important this is. Before contributing to any oss, read the docs. The docs help answer most of the questions that you might have and provide so much information that'll really help a beginner get up to speed with what's going on and how stuff is structured.

Before working on a feature, try to understand what it does. Visit the user friendly docs and try to learn how the feature works and how a certain user would interact with it. Maybe try it out locally by following a tutorial. This really helps you to be comfortable with the said feature.

Once you're done understanding a feature, try to read the contributor docs. The development README file has a lot of info that you'll need as a contributor. It has info regarding understanding the github workflow, setting up your development environment, managing tests, coding conventions etc. If you're a beginner then this can be a good place for you to start.

Introduce yourself and ask questions. Say that you'd want to work on an issue from a certain SIG and ask questions when you're stuck. If you're stuck on a particular issue then mention what you did to solve the problem and what you think can be a possible solution (you don't have to provide the exact solution, just mention something that you think may work). Also, take this as general advice towards asking good questions.

Sidenote: If you want to get going with a language of your choice then you could look towards contributing to the different kubernetes-client repositories. Eg: The python client. More info here: Client-libraries

Working on issues

You've found a bug while working. Try fixing it yourself. Try adding better comments to explain code blocks. This is more or less general advice. Some K8s specific advice:

Labels

Check for the labels on any issue. If the issue has a good first issue or help wanted label, which means it's for beginners. You can expect help and mentorship when working on that issue.

There are also SIG specific labels such as sig/cli, sig/testing etc showing that an issue belongs to a particular SIG. Also some kind specific labels like kind/bug, kind/feature to help you understand what you're looking at. Try to search for such labels when you're out issue hunting.

Take part in the roadmap planning

Each SIG has its roadmap to decide who will work on what feature for the current release cycle. The planning is done based on how many people are willing to work. One doesn't have to be an expert to get started. You just have to be committed to the work that you promise to put in.

Shadowing someone

The release team has well defined roles. Each role has a lead throughout the release cycle and the lead would mentor the shadows under them. There are well defined handbooks for you to understand your designated tasks. They're a great way to get into contributing to Kubernetes and you can also become a lead for the next release cycle. More info here

Non code contributions

You don't necessarily have to contribute to the code base. The docs can always be improved. If you think that some documentation is missing out on some key information or that documentation could be better worded, go forward and create issues and make the necessary changes.

You can also write blog posts for the K8s contributor site: kubernetes.dev. Moderation and event organizing is another place where you could help. Help spread awareness about kubernetes in your locality by taking charge of events or help out in moderation in the community. More info here

Technical details surrounding a pr

You'll be talking a lot with the k8s-ci-robot. It exists to perform checks. You'll need to sign the CLA when starting out. Then comes the review process. You'll need to have the /lgtm and /approve labels for your pr to get merged. Each pr would be solving an issue wrt a certain SIG and so you'd need to check the OWNERS file for the specific SIG.

In this file, you'll be able to find the owner aliases for your SIG which you can then locate in the OWNERS_ALIASES file to find who's associated with your SIG and then request them for a review. To request a review from person xyz, you'd type /cc @xyz in the pr. Try using the #pr-reviews slack channel in case your pr isn't getting much attention.

In case your pr isn't getting merged, you'll be able to scroll down your pr to find an ui that details tests that might be failing or labels that might be missing.

Finishing up the blog, I think that there's still a lot of info that I can write down and hence I'll keep updating the blog from time to time. Feel free to leave reviews in the comments too.

That being said, if you've managed to make it this far then thank you for persevering and reading through the blog. Hope my blog gave you some value. 🤗