Kubernetes Deployments: Rolling Updates, Readiness Probes, and Why Rollbacks Fail Silently

What a Deployment manages

A Deployment is a Kubernetes resource that manages a ReplicaSet, which manages Pods. You describe the desired state — image version, replica count, resource limits — and the deployment controller continuously reconciles actual state with desired state.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: myrepo/api:v2.1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

maxSurge and maxUnavailable: the tradeoff

With 4 replicas and default settings (25%):

maxSurge = 1      (can have 5 pods during rollout)
maxUnavailable = 1 (can have 3 available pods minimum)

Kubernetes starts one new pod. When it becomes ready, it terminates one old pod. Continues until all old pods are replaced. At no point are fewer than 3 pods available.

For zero-downtime deploys with a readiness probe, the important setting is maxUnavailable: 0. This prevents any pod from being terminated before its replacement is ready:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # Allow one extra pod temporarily
    maxUnavailable: 0  # Never take a pod down before replacement is ready

With maxUnavailable: 0, rollout is slower (sequential) but guarantees capacity is maintained throughout.

The readiness probe trap

The readiness probe is what determines when a new pod is "ready" to receive traffic. A pod without a readiness probe is considered ready immediately after the container starts — before your application has actually finished initializing.

readinessProbe:
  httpGet:
    path: /ready  # Your app's readiness endpoint
    port: 8080
  initialDelaySeconds: 5   # Wait before first check
  periodSeconds: 10        # Check every 10s
  failureThreshold: 3      # 3 failures → not ready
  successThreshold: 1      # 1 success → ready

If your application takes 15 seconds to warm up (connect to database, load caches), but initialDelaySeconds is 2, Kubernetes marks the pod as not ready, counts 3 failures in 30 seconds, and the pod stays out of rotation. Set initialDelaySeconds conservatively.

The liveness probe is different: it kills and restarts a pod that fails it. Do not confuse the two:

• Readiness: should this pod receive traffic? Fails → pod removed from service, not restarted.
• Liveness: is this pod alive? Fails → pod restarted.

Why rollbacks fail silently

kubectl rollout undo reverts to the previous ReplicaSet. This looks like a rollback, but there is a common failure mode: if the previous version had a configuration issue (wrong image, bad env var), the "rollback" deploys the same broken configuration.

Worse: if the new version has a bug that causes it to start but immediately fail requests (crashing after init, returning 500 to the health check endpoint), the deployment succeeds — pods are running — but traffic is failing.

# Check rollout status
kubectl rollout status deployment/api-server

# View rollout history
kubectl rollout history deployment/api-server

# Roll back to previous revision
kubectl rollout undo deployment/api-server

# Roll back to a specific revision
kubectl rollout undo deployment/api-server --to-revision=3

The only reliable way to ensure a rollback works is a readiness probe that accurately reflects the application's ability to serve traffic. A probe that always returns 200 is worse than no probe — it gives false confidence.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
spec:
  minAvailable: 3  # always keep at least 3 pods running
  selector:
    matchLabels:
      app: api-server