Why Not Just Roll Forward?
A standard Kubernetes rolling update replaces old pods with new ones gradually, but all traffic still eventually reaches the new version with limited control over exposure and rollback speed. Blue-green and canary deployments give operators finer-grained control: blue-green enables an instant, atomic cutover (and instant rollback), while canary exposes the new version to a small percentage of real traffic first, limiting the blast radius of a bad release.
Cricket analogy: Instead of gradually resting bowlers, a captain could bench the whole XI for a fresh side after a warm-up (blue-green) or bring on one debutant while nine trusted players continue (canary), controlling risk before a Test match.
Blue-Green Deployment with Two Deployments and a Service Selector
In Kubernetes, blue-green is implemented by running two independent Deployments ('blue' = current production, 'green' = new version) simultaneously, each with its own label (e.g. version: blue / version: green). A single Service selects pods by label. To release, you deploy 'green' fully, run smoke tests against it directly (e.g. via a temporary Service or port-forward), and then switch traffic by updating the Service's selector to version: green. Rollback is just flipping the selector back to version: blue.
Cricket analogy: Like fielding two full playing XIs labeled 'Squad A' and 'Squad B' in the dugout, the team-sheet (Service selector) simply names which squad takes the field; reverting is just re-naming the sheet back to Squad A.
# blue deployment (currently live)
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-blue
spec:
replicas: 4
selector:
matchLabels:
app: api
version: blue
template:
metadata:
labels:
app: api
version: blue
spec:
containers:
- name: api
image: ghcr.io/org/api:v1.4.0
---
# green deployment (new version, deployed alongside blue)
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-green
spec:
replicas: 4
selector:
matchLabels:
app: api
version: green
template:
metadata:
labels:
app: api
version: green
spec:
containers:
- name: api
image: ghcr.io/org/api:v1.5.0
---
# service currently points at blue; cut over by patching the selector to "green"
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
version: blue # change to "green" to cut over instantly
ports:
- port: 80
targetPort: 8080Cutover command: kubectl patch service api -p '{"spec":{"selector":{"app":"api","version":"green"}}}'. Because the selector change is atomic at the Service/endpoints level, the switch is effectively instant, and rolling back is the same command with 'blue' substituted back in.
Canary Deployment via Replica-Weighted Rollout
A simple canary in vanilla Kubernetes uses two Deployments sharing the same Service selector (e.g. both labeled app: api), where the proportion of traffic each version receives is approximated by the ratio of ready replicas, since a Service load-balances round-robin across all matching endpoints. For example, 9 replicas on the stable version and 1 on the canary approximates a 90/10 split. This is coarse-grained — precise percentage control requires a service mesh or an ingress controller with traffic-splitting support (e.g. Istio VirtualService, Linkerd, or NGINX/Traefik canary annotations).
Cricket analogy: Selecting 9 seasoned bowlers and 1 rookie into the same attack roughly gives the rookie about a tenth of the overs by chance, a rough approximation; exact over-allocation needs a dedicated bowling plan (a service mesh), not luck.
# Istio VirtualService: precise weighted traffic split for canary
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api
spec:
hosts:
- api
http:
- route:
- destination:
host: api
subset: stable
weight: 90
- destination:
host: api
subset: canary
weight: 10Progressive Delivery and Automated Rollback
Tools like Argo Rollouts and Flagger extend canary deployments into 'progressive delivery': they automatically shift traffic in small increments (e.g. 5% -> 20% -> 50% -> 100%), pausing at each step to query metrics (error rate, latency p99) from Prometheus or a similar backend, and automatically roll back if thresholds are breached — removing the need for a human to babysit each step.
Cricket analogy: Like a captain gradually increasing a young bowler's overs each match (5%, then 20%, then 50%, then a full spell) while an analyst checks the economy rate and strike rate after every spell, pulling them out automatically if figures blow out.
Blue-green doubles resource consumption during the overlap window since both full environments run simultaneously — budget cluster capacity accordingly. Canary deployments require the new and old versions to be backward-compatible at the data layer (e.g. shared database schema), since both versions serve traffic concurrently during the rollout. Choose blue-green when you need an instant, all-or-nothing cutover with the fastest possible rollback (e.g. major version bumps or schema-sensitive releases); choose canary when you want to limit blast radius by validating a release against a small slice of real production traffic before a full rollout.
- Blue-green uses two full Deployments and cuts over instantly by changing the Service selector; rollback is just reverting the selector.
- Vanilla Kubernetes canary approximates traffic split via the ratio of ready replicas across two Deployments sharing one Service.
- Precise, non-replica-count traffic splitting requires a service mesh (Istio, Linkerd) or canary-aware ingress controller.
- Argo Rollouts and Flagger automate progressive delivery with metric-based analysis and automatic rollback.
- Blue-green temporarily doubles resource usage; canary requires backward-compatible data layers during the overlap.
Practice what you learned
1. How is traffic cut over in a Kubernetes blue-green deployment?
2. In a vanilla Kubernetes canary (no service mesh), how is the approximate traffic split controlled?
3. What capability do tools like Istio or Linkerd add to canary deployments beyond vanilla Kubernetes?
4. What is a major resource cost consideration specific to blue-green deployments?
5. What do progressive delivery tools like Argo Rollouts or Flagger add to canary releases?
Was this page helpful?
You May Also Like
Rolling Updates and Rollbacks
Learn how Kubernetes Deployments update Pods gradually with zero downtime and how to roll back safely when a release breaks.
Services and Networking
Understand how Kubernetes Services provide stable networking identities and load balancing for ephemeral, dynamically scheduled Pods.
Deployments and ReplicaSets
Learn how Deployments manage ReplicaSets to declaratively run, scale, and update stateless Pod replicas in Kubernetes.
CI/CD Pipelines for Containers
How to design continuous integration and delivery pipelines that build, test, scan, and deploy containerized applications to Kubernetes.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics