A plain Kubernetes rolling update is fine for most changes, but it has one weakness: once the rollout finishes, every user is on the new version, and rolling back means another rollout. For risky releases, two strategies give you more control: blue-green and canary.
Blue-green: switch all traffic at once
Run the new version (green) next to the current one (blue), test it, then move the Service selector.
# two Deployments with different version labels
# account-search-blue labels: app=account-search, version=blue
# account-search-green labels: app=account-search, version=green
apiVersion: v1
kind: Service
metadata:
name: account-search
spec:
selector:
app: account-search
version: blue # change to green to cut over
ports:
- port: 80
targetPort: 8080
# cut over
kubectl patch service account-search \
-p '{"spec":{"selector":{"app":"account-search","version":"green"}}}'
# instant rollback
kubectl patch service account-search \
-p '{"spec":{"selector":{"app":"account-search","version":"blue"}}}'
Good for: releases you can fully test before exposure, and instant rollback. Cost: double capacity during the switch, and database changes must work for both versions.
Canary: shift traffic gradually
Send a small share of real traffic to the new version, watch metrics, then increase. Argo Rollouts makes this declarative:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: account-search
spec:
replicas: 10
selector:
matchLabels: { app: account-search }
template:
# same pod template as your Deployment
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 10m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
Without a service mesh or ingress integration, the weight is approximated by replica counts. With NGINX Ingress, Istio or a Gateway API controller, Rollouts can split traffic precisely. Add an AnalysisTemplate that queries Prometheus (error rate, p95 latency) and the rollout aborts and rolls back by itself when the canary looks worse than stable.
Good for: changes whose real-world behaviour you can't fully test. Cost: you need good metrics, and two versions serve users at the same time.
Which one should you use?
- Rolling update – the default for routine changes.
- Blue-green – big-bang releases, strict cut-over windows, or when you need instant rollback.
- Canary – high-traffic services where a small blast radius and metric-driven promotion matter.
Whatever you pick, make database migrations backward compatible (expand, then contract). That one discipline makes every strategy here safe to roll back.
