The idea for a practical guide to build an open source project and publishing it to CNCF came to me when I was working on KubeReport, an open source tool that automatically generates PDF/CSV deployment reports from your Kubernetes cluster. It is designed for DevOps teams, QA, and managers. It can auto-email reports, integrate with Jira, and track exactly what got deployed and when.
I noticed that there were not clear enough documentation on how to create a project that adheres to CNCF standards. And thus I created this guide from the experience I gained with KubeReport.
💡
I have created a small project, KubePRC (Pod Restart Counter), for you to practice hands-on Kubernetes concepts before building your own open-source products in any programming language. I presume that you are familiar with some sort of coding and GitHub. Explaining those things are out of scope for this guide.
Step 0: Ask yourself first: Why are you building the project?
Before you start building anything, be clear about why are you doing it? Think about these three points:
- market gap
- market trend
- long-term vision.
Let me take the example of my existing project KubeReport again.
🌉 Market Gap – Automatic reports post deployment
In fast-moving environments with 40–50 clients, deployments happen every day. After deployment, we often rely on manual smoke tests before involving QA. But issues like:
- Missed service failures
- No track of deployment count
- No visibility into images or teams involved
…often surface only after clients report problems.
This is not just a company-specific issue. These gaps are common across the DevOps world.
KubeReport fills that gap. It provides a centralized, auditable report after every deployment — in the form of downloadable PDFs or CSVs — sent automatically to managers, clients, Jira tickets and email groups.
📈 Market Trend – Rising demand for AI-driven automation
As DevOps matures, there’s an increasing demand for:
- Lightweight, CLI-based tools integrated into pipelines
- Immediate post-deployment health visibility
- Intelligent automation and alerting systems
🤖 Future Scope – AI-powered task automation
In the long term, the goal is to reduce manual intervention by integrating AI to:
- Detect anomalies in restart counts based on historical deployment trends
- Automatically classify failures (e.g., infra-related vs. app-related)
- Generate intelligent deployment health reports
- Recommend or trigger self-healing actions (like auto-restart, scaling, or rollback)
These enhancements will empower teams to act faster with minimal manual input — reducing human error and increasing confidence in every release.
This is how I outlined it before creating the KubeReport tool. You get the gist. You should build a tool that not only solves real problems but also has a future scope for improvements.
🔍 Step 1: Check if your idea already exists
Before building KubeReport, we asked:
Is there already something like this out there?
If an idea already exists — for example, a MySQL Operator — you have three options:
- Don’t build it
- Build a better version
- Solve it for a different target (e.g., MongoDB or Postgres)
In our case, there was no specific open-source tool that automated Kubernetes deployment reports like this — so we started building.
💻 Step 2: Language & tech stack selection
Kubernetes is written in Go, which makes it a strong choice for any native integration. Our goals were:
- Fast performance
- Access to client libraries
- Ease of deployment
So we used:
- Go for core logic
- Kubernetes APIs to fetch pod/deployment data
- Go PDF/CSV libraries for report generation
📋
You can adapt your stack based on your needs. Choose what offers good performance, community support, and personal comfort.
🧩 Step 3: Design the Architecture
If your project has multiple components (like frontend, backend, APIs, and DB), architecture diagrams can be very useful.
I recommend:
- Miro or Whimsical for quick architecture and flow diagrams
- Weekly planning: what to build this week, next, and this month
Breaking down work into phases keeps the project manageable.
🛠️ Step 4: Start Small – “Hello World” First
Always begin with a small, functional unit.
For example, the first version of KubeReport:
- Listed pods from Kubernetes
- Generated a simple PDF
That was it. Later, we added:
- CSV format
- Deployment filters
- Auto-email feature
- Cloud storage
✅ One step at a time. Build a small working thing, then grow.
Let’s see all this with a sample project. Feel free to replicate the steps.
Building kubeprc (Kube Pod Restart Counter)
Let’s take kubeprc as an example project for hands-on practice.
kubeprc (short for Kube Pod Restart Counter) is a lightweight open source tool that scans your Kubernetes cluster and reports on pod restart counts. It’s ideal for DevOps and SRE teams who need to monitor crash loops and container stability — either in real-time or as part of automated checks.
Why are we building this?
As part of early discovery (Step 1 & Step 2), we identified a clear market gap:
There was no simple, focused tool that:
- Counted pod restarts across a cluster
- Worked both locally and in-cluster
- Could be deployed cleanly via Helm
- Was lightweight and customizable
While 2–3 similar tools exist, they either lack flexibility or are too heavy. Our aim is to build:
- A focused tool with a clean CLI
- Extra features based on real-world DevOps use cases
- A Helm chart for seamless integration in CI/CD pipelines or monitoring stacks
Feature Planning
I used Miro for feature plans layout. You can use any project management tool of your choice.
Tech Stack
Kubernetes is written in Go, so client libraries and API access are very well supported. Go offers great performance, concurrency, and portability.
| Tool | Purpose |
|---|---|
| Go | Core CLI logic & Kubernetes client |
| Docker | Containerization for portability |
| Helm | Kubernetes deployment automation |
| Minikube / Cloud (Azure/GCP/AWS) | Local & cloud testing environments |
