Sign In

Curriculum 8: Updating Resources

Rolling Updates

15 min · 15 XP

Rolling Updates

Rolling updates let you update your application with zero downtime. Kubernetes gradually replaces old Pods with new ones, ensuring that your service stays available throughout the process.

How Rolling Updates Work

When you update a Deployment (for example, changing the container image), Kubernetes does not replace all Pods at once. Instead, it:

  1. Creates a new ReplicaSet with the updated Pod template
  2. Scales up the new ReplicaSet by adding new Pods
  3. Scales down the old ReplicaSet by removing old Pods
  4. Repeats until all Pods are running the new version
# Trigger a rolling update by changing the image
kubectl set image deployment/my-app nginx=nginx:1.27

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

Controlling the Update Speed

Two fields in the Deployment spec control how fast the update happens:

maxSurge -- the maximum number of Pods that can exist above the desired count during an update. This controls how many new Pods are created before old ones are removed.

maxUnavailable -- the maximum number of Pods that can be unavailable during an update. This controls how many old Pods are removed before new ones are ready.

Both can be set as absolute numbers or percentages:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

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

  • At most 5 Pods exist at any time (4 + 1 surge)
  • At least 3 Pods are available at any time (4 - 1 unavailable)

Monitoring Rollouts

# Check rollout status
kubectl rollout status deployment/my-app

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

# See details of a specific revision
kubectl rollout history deployment/my-app --revision=2

Rolling Back

If something goes wrong, roll back to the previous version:

# Undo the last rollout
kubectl rollout undo deployment/my-app

# Roll back to a specific revision
kubectl rollout undo deployment/my-app --to-revision=3

Pausing and Resuming

For complex updates that require multiple changes, pause the rollout, make all changes, then resume:

# Pause the rollout
kubectl rollout pause deployment/my-app

# Make multiple changes without triggering separate rollouts
kubectl set image deployment/my-app nginx=nginx:1.27
kubectl set resources deployment/my-app --limits=cpu=500m,memory=256Mi
kubectl set env deployment/my-app VERSION=2.0

# Resume to apply all changes in a single rollout
kubectl rollout resume deployment/my-app

Key Takeaways

  • Rolling updates replace Pods gradually to maintain availability
  • maxSurge controls how many extra Pods can exist during an update
  • maxUnavailable controls how many Pods can be down during an update
  • Use kubectl rollout undo to roll back a bad deployment quickly
  • Pause and resume rollouts when you need to batch multiple changes