Bhagirath

Posted on Jan 20

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

#jenkins #kubernetes #cicdpipeline #cloudnative

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.

DEV Community