Introduction

Jenkins and Kubernetes are commonly integrated in two ways: Jenkins itself runs on Kubernetes, and Jenkins uses Kubernetes to launch ephemeral build agents for jobs. The second part is usually the most valuable one because it gives each pipeline a fresh, disposable execution environment instead of a long-lived shared build machine.

That makes the integration about more than "install Jenkins in a cluster." A good setup gives Jenkins just enough access to create temporary pods, run builds, and deploy workloads without turning the CI system into an unrestricted cluster admin.

The Common Architecture

A practical Jenkins-Kubernetes integration usually looks like this:

• Jenkins controller stores pipeline definitions and job state,
• the Kubernetes plugin creates short-lived agent pods on demand,
• each agent pod contains the tools needed for one pipeline stage,
• deployment steps use kubectl, Helm, or GitOps handoff to update workloads.

This model keeps the controller stable while scaling build capacity dynamically.

Example Jenkins Pipeline Using a Kubernetes Agent

With the Kubernetes plugin, a pipeline can define its own build pod:

1pipeline {
2  agent {
3    kubernetes {
4      yaml '''
5apiVersion: v1
6kind: Pod
7spec:
8  containers:
9    - name: builder
10      image: maven:3.9.9-eclipse-temurin-17
11      command:
12        - cat
13      tty: true
14'''
15    }
16  }
17
18  stages {
19    stage('Build') {
20      steps {
21        container('builder') {
22          sh 'mvn -B test package'
23        }
24      }
25    }
26  }
27}

Each run gets a fresh pod. When the job ends, the agent can be destroyed, which keeps the build environment clean and reproducible.

What Kubernetes Needs to Allow

Jenkins does not need unlimited cluster power just to launch agents. At minimum, the service account used by Jenkins typically needs permission to:

• create and delete pods in the agent namespace,
• read pod logs and status,
• optionally create secrets or config maps if your workflow requires them.

That is why RBAC matters so much. A sloppy integration often "works" only because someone gave Jenkins full cluster-admin rights, which is a bad long-term security posture.

Deploying Applications from Jenkins

Once builds are working, a pipeline can deploy to Kubernetes directly:

1stage('Deploy') {
2  steps {
3    sh 'kubectl apply -f k8s/deployment.yaml'
4  }
5}

Or with Helm:

1stage('Deploy') {
2  steps {
3    sh 'helm upgrade --install myapp ./chart --namespace app'
4  }
5}

Direct deployment is common, though many teams now prefer Jenkins to build and publish artifacts while a GitOps controller performs the actual cluster reconciliation.

Operational Concerns

A strong integration also plans for:

• image pull credentials for agent containers,
• persistent storage only where Jenkins truly needs it,
• resource requests and limits for build pods,
• secret handling through Kubernetes secrets or external secret managers,
• namespace isolation for CI workloads.

Without these controls, the cluster can become noisy, expensive, or insecure very quickly.

Common Pitfalls

• Installing Jenkins on Kubernetes and stopping there without using ephemeral agents, which loses much of the integration's value.
• Granting Jenkins cluster-admin rights when narrower RBAC would be enough.
• Running all builds in one giant static agent image instead of defining focused pod templates.
• Mixing CI concerns and production deployment permissions into the same broad service account.
• Forgetting resource limits, which can let builds starve other workloads on the cluster.

Summary

• Jenkins-Kubernetes integration is most useful when Jenkins launches ephemeral build pods on demand.
• The Jenkins controller should be stable, while agents are disposable and workload-specific.
• RBAC should grant only the permissions Jenkins actually needs.
• Pipelines can build, test, and deploy using Kubernetes-native tools such as kubectl and Helm.
• The best setups emphasize reproducibility, isolation, and least privilege rather than just convenience.