Zero-Downtime Deploys with Rolling Update Strategy
Rolling updates let you deploy new versions with minimal or zero downtime when properly configured.
What
Rolling updates gradually replace old pods with new ones, ensuring your application stays available throughout the deployment process. Kubernetes creates new pods with the updated spec, waits for them to be ready, then terminates old ones. You control the pace with maxSurge and maxUnavailable.
Why It Matters
In production, downtime during deployments is unacceptable. Rolling updates are the default Kubernetes deployment strategy because they keep your app serving traffic while new pods spin up. Combined with readiness probes, they ensure users are unlikely to hit an unavailable instance.
Example
# Deployment with rolling update strategy
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # max 1 extra pod during update
maxUnavailable: 0 # never reduce below desired count
template:
spec:
containers:
- name: web
image: myapp:v2
readinessProbe:
httpGet:
path: /ready
port: 8080
# Watch the rollout in real time
kubectl rollout status deployment/web-app
# Undo a bad deployment instantly
kubectl rollout undo deployment/web-appCommon Mistake
Not setting readiness probes on your pods. Without them, Kubernetes considers a pod ready as soon as the container starts, and sends traffic to pods that haven't finished initializing.
Quick Fix
Always pair rolling updates with readiness probes. Set maxUnavailable to 0 so Kubernetes never removes an old pod until a new one is ready. This enables near-zero-downtime deploys when combined with proper readiness probes.
Key Takeaways
- 1RollingUpdate: replace pods gradually, not all at once
- 2maxSurge: how many extra pods during update
- 3maxUnavailable: how many pods can be down
- 4Set maxUnavailable=0 to minimize downtime
- 5Always use readiness probes with rolling updates
Was this tip helpful?
Help us improve the DevOpsPath daily collection