Skip to content

Kubernetes Level 01 Day 05: Performing Zero-Downtime Rolling Updates on a Deployment

This document explains how to upgrade an existing Deployment to a new container image version using Kubernetes’ rolling update strategy. The objective is to change the image used by nginx-deployment to nginx:1.19 while ensuring continuous availability and avoiding downtime.

Rolling updates are not just about changing an image tag. They involve coordinated ReplicaSet transitions, readiness checks, and controlled scaling behavior managed automatically by the Deployment controller.





Understanding the Situation Before Updating

A Deployment manages a ReplicaSet, which manages Pods. When you modify the Pod template (for example, by changing the container image), Kubernetes does not modify existing Pods directly. Instead, it creates a new ReplicaSet derived from the updated template.

The old ReplicaSet represents the previous version. The new ReplicaSet represents the updated version. Kubernetes gradually shifts traffic by scaling one down and the other up.



Step 1: Verify the Current State of the Deployment

Before updating, confirm that the Deployment exists and that its Pods are running.

kubectl get deployments
kubectl get pods

Check the current image in use:

kubectl describe deployment nginx-deployment | grep Image

This establishes a baseline before modification.



Step 2: Identify the Container Name Inside the Deployment

The kubectl set image command requires the container name defined inside the Pod template.

kubectl describe deployment nginx-deployment

Under the Pod Template section, locate Containers: and note the container name. This may be nginx or another name specified when the Deployment was created.

The container name is important because a Deployment can technically manage multiple containers within one Pod.



Step 3: Perform the Rolling Update

Update the image using the imperative method.

kubectl set image deployment/nginx-deployment nginx=nginx:1.19

This command updates the Pod template. Kubernetes detects the template change and automatically performs a rolling update.

Alternatively, edit the Deployment directly:

kubectl edit deployment nginx-deployment

Change the image field under:

spec:
  template:
    spec:
      containers:
        - name: nginx
          image: nginx:1.19

Saving the file triggers the update process.



Step 4: Monitor the Rolling Update

Track progress in real time.

kubectl rollout status deployment/nginx-deployment

Expected output upon completion:

deployment "nginx-deployment" successfully rolled out

Observe ReplicaSets during rollout:

kubectl get replicasets

You will see two ReplicaSets temporarily:

  • One old (previous image)
  • One new (nginx:1.19)

Watch Pods during the transition:

kubectl get pods -w

Pods with new template hashes will gradually replace old ones.



Verifying the New Image Is Active

Confirm the image version:

kubectl describe deployment nginx-deployment | grep Image

Or inspect Pods directly:

kubectl get pods -o wide
kubectl describe pod <pod-name> | grep Image

All Pods should now reference nginx:1.19.



Internal Mechanics of Rolling Updates

The default rolling update strategy is defined as:

  • maxSurge: 25%
  • maxUnavailable: 25%

These values mean Kubernetes may create up to 25% extra Pods above the desired replica count during update (surge capacity), and may allow up to 25% of Pods to be temporarily unavailable.

For example, if replicas = 4:

  • Up to 5 Pods may run temporarily (surge)
  • At least 3 remain available during transition

These parameters can be customized:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Setting maxUnavailable: 0 guarantees zero downtime at the cost of temporary extra resource usage.



Observing Revision History

Each update creates a revision.

kubectl rollout history deployment/nginx-deployment

To inspect a specific revision:

kubectl rollout history deployment/nginx-deployment --revision=2



Performing a Rollback

If the new version is unstable, revert to the previous revision.

kubectl rollout undo deployment/nginx-deployment

Kubernetes restores the previous ReplicaSet by updating the Deployment template again.

Monitor rollback:

kubectl rollout status deployment/nginx-deployment



What Happens If New Pods Fail

If the new image fails readiness checks or crashes repeatedly, rollout pauses. You can inspect:

kubectl describe deployment nginx-deployment
kubectl get pods

If readiness probes were configured, Kubernetes waits until new Pods are marked Ready before scaling down old ones. Without readiness probes, traffic may shift prematurely.



Final State After Completion

At the end of this task:

  • The Deployment nginx-deployment uses image nginx:1.19
  • A new ReplicaSet replaced the old one
  • Pods were updated incrementally
  • Availability was maintained during transition
  • Revision history is preserved for rollback

Rolling updates demonstrate how Kubernetes handles controlled application upgrades without shutting down services, forming the basis for production-grade deployment strategies.