As Kubernetes contributors, we often get asked whether you need to be a member of a Big Tech organization to contribute to the project. The resounding answer to this is no, you don’t, and G-Research is a brilliant example of that in action.
Our team is relatively small when compared to the seemingly-infinite resources of other organizations in the ecosystem, but we’re ranked #17 in the list of companies that have contributed to Kubernetes in the last year.
This shows that open source is a great equalizer. Any company or team can contribute to Kubernetes; it is open to developers from disparate backgrounds and gives them the opportunity to make meaningful contributions quickly, in a way that few other projects can.
Part of our role within the G-Research Open Source team is to increase awareness of how developers can start their own open source journey. This isn’t just because more contributors equals good news for us (it does; it makes our code more stable and interoperable), it’s because of the opportunities it can afford developers too.
In our experience, once a developer clears the initial hurdle of starting out, it opens the door to a lifetime of opportunities. Someone with open source experience is more likely to:
- Contribute to future projects
- Write their software with collaboration in mind
- Launch new open source projects later in their career
In this post I will walk you through my experience becoming a Kubernetes contributor, but to do that, it’s first important to understand how to approach Kubernetes development as well as Kubernetes architecture, and how contributors fit in.
Kubernetes architecture
Almost each and every component of Kubernetes has a specific team to manage its backlog and implement features. These designated teams are called Special Interest Groups (SIGs), and there are many of them, because Kubernetes is a massive project. As such, when looking to become a contributor, it’s worth focusing specifically on the areas that interest you.
G-Research provides a good example of this approach in action. We are interested in running batch workloads on Kubernetes, so we work across a number of SIGs related to that area:
- Sig-Scheduling focuses on the domain of assigning pods to nodes. This is the scheduler component in the architecture diagram
- Sig-Node is focused on how containers interact with the host and they own the code around Kubelet
- Sig-Apps focuses on higher level controllers to make Kubernetes easier, such as Deployments, StatefulSet, and Jobs
As you can see from the SIGs across which we work, running batch workloads requires coordination between three separate teams. And when this is the case, it can often lead to the creation of work groups.
These work groups combine the resources and power of multiple SIGs to work together on shared goals, with concrete goals set out in their charters.
These work groups by their nature are good indicators of what the community is focusing on in the short-term, so if you’re looking to become a contributor, they can be a great source of inspiration for where you can get involved, which is exactly how I started working on Kubernetes.
My Kubernetes journey
My involvement with Kubernetes kicked off by doing development as part of the batch working group.
This batch working group aims to make high-performance computing workloads easier to run on Kubernetes, which is an area I find personally fascinating; I started my career as a scientific computing engineer, primarily focused on utilizing high-performance computing to accelerate simulations.
The group has identified a series of pain points around queueing, API representation for batch workloads and performance of the job controller, and its main goal is to promote features/development around batch processing.
It was at HPC-Batch day at Kubecon where I heard about Kueue, a Kubernetes-native way of adding queueing functionality to Kubernetes clusters and a Sig-Scheduling sponsored project open for all contributors – and that’s where I first dipped my toe into Kubernetes.
How I got started with Kueue
Contributing to a Kubernetes sponsored project in the form of Kueue was a brilliant experience as the rate of development is much faster than core Kubernetes. You can get faster feedback cycles and you can learn a lot more about Kubernetes development.
I browsed the Kueue repo and started to work on some minor features. I was able to learn how to write code in that project and I had some familiarity with how its engineers interact.
Once I felt comfortable, I ended up working on a CI/CD task involving adding end-to-end tests. This actually helped me learn way more about how Kubernetes development is structured, and I had to learn about the CI/CD process around Kubernetes too.
As an Armada maintainer, I also had some experience in what eats up a lot of time around code hygiene. A common problem is keeping dependencies up-to-date, so I helped add Dependabot integration to Kueue and a few other Kubernetes repositories.
After working on these items, I was invited to join the Kubernetes organization as a Kubernetes contributor. I am now leading the design on a Kubernetes Enhancement Proposal (KEP) and improving the Kubernetes Job API.
Some other projects I have worked on are increasing code coverage, removing deprecated code, adding Kubernetes official labels to distinguish between user labels and Kubernetes labels, and some documentation updates.
Batch working group and G-Research
Looking forward, our open source team continues to be actively engaged with the batch working group, as we are aligned on its goals. We want to make batch processing easier and better in the Kubernetes ecosystem, so we are contributing to those areas. And we are only starting our journey as core Kubernetes contributors.
It feels pretty good for our small team to be tackling this big project. I know it’s a critical component that will really improve the functionality for the entire community and it feels like we’re having a meaningful impact for the people and organizations that rely on Kubernetes. And we hope our example can encourage others to join and support the larger open source ecosystem.
