Rolling Update

The Kubernetes default: replace pods one at a time with zero downtime.

Rolling Update is the Kubernetes default deployment strategy. It replaces old pods with new pods incrementally, ensuring some pods are always available to serve traffic. No additional infrastructure is needed.

How It Works

Kubernetes creates a new ReplicaSet with the updated pod spec and gradually scales it up while scaling down the old ReplicaSet. Two parameters control the pace: maxSurge (how many extra pods can exist) and maxUnavailable (how many pods can be down during update). Readiness probes ensure new pods are healthy before old ones are terminated.

InfoDuring a rolling update, both old and new versions serve traffic simultaneously. Your application must handle this mixed-version state gracefully (backward-compatible APIs, shared data formats).

When to Use

Stateless microservices and APIs
Changes are backward-compatible
You want the simplest zero-downtime deployment
Standard CI/CD pipelines

When NOT to Use

Breaking API changes between versions
Database schema migrations that break backward compatibility
You need an atomic all-or-nothing switch
Real-time systems where mixed versions cause inconsistency

Real-World Examples

Walmart - Product Catalog API

Walmart deploys product catalog updates across 200+ pods using rolling updates during business hours. maxSurge=25% and maxUnavailable=0 ensures no capacity loss. Readiness probes validate each pod can query the catalog database before receiving traffic.

Target - Price Update Service

Target rolls out price service updates with maxSurge=1 to ensure consistent pricing. Each pod is validated with readiness probes that check price calculation accuracy before receiving traffic.

Step-by-Step Implementation

1. Configure rolling update strategy

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: product-catalog
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 1 extra pod during update
      maxUnavailable: 0    # Never reduce capacity
  selector:
    matchLabels:
      app: product-catalog
  template:
    metadata:
      labels:
        app: product-catalog
    spec:
      containers:
      - name: catalog
        image: myregistry/catalog:2.0.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

2. Apply and monitor rollout

bash

kubectl apply -f deployment.yaml
kubectl rollout status deployment/product-catalog
kubectl get rs -l app=product-catalog  # See old and new ReplicaSets

3. Rollback if needed

bash

kubectl rollout undo deployment/product-catalog
kubectl rollout history deployment/product-catalog

Common Pitfalls

Pitfall	Symptom	Fix
No readiness probe	Traffic routed to unready pods, causing errors	Always define readinessProbe for every container
API version incompatibility	Errors during mixed-version window	Ensure backward compatibility; use API versioning
maxUnavailable too high	Capacity drops below acceptable level	Set maxUnavailable: 0 for critical services
Slow readiness probes	Rollout takes too long	Optimize startup time; use startupProbe for slow-starting apps