Updating applications

Kubernetes has a built-in rolling update mechanism that ensures zero downtime during the update process. This mechanism works by gradually replacing old pods with new ones until all pods have been updated. The beauty of this approach is that it ensures that there is no disruption of service to the end users. If a new pod fails to launch for any reason, Kubernetes will stop the rollout and leave the old ones in place, ensuring that your application remains available at all times.

This makes updating applications a simple process. As soon as we have a release ready, packaged and containerized as a Docker image we can update the deployment manifest with the new image.

Kubernetes deployments are a description of the desired state of your application so once we have updated the deployment manifest Kubernetes takes over and turns our desires into reality using the rolling update mechanism we talked about earlier.

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

Behind the scenes, Kubernetes performs a rolling update — creating a new pod with the updated image, waiting for it to become ready, then terminating the old one. Here's what that process looks like:

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 is created with a new identifier (nginx-deployment-7754fdff65-slkqh) and starts in the pending state. Then the container gets created and the pod starts running. As soon as the new one is up and running, Kubernetes terminates the old pod. The result: an updated deployment with no downtime.

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

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

After updating a deployment it is good practice to annotate why you did it with some identifying cause for the change. You will see later why this is a good idea.

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 performs the same rolling update pattern — creating a new pod, bringing it to a running state, then terminating the old one.

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

Finally for posterity let's annotate this new deployment:

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

Now we have successfully updated our application. Let's move onto the final part -- revision histories and rollbacks.