← back to blog
Kubernetes passing · 12 August 2026 · 6 min read

Zero-Downtime Kubernetes Deploys: The Checklist I Actually Use

KubernetesCI/CDReliability

Every platform team eventually learns the same lesson the hard way: a deploy that “should be fine” is not a deploy strategy. Here’s the checklist I hold every service to before it earns a spot in a production pipeline.

1. Readiness probes, not liveness probes, gate traffic

Liveness probes restart broken pods. Readiness probes decide whether a pod receives traffic at all. Conflating the two is the single most common cause of a rolling update that drops requests — the pod is technically alive, but not actually ready to serve.

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

2. maxUnavailable: 0 on anything customer-facing

The default RollingUpdate strategy will happily take capacity away before new capacity is ready. For anything serving live traffic, that trade is rarely worth it:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

3. A PodDisruptionBudget that matches your real minimum

Node drains, cluster autoscaling and spot reclamation don’t care about your deploy strategy — they’ll evict pods independently. A PodDisruptionBudget is what stops a routine node rotation from becoming an incident.

4. Pipeline gates before the rollout, not after

The pipeline stage order matters:

commit → build → test → policy gate → canary → full rollout → monitor

Policy gates (image scanning, admission control, SLO burn-rate checks) belong before traffic shifts, not as a retrospective. On a platform serving twenty-plus product teams, that gate is the difference between catching a bad image in CI and catching it in an incident channel.

5. Automate the rollback, not just the rollout

If rolling forward is automated but rolling back is manual, you’ve only automated half the risk. Wire your rollout controller (Argo Rollouts, Flagger, or a plain Deployment + automated kubectl rollout undo on SLO-breach) so a bad deploy reverts itself before a human is paged.

None of this is exotic. It’s boring, and that’s the point — boring is what lets you ship dozens of times a day without dreading Friday afternoons.