Updating applications

Kubernetes Deployments support rolling updates: gradually replace old Pods with new ones, within the configured availability and surge limits. This can preserve availability, but it does not guarantee zero downtime. You still need sufficient capacity, useful readiness checks, graceful shutdown, and compatible application changes. A stalled rollout needs investigation; Kubernetes does not automatically roll it back for you.

The browser simulator simplifies replacement timing. Use it to practice the desired-state workflow, then verify rollout behavior in a real disposable cluster before relying on it at work.

To release a new application version, update the image in the Deployment's Pod template. Kubernetes creates a new ReplicaSet and replaces Pods according to the rollout settings.

Let's update our deployment to use a newer version of the nginx image:

kubectl set image deployment/nginx-deployment nginx=nginx:1.27.3
deployment.apps/nginx-deployment image updated

In this rollout, Kubernetes creates a Pod with the updated image, waits for it to become ready, then terminates the old one:

NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-685b6fc776-w8fmr   1/1     Running             0          2d
nginx-deployment-7754fdff65-slkqh   0/1     Pending             0          0s
nginx-deployment-7754fdff65-slkqh   0/1     ContainerCreating   0          0s
nginx-deployment-7754fdff65-slkqh   1/1     Running             0          9s
nginx-deployment-685b6fc776-w8fmr   1/1     Terminating         0          2d
nginx-deployment-685b6fc776-w8fmr   0/1     Terminating         0          2d

A new Pod (nginx-deployment-7754fdff65-slkqh) starts in Pending, moves through ContainerCreating, and becomes ready. In this example, the old Pod then terminates. Check application requests during a real rollout to confirm whether availability was preserved.

You can verify the update is complete by checking the pods:

kubectl get pods
nginx-deployment-7754fdff65-slkqh   1/1     Running   0          40s

Record the reason for the update in an annotation. This description appears in rollout history, which helps you identify revisions later.

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="version change to 1.27" --overwrite=true
deployment.apps/nginx-deployment annotated

To get a better feel for this let's update it again:

kubectl set image deployment/nginx-deployment nginx=nginx:1.28.0
deployment.apps/nginx-deployment image updated

Kubernetes repeats the rollout with the new image. Watch for the replacement Pod to become ready and the old Pod to terminate.

You can verify that the new pod is up and running:

kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-bfcc6b74b-wqx4r   1/1     Running   0          18s

Record the second update as well:

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="version change to 1.28" --overwrite=true
deployment.apps/nginx-deployment annotated

The next lesson uses these recorded revisions to restore an earlier application version.