Amazon EKS — Rolling Updates & Rollbacks

Rolling Updates & Rollbacks

Rolling updates replace pods gradually — zero downtime by default.

---

How Rolling Updates Work

Rolling Update (maxSurge=1, maxUnavailable=0)
─────────────────────────────────────────────

Step 1: [v1] [v1] [v1]          ← 3 pods running v1
Step 2: [v1] [v1] [v1] [v2]     ← 1 new v2 pod created
Step 3: [v1] [v1] [v2]          ← 1 old v1 terminated
Step 4: [v1] [v1] [v2] [v2]     ← another v2 created
Step 5: [v1] [v2] [v2]          ← another v1 terminated
Step 6: [v1] [v2] [v2] [v2]     ← last v2 created
Step 7: [v2] [v2] [v2]          ← all v1 gone ✅

---

Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # Max extra pods during update
      maxUnavailable: 0    # Zero downtime
  template:
    spec:
      containers:
        - name: web
          image: myapp:v2
          readinessProbe:       # CRITICAL for rolling updates
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

---

Rollback

# Check rollout status
$ kubectl rollout status deployment/web
deployment "web" successfully rolled out

# View history
$ kubectl rollout history deployment/web
REVISION  CHANGE-CAUSE
1         Initial deployment
2         Updated to v2
3         Updated to v3

# Rollback to previous version
$ kubectl rollout undo deployment/web

# Rollback to specific revision
$ kubectl rollout undo deployment/web --to-revision=1

---

Common Mistakes

Mistake	Impact
No readiness probe	Traffic sent to unready pods
maxUnavailable too high	Service degradation during update
No resource limits	New version might OOM and crash-loop
Not watching rollout status	Missing failed deployments

---

What’s Next?

Advanced patterns: Blue/Green & Canary.