Zero-downtime rollouts on Kubernetes

Shipping to production should feel boring. This note covers the minimum controls we use before calling a rollout “safe”.

Why rollouts fail#

Most outages during deploys are not “Kubernetes bugs”. They are missing readiness signals, aggressive pod disruption, or sudden traffic cutovers.

Signals that matter#

• Readiness must fail until the process can actually serve traffic.
• Liveness should restart stuck processes — not restart during warm-up.
• Startup probes buy time for heavy JVMs and migrations.

Math for capacity during a surge#

If baseline RPS is $R$ and peak multiplier is $k$, you need headroom roughly:

where $m$ is a safety margin (we usually start at $0.25$).

Example Deployment snippet#

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
        - name: api
          readinessProbe:
            httpGet:
              path: /readyz
              port: 8080
            periodSeconds: 5

Highlight the important bits:

// Focus the probe contract, not framework noise
export async function readyz(ctx: Context) {
  await ctx.db.ping(); 
  return ctx.json({ ok: true });
}

Checklist before promote#

1. PDB allows at least one healthy replica.
2. Migrations are backward compatible for one release.
3. Dashboards cover error rate, latency, and saturation.
4. Rollback path is rehearsed — not theoretical.

Closing#

Zero downtime is a product of discipline, not a single annotation. Start with probes and PDB; automate the rest.