Deploying to Kubernetes from Jenkins

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Jenkins deploys to Kubernetes using kubectl commands with the kubeconfig stored as a Jenkins File credential. The pipeline builds a Docker image tagged with the build number, pushes to a registry, then runs kubectl set image to trigger a rolling deployment.

Interview Answer2 min

Deploying to Kubernetes from Jenkins requires a kubeconfig credential injected into the pipeline and kubectl or Helm available in the agent environment. The pipeline should verify the deployment completes before reporting success.

Credential and tooling setup

Store the kubeconfig file as a Jenkins File credential — withCredentials([file(credentialsId: 'kubeconfig-prod', variable: 'KUBECONFIG')]) injects the file path into the KUBECONFIG environment variable, which kubectl reads automatically
Never commit kubeconfig files to the repository — they contain cluster server addresses and authentication tokens that grant cluster access to anyone who can read the file
Use a namespaced Service Account with RBAC restricted to the deployment target namespace — the Jenkins CI service account needs get, list, create, update, patch on Deployments and Services in the target namespace; not cluster-admin

Deploy steps and rollout verification

kubectl set image deployment/payment-service app=${IMAGE_NAME}:${IMAGE_TAG} -n production triggers a rolling update from the pipeline — simpler than applying a full YAML for routine image updates
kubectl rollout status deployment/payment-service -n production --timeout=300s waits up to 5 minutes for the rollout to complete and exits with a non-zero code if it times out or a new Pod fails readiness — this is how the pipeline knows whether the deployment succeeded, not just whether the kubectl command ran
Without rollout status, the pipeline reports success the moment the rolling update starts — a broken new image that fails readiness probes causes the pipeline to show green while production traffic is still on the old version

Helm-based deployments

helm upgrade --install payment-service ./helm/payment-service --set image.tag=${IMAGE_TAG} -n production --wait --timeout 5m combines install and upgrade, waits for rollout, and fails the pipeline if pods do not become ready — --wait is the Helm equivalent of kubectl rollout status
Use Helm's --atomic flag for canary or risky deployments — on failure, Helm automatically rolls back to the previous release rather than leaving a partially updated state

Interview-ready guide

Interview answer

Credential and tooling setup

Store the kubeconfig file as a Jenkins File credential — withCredentials([file(credentialsId: 'kubeconfig-prod', variable: 'KUBECONFIG')]) injects the file path into the KUBECONFIG environment variable, which kubectl reads automatically
Never commit kubeconfig files to the repository — they contain cluster server addresses and authentication tokens that grant cluster access to anyone who can read the file
Use a namespaced Service Account with RBAC restricted to the deployment target namespace — the Jenkins CI service account needs get, list, create, update, patch on Deployments and Services in the target namespace; not cluster-admin

Deploy steps and rollout verification

kubectl set image deployment/payment-service app=${IMAGE_NAME}:${IMAGE_TAG} -n production triggers a rolling update from the pipeline — simpler than applying a full YAML for routine image updates
kubectl rollout status deployment/payment-service -n production --timeout=300s waits up to 5 minutes for the rollout to complete and exits with a non-zero code if it times out or a new Pod fails readiness — this is how the pipeline knows whether the deployment succeeded, not just whether the kubectl command ran
Without rollout status, the pipeline reports success the moment the rolling update starts — a broken new image that fails readiness probes causes the pipeline to show green while production traffic is still on the old version

Helm-based deployments

helm upgrade --install payment-service ./helm/payment-service --set image.tag=${IMAGE_TAG} -n production --wait --timeout 5m combines install and upgrade, waits for rollout, and fails the pipeline if pods do not become ready — --wait is the Helm equivalent of kubectl rollout status
Use Helm's --atomic flag for canary or risky deployments — on failure, Helm automatically rolls back to the previous release rather than leaving a partially updated state

03 · Deep dive