Zero-Downtime Deployments on Kubernetes: A Complete Guide

"We deploy at 2 AM to be safe" is an admission that your deployment process is broken. Kubernetes gives you everything needed to ship at 2 PM on a Tuesday — if you configure four things correctly.

1. Rolling update strategy

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # one extra pod during rollout
    maxUnavailable: 0  # never drop below desired count

maxUnavailable: 0 is the key line — Kubernetes will only remove an old pod after a new one is fully ready.

2. Readiness probes that tell the truth

The single most common cause of deployment blips: pods receiving traffic before the app inside can serve it. A readiness probe must check real dependencies (DB connection, cache warm), not just "the process started".

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

3. Graceful shutdown

When a pod terminates, kube-proxy needs a moment to remove it from endpoints. Without a preStop hook, in-flight requests die. Give the app time to drain:

lifecycle:
  preStop:
    exec:
      command: ["sleep", "10"]
terminationGracePeriodSeconds: 30

4. PodDisruptionBudgets for node drains

Deployments aren't the only disruption — node upgrades and spot interruptions evict pods too. A PDB guarantees a minimum availability during voluntary disruptions:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api

Going further: canary releases

Once rolling updates are boring, graduate to canary: route 5% of traffic to the new version, watch error rates and latency, then promote automatically. Argo Rollouts does this natively and integrates with Prometheus metrics for automated analysis — a rollout aborts itself if the canary's error rate spikes. That's the end state: deployments so safe they are boring.