How to Do a Kubernetes Rolling Update

How Kubernetes rolling updates work

When you change a Deployment's pod template (usually the container image tag), Kubernetes creates a new ReplicaSet and migrates traffic to it gradually. The default RollingUpdate strategy keeps the service up throughout:

• maxSurge: 25% - how many extra pods above the desired count can exist at once
• maxUnavailable: 25% - how many pods can be missing from the desired count at any time

For a 3-replica Deployment that means at most 1 pod goes down before a replacement is Ready - so at least 2 pods are always serving.

Step 1: check the current image

kubectl get deploy api -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'

This confirms which image is running before you touch anything.

Step 2: bump the image tag in the Deployment manifest

Edit deployment.yaml and update the image field:

spec:
  template:
    spec:
      containers:
        - name: api
          image: nginx:1.27-alpine   # was nginx:1.26-alpine

Then apply:

kubectl apply -f deployment.yaml

Step 3: watch the rollout

kubectl rollout status deploy/api

Output tracks each pod as it is replaced:

Waiting for deployment "api" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "api" rollout to finish: 2 out of 3 new replicas have been updated...
deployment "api" successfully rolled out

The command exits 0 on success and non-zero if the rollout stalls, making it safe to use in a CI pipeline step.

If something goes wrong: roll back

kubectl rollout undo deploy/api

This reverts to the previous ReplicaSet in seconds - no manifest editing required. Check history with kubectl rollout history deploy/api.

What to add before production

• Readiness probe - Kubernetes only sends traffic to a pod once its readiness probe passes. Without one, a new pod can receive requests before the app is ready, causing transient errors during the rollout.
• PodDisruptionBudget - caps how many pods the cluster can evict at once (node drains, HPA scale-down). It works alongside maxUnavailable to protect availability during maintenance events as well as rollouts.
• Progressive delivery - tools like Argo Rollouts or Flagger add canary releases and automatic rollback on error-rate signals, going beyond the built-in all-or-nothing ReplicaSet swap.