Kubernetes Rolling Updates
Zero-downtime deploys with rolling update strategy and readiness probes.
ContainersIntermediate
Why
Rolling updates replace pods one at a time, ensuring zero downtime. With readiness probes, new pods only receive traffic when ready. maxSurge and maxUnavailable control speed.
When
Use rolling updates for stateless services. Use blue-green or canary for risky changes.
How
1. Strategy — RollingUpdate (default)
2. maxSurge — extra pods during update (e.g., 25%)
3. maxUnavailable — pods down during update (e.g., 25%)
4. readinessProbe — gate traffic to ready pods
5. progressDeadlineSeconds — fail if stuck
6. Pause — kubectl rollout pause
7. Undo — kubectl rollout undo
Example
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: myapp }
spec:
replicas: 6
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2 # 2 extra pods during update
maxUnavailable: 1 # 1 pod down at most
template:
spec:
containers:
- name: app
image: myapp:v2
readinessProbe:
httpGet: { path: /health, port: 3000 }
initialDelaySeconds: 5
periodSeconds: 5
# Commands
kubectl set image deployment/myapp app=myapp:v2
kubectl rollout status deployment/myapp
kubectl rollout undo deployment/myapp # rollback
Common Problems
- ⚠Deploy stuck — readiness probe failing, new pods never ready
- ⚠Downtime — no readiness probe, traffic to unready pods
- ⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical
Best Practices
- ✓Always set readinessProbe — gates traffic, zero downtime
- ✓Set maxUnavailable: 0 for strict zero-downtime — never reduce available pods
- ✓Set up health checks and graceful shutdown — handle SIGTERM to drain in-flight requests before exit