Canary, blue-green and rolling, drawn

Quick reference

Rolling update

• Replaces instances in batches
• No extra environment, needs surge capacity
• Rollback is another rollout, not instant
• The Kubernetes default for stateless apps

Blue-green

• Two identical environments, one router
• The switch sends all traffic at once
• Rollback is a switch back in seconds
• Costs double capacity at cutover

Canary

• A small share of real traffic goes first
• Compare errors and latency to stable
• Raise the share only when the numbers hold
• Needs traffic splitting and metrics

When each fits

• Rolling: stateless, schema-compatible
• Blue-green: instant switch, spare capacity
• Canary: high traffic, risky change, metrics
• All three need a signal you trust

Explained

Rolling

A rolling update replaces instances in batches. Kubernetes starts new pods, waits for readiness, then removes old ones, so versions overlap. It needs no second environment, only surge capacity, and the default is a quarter of the replicas at a time. Rollback is another rolling update in reverse, which is safe but not instant.

Blue-green

Blue-green runs two identical environments. Blue serves all traffic while green receives the new release and its smoke tests; then the router switches, and rollback is a switch back. The switch is instant, the cost is double capacity at cutover, and the shared database is where most plans meet reality.

Canary

A canary sends a small share of real traffic to the new version, compares error rate and latency against the stable baseline, then raises the share. That comparison needs traffic splitting and metrics good enough to separate signal from noise.

Choosing

Rolling fits stateless services with a compatible schema. Blue-green fits when the switch must be instant and you can pay for two environments. Canary fits high-traffic changes where a small exposure is cheaper than a big one.

In one line

Advance the canary

$kubectl argo rollouts promote api