How Does the Rolling Update Strategy Work in Kubernetes?

intermediate|deploymentsdevopssrecloud architectCKACKAD

TL;DR

A rolling update gradually replaces old Pods with new ones by creating new ReplicaSet Pods while scaling down the old ReplicaSet, controlled by maxSurge and maxUnavailable parameters to ensure zero-downtime deployments.

Detailed Answer

The RollingUpdate strategy is the default for Kubernetes Deployments. It incrementally replaces Pods from the old version with Pods of the new version, ensuring the application stays available throughout the process.

How It Works

You update the Deployment spec (e.g., change the container image)
Kubernetes creates a new ReplicaSet with the updated Pod template
New Pods are created in the new ReplicaSet while old Pods are terminated
The rollout respects maxSurge and maxUnavailable constraints

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # At most 5 Pods during update (4 + 1)
      maxUnavailable: 1    # At least 3 Pods always available
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-app:v2

Monitoring a Rollout

# Watch rollout progress
kubectl rollout status deployment/my-app

# View rollout history
kubectl rollout history deployment/my-app

# Roll back to previous version
kubectl rollout undo deployment/my-app

maxSurge and maxUnavailable Explained

With replicas: 4, maxSurge: 1, maxUnavailable: 1:

Maximum Pods at any time: 5 (4 + maxSurge)
Minimum available Pods: 3 (4 - maxUnavailable)
Kubernetes creates 1 new Pod, waits for it to be ready, then terminates 1 old Pod, and repeats

Why Interviewers Ask This

Interviewers want to know if you understand how Kubernetes achieves zero-downtime deployments. This question reveals whether you've managed real production workloads.

Common Follow-Up Questions

What's the difference between RollingUpdate and Recreate strategies?

RollingUpdate replaces Pods incrementally for zero downtime. Recreate kills all old Pods before creating new ones — causes downtime but avoids running two versions simultaneously.

How do you roll back a failed deployment?

Use kubectl rollout undo deployment/my-deployment. Kubernetes reverts to the previous ReplicaSet revision.

What are maxSurge and maxUnavailable?

maxSurge controls how many extra Pods can exist above the desired count. maxUnavailable controls how many Pods can be unavailable during the update. Both accept absolute numbers or percentages.

Key Takeaways

Rolling updates are the default deployment strategy in Kubernetes.
maxSurge and maxUnavailable control the pace of the rollout.
Each rollout creates a new ReplicaSet while scaling down the old one.
Use kubectl rollout status to monitor progress and kubectl rollout undo to revert.