The CNCF has a lot of projects. When I opened the CNCF Landscape for the first time, I spent days just trying to figure out where to start. Kubernetes, Cilium, Argo CD, Flux, Istio etc. There is a lot going on. It is easy to feel overwhelmed.
I had used Argo CD before on a personal project, so GitOps felt familiar. That's when I found PipeCD, a continuous delivery tool still in the CNCF sandbox stage. What caught my attention was the plugin architecture. Instead of one big codebase handling every deployment type, PipeCD had redesigned things so each platform like Kubernetes, ECS, Lambda has its own separate plugin, a standalone binary talking to the agent over gRPC. That design meant the Kubernetes multi-cluster plugin was its own contained project, and it was still being built out. I could contribute to something real without needing to understand the entire codebase first. Being sandbox stage also meant I could get involved early, at a point where the project was still taking shape. That felt like the right fit.
The Project
During Term 1 2026, I worked with the PipeCD team to build out the Kubernetes multi-cluster plugin. The goal was simple: let teams deploy to multiple Kubernetes clusters from one pipeline, with proper progressive delivery such as canary testing, baseline comparison, gradual rollout, instead of pushing to every cluster at once and hoping for the best.
When I joined, the plugin could only do a basic sync and rollback. Over 30+ merged PRs, I built six deployment stages: Canary Rollout, Canary Clean, Baseline Rollout, Baseline Clean, Primary Rollout, and Traffic Routing. Each stage can target a different set of clusters, so you can test on one cluster before rolling out to the rest. I also updated the plugin SDK to report pass or fail per cluster instead of one combined result, and added health checks, rollback cleanup, and drift detection for five Kubernetes workload types.
The Part That Humbled Me
My first PR was a small refactor, easy, clean, merged quickly. That gave me too much confidence. A few weeks in, I jumped straight into building the Analysis stage plugin without really understanding what was needed or why. I opened three PRs. Two were closed. One was merged after a lot of rework. I had rushed in without reading the existing code or asking questions first.
The lesson was simple: read the issue, read the code, ask questions, then write. I had it backwards.
What Surprised Me
Open source is still the best place to learn in public and get real feedback on your work. What surprised me is how much a small change can matter. Before this mentorship, I had contributed to GitLab: a single change fixing an outdated tutorial that was sending new contributors to a search string that no longer existed in the codebase. Small fix, but every new contributor who followed that guide hit that wall. It just went in and quietly stopped being a problem for people.
The Mentorship Itself
The LFX Mentorship gave me something I could not get from a course or a side project. I was working on real code that real users run, with experienced engineers reviewing everything I wrote. My mentors Shinnosuke Sawada-Dazai and Khanh Tran gave honest feedback on every PR. They pushed me to write cleaner Go, think about edge cases I would have missed, and understand why a design decision matters, not just what it does. Doing all of this in the open, with every comment and discussion public, raised the bar for how carefully I thought before writing code.
If You Are Applying Next Term
Take your time choosing a project. CNCF is large and it is easy to pick something just because it is well known. Pick something you actually use or are genuinely curious about. Find the community on Slack, read through past issues, watch how the project works before you jump in. The community is what makes CNCF work. Being active in it will take you further than the code alone.
For the technical details of what I built so far, check out these posts:
Top comments (0)