Kubernetes Rolling Updates: Complete Guide to Zero-Downtime Deployments

Comprehensive guide to Kubernetes Rolling Updates covering zero-downtime deployment strategies, update configurations, kubectl commands, rollback procedures, and best practices.

What are Kubernetes Rolling Updates?

Rolling updates allow you to update your application with zero downtime by incrementally updating Pods instances with new ones. The Deployment ensures that only a certain number of Pods are down while they are being updated, and only a certain number of Pods are created above the desired number of Pods.

Zero Downtime

Update applications without service interruption by gradually replacing pods

Rollback Capability

Easy rollback to previous versions if issues are detected

Configurable Parameters

Control update speed and availability with maxSurge and maxUnavailable

Progress Monitoring

Monitor update progress and status in real-time

kubectl Commands for Rolling Updates

Update a Deployment

kubectl apply -f [definition.yaml]

Apply new configuration to trigger rolling update

Check Update Progress

kubectl rollout status

Get the progress of the update

View Deployment History

kubectl rollout history deployment [deploymentname]

Get the history of the deployment

Rollback Deployment

kubectl rollout undo deployment [deploymentname]

Rollback to the previous revision

Rollback to Specific Revision

kubectl rollout undo deployment [deploymentname] \
  --to-revision=[revision#]

Rollback to a specific revision number

Deployment Update Strategies

Strategy: RollingUpdate

Gradually replaces old pods with new ones, ensuring zero downtime and maintaining service availability throughout the update process.

v1
v1
v2
v1
v2
v2
v2
v2
v2
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

Strategy: Recreate

Terminates all existing pods before creating new ones. This results in downtime but ensures all pods run the same version simultaneously.

v1
v1
v1
X
X
X
v2
v2
v2
spec:
  strategy:
    type: Recreate

Default Strategy: RollingUpdate is the default strategy with both maxSurge and maxUnavailable set to 25%.

RollingUpdate Configuration Parameters

maxSurge

Maximum number of Pods that can be created over the desired number of Pods

  • Can be specified as an absolute number or percentage
  • Controls how many extra pods can be created during update
  • Higher values allow faster updates but consume more resources
  • Default: 25%

Example: With 4 replicas and maxSurge: 1, up to 5 pods can exist during update

maxUnavailable

Maximum number of Pods that can be unavailable during the update process

  • Can be specified as an absolute number or percentage
  • Controls how many pods can be temporarily unavailable
  • Lower values ensure higher availability but slower updates
  • Default: 25%

Example: With 4 replicas and maxUnavailable: 1, at least 3 pods must remain available

Complete YAML Example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # Can have up to 6 pods during update
      maxUnavailable: 1   # At least 3 pods must remain available
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.20
        ports:
        - containerPort: 80

Rolling Update Best Practices

Configuration Tips

  • Use maxUnavailable: 0 for critical services that require 100% availability
  • Set maxSurge: 100% for faster deployments when resources allow
  • Configure proper readiness and liveness probes for smooth updates
  • Use resource limits to prevent resource exhaustion during updates
  • Test updates in staging environments before production

Monitoring & Rollback

  • Monitor rollout status continuously during updates
  • Set up alerts for failed deployments
  • Keep sufficient revision history for rollback options
  • Use canary deployments for high-risk updates
  • Implement automated rollback on health check failures