Rolling Updates

Your web-app Deployment has three Pods running nginx:1.28. You want to release nginx:1.26. With a ReplicaSet, you would delete all Pods and accept the downtime. With a Deployment, you change one line and Kubernetes handles the rest: new Pods replace old ones one at a time, always keeping the application running.

Triggering an update

If web-app is not running from the previous lesson, recreate it first:

kubectl apply -f web-deployment.yaml

Then change the image:

kubectl set image deployment/web-app web=nginx:1.26
kubectl rollout status deployment/web-app

Watch rollout status report each step as new Pods become ready and old ones terminate. When it exits cleanly, the update is complete.

What happens internally

The Deployment controller does not modify the existing ReplicaSet. It creates a new one for nginx:1.26, then scales the two ReplicaSets in alternating steps until the old one reaches zero.

At each step, a new Pod becomes Ready before an old one is terminated. Traffic is always served by healthy Pods. This is what “zero-downtime” means in practice: the application never fully stops.

After the rollout, check the ReplicaSets:

kubectl get replicaset -l app=web

Two ReplicaSets: one at 3 replicas (active), one at 0 (preserved for rollback). Their hashes differ because they represent different Pod templates.

Updating via the manifest

kubectl set image is quick but it changes the cluster without touching your file. A better approach is to edit the manifest and re-apply:

nano web-deployment.yaml

Change the image to nginx:1.25, then:

kubectl apply -f web-deployment.yaml
kubectl rollout status deployment/web-app

The file now reflects what is running. In a team setting, the manifest is the source of truth, not the cluster state.

Controlling the pace with maxSurge and maxUnavailable

These two fields in the rolling update strategy control how fast and how safely the update proceeds.

# illustrative only
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

maxUnavailable sets how many Pods can be unavailable at once during the update. A lower value means slower but safer: fewer Pods are out of rotation at any given moment.

maxSurge sets how many extra Pods (above replicas) can exist during the update. A lower value means less capacity used, which is useful on resource-constrained clusters.

Both default to 25% of replicas, rounded down for maxUnavailable and up for maxSurge.

Leave web-app running. The next lesson uses it to demonstrate rollback.