How to contribute to Kubernetes if you have a full-time job

A graduate degree could springboard you into an open source job

Image by:

Opensource.com

I started contributing to Kubernetes (K8s) in October 2018, when I was working on the Product Security Incident Response Team at IBM. I was drawn to distributed systems, but I couldn't work with them in my day job, so my mentor, Lin Sun, suggested I contribute to open source distributed systems in my spare time. I became interested in K8s and have never looked back!

I've worked mainly in the Kubernetes special interest groups (SIGs) sig-testing, sig-storage, and sig-release. My most notable code contribution was implementing the plugin manager under the lead of Saad Ali. The plugin manager is a controller that manages plugin registration/unregistration. This gives Kubelet plugin registration retry and exponential backoff logic in cases where registration of plugins (like CSI or device plugin) fails.

I became a member of K8s in January 2019 and joined the IBM Open Technology team as an open source contributor and developer advocate in July 2019, where I currently contribute to Knative, a Kubernetes-based platform for deploying and managing serverless workloads.

New Kubernetes contributors are more than welcome, so if you would like to follow my path and start contributing in your spare time, continue reading.

Skills you need to start contributing to Kubernetes

Any version control system (e.g. git, svn)

K8s' source code is hosted on GitHub, so it's important that you know how to work with Git or another version control system. To get started, familiarize yourself with these common commands.

Golang

I come from a C/C++ background and did not know any Golang before I started. If you are familiar with object-oriented programming, Golang should be fairly easy to pick up. I suggest learning Go while you're learning the K8s code base. My coworker Wei Huang introduced me to the Ultimate Go Programming video series, which helped me immensely.

Other requirements

Before your commits can be merged into the K8s code base, you must sign the Contributor License Agreement (CLA). Also, be aware of the community guidelines, code of conduct, how to set up your dev environment, and other things described in "before you get started" in Kubernetes' GitHub repo.

How to pick your first Kubernetes issue

The first way to find things to work on in Kubernetes is to look at the list of open issues. You can filter the list of issues by tag, such as "good first issue" and "help wanted," which indicate the issue is newcomer-friendly. Occasionally, an issue can be mislabeled; maybe the issue's technical complexity is underestimated, and it's mislabeled as "good first issue." So, don't be surprised if a "good first issue" seems more complicated than you expect.

The second way to find things to work on is to search for "TODO"s in the codebase. There are hundreds of TODOs for lower priority improvements. It's a great way to learn the codebase and cross an item off of someone's TODO list—a win-win!

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.

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.

Other ways to contribute

There are many other ways to contribute besides writing code. Reviewing code is important, as it helps existing reviewers and maintainers with their review workload and provides a diversity of opinions. It's also one of the best ways to learn the K8s codebase!

You can also contribute to the Kubernetes release process by joining the release team as a shadow for a role. Access the role handbooks to learn more about the different roles on the release team. I shadowed the Test Infra lead for two releases until we automated the process and eliminated the role.

Being a shadow has taught me a lot, including about the CI/CD automation and project management behind a highly visible product that impacts companies all around the world. I was especially impressed by the continuing effort of the release team to automate tasks and eliminate manual tasks for all roles to achieve better CI/CD.

If you're interested in being a shadow, check out the formal process for applying.

One note if you're working on Kubernetes in your spare time: There are weekly release team meetings, but shadows are not required to attend all of them. The meetings usually happen during work hours in the US Pacific time zone and last a half hour. Fortunately, my job was flexible enough for me to book a conference room two or three times a week to attend meetings with the release team.

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.

Summary

Contributing to K8s is one of the most rewarding experiences I've ever had. Programming used to be just a job, but now it's also a hobby. If you have a day job that isn't too demanding, I highly recommend trying it out.