Contributing to CNCF: My Kubernetes Open Source Journey
How getting involved with CNCF and the Kubernetes community changed the way I think about infrastructure
Six months ago, I submitted my first pull request to a CNCF project. It was a documentation fix for Kubernetes: a correction to a kubectl example that had an incorrect flag. Three lines changed, a five-minute fix. But the process of finding the issue, forking the repo, understanding the contribution guidelines, getting the CLA signed, and navigating the review process took me an entire Saturday afternoon.
That small contribution opened a door I did not expect. Since then, I have contributed to several CNCF ecosystem projects, attended contributor meetings, and become embedded in a community that has fundamentally changed how I think about infrastructure engineering.
Why Open Source Contributions Matter
I want to be direct about something: contributing to open source is not charity work. It is one of the highest-leverage career investments an engineer can make.
When you contribute to a project like Kubernetes, you gain access to code written by engineers at Google, Red Hat, Microsoft, and dozens of other organizations. You see how they structure their code, how they handle error cases, how they design APIs. You participate in design discussions where the reasoning behind architectural decisions is debated openly. This is an education you cannot buy.
At a major entertainment company where I work, we run significant Kubernetes workloads. Understanding the internals of the system I operate in production gives me a diagnostic advantage that no amount of documentation reading can provide. When a pod gets stuck in a pending state, I do not just check the events; I understand the scheduler's decision tree because I have read the code.
The CNCF Landscape
The Cloud Native Computing Foundation has grown remarkably in the past two years. What started with Kubernetes as the anchor project now encompasses a sprawling ecosystem: Prometheus for monitoring, Envoy for service mesh, Fluentd for logging, containerd for container runtime, and dozens more at various stages of maturity.
The landscape can be overwhelming. When I first looked at the CNCF landscape diagram, it felt like staring at the periodic table. My approach was to start with the projects I used in production and expand outward from there.
Kubernetes was the natural starting point. We run it daily, I had opinions about where the documentation could be clearer, and the project has a well-structured contribution process. From there, I moved to Helm charts, because we use Helm extensively for packaging our deployments, and I found several charts with configuration options that did not match the documented behavior.
The Contribution Process
For anyone considering contributing to CNCF projects, here is what the process actually looks like in practice.
Finding issues. Most CNCF projects label beginner-friendly issues with tags like "good first issue" or "help wanted." Kubernetes has a dedicated special interest group (SIG) for contributor experience that actively curates these issues. I started there.
Understanding the codebase. Kubernetes is written in Go, which I had to learn specifically for this purpose. The codebase is large, but well-organized. The pkg/ directory contains the core libraries, cmd/ contains the entry points for each binary, and staging/ contains packages that are published as separate modules. The code is not overly clever, which I mean as a compliment. It is readable and well-commented.
The review process. CNCF projects use a rigorous review process. Your pull request needs approval from at least two reviewers, one of whom must be an "approver" for the changed files (defined in OWNERS files throughout the repo). Reviews are thorough. My first non-trivial code contribution received 47 review comments and went through four revision cycles before being merged.
This felt excessive at the time. In retrospect, it was one of the most valuable learning experiences of my career. Each review comment taught me something about Go idioms, Kubernetes coding conventions, or edge cases I had not considered.
Community interaction. The Kubernetes community communicates primarily through Slack, mailing lists, and SIG meetings. The SIG meetings are open video calls where contributors discuss ongoing work, triage issues, and plan releases. Attending these meetings gave me context that made my contributions significantly more effective.
What I Have Learned
Go as an Infrastructure Language
Learning Go for Kubernetes contributions turned out to be valuable beyond the project itself. Go's simplicity, strong concurrency primitives, and fast compilation make it well-suited for infrastructure tooling. I have since started writing internal tools in Go that previously would have been Python scripts or Java utilities.
The Go philosophy of preferring explicit code over clever abstractions aligns well with infrastructure work, where clarity and predictability matter more than expressiveness. When I am debugging a production incident at 2 AM, I want code that does exactly what it says, nothing more.
API Design Principles
Kubernetes has a remarkably well-designed API. Studying it taught me principles I now apply to my own service APIs:
- Declarative over imperative. You tell Kubernetes what you want (desired state), not how to get there. The system continuously reconciles actual state toward desired state. This pattern is applicable far beyond container orchestration.
- Level-triggered over edge-triggered. Kubernetes controllers watch the current state and act, rather than reacting to events. This makes the system resilient to missed events and simplifies recovery from failures.
- API versioning. Kubernetes supports multiple API versions simultaneously, with clear deprecation policies and migration paths. This is how you evolve an API without breaking consumers.
The Operator Pattern
One of the most interesting patterns to emerge from the Kubernetes ecosystem is the Operator pattern, formalized by CoreOS. An Operator extends Kubernetes with domain-specific knowledge by implementing a custom controller that manages a custom resource.
For example, instead of deploying a PostgreSQL database using a generic StatefulSet and manually handling backups, failover, and scaling, you deploy a PostgreSQL Operator that understands PostgreSQL operations and automates them using the same reconciliation loop that drives core Kubernetes resources.
I have been exploring this pattern for managing some of our internal services, and the results are promising. Encoding operational knowledge into a controller that runs continuously means that the system responds to failures and drift automatically, without human intervention.
The Community Itself
Beyond the technical learning, the CNCF community has been genuinely welcoming. This is not universally true of open source communities, and it is worth acknowledging.
The Kubernetes contributor experience SIG actively works on reducing barriers to entry. They maintain documentation for new contributors, run mentoring programs, and moderate community spaces to keep them professional and inclusive. When I asked my first naive question in the Kubernetes Slack, I got a helpful answer within minutes, not a sarcastic "RTFM."
I have also started attending local CNCF meetups, which have been valuable for connecting with other engineers working on similar problems. Hearing how other companies approach Kubernetes networking, or storage, or multi-cluster management gives me perspectives I would not get within the walls of a single organization.
Looking Ahead
I plan to increase my contribution activity over the next year. I have my eye on a few areas: improving the scheduler documentation (which is dense even by Kubernetes standards), contributing to the Cluster API project for declarative cluster lifecycle management, and potentially working toward becoming a reviewer for one of the SIGs I have been active in.
Open source contribution is a long game. The time investment is real, and the returns are not immediate. But the compound effect, deeper technical knowledge, a professional network that spans the industry, and the satisfaction of building something that thousands of organizations depend on, makes it one of the best investments I have made in my engineering career.
If you are considering contributing to a CNCF project, start small. Fix a typo. Update a stale example. File a well-written bug report. The first step is the hardest, and the community will meet you halfway.