RollingUpdate in Kubernetes: Updating Applications Without Downtime
How does Kubernetes manage to update an application without taking down all Pods at once?
This is one of the biggest advantages of using a Deployment.
When we change an image, add resources, or modify any manifest configuration, Kubernetes doesn’t remove all Pods immediately.
Instead, it performs a gradual update.
This strategy is called RollingUpdate.
In this article, we will understand how it works and the role of the maxSurge and maxUnavailable parameters.
What is RollingUpdate?
RollingUpdate is the default strategy used by Deployments.
Its goal is to gradually replace old Pods with new ones.
Thus, the application remains available for virtually the entire update.
Visually, the process happens like this.
Before
Pod 1 (v1)
Pod 2 (v1)
Pod 3 (v1)
Pod 4 (v1)
│
RollingUpdate
▼
Pod 1 (v2)
Pod 2 (v2)
Pod 3 (v2)
Pod 4 (v2)Instead of removing all old Pods, Kubernetes performs this swap gradually.
Configuring the Strategy
Inside the Deployment, we find the strategy field.
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 2In this snippet, we are telling Kubernetes how we want the update to be performed.
The two most important parameters are:
maxSurgemaxUnavailable
Let’s understand each of them.
What is maxSurge?
maxSurge defines how many extra Pods can temporarily exist during an update.
Imagine a Deployment with:
10 PodsIf we configure:
maxSurge: 1During the update, Kubernetes can create:
10 old Pods
+
1 new Pod
=
11 PodsThese extra Pods exist only during the RollingUpdate.
After the update, the Deployment returns to the desired quantity.
What is maxUnavailable?
maxUnavailable defines how many Pods can be unavailable during the update.
For example.
maxUnavailable: 2With a Deployment containing ten replicas.
10 PodsKubernetes can remove up to two Pods before creating new ones.
Thus, we will have:
8 available Pods
2 Pods being replacedIn other words.
Even during the update, at least eight Pods will continue to respond to requests.
Understanding the Process Step by Step
Let’s imagine again a Deployment with ten replicas.
Initial state
10 old
0 newWith:
maxSurge: 1
maxUnavailable: 2Kubernetes starts by creating a new Pod.
10 old
1 new
Total = 11 PodsNow it can remove up to two old Pods.
8 old
1 new
Total = 9 PodsAs two slots opened up, it creates two more new Pods.
8 old
3 new
Total = 11 PodsThen it removes more old Pods.
Creates new ones again.
And continues repeating this process until all are using the new version.
Visualizing the RollingUpdate
The behavior can be represented like this.
10 old
↓
11 Pods
(10 old + 1 new)
↓
9 Pods
(8 old + 1 new)
↓
11 Pods
(8 old + 3 new)
↓
...
↓
10 new PodsThis update happens automatically.
In most cases, users don’t even notice that the application has been updated.
Applying an Update
After changing the manifest.
image: nginx:1.31.0We apply it again.
kubectl apply -f deployment.yamlExpected result:
deployment.apps/nginx-deployment configuredAt this point, the RollingUpdate begins.
Monitoring the Update
While the Deployment is being updated, we can observe the Pods.
kubectl get pods -n giropopsExpected result:
NAME READY
nginx-xxxxx Running
nginx-yyyyy Terminating
nginx-zzzzz RunningYou will see old Pods being terminated while new Pods appear.
Monitoring the Rollout
There is a specific command to monitor the update’s progress.
kubectl rollout status deployment \
-n giropops \
nginx-deploymentExplaining:
rollout status→ monitors the update.deployment→ resource type.-n giropops→ Namespace.nginx-deployment→ Deployment name.
Expected result:
Waiting for deployment...
deployment "nginx-deployment" successfully rolled outThis command is widely used during production deployments.
When to Change maxSurge?
A higher value makes the update finish faster.
However.
It also consumes more cluster resources.
Example.
maxSurge: 3In this case, Kubernetes can create up to three extra Pods during the process.
This reduces the update time.
But it requires more CPU and memory.
When to Change maxUnavailable?
This parameter controls the minimum availability of the application.
The higher this number.
The faster the update tends to be.
On the other hand.
Fewer Pods will remain serving users.
In critical applications, this value is usually low.
Summary
RollingUpdate
│
├── Updates gradually
├── Avoids downtime
├── Creates new Pods
├── Removes old Pods
└── Keeps the application availableThe two parameters work as follows.
| Parameter | Function |
|---|---|
maxSurge | Maximum number of extra Pods during the update |
maxUnavailable | Maximum number of unavailable Pods during the update |
Conclusion
RollingUpdate is one of the most important features of Deployments.
It allows applications to be updated practically without interrupting the service.
By correctly combining maxSurge and maxUnavailable, we can control the balance between update speed and application availability.
In the next article, we will learn about the Recreate strategy, understand how it works, and discover in which scenarios it still makes sense, even though it causes a period of downtime.