Open source is changing the way we build software, and Kubernetes has helped to pioneer the use of open source in the world of containers. In this guide, you’ll learn about how open source shapes Kubernetes, and how you can take part in expanding its capabilities for yourself, your organization, and the community.
Do you have questions about contributing to Kubernetes? Do you want to learn how to become a Kubernetes maintainer? In this session, I will go over the process from start to finish on how one can contribute, from first developing a patch through opening a pull request and the subsequent process. We will also discuss my journey from contributor to maintainer with my experience maintaining modules such as batch/killgrpc.
How to join the Kubernetes community
For everyday communication, the Kubernetes Slack is great for direct messaging other contributors and asking questions. I suggest joining the SIG channels you are most interested in (such as sig-cli, sig-storage, sig-testing, etc.).
KubeCons are a great place to meet other contributors face-to-face. There’s one in North America in November 2019 and 2020, one in Europe in March/April, and one in Asia in July. I highly recommend the following two events for all aspiring, new, and seasoned contributors:
- Kubernetes Contributor Summit: This is a free, all-day event the day before KubeCon officially starts. There are workshops for both new and current contributors that are focused on learning and development.
- Networking + Mentoring Session: This is a place to meet with experienced open source veterans across many CNCF projects, including Kubernetes. You will be paired with two other people in a pod-like setting to explore technical issues and community questions, and you can even do pair-programming on a problem of your choice.
Once I decided what issue I was going to work on, I cloned the repo and started looking through the code. Kubernetes, for better or for worse, contains nearly 4,000,000 lines of code spread out across more than 13,000 files. Navigating a codebase this large can be daunting, to say the least, so diving in without a plan is definitely not advised.
One thing that can greatly narrow your search domain is identifying which packages or libraries you’ll need to dig into to accomplish your goals. My patch, for example, targets the apimachinery library. That cuts it down to around 60kloc across ~330 files. Now we’re getting somewhere!
Once you know where to look, a good understanding of how to search the source with tools like find and ack will be an invaluable asset, so it pays to brush up on their usage (the Linux man pages are a great place to start). You should ultimately be able to focus your attention on, at most, a handful of files.
How to work on an issue
Read any linked issues or pull requests (PRs) to help you understand an issue’s context and problem. If the issue description is not clear, make sure to reach out to the issue creator to get a clearer understanding before investing time in it. If it’s a bug, verify that you can reproduce the bug. Note that this can take a significant investment of time; I have spent a lot of time setting up my environment to try to reproduce bugs.
Once you have an idea for a solution, it is a good idea to reach out to the issue creator on Slack to verify your approach before making a PR. If you have not heard back from the creator within a week, go ahead a make a PR so the person can review it with a concrete solution.
At first, I was confused about was how quickly I should submit a PR after calling dibs on an issue. Since I had to work on K8s outside my fulltime job, I also wondered how this would affect my work-life balance. After looking through issues and other PRs, I discovered I needed to provide a PR or status update within at least two weeks. If you have an initial implementation that’s not tested yet, in my opinion, it’s still okay to make the initial PR so you can get feedback as soon as possible about whether you are on the right track.
While developing your solution, make sure to add unit tests or integration tests to verify the bug is fixed or that the feature works as intended. K8s uses a continuous integration/continuous development (CI/CD) system called Prow, which runs all unit and integration tests for a PR if it has the /ok-to-test label. The CI jobs will not run automatically if you’re not a member of the Kubernetes project. In that case, I suggest that you run the test locally first, then ask on the relevant SIG Slack channel for a member of the Kubernetes GitHub org to comment /ok-to-test on your PR.
Do Your Thing
The next step is to actually write your code. In my case, that meant adding a few tests to an existing file. If your patch is much larger in scope, then you should probably put it on hold, and find something smaller. It’s no fun to spend weeks writing something you’re proud of, only to have it rejected right off the bat.
I can’t provide much more guidance when it comes to writing your first patch, since every issue is unique. Hopefully, you didn’t bite off more than you could chew. Once you’re happy with your code and/or documentation, it’s time to submit your pull request. That can be a rather stressful experience for the uninitiated, and if you’re not used to very direct feedback, it can be hurt. Try not to take things too personally.
To minimise the pain, it’s a good idea to make sure your contribution is consistent with the existing codebase, and/or Documentation Style Guide. Also, make sure your git history is clean, by squashing and rebasing your working commits and checking the diffs against the latest master.
How to manage your time when you have a full-time job
It’s helpful to set a number of hours per week you want to dedicate to K8s contribution, as it is very easy to get sucked into development activities. It’s also important to take a break from contributing to K8s when your day job or life gets busy. There are downtimes in the K8s development community that usually coincide with the release code freeze period before a release cut. This would be a great time for you to take a break—because other contributors are less involved during this period, you are less likely to get a reply on your PRs or Slack messages.
It’s also good to let your team and manager at your job know about your new hobby since it can be beneficial to share your knowledge. If your team or company uses Kubernetes (or any container technologies), it will benefit from your knowing the internals of K8s. If not, it’s still great to share trends in the industry, software engineering design patterns, and architectural design decisions in Kubernetes with your development team. Consider hosting monthly talks on those topics or presenting what you learn at KubeCon and other conferences.
Read The Fine Print
Before your patch can be reviewed, you will have to sign the CNCF Contributor License Agreement, which grants the Cloud Native Computing Foundation additional rights and limitations not covered under the Apache-2.0 license that accompanies the project. While the CLA requirement definitely merits further discussion, this article is not the place to do it.
Once you’ve signed the CLA, make sure you read and follow the pull request template. In the same vein, you should pay special attention to the format and content of your commit message. Make sure that the message is clear and concise, and that it conveys the purpose of your changes/additions. If you’re not sure what format to use, I’m quite fond of:
`topic: subtopic: Concise description of your patch here`
For example, the commit message for my patch was:
`apimachinery: protobuf: Test protobuf compatibility`
Wait For It…
Now comes the hard part: waiting for review. Kubernetes is one of the most active projects on GitHub, and currently has over 1,000 open pull requests, so it shouldn’t come as a surprise that you might have to wait a while before you get any feedback.
First, someone from the Kubernetes organisation will triage your patch, and assign it to a suitable reviewer. If that person deems it safe, they will trigger the tests and review your code for style, correctness, and utility. You will probably need to make some changes, unless your patch is tiny and you’re a rock star. Finally, once they’re happy with your patch, they’ll flag it with a ‘/LGTM’ message, and it will be automatically merged into Kubernetes’ master branch.
Congratulations, you’re now part of the CNCF/Kubernetes developer community! That wasn’t so bad, was it? Feel free to share your thoughts in the comments below, and ping me here or on Twitter if you have any questions or comments.
You want to contribute to Kubernetes, but you do not know how? Tired of googling around and still stuck with this question: “How can I contribute to the open-source?” In this guide, we’ll briefly explain which project is maintained by Kubernetes Inc. and which project is kept by enthusiasts. We’ll then share guidelines that can help you effectively contribute to any project.