Kubernetes offers administrators a way to update our hosted services and containerized applications without having any downtime. This is accomplished through rolling updates, which will update the application in one replica at a time, so that users accessing the service can continue without interruption. After a little time, every replica will have undergone the issued update.
This is a big improvement over traditional deployments, where administrators often needed to take services completely offline in order to perform updates. High availability and reduced downtime are the main goals for any Kubernetes cluster, and rolling updates are a big help towards that. If the new update causes any problems, it is also simple enough to rollback to the previous version until the kinks are worked out.
In this tutorial, we will go through the step by step instructions to perform a rolling update in Kubernetes on a Linux system.
In this tutorial you will learn:
- How to perform a rolling update in Kubernetes
- How to check the status of updates in Kubernetes
- How to roll back a bad update

Category | Requirements, Conventions or Software Version Used |
---|---|
System | Any Linux distro |
Software | Kubernetes |
Other | Privileged access to your Linux system as root or via the sudo command. |
Conventions |
# – requires given linux commands to be executed with root privileges either directly as a root user or by use of sudo command$ – requires given linux commands to be executed as a regular non-privileged user |
Perform Rolling Update in Kubernetes
These steps assume that you already have your Kubernetes cluster up and running, and have access to the kubectl command.
- In our example, we already have four Nginx replicas up and running. We can check to see that they are running as expected with the following commands:
$ kubectl get deployment $ kubectl get pods
Your output should show that all of your pods are currently up to date.
Our deployment currently has four replicas, which we will update gradually with a rolling update - Next, we issue our rolling update
kubectl
command. It will follow this syntax:$ kubectl set image deployments/[deployment name] [container name]=[new image path]
For our example, here is how we update our four Nginx replicas to version 1.22.1:
$ kubectl set image deployments/nginx-deployment nginx=nginx:1.22.1
In this case, Kubernetes will retrieve Nginx version 1.22.1 from Docker Hub (default repository unless we specify one, or a local file) and then push it out to each replica, one by one.
- We can see the update’s current progress with a few commands.
$ kubectl get deployment $ kubectl get pods
As you see in the screenshot below, 2 of our replicas are up to date (out of 4). We can see that 2 of the replicas are currently being created again, this time with the new update.
We can see that the update is gradually being processed into each replica - You can verify that the rolling update is complete with the following
kubectl
commands:$ kubectl rollout status deployments/nginx-deployment deployment "nginx-deployment" successfully rolled out $ kubectl describe pods | grep Image: Image: nginx:1.22.1 Image: nginx:1.22.1 Image: nginx:1.22.1 Image: nginx:1.22.1 Image: nginx
As you can see, the four Nginx images bear the version number 1.22.1 that we rolled out to the cluster.
All four of our hosted Nginx applications now reflect the new version number - In case you do not get a positive confirmation from the commands above, and need to roll back the update, it is simple enough to do by executing:
$ kubectl rollout undo deployments/[deployment name]
In our example the command would be:
$ kubectl rollout undo deployments/nginx-deployment deployment.apps/nginx-deployment rolled back
Closing Thoughts
In this tutorial, we saw how to perform a rolling update in a Kubernetes cluster on a Linux system. Issuing rolling updates is a very convenient feature of Kubernetes, as clients will not notice any downtime. The icing on the cake is that the update is easy to roll back with just one command, in case something goes wrong. What used to take hours and cause downtime now only takes a few moments with Kubernetes.