Zero-Downtime Deployments with Kubernetes & ArgoCD

Downtime Is Usually a Design Choice

Rolling updates make most outages optional. The incidents we have seen came from the assumptions around the rollout — connection draining, schema changes, and readiness — rather than from the strategy itself.

Strategies We Run in Production

Each one earns its complexity only for certain kinds of services, and we pick per workload rather than cluster-wide.

• Rolling update as the default for stateless HTTP services
• Blue-green when a release must be reverted in one action
• Canary with metric-based promotion for anything touching payments
• Feature flags to decouple deploying from actually releasing
• Database migrations written to run against both versions at once

Operational Habits That Matter

The tooling is rarely the missing piece; the discipline around it usually is.

• A readiness probe that reflects real dependency health, not a TCP port
• Termination grace periods longer than the slowest in-flight request
• Pre-stop hooks so connections drain before the pod leaves the load balancer
• Pod disruption budgets declared alongside the deployment, not after it
• ArgoCD sync windows that match when the on-call team is awake