Forem: Bhagirath

End-to-End CI/CD Pipeline Using Jenkins and Kubernetes

Bhagirath — Tue, 20 Jan 2026 03:40:05 +0000

Building Scalable, Cloud-Native CI/CD Pipelines with Jenkins and Kubernetes

In modern DevOps workflows, running Jenkins on static or long-lived build agents often leads to scalability issues, inefficient resource usage, and maintenance overhead. As applications grow and deployment frequency increases, CI/CD systems must be dynamic, resilient, and cloud-native.

Kubernetes solves these challenges by providing on-demand, isolated, and auto-scalable environments for Jenkins workloads. By integrating Jenkins with Kubernetes, teams can dynamically provision build agents as pods, optimize resource utilization, and build highly scalable CI/CD pipelines.

In this blog, you’ll learn how Jenkins integrates with Kubernetes for CI/CD, understand the pipeline architecture, set up Jenkins on Kubernetes, and build a production-ready CI/CD pipeline using containerized workloads and Kubernetes deployments.

1. Why Integrate Jenkins with Kubernetes for CI/CD?

Kubernetes provides a robust and scalable platform for running containerized applications, and Jenkins is a powerful tool for automating the CI/CD pipeline. When integrated, these two tools can provide significant benefits:

Dynamic Agent Provisioning: Jenkins dynamically creates Kubernetes pods as build agents for each pipeline run. Agents are provisioned only when needed and automatically destroyed after job completion, eliminating idle infrastructure.
Scalability: Kubernetes scales Jenkins agents based on workload demand. Multiple pipelines can run in parallel, allowing for faster builds and testing cycles.
Isolation: Each Jenkins job runs inside its own Kubernetes pod, ensuring clean, reproducible, and conflict-free build environments across pipelines.
Cloud-Native Deployment: Applications can be built, containerized, and deployed directly to Kubernetes *clusters, enabling seamless end-to-end CI/CD workflows in cloud-native environments.
Resource Efficiency: Because agents are short-lived and container-based, system resources are consumed only during active pipeline execution, significantly reducing infrastructure costs.

2. Prerequisites for Jenkins and Kubernetes CI/CD Integration

Before integrating Jenkins with Kubernetes, ensure you have the following prerequisites in place. These prerequisites form the foundation for a stable and production-ready CI/CD setup.

Kubernetes Cluster: A running Kubernetes cluster is required to host Jenkins agents and deploy applications. This can be a managed Kubernetes service such as Amazon EKS, Google GKE, Azure AKS, or a self-managed on-premise cluster.
Jenkins Installed: Jenkins must be installed and accessible. It can run:
- inside a Kubernetes cluster (recommended for cloud-native setups)
- on a standalone virtual machine or server.
Kubernetes Plugin for Jenkins: The Kubernetes Plugin enables Jenkins to dynamically provision Kubernetes pods as build agents. This plugin is essential for running CI/CD pipelines using Kubernetes-based agents.
Cluster Access and Permissions: Jenkins must have permission to communicate with the Kubernetes API server. This is typically achieved using a Kubernetes Service Account with the required RBAC roles.
kubectl: The kubectl CLI tool is useful for:
- managing Kubernetes resources
- debugging deployments
- running deployment steps inside Jenkins pipelines

3. Jenkins Kubernetes Integration Architecture

Jenkins integrates with Kubernetes using the Kubernetes Plugin, which allows Jenkins to run CI/CD jobs inside Kubernetes pods instead of on static build agents.

In this setup, Jenkins focuses on orchestrating the pipeline, while Kubernetes handles executing jobs and managing resources. Whenever a pipeline starts, Jenkins asks Kubernetes to spin up a temporary pod to run the job. Once the job finishes, the pod is automatically removed.

This makes the entire CI/CD system dynamic, scalable, and cloud-native.

How Jenkins and Kubernetes Work Together:

Jenkins Controller: Jenkins controller manages pipelines, jobs, and credentials. It does not run builds directly. Instead, it coordinates with Kubernetes to run jobs on demand.
Kubernetes Plugin: plugin connects Jenkins to the Kubernetes cluster and handles the creation and cleanup of agent pods whenever a pipeline is triggered
Kubernetes Agent Pods: Each CI/CD job runs inside its own Kubernetes pod. These pods are:
- created only when needed
- isolated from each other
- automatically destroyed after the job completes
Jenkins Pipeline: A Jenkinsfile defining the CI/CD steps, including build, test, and deployment stages.
Kubernetes Cluster: Kubernetes cluster provides the infrastructure where agent pods run and where applications are ultimately deployed.

4. CI/CD Pipeline Architecture with Jenkins and Kubernetes

This CI/CD architecture uses Jenkins as the pipeline orchestrator and Kubernetes as the execution and deployment platform. Instead of relying on static Jenkins agents, Kubernetes dynamically provisions build agents as pods, making the pipeline scalable and resource-efficient.

4.1. Git

The pipeline begins with a code change pushed to a Git repository (GitHub, GitLab, or Bitbucket).
A webhook triggers Jenkins automatically on every commit or pull request, ensuring that no manual intervention is required.

Role of Git:

Stores application source code and Dockerfile
Triggers Jenkins pipelines via webhooks
Acts as the single source of truth for builds

4.2. Jenkins Controller

The Jenkins controller manages the CI/CD pipeline logic defined in the Jenkinsfile.
When a build is triggered, Jenkins does not execute jobs on itself. Instead, it requests Kubernetes to create an ephemeral agent pod.

Key Responsibilities:

Parses the Jenkinsfile
Orchestrates pipeline stages (build, test, deploy)
Requests Kubernetes to provision agent pods
Tracks pipeline execution and logs

4.3. Kubernetes Agent Pods (Dynamic Build Agents)

Using the Jenkins Kubernetes Plugin, Jenkins dynamically spins up agent pods inside the Kubernetes cluster. Each pipeline run gets its own isolated pod, which is destroyed after completion.

Why this matters:

No long-running or idle agents
Clean environment for every build
Parallel pipelines without conflicts
Automatic scaling based on workload

Each agent pod can include multiple containers (for example: Maven, Docker CLI, kubectl), allowing different stages to run in the right environment.

4.4. Docker Image Build & Push

Inside the Kubernetes agent pod, Jenkins builds the application and creates a Docker image using the project’s Dockerfile.
The image is then pushed to a container registry such as Docker Hub, Amazon ECR, or GCR.

What happens here:

Application is compiled and tested
Docker image is built inside the agent pod
Image is tagged with version or commit hash
Image is pushed to a container registry

This ensures the same image is used across all environments.

4.5. Kubernetes Deployment

Once the Docker image is available in the registry, Jenkins deploys the application to Kubernetes using kubectl or Helm.

Deployment flow:

Jenkins applies Kubernetes manifests or Helm charts
Kubernetes pulls the image from the registry
Pods are created or updated using rolling deployments
Application becomes available via Service or Ingress

This completes the end-to-end CI/CD loop from code commit to a running application in Kubernetes.

5. How to Install and Run Jenkins on Kubernetes

Getting Jenkins up and running on Kubernetes is easier than you might think, especially with Helm, the package manager for Kubernetes. Helm simplifies complex deployments and ensures you can get a production-ready Jenkins instance quickly.

5.1 Installing Jenkins with Helm

The easiest way to install Jenkins on Kubernetes is using Helm.

Step 1: Create a Namespace for Jenkins

It’s a good practice to isolate Jenkins in its own namespace:

kubectl create namespace jenkins

Step 2: Install Jenkins

Helm is a package manager for Kubernetes that simplifies the installation of complex applications like Jenkins. To install Jenkins using Helm:

helm repo add jenkins https://charts.jenkins.io
helm repo update
helm install jenkins jenkins/jenkins --namespace jenkins

Step 3: Access Jenkins

Once installed, you can access Jenkins via the Kubernetes service. To get the admin password:

kubectl get svc --namespace jenkins

kubectl exec --namespace jenkins -it $(kubectl get pods --namespace jenkins -l "app.kubernetes.io/component=jenkins-master" -o jsonpath="{.items[0].metadata.name}") -- cat /run/secrets/chart-admin-password

Open Jenkins in your browser using the service IP and port, then log in using the retrieved admin password.

5.2 Configuring the Cloud

Once Jenkins is installed, configure it to use Kubernetes for dynamic agent provisioning:

Install the Kubernetes Plugin: Go to Manage Jenkins > Manage Plugins and install the Kubernetes Plugin. This plugin allows Jenkins to communicate with your cluster and provision agents on-demand.
Configure Kubernetes Cloud:
- Navigate to Manage Jenkins > Configure System.
- Scroll down to Cloud and click Add a new cloud > Kubernetes.
- Provide the Kubernetes API URL, Jenkins URL, and configure the Kubernetes Service Account so Jenkins can manage pods.
Create Pod Templates: Pod templates define what containers are included in each Jenkins agent pod. You can create different templates for different types of jobs, for example:
- Maven builds
- Docker image builds
- Helm deployments

6. Jenkinsfile-Based CI/CD Pipeline Implementation

With Jenkins configured to use Kubernetes, the next step is to set up CI/CD pipelines that build and deploy applications to Kubernetes.

A Jenkinsfile allows you to describe your entire pipeline — build, test, and deployment as code, making it version-controlled, repeatable, and easy to maintain.

6.1 Configuring Jenkins Pipeline for Kubernetes

A Jenkinsfile defines what steps your pipeline runs and where they run.
When using Kubernetes integration, Jenkins dynamically creates a pod-based agent for each pipeline execution.

Here’s an example of a Jenkinsfile that uses Kubernetes agents and deploys an application to a Kubernetes cluster:

pipeline {
    agent {
        kubernetes {
            label 'my-k8s-agent'
            defaultContainer 'jnlp'
            yaml '''
            apiVersion: v1
            kind: Pod
            spec:
              containers:
              - name: maven
                image: maven:3.9.6-eclipse-temurin-17
                command:
                - cat
                tty: true
              - name: kubectl
                image: bitnami/kubectl:latest
                command:
                - cat
                tty: true
            '''
        }
    }
    stages {
        stage('Build') {
            steps {
                container('maven') {
                    sh 'mvn clean install'
                }
            }
        }
        stage('Test') {
            steps {
                container('maven') {
                    sh 'mvn test'
                }
            }
        }
        stage('Deploy to Kubernetes') {
            steps {
                container('kubectl') {
                    sh 'kubectl apply -f deployment.yaml'
                }
            }
        }
    }
}

What’s happening here?

Jenkins creates a temporary Kubernetes pod for this pipeline run
The pod includes multiple containers (Maven for build/test, kubectl for deployment)
Each stage runs in the most appropriate container
After the pipeline finishes, the pod is automatically destroyed

This approach keeps builds clean, isolated, and scalable.

6.2 Automating Deployments to Kubernetes

In the pipeline above, the Deploy to Kubernetes stage uses kubectl to apply Kubernetes manifests.
These YAML files typically define resources such as:

Deployments
Services
ConfigMaps
Ingress

Because deployment happens only after successful build and test stages, Jenkins ensures that only validated artifacts reach your Kubernetes cluster.

This automation removes manual deployment steps and enables fast, consistent releases.

6.3 Deploying Applications with Helm

While kubectl apply works well, managing multiple YAML files can become difficult as applications grow.
This is where Helm becomes extremely useful.

Helm allows you to:

Package Kubernetes resources into reusable charts
Version deployments
Easily upgrade or roll back releases

Here’s a simple Jenkinsfile example that deploys an application using Helm:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Deploy to Kubernetes with Helm') {
            steps {
                sh 'helm upgrade --install myapp ./helm-chart/'
            }
        }
    }
}

With Helm:

Application configuration becomes cleaner
Environment-specific values are easier to manage
Production deployments are more predictable

7. Best Practices for Jenkins Kubernetes CI/CD Pipelines

To get the most out of Jenkins and Kubernetes, it’s important to follow a few proven best practices. These help keep your pipelines scalable, secure, and easy to maintain as workloads grow.

Use Pod Templates: Define reusable pod templates for different job types to avoid duplication.
Run Each Job in an Isolated Pod: Each Jenkins job should run in an isolated pod to ensure that builds are clean and independent.
Leverage Auto-scaling: Enable auto-scaling in Kubernetes to dynamically adjust the number of nodes based on Jenkins job demand.
Manage Secrets Securely: Use Kubernetes secrets to securely manage credentials and sensitive information.
Use Helm: Package your application as a Helm chart to simplify deployment and versioning.

8. Monitoring and Scaling Jenkins CI/CD Pipelines on Kubernetes

As CI/CD pipelines grow in complexity and usage, monitoring and scaling become critical to maintaining performance and reliability. Kubernetes makes this much easier by providing built-in scalability and strong observability integrations.

Monitoring Jenkins

Jenkins Dashboard: The Jenkins dashboard gives a quick, high-level view of pipeline executions, build history, and agent activity. It’s useful for tracking failed jobs, build durations, and overall pipeline health.
Prometheus and Grafana: For deeper visibility, Jenkins can be integrated with Prometheus and Grafana. This allows teams to monitor:
- Resource usage of Jenkins controllers and agents
- Build and job execution metrics
- Pod and node performance inside the Kubernetes cluster

Grafana dashboards make it easy to visualize trends, detect bottlenecks, and proactively address performance issues before they impact deployments.

Scaling Jenkins with Kubernetes

Kubernetes enables Jenkins to scale automatically based on workload demand. Jenkins agents can be created or destroyed as pods, allowing the CI/CD system to handle sudden spikes in build traffic without manual intervention.

By combining Kubernetes auto-scaling with proper monitoring, teams can ensure that:

Builds remain fast during peak usage
Infrastructure costs stay optimized
CI/CD pipelines remain reliable and resilient

Conclusion

Integrating Jenkins with Kubernetes creates a modern, cloud-native CI/CD platform that is scalable, efficient, and production-ready. By running Jenkins agents as Kubernetes pods, teams can dynamically provision build environments, optimize resource usage, and eliminate the limitations of static build agents.

Kubernetes features such as pod isolation, auto-scaling, and Helm-based deployments allow Jenkins pipelines to remain clean, reliable, and easy to manage as applications grow. This integration enables seamless automation—from code commits and builds to testing and deployment directly into Kubernetes clusters.

By combining Jenkins and Kubernetes, you can build CI/CD pipelines that are faster, more resilient, and ready for real-world production workloads—making continuous delivery a natural part of your DevOps workflow.

How Git Stores Files Internally to Saves Space in Your Repository

Bhagirath — Thu, 15 Jan 2026 10:40:05 +0000

Learn how Git stores files internally using snapshots, blobs, trees, and hashing to avoid duplication and save repository space efficiently.

Git is the most widely used version control system in the world, and one of the key reasons for its popularity is its highly efficient storage model. At first glance, Git appears to store a complete copy of your project every time you commit. Surprisingly, repositories remain compact even after thousands of commits.

So how does Git duplicate files while still saving disk space?

In this article, we will explore how Git stores files internally, how it avoids unnecessary duplication, and why its storage mechanism is both fast and space-efficient. By the end, you will clearly understand how Git manages file data under the hood and why it scales so well for large projects.

Overview: How Git Stores Data Efficiently

Unlike traditional version control systems such as Subversion (SVN), which store file differences between versions, Git takes a fundamentally different approach.

Git stores snapshots of the entire project state at every commit.

However, Git is smart enough not to duplicate unchanged data. If a file has not changed between commits, Git simply reuses the previously stored version instead of saving a new copy. This design enables Git to deliver:

Faster operations (branching, merging, checkout)
Reduced disk usage
Strong data integrity and reliability

1. How Git Stores Data Using Snapshots Instead of File Differences

Most version control systems track line-by-line changes over time. Git does not.

Every time you create a commit, Git records a snapshot of the entire file structure at that moment.

What Happens When Files Don’t Change?

If a file remains unchanged between commits:

Git does not store the file again
Git simply creates a reference to the existing stored content

This means Git behaves like a content-addressable filesystem, where identical content is stored once and referenced many times.

Why This Matters

This snapshot model allows Git to:

Instantly switch between branches
Perform fast merges
Avoid recalculating diffs repeatedly

2. Git Object Model: How Files Are Stored Internally

Git stores all repository data as objects inside the .git/objects directory. Each object is identified by a cryptographic hash based on its content.

There are four primary object types in Git:

Blob — File contents
Tree — Directory structure
Commit — A snapshot with metadata
Tag — Named references to commits

2.1 Blob Objects: File Content Storage

A blob (Binary Large Object) represents the raw content of a file.

Key characteristics of blobs:

Store file data only (no filename or permissions)
Identical file contents result in identical blob hashes
Stored only once, regardless of how many commits reference them

Why Blobs Enable De-duplication

If two files — or the same file across commits — have identical content:

Git stores one blob
Multiple commits point to the same blob

This is the foundation of Git’s space-saving mechanism.

You can inspect blobs using:

git ls-tree <commit-hash>

2.2 Tree Objects: Directory Structures

A tree object represents a directory in your project.

It contains:

File names
File permissions
References to blob objects
References to other tree objects (subdirectories)

Each directory in your project maps to a tree object, allowing Git to recreate the complete filesystem structure for any commit.

2.3 Commit Objects: Snapshots in Time

A commit object ties everything together.

It contains:

A reference to the root tree
Author and committer information
Commit message
Parent commit(s)

Commit Structure Example

Commit
└── Tree (Root Directory)
    ├── Blob (File 1)
    ├── Blob (File 2)
    └── Tree (Subdirectory)
        ├── Blob (File 3)
        └── Blob (File 4)

Each commit represents a complete snapshot, but most data is reused from earlier commits.

3. Inside the `.git` Directory: Git’s Internal Storage and Control System

The .git directory is the core of every Git repository. It stores all metadata, objects, and references.

3.1 `.git/objects/`

This directory stores all Git objects (blobs, trees, commits) in compressed form. Objects are named using their hash values.

3.2 `.git/refs/`

References to branches and tags live here. Each branch is simply a pointer to a commit.

3.3 `.git/index` (Staging Area)

The index tracks what will be included in the next commit. It bridges the gap between your working directory and the repository.

3.4 `.git/HEAD`

The HEAD file points to the currently checked-out branch or commit.

4. How Git Uses Hashing, Compression, and De-duplication to Save Space

Git’s efficiency comes from three core techniques.

4.1 Content-Addressable Hashing

Git computes a hash (SHA-1 by default, SHA-256 supported) for every object based on its content.

Same content → same hash
Different content → different hash

This guarantees data integrity and prevents duplication.

4.2 Object Compression

Git compresses objects using zlib, reducing disk usage while maintaining fast access.

4.3 Automatic De-duplication

Git never stores the same content twice. If a file hasn’t changed:

No new blob is created
Existing blobs are reused

This is how Git duplicates files logically without duplicating data physically.

5. From Working Directory to Commits: How Git Builds and Stores Snapshots

To fully understand how Git duplicates files while saving space, it is essential to understand the three logical areas through which every change flows: the working directory, the staging area, and the commit history. These are not just conceptual layers — they directly influence how Git creates objects and reuses existing data.

5.1 Working Directory

The working directory is the actual project folder on your local machine. It contains real files that you edit using your editor or IDE.

Key characteristics:

Files here exist outside of Git’s object database
Changes are not tracked automatically
Git does not store anything permanently at this stage

When you modify a file in the working directory:

Git detects the change
No new blob is created yet
No disk space inside .git/objects is used

This design allows Git to remain fast and lightweight while you experiment with changes.

5.2 Staging Area (Index)

The staging area, also called the index, is where Git begins its internal storage optimization.

When you run:

git add <file>

Git performs the following actions:

Reads the file content from the working directory
Computes a hash based on the content
Checks whether an identical blob already exists
Reuses the existing blob or creates a new one if needed
Records the blob reference in .git/index

Important details:

The staging area stores references, not copies
Unchanged files reuse existing blob objects
Partial staging is supported, allowing fine-grained commits

This is where Git’s de-duplication logic begins to take effect.\

5.3 Commit History

When you run:

git commit

Git creates a commit object, which includes:

A reference to a tree object
Metadata (author, timestamp, message)
A reference to the parent commit

Crucially:

Git does not duplicate file content
The new tree references existing blobs whenever possible
Only changed files produce new blobs

Each commit represents a complete snapshot, but internally, most data is shared across commits. This allows Git to maintain a full project history without ballooning repository size.

6. Exploring Git’s Internals Using Low-Level Git Commands

One of Git’s strengths is transparency. Git provides low-level commands that allow you to inspect its internal object database, making it easier to understand how files are stored and reused.

These commands are especially valuable for developers who want to understand Git beyond everyday workflows.

6.1 `git cat-file`: Viewing Raw Git Objects

The git cat-file command allows you to inspect any Git object directly.

To view a commit object:

git cat-file -p <object-hash>

This displays:

The referenced tree
Parent commit
Author and committer details
Commit message

You can also inspect blob objects to see file content exactly as Git stores it, confirming that identical content is reused across commits.

6.2 `git ls-tree`: Exploring Tree Structures

The git ls-tree command shows how a commit or tree maps to files and directories.

git ls-tree <commit-hash>

Output includes:

File permissions
Object type (blob or tree)
Object hash
File or directory name

This command clearly demonstrates how Git builds directory snapshots using tree objects that reference blob objects, without duplicating data.

6.3 `git rev-parse`: Resolving References to Hashes

The git rev-parse command helps resolve symbolic references into their actual object hashes.

git rev-parse HEAD

Use cases include:

Verifying which commit a branch points to
Debugging detached HEAD states
Understanding reference resolution

This reinforces the idea that branches and tags are lightweight pointers, not copies of data.

Conclusion: Why Git’s Storage Model Is So Powerful

Git’s ability to duplicate files logically without duplicating data physically is the cornerstone of its performance and scalability. By storing content as immutable, hashed objects and reusing them across commits, Git ensures that repositories remain fast and space-efficient — even with extensive histories.

Key Takeaways

Git stores snapshots, not file diffs
Identical file content is stored only once and reused
Blobs, trees, and commits form Git’s object model
The .git directory contains all internal data
Hashing and compression ensure integrity and efficiency

Understanding Git’s internal storage model gives you deeper confidence when working with branches, rebases, merges, and large repositories. It also explains why Git continues to outperform traditional version control systems in both speed and reliability.

Why a Good README.md Matters More Than Your Code

Bhagirath — Mon, 01 Dec 2025 10:09:45 +0000

Is your repository a ghost town? Discover why the README.md is the most critical file in your project.

The “Black Box” Problem

Imagine you are shopping for a new laptop online. You click on a product that looks promising, but the page has no photos, no spec sheet, and no price. It just has a button that says “Buy Now.”

Would you click it? Of course not. You have no idea what you are getting into.

In the world of software development, your GitHub or GitLab repository is the product page, and your README.md is the sales pitch.

Too many developers fall into the “Black Box” trap. They spend hundreds of hours writing elegant, highly optimized algorithms, pushing perfectly tested code to the src folder, and then leave the root directory empty. They assume the code speaks for itself.

Code never speaks for itself. Unless a user can understand what your project does, how to install it, and why it matters in under 30 seconds, your code effectively does not exist.

This guide moves beyond the theory. You’ll look at the architecture of documentation, visualize the user journey, and provide the exact syntax you need to turn a dead repository into a thriving open-source project.

1. The Visual Impact: Before vs. After

Let’s look at a concrete example. We have a hypothetical library called Data-Muncher, a simple Python script that cleans CSV files.

Scenario A: The “Ghost Town” (No README)

When a recruiter or developer lands on this repository, this is all they see:

📁 Data-Muncher /
├── 📁 src /
│   └── main.py
├── 📁 tests /
│   └── test_main.py
├── .gitignore
└── requirements.txt

The User Experience:

Confusion: “What does this do? Does it munch data? Is it for SQL or CSV?”
Frustration: “I have to read the source code to figure out how to run it.”
Action: The user hits the “Back” button and finds a competitor.

Scenario B: The “Professional Product” (With README)

Now, look at the exact same code, but with a structured README.md.

The directory now looks like this, but the rendering on GitHub presents a beautiful interface:

# 🦁 Data-Muncher

![Build Status](https://img.shields.io/badge/build-passing-brightgreen)
![Version](https://img.shields.io/badge/version-1.0.2-blue)
![License](https://img.shields.io/badge/license-MIT-green)

> A lightning-fast Python library to clean messy CSV files 10x faster than Pandas.

## 🚀 Features
- Removes duplicates automatically.
- Normalizes date formats (ISO-8601).
- zero-dependency architecture.

## 📦 Installation
pip install data-muncher

The User Experience:

Clarity: They know exactly what it is immediately.
Trust: The “build passing” badge proves it works.
Ease: They can copy-paste the installation command.

2. The “5-Second Rule”

In UX design, we often talk about the Time to Hello World (TT-HW). This is the time it takes for a new user to land on your repo and get the code running on their machine.

If your TT-HW is longer than 5 minutes, you lose 80% of your potential users.

The User Decision Flowchart

Below is a diagram illustrating the mental process a developer goes through when evaluating your library.

A good README removes the “No” branches from this flowchart. It streamlines the path to the “Star the Repo” outcome.

3. The Technical Anatomy of a Perfect README

A professional README isn’t just a wall of text; it is structured data using Markdown. Here are the essential components and the syntax to create them.

A. The Header and Elevator Pitch

Don’t start with “Introduction.” Start with the name and a hook.

Code Syntax:

# Project Name
**The one-line elevator pitch goes here.** *Example: "The only React Native boilerplate you will ever need."*

B. Shields (Badges)

Badges are the “Social Proof” of open source. They tell the user that the project is alive, maintained, and licensed. You don’t need complex code for this; you use markdown image links.

Code Syntax:

![License](https://img.shields.io/badge/License-MIT-green.svg)
![Downloads](https://img.shields.io/badge/downloads-10k%2Fmonth-blue)

C. The Visual Demo (Show, Don’t Tell)

If you are building a UI, a GIF is mandatory. If you are building a CLI (Command Line Interface), a screenshot of the terminal is mandatory.

Why? The human brain processes images 60,000x faster than text.

Code Syntax:

![App Demo GIF](./assets/demo.gif)
*Caption: Seeing the app in dark mode.*

D. The Quick Start (Copy-Paste Ready)

This is the most crucial technical section. Do not describe how to install it; give the command. Use “Code Fences” (triple backticks) to allow users to copy the code easily.

Bad Documentation:

“To install, you need to open your terminal and run the npm install command for our package.”

Good Documentation:

npm install my-awesome-package
# or
yarn add my-awesome-package

4. README Driven Development (RDD)

Most developers write the code first!!

Readme Driven Development (RDD) suggests that you should write the README before you write a single line of code.

How RDD Works:

Draft the README: Write down the hypothetical installation command and the API functions you wish existed.
Reality Check: As you write the README, you might realize, “Wait, this function requires 5 arguments. That is too complicated to explain.”
Refactor Design: You simplify the design before coding it, simply because explaining the complex version in the README was too hard.

5. Formatting Matters: Markdown Tricks for SEO and Readability

A wall of plain text is hard to scan. You need to use Markdown features to create hierarchy and “scannability.” Search engines (SEO) also prefer structured content.

Using Collapsible Sections

If you have a long list of configurations, use the HTML tag within your Markdown to keep the page clean.

Code Syntax:

<details>
<summary>Click to view Advanced Configuration</summary>

| Option | Type | Default |
|--------|------|---------|
| --verbose | bool | false |
| --dry-run | bool | false |

</details>

Using Tables for Data

Don’t list arguments in paragraphs. Use tables. They are cleaner and look professional.

Code Syntax:

| Method | Description | Returns |
|--------|-------------|---------|
| `.init()` | Starts the server | `void` |
| `.stop()` | Kills the process | `boolean` |

6. The “Bus Factor” and Maintenance

Documentation is an insurance policy against the “Bus Factor.”

The “Bus Factor” is the minimum number of team members that have to be hit by a bus (or quit) before the project creates stops functioning because no one knows how it works.

If only you understand how to deploy the database, your project has a Bus Factor of 1. This is dangerous.

A good README acts as an “External Brain.” It remembers the setup steps so you don’t have to.

Essential “Maintenance” Sections to Include:

Development Setup: How to clone and run the repo locally.
Testing: How to run the test suite (npm run test).
Deployment: How the code gets to production.

7. SEO: Getting Your Repo Found

You want your project to be found on Google, not just GitHub. The README.md is the primary source of content that Google crawls.

SEO Checklist for READMEs:

Keywords in H1/H2: If your project is a “JSON Parser,” ensure those words appear in the Title and Description.
Alt Text for Images: Google cannot see images.
Bad: ![image](img.png)
Good: ![Screenshot of the JSON Parser Dashboard showing real-time metrics](img.png)
Linking: Link to your other projects or your portfolio. This creates a “backlink” structure that improves your ranking.

Conclusion: Documentation is Empathy

Ultimately, writing a good README is an act of empathy. It signals that you care about the person on the other side of the screen.

When a hiring manager looks at your portfolio, they aren’t going to clone your repo and audit your variable names. They are going to read your README.

Messy README = Messy Developer.
Structured, Clear README = Senior Engineer potential. Don’t let your brilliant code die in the dark. Light it up with a README that sells, explains, and guides.

How Kubernetes detects and restarts crashing pods automatcially

Bhagirath — Wed, 26 Nov 2025 17:35:33 +0000

A Deep Dive into the Kubelet, PLEG, and Controller Manager

One of the defining promises of Kubernetes is “Self-Healing.” When a service crashes, the platform automatically detects the failure and restores the workload without human intervention. But How does Kubernetes restart crashing pods?

Kubernetes does not technically restart pods; it replaces the containers within them. This process is managed by the Kubelet on each node, which uses the Pod Lifecycle Event Generator to monitor container states. When a container fails — indicated by a non-zero exit code, an OOMKilled signal, or a failed Liveness Probe — the Kubelet applies a restart action. This restart is throttled by an exponential backoff algorithm (doubling delay up to 300 seconds) to prevent CPU exhaustion, ensuring the system heals itself automatically.

1. The Architecture of Failure: Kubelet and PLEG

To understand detection, we must look at the Node Level. The Kubernetes Control Plane (API Server) is often too far removed to handle immediate process failures. The heavy lifting is performed locally by the Kubelet.

SyncLoop

The Kubelet runs a continuous control loop called the SyncLoop. Its job is simple: Reconcile Expected State with Actual State.

Expected State: “Run Nginx version 1.2.” (From API Server)
Actual State: “Nginx is running.” (From Runtime)

Problem with Polling

In early versions of Kubernetes, the Kubelet would constantly ask the Docker daemon, “Are my containers running?” repeatedly. With 100+ pods per node, this polling choked the CPU.

Solution: PLEG (Pod Lifecycle Event Generator)

This is the internal mechanism that makes detection fast and efficient.

Relisting: PLEG periodically relists all containers from the runtime.
Comparison: It compares the old list with the new list.
Event Generation: If it sees a change (e.g., Container ID abc changed state from Running to Exited), it generates a ContainerDied event.
Immediate Action: This event wakes up the Kubelet immediately, bypassing the standard polling cycle.

2. The Three Signals of Death

How does the runtime know a container has failed? It relies on three specific signals from the Linux Kernel and the Kubelet’s own probing logic.

A. Process Exit (Crash)

When the main process inside your container (PID 1) stops, it sends an exit code to the operating system.

Exit Code 0: The process finished successfully. (Kubernetes considers this “Completed”).
Exit Code 1–255: The process crashed or threw an error.

The Kubelet sees this non-zero code via the CRI and marks the container as Error.

B. The OOMKilled Signal (Exit Code 137)

This is the most common and misunderstood crash.

Scenario: Your application tries to allocate 512MB of RAM, but your Pod YAML limits it to 256MB.
Kernel’s Reaction: The Linux Kernel cgroups mechanism denies the memory request. The kernel invokes the OOM Killer (Out of Memory Killer), which immediately sends SIGKILL to the process.
Result: The container dies instantly with Exit Code 137 (128 + 9 for SIGKILL).

What it looks like in kubectl describe pod:

State:          Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Mon, 01 Jan 2024 12:00:00 GMT
  Finished:     Mon, 01 Jan 2024 12:05:00 GMT

If you see Exit Code 137, restarting the pod won’t fix it. You must either fix the memory leak in your code or increase the resources.limits.memory in your YAML.

C. The Liveness Probe (The Deadlock)

Sometimes, PID 1 is still running, but the application is frozen (deadlocked) or stuck in an infinite loop. The process exists, so the kernel thinks everything is fine.

This is where Liveness Probes come in. You configure the Kubelet to actively “ping” your app.

livenessProbe:
 httpGet:
 path: /healthz
 port: 8080
 initialDelaySeconds: 15
 periodSeconds: 20
 failureThreshold: 3

If the endpoint returns a 500 error or times out 3 times in a row, the Kubelet decides the application is broken. It forcefully kills the container to trigger a restart.

3. The Recovery Logic: Restart Policies

Once a failure is confirmed, the Kubelet consults the restartPolicy defined in the Pod spec.

“Always” Policy (Default) This is used for standard web servers and long-running services. Kubelet restarts the container regardless of why it stopped.

spec:
  restartPolicy: Always

“OnFailure” Policy Used for batch jobs or data processing. The container is only restarted if it crashes (non-zero exit code). If it finishes cleanly (Exit Code 0), it stays stopped.

spec:
  restartPolicy: OnFailure

“Never” Policy Used for debugging or one-off static pods. Kubernetes will never restart the container.

spec:
  restartPolicy: Never

4. The Algorithm: CrashLoopBackOff

Imagine your database is down, and your API crashes immediately upon connecting. If Kubernetes restarted your API instantly every time, it would restart 1,000 times a second, consuming all the CPU on the node.

To prevent this, Kubernetes uses an Exponential Backoff Algorithm.

Math Behind the Wait

When a container crashes repeatedly, the Kubelet inserts a delay before attempting the next restart. The delay doubles with every crash:

Crash 1: Immediate Restart.
Crash 2: Wait 10s.
Crash 3: Wait 20s.
Crash 4: Wait 40s.
…
Max Delay: 300s

When you run kubectl get pods and see status CrashLoopBackOff, it means Kubernetes is currently waiting for this timer to expire before trying again.

Resetting the Timer:
The timer doesn’t last forever. If the container starts and runs successfully for 10 minutes (configurable via minReadySeconds), Kubernetes resets the backoff counter to zero.

5. Cluster-Level Recovery: When the Node Dies

The Kubelet handles local software failures. But what happens if the physical server (Node) fails? This scenario moves the responsibility from the Kubelet to the Kubernetes Controller Manager.

Node Controller Loop:

Heartbeat Loss: Every node sends a status update to the API Server every 10 seconds.
Timeout: If the API Server receives no update for 5 minutes (default --pod-eviction-timeout), the Node Controller marks the node condition as Unknown or NotReady.
Eviction: The controller applies a NoExecute taint to the node.
Rescheduling: The ReplicaSet Controller observes that the number of running replicas has dropped below the desired count. It immediately schedules new pods on remaining healthy nodes.

6. Advanced Engineering: Startup Probes & Sidecars

As Kubernetes evolves, new features allow for more granular control over restarts.

“Slow Start” Problem
Legacy Java apps or AI models loading large weights into GPU memory can take minutes to start. A standard Liveness Probe would kill these containers before they finish booting.

The Solution: Use a startupProbe.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Logic: The probe checks every 10 seconds for 30 times (300 seconds total).
Behavior: Liveness probes are disabled until the Startup probe succeeds once.

7. How to Debug Crash Loops

When facing a crash loop, use these three commands to diagnose the root cause:

Step 1: Check the Previous Logs If the pod is currently crashing, standard logs might be empty. You need to see the logs of the previous instance that died.

kubectl describe pod <pod-name>

Look for Last State: Terminated and the Exit Code.

Step 2: Inspect the Events The “Events” section tells you why Kubelet killed it (e.g., Liveness Probe Failed, OOMKilled).

kubectl logs <pod-name> --previous

Look for the “Last State” section.

Step 3: Debug with an Ephemeral Container If the container crashes too fast to inspect, attach a debug shell to the running pod without restarting it.

kubectl debug -it <pod-name> --image=busybox --target=<container-name>

Conclusion

Kubernetes “Self-Healing” is not a single feature; it is a symphony of independent systems.

PLEG ensures crashes are detected in milliseconds.
CRI captures the specific exit codes to determine the cause.
Backoff Algorithms prevent your infrastructure from being overwhelmed by failing applications.
Controllers* handle the catastrophic loss of physical hardware.

By understanding these internals, engineers can move beyond basic troubleshooting and architect systems that are resilient to both software bugs and infrastructure failures.

Click Report Resolve: My SIH 2025 Journey to Smarter Civic Governance

Bhagirath — Fri, 19 Sep 2025 13:54:19 +0000

Imagine spotting a pothole or garbage pile on your street and reporting it within seconds — no complicated forms, no waiting endlessly for updates. Civic participation in India has long faced challenges like inefficient reporting, lack of transparency, and low accessibility.

At Smart India Hackathon 2025, my team Fedora tackled this problem head-on with an innovative idea: an AI-powered crowdsourced civic issue reporting and resolution system. This solution makes reporting problems as simple as clicking a photo and empowers citizens and governments alike with real-time insights.

The Problem with Current Systems

Inefficient Reporting — Most systems are slow, manual, and lack automation.
Lack of Transparency — Citizens rarely know if their complaint is received or resolved.
Low Accessibility — Existing portals are complex, especially for semi-literate or first-time digital users.

These issues widen the gap between citizens and government bodies, ultimately slowing down civic improvements.

My Solution: CityFix

I built a mobile-first, AI-powered platform designed to make civic reporting simple, transparent, and accessible to all.

Key Features:

One-click photo reporting with auto-location tagging
AI auto-classification of issues (potholes, garbage, etc.) with urgency detection
Real-time tracking of complaints with status updates
WhatsApp chatbot support for instant updates without app installation
Multi-language accessibility (English, Hindi, and local dialects)
Centralized dashboard for officials with analytics and heat maps

Technical Approach

Citizen (Web-App)
Frontend: React Native (for web)
UI/UX: TailwindCSS + Material UI (for fast, accessible, multilingual design)
Multilingual Support: i18next library
Reporting Features
Camera + Location: React Native Camera/GPS (mobile)
Notifications: Firebase Cloud Messaging (push notifications across devices)
Backend Infrastructure
Serverless Processing: Google Cloud Functions (auto-scale, low latency)
Data Management: Google Firestore (real-time sync, scalable), Firebase Storage (images, video)
Authentication: Firebase Auth (secure login via email/phone/social)
Admin Dashboard
Frontend: React.js + Chart.js / Recharts (data visualization)
Maps: Leaflet.js (interactive city maps with issue heatmaps)
Task Routing Engine: Custom ML model (Python/FastAPI) + rule-based priority system
Advanced Features
AI/ML Layer: TensorFlow Lite for image classification (pothole, garbage, etc.)
Analytics & Insights: Google Data Studio / Looker for admin reports / Heatmaps for hotspots and trend analysis
Scalability & Integration
APIs: REST + GraphQL APIs for future extensions
Offline Mode: Local storage with background sync (PWA capabilities)
This modular, scalable stack ensures smooth performance and accessibility.

Impact & Benefits

→ For Citizens:

Faster, easier reporting
Real-time status tracking
Builds trust in government systems

→ For Government:

Efficient allocation of resources and workforce
Data-driven decisions with hotspot analytics
Increased accountability and transparency

→ For Communities:

Cleaner, safer, and more eco-friendly cities
Better collaboration between people and government
A step towards Smarter, Sustainable India

Why It Matters

This solution aligns perfectly with the Clean & Green Technology theme of SIH 2025. By merging AI, crowdsourcing, and civic governance, it bridges the gap between citizens and authorities — making cities not just smarter, but more inclusive and transparent.

References & Inspiration

My research drew inspiration from existing civic platforms like:

fixmystreet

pgportal

mygov

Conclusion

Civic engagement shouldn’t be a struggle — it should be empowering. With Fedora's Cityfix, we aim to simplify reporting, strengthen transparency, and accelerate issue resolution. Together, citizens and governments can co-create a cleaner, greener, and smarter India.

Beyond Text — The Rise of Multimodal AI and Its Impact

Bhagirath — Mon, 01 Sep 2025 07:48:52 +0000

Large Language Models (LLMs) have transformed how we interact with technology, but for a long time, their power was limited to a single domain: text. You could ask a chatbot a question, and it would give you a text response. But what if you could show it a picture and ask it to write a poem about it? Or show it a video and have it describe the events in a single paragraph?

This is the promise of multimodal AI, the next frontier in artificial intelligence. Instead of just “reading” words, these models can see, hear, and understand the world through multiple data formats, or “modalities,” just like humans do. This shift from single-sense to multi-sense AI is already reshaping industries and creating a new wave of applications.

What is Multimodal AI?

At its core, multimodal AI refers to a system that can process, understand, and generate content from more than one data type simultaneously. While a traditional LLM (like early versions of GPT) was “unimodal” (text-in, text-out), a multimodal model can handle a mix of inputs, such as:

Text (written language)
Images (photos, graphics)
Audio (speech, sound effects)
Video (a combination of images and audio over time)

This allows for more complex and context-rich interactions. For example, a doctor could input an X-ray, a patient’s medical history (text), and a recorded description of their symptoms (audio) to get a comprehensive diagnostic summary.

How Multimodal Models Work

The magic behind multimodal AI lies in its ability to fuse different data types into a single, unified representation. Here’s a simplified breakdown:

Input Modules: The model uses specialized “encoders” to process each data type. A separate neural network might handle images (like a Convolutional Neural Network), while another handles text (Transformer-based models).
Fusion Module: This is the brain of the operation. The model takes the encoded data from each modality and combines them in a shared space. It learns the relationships between them — for instance, how a picture of a dog relates to the word “dog.”
Output Module: Once the data is fused, the model can generate a response in a single or multiple formats. This could be a text description, a new image, or a synthesized voice. By learning these deep connections, models like Google’s Gemini and OpenAI’s GPT-4o can reason across different types of information, leading to more accurate and coherent results with fewer “hallucinations.”

Real-World Applications and Use Cases

Multimodal AI isn’t just a research topic; it’s already powering groundbreaking applications across various fields.

Healthcare: Analyzing medical scans (images) alongside patient records and notes (text) to assist with diagnostics.

Retail & E-commerce: Providing personalized shopping recommendations by analyzing a customer’s search query (text) and past purchases (transaction data) as well as the images of products they’ve browsed.
Autonomous Driving: Integrating real-time data from multiple sensors — cameras (video), radar, and LiDAR (sensor data) — to perceive the environment and make immediate decisions.

Content Creation: Generating a video script (text) from a series of images, or creating a new image from a combination of text and an existing photo.
Customer Service: Analyzing a customer’s tone of voice (audio) and chat log (text) to better understand their sentiment and provide a more empathetic response.

The Future of Human-Computer Interaction

The shift to multimodal AI marks a fundamental change in how we interact with technology. It’s moving us closer to a future where AI systems are not just tools but true collaborators that can perceive the world in a more holistic, human-like way.

As these models become more sophisticated, we can expect them to become even more integrated into our daily lives. From smart home assistants that can “see” a broken appliance and guide you through the repair, to educational tools that can “watch” you solve a problem and offer personalized feedback, the possibilities are nearly limitless.

By understanding the power of multi-modal AI, you’re not just keeping up with the latest trends — you’re preparing for a future where the digital world is as sensory and interconnected as our own.

Forem: Bhagirath

End-to-End CI/CD Pipeline Using Jenkins and Kubernetes

1. Why Integrate Jenkins with Kubernetes for CI/CD?

2. Prerequisites for Jenkins and Kubernetes CI/CD Integration

3. Jenkins Kubernetes Integration Architecture

How Jenkins and Kubernetes Work Together:

4. CI/CD Pipeline Architecture with Jenkins and Kubernetes

4.1. Git

4.2. Jenkins Controller

4.3. Kubernetes Agent Pods (Dynamic Build Agents)

4.4. Docker Image Build & Push

4.5. Kubernetes Deployment

5. How to Install and Run Jenkins on Kubernetes

5.1 Installing Jenkins with Helm

5.2 Configuring the Cloud

6. Jenkinsfile-Based CI/CD Pipeline Implementation

6.1 Configuring Jenkins Pipeline for Kubernetes

6.2 Automating Deployments to Kubernetes

6.3 Deploying Applications with Helm

7. Best Practices for Jenkins Kubernetes CI/CD Pipelines

8. Monitoring and Scaling Jenkins CI/CD Pipelines on Kubernetes

Monitoring Jenkins

Scaling Jenkins with Kubernetes

Conclusion

How Git Stores Files Internally to Saves Space in Your Repository

Overview: How Git Stores Data Efficiently

1. How Git Stores Data Using Snapshots Instead of File Differences

What Happens When Files Don’t Change?

Why This Matters

2. Git Object Model: How Files Are Stored Internally

2.1 Blob Objects: File Content Storage

Why Blobs Enable De-duplication

2.2 Tree Objects: Directory Structures

2.3 Commit Objects: Snapshots in Time

3. Inside the .git Directory: Git’s Internal Storage and Control System

3.1 .git/objects/

3.2 .git/refs/

3.3 .git/index (Staging Area)

3.4 .git/HEAD

4. How Git Uses Hashing, Compression, and De-duplication to Save Space

4.1 Content-Addressable Hashing

4.2 Object Compression

4.3 Automatic De-duplication

5. From Working Directory to Commits: How Git Builds and Stores Snapshots

5.1 Working Directory

5.2 Staging Area (Index)

5.3 Commit History

6. Exploring Git’s Internals Using Low-Level Git Commands

6.1 git cat-file: Viewing Raw Git Objects

6.2 git ls-tree: Exploring Tree Structures

6.3 git rev-parse: Resolving References to Hashes

Conclusion: Why Git’s Storage Model Is So Powerful

Key Takeaways

Why a Good README.md Matters More Than Your Code

The “Black Box” Problem

1. The Visual Impact: Before vs. After

Scenario A: The “Ghost Town” (No README)

Scenario B: The “Professional Product” (With README)

2. The “5-Second Rule”

The User Decision Flowchart

3. The Technical Anatomy of a Perfect README

A. The Header and Elevator Pitch

B. Shields (Badges)

C. The Visual Demo (Show, Don’t Tell)

D. The Quick Start (Copy-Paste Ready)

4. README Driven Development (RDD)

How RDD Works:

5. Formatting Matters: Markdown Tricks for SEO and Readability

Using Collapsible Sections

Using Tables for Data

6. The “Bus Factor” and Maintenance

Essential “Maintenance” Sections to Include:

7. SEO: Getting Your Repo Found

SEO Checklist for READMEs:

Conclusion: Documentation is Empathy

How Kubernetes detects and restarts crashing pods automatcially

1. The Architecture of Failure: Kubelet and PLEG

SyncLoop

Problem with Polling

Solution: PLEG (Pod Lifecycle Event Generator)

3. Inside the `.git` Directory: Git’s Internal Storage and Control System

3.1 `.git/objects/`

3.2 `.git/refs/`

3.3 `.git/index` (Staging Area)

3.4 `.git/HEAD`

6.1 `git cat-file`: Viewing Raw Git Objects

6.2 `git ls-tree`: Exploring Tree Structures

6.3 `git rev-parse`: Resolving References to Hashes