iwantcoding.com
🔥 Daily 👥 Rooms 🏆 Top Log in Sign up

Rolling Updates

By · Reviewed & last updated · Part of Kubernetes Tutorial

A Deployments default strategy is RollingUpdate — pods of the new version come up and old ones shut down in batches controlled by maxSurge and maxUnavailable. Tune those two knobs and the readiness probe and you have safe, zero-downtime deploys. Get the probe wrong and rolling update happily replaces healthy pods with broken ones.

Tune RollingUpdate, readinessGates, and rollback

EXAMPLE
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
  namespace: shop
spec:
  replicas: 6
  selector:
    matchLabels: { app: shop-api }
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # 1) Knobs that decide how aggressive the rollout is
      maxSurge:       25%       # may go OVER replicas by this many
      maxUnavailable: 0         # NEVER go below 'replicas' ready pods

  minReadySeconds: 10           # pod must stay Ready for 10s before counting
  revisionHistoryLimit: 5       # how many old ReplicaSets to keep for rollback
  progressDeadlineSeconds: 600  # if not progressing in 10 min -> stuck, fail

  template:
    metadata:
      labels: { app: shop-api }
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: api
          image: example.com/shop-api:v1.4.0
          ports: [ { containerPort: 8080 } ]

          # 2) Readiness probe — controls when traffic moves to the pod
          readinessProbe:
            httpGet: { path: /readyz, port: 8080 }
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
          # 3) Liveness probe — restarts a pod that has crashed quietly
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }
            initialDelaySeconds: 30
            periodSeconds: 10
          # 4) Startup probe — for slow-booting apps (JVM, .NET)
          startupProbe:
            httpGet: { path: /healthz, port: 8080 }
            failureThreshold: 30
            periodSeconds: 5

          # 5) Graceful shutdown — fail readiness for N seconds before terminating
          lifecycle:
            preStop:
              exec: { command: ['sh','-c','sleep 5 && /app/shutdown.sh'] }

          resources:
            requests: { cpu: '100m', memory: '256Mi' }
            limits:   { cpu: '500m', memory: '512Mi' }

---
# 6) PodDisruptionBudget — keeps minimum capacity during voluntary disruptions
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: shop-api-pdb, namespace: shop }
spec:
  minAvailable: 5
  selector: { matchLabels: { app: shop-api } }

# 7) Drive the rollout from the CLI
kubectl -n shop set image deployment/shop-api api=example.com/shop-api:v1.4.1
kubectl -n shop rollout status deployment/shop-api --timeout=10m

# 8) Pause / resume — useful for canary patterns
kubectl -n shop rollout pause  deployment/shop-api
kubectl -n shop rollout resume deployment/shop-api

# 9) Rollback
kubectl -n shop rollout history deployment/shop-api
kubectl -n shop rollout undo    deployment/shop-api               # last good
kubectl -n shop rollout undo    deployment/shop-api --to-revision=42

# 10) Knobs explained
# maxSurge=25%        on 6 replicas -> up to 8 pods during rollout
# maxUnavailable=0    means new pods come up FIRST, then old ones go
# minReadySeconds=10  guards against flapping (port-bound, brief warm-up)
# preStop sleep 5     gives the load balancer time to deregister the pod

Why it matters

Set maxUnavailable=0 + a real readiness probe + a small minReadySeconds for any service with users. The rollout becomes "new pods come up healthy first, old ones go away second" — the only shape that gives zero-downtime deploys without writing custom orchestration on top.

Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.

Example

Example
spec:
    strategy:
        type: RollingUpdate
        rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
Try it Yourself »

Exercise

Roll back the last deploy.

kubectl rollout deployment/api

Discussion

Loading…