Kubernetes Deployment Strategies: Rollouts That Don't Wake SRE
Recreate, rolling, blue-green, canary. How to pick the right Kubernetes deployment strategy — and what can go wrong with each one.
Deployments are where Kubernetes shows its teeth. A Pod that restarts is fine; a version your customers hate for 20 minutes is not. Here's how the four main strategies behave and when to use each.
Recreate
The simplest strategy: kill everything, start the new version. One API call, zero complexity — and guaranteed downtime.
Use it when: stateful workloads that cannot run two versions, weekly maintenance windows with explicitly scheduled downtime.
strategy:
type: Recreate
RollingUpdate (the default)
Kubernetes kills and creates Pods in waves. It is the correct default for most services.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
The trap: rolling updates judge success by whether the container starts, not whether the app works. Bad code ships 100% of the way through a rolling update over minutes — while your metrics quietly go red.
Blue-green
Two full stacks exist at once; you switch the router between them. Instant rollback: flip the router back.
The trap: double the infrastructure cost, and you must validate the "green" environment with real traffic before cutting over — otherwise you only confirm the blue environment was fine.
Canary
Send 5% of traffic to the new version, watch metrics, then step up to 25%, 50%, 100%.
The modern way is progressive delivery with Argo Rollouts:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 10m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
The trap: canaries multiply your debugging surface. You need metrics that can distinguish this version's errors from everyone's normal noise, or the canary never "looks healthy."
The questions that decide for you
| Question | If yes → |
|---|---|
| Can two versions run side by side? | Blue-green or canary |
| Do you have error-rate + latency telemetry? | Canary |
| Is rollback truly instant (DB migrations reversible)? | Blue-green |
| Do you run a weekly maintenance window? | Recreate is acceptable |
The thing teams forget: data
Every strategy above assumes your schema works with both versions. A forward-only DB migration poisons every strategy at once. Run migration as part of the release, test rollback migrations in CI, and keep migrations additive for at least one release cycle.
Summary
Pick rolling for default services, canary when you have trustworthy telemetry, blue-green when rollback must be instant, and recreate only when you genuinely can't overlap versions. Then — please — test the out-of-the-box scenario: what happens when the canary looks bad? Drill it.