Are you interested in getting involved with the Kubernetes community, but aren’t sure where to start? This blog post aims to help remove the ambiguity associated with contributing to an open source project as big as Kubernetes while providing some anecdotal experience to give you an idea of what contributing to an open source project such as Kubernetes can look like as a beginner.
By detailing my experience as a contributor, I hope to inspire you to take that first step to begin your path as an open source contributor. You can contribute to Kubernetes regardless of your background or years of experience. Everyone’s contributions are an important and valued part of the open source community. Below, I detail my experience as a contributor and outline key steps anyone can take to become involved.
Why I started contributing to Kubernetes
Contributing to an open source project such as Kubernetes takes many forms: submitting code PRs, updating documentation, triaging issues, reporting bugs, improving tests, reviewing code, reviewing Kubernetes Enhancement Proposals (KEPs), and participating in Kubernetes release management. Kubernetes exists and thrives thanks to the countless hours spent by current contributors and future contributors like you.
I was first introduced to Kubernetes when I was asked to write a trade study on solutions a company I worked for could use to containerize our services and manage them with a container orchestrator. With the knowledge of what Kubernetes could do, at my next job I was able to start actually using Kubernetes when I noticed inconsistencies in the way some apps were maintained and operated, and suggested containerization as a solution. This allowed me to explore the Kubernetes repository, and while doing so I came across an issue that seemed like a good first contribution.
I had always been interested in contributing to open source projects, and felt that if I started contributing to Kubernetes I’d get more knowledgeable about distributed systems. Nothing gets you more experience with something than writing the code for it, which is how I became involved in Kubernetes and why it’s so valuable for others to do the same.
How to contribute to Kubernetes as a beginner
Here are some of the first steps to take to start contributing to Kubernetes.
1. Look for relevant documentation available for contributors
Typically, when you are a new contributor to any open source project, you should look for any relevant documentation for contributors. Usually, this is in the form of a CONTRIBUTING.md file or something similar. The README at the root of a repo is also a good place to start. Any project looking to foster a community of contributors should have this information easily accessible to new contributors. Another thing to consider is the means of communication that the developers on that particular project or sub-project use. For example, Kubernetes relies heavily on Slack and mailing lists: subscribe to the slack channels and email lists that interest you most, especially for the areas of Kubernetes you plan on contributing to.
As a complete beginner to Kubernetes in general, as well as a person with no experience contributing to the Kubernetes codebase, I jumped right to the CONTRIBUTING.md file. It’s well documented and pointed me right to the necessary documentation to set up my environment to begin development.
2. Search and filter for issues that interest you
-
Finding issues to work on: Once you have your dev environment setup you’ll want to find something to work on. When I first started, after I got my environment set up, I proceeded to look at the issues in the Kubernetes repo. In GitHub, when you search for issues for a given project, there is a filtering label that can be applied to filter for “good first issue” which indicates the issue can be worked on by a beginner. For example, is:open is:issue label:"good first issue" in the GitHub issue search bar would provide you with a list of all open issues labeled as “good first issue”. To filter even further on for a specific Special Interest Group (SIG) such as sig/network, you’d search for :open is:issue label:“good first issue” label:sig/network. From here I was able to find my first issue.
-
Making fixes for the issues you find: After finding an issue, you should let the maintainers know your intentions of working on it. The first thing I did was ask on the GitHub issue if I could work on the issue I found, which was a PR to remove all redundant new lines being passed into Logf() functions. This involved going through code in both test/e2e and test/e2e_node, finding the newline redundancies in calls to Logf() and removing them. This task was a good exercise in learning how to make a contribution to the Kubernetes codebase as it involved me making the changes locally, making a PR up against the main branch, and addressing review feedback.
Throughout the process, it was important to ask for clarification on the feedback that I didn’t understand. For example, the phrase “find and fix offenders” was confusing because I didn’t know what an offender was. But once I asked, I got a simple answer telling me that it means to remove all trailing lines throughout the e2e code.
-
Communication is key: Communication throughout the contribution process is extremely important and is critical to open source development. If you are stuck on a PR, not sure how to address feedback, or don’t understand the logic, ask questions. It’s best to over-communicate when it comes to being a contributor, including communicating when you need to step back from the project. Taking breaks is expected and accounted for in open source development, and communication allows for transparency and faster iteration on the work being done. By communicating clearly, you ensure everyone working on a project around the world is informed, saving time and minimizing items that get lost in translation.
As a new contributor, I felt unsure and confused when working on my first task. I find that becoming comfortable with not knowing the solution immediately is valuable in addressing issues you’ve been assigned and driving the solution forward. This doesn’t mean sitting in a dark room and solving it yourself, it means asking for help when you need clarification of the problem, when you aren’t familiar with terminology as I pointed out in my example earlier, or even when you just want some eyes on your proposed solution. This attitude of relying on teamwork and collaboration when needed will help you go a long way in open source contribution and in tech in general. Keep in mind, as a driver of a solution you’re supposed to be a collection of all the debugging and information you’ve gained in attempting to solve the problem while collaborating with others. There is typically no real deadline (unless communicated otherwise) associated with these “good first issues”, so feel free to take as long as you need making sure to constantly communicate progress on the GitHub issue and keep people in the loop, pulling others in to help as needed. If you end up discovering you no longer have the bandwidth to work on it, communicate that on the related issue and someone else will pick it up.
3. Stuck finding issues? Try becoming a Kubernetes release shadow
Another way to contribute is through documentation updates, which is a common way for new contributors to get in an open source project other than contributing code changes. One interesting path that I’ve participated in recently is the Kubernetes release shadow program, a program in which those new to Kubernetes release management can take part in to work on one of many different sections of the release. I worked on the Kubernetes Enhancements for 1.20. The task I was given was to review and track all Kubernetes Enhancements Proposals (KEPs), with the help of a few other shadows and a lead. This gave me a lot of insight into the KEP process and allowed me to work with quite a few contributors in the process. I highly recommend this path to anyone looking to jumpstart their network and impact within the Kubernetes community.
The benefits of becoming a Kubernetes member
Becoming a Kubernetes member is a consequence of contributing frequently and working closely with at least 2 different existing members with reviewing capabilities for a particular project within the Kubernetes repo. In other words, contribute a lot to 2 different areas within the Kubernetes project, and find a person you can work with closely from each. Over time, as you gain experience and have some PRs under your belt, ask these people if they could sponsor you to become a member.
A major benefit of becoming a member is being able to assign yourself issues and have more influence over certain areas of the code you’re working on. Another tangible benefit of being a member is receiving Kubernetes Common Vulnerabilities and Exposures (CVEs) as soon as they are recognized by the community. This was valuable to the DigitalOcean Kubernetes team as we receive information on these security vulnerabilities before the general public, allowing us to thwart undesired attempts at compromising our platform and ensuring our customers stay protected while using DOKS and other Kubernetes based products on the DigitalOcean platform.
The membership I possess also presents many opportunities, like being able to co-maintain the kubernetes-sigs/cluster-api-provider-digitalocean project and being able to sponsor a coworker of mine for Kubernetes membership. The value of Kubernetes membership has not only benefited me, but also my team, DigitalOcean, and the DigitalOcean community at large.
Common obstacles on your path to becoming a Kubernetes contributor
There are many obstacles that can prevent progress in contributing to Kubernetes or slow you down. The main hurdle is getting your first code contribution in. Due to the tremendous number of contributions on a daily basis and the limited number of reviewers, some PRs can sit for months or longer. The way to deal with this is to make sure you are contributing code that is actually needed. You can ensure this by tying it to an existing issue or creating an issue to get consensus from the owners of the code you want to contribute to that it is an actual issue, and keeping the approvers/reviewers of that area of code involved in what you plan to contribute.
1. Contributing code without collaborating with the community
Remember, drive-by commits may not get reviewed as quickly as you expect. Maintainers of a project can only do so much and hold so much context. It’s your job as a contributor to make your PR as reviewable as possible. Provide well-written, thoughtful descriptions for your PRs. If it’s a huge change, make sure there’s agreement on the change and break it out into multiple PRs as needed. Respectfully ping the maintainers in the appropriate slack channel if time has lapsed since you’ve made the PR and respond to comments on your PR in a timely fashion.
2. Not being humble or respectful as a contributor
Another obstacle I see in new contributors is ego. A lot of the time, an issue that is new to you isn’t new to others, so it is important to hear them out and proceed in civil discourse. Don’t go into any situation thinking you have all of the necessary information to proceed with a PR, and listen to others’ input and take it into consideration when providing/updating your solution for whatever issue you’re working on. If people ask for updates and you don’t agree with them, ask for clarification on the suggestions until you both are satisfied with the outcome. The beauty of open source is the ability to collaborate with others and make iterations on a product to lead to a net positive for the project being worked on. Remember we’re all on the same team, and don’t take things personally!
Recap: How to become a Kubernetes open source contributor as a beginner
- Find an area of K8s that interests you and find a “good first issue” labeled issues to work on right away.
- Remember, over-communication is good.
- Follow through on the task in a positive way.
- Help others along the way, just like you would have wanted when starting out.
Key takeaways
After reading this blog post, you should walk away knowing how to start contributing to Kubernetes, how it benefits you and your career, how to become a Kubernetes member, and how to overcome obstacles you may encounter. In a world where cloud is increasingly popular, companies like DigitalOcean are always in need of people in tune with the cloud native community. Kubernetes is a very accessible way of getting to be a part of this amazing ecosystem built on love, respect, and collaboration with one another!
