advanced~4h

Deployment Strategies: Rolling, Blue-Green, Canary & Argo Rollouts

Kubernetes native rolling update is one of several strategies. Blue-Green runs two full production environments simultaneously and switches traffic atomically. Canary routes a small percentage to the

Kubernetes native rolling update is one of several strategies. Blue-Green runs two full production environments simultaneously and switches traffic atomically. Canary routes a small percentage to the new version. Argo Rollouts extends native Kubernetes to implement Canary and Blue-Green with automated analysis.

Rolling update (native): gradually replaces old Pods with new. No duplicate environments, governed by maxUnavailable and maxSurge.
Blue-Green: both environments fully deployed simultaneously. Traffic switch is a Service selector update -- instantaneous. Double compute cost.
Canary: small replica count of new version receives a real traffic slice. Traffic splits by Ingress/mesh for precise control or replica ratio for coarse.
Argo Rollouts integrates with Prometheus for automated analysis -- if error rate rises during canary, automatically rolled back.

For native rolling update: set spec.strategy.type: RollingUpdate on the Deployment with maxUnavailable/maxSurge tuned to your risk tolerance -- this is the default and needs no extra tooling.
For Blue-Green: deploy the new version as a fully separate, complete environment (Deployment) alongside the old one, verify it independently, then switch traffic by updating the Service's selector to point at the new version's Pods -- an atomic cutover.
For Canary (manual): deploy a small number of new-version replicas alongside the stable version, split traffic between them (via replica-ratio or Ingress/mesh weighted routing), monitor, then gradually shift the rest.
For automated Canary/Blue-Green: install Argo Rollouts and replace the Deployment with a Rollout resource defining canary/blueGreen strategy steps (e.g. set weight, pause, analyze).
Define an AnalysisTemplate referencing a Prometheus query (e.g. error rate) that Argo Rollouts evaluates automatically at each step, promoting or auto-rolling-back based on the result.
Watch progress with kubectl argo rollouts get rollout <name> (or the Argo Rollouts dashboard) instead of kubectl rollout status.

A routine low-risk backend service update using native rolling update with default maxUnavailable/maxSurge -- no extra tooling needed.
A payment-processing service using Blue-Green deployment so the new version is fully verified in a live-identical environment before an instantaneous, easily-reversible traffic cutover.
A high-traffic public API using Argo Rollouts canary with automated Prometheus-based analysis, so a bad release is automatically rolled back within minutes of error rate rising, before most users are affected.
A mobile backend gradually shifting traffic percentage (5% -> 25% -> 50% -> 100%) to a new version via Ingress-level weighted canary routing, verified manually at each step before proceeding.
A team choosing native rolling update for internal tooling but Blue-Green for the customer-facing checkout service where instant, safe rollback matters more than infrastructure cost.

Default to native rolling update for most workloads -- reserve Blue-Green and Canary for services where the extra safety is worth the added infrastructure and operational complexity.
Always pair Canary deployments with real automated analysis (Argo Rollouts + Prometheus) rather than a human watching a dashboard for a fixed number of minutes.
For Blue-Green, keep the old ('blue') environment running for a defined soak period after cutover before tearing it down, so instant rollback stays available.
Choose traffic-splitting mechanism deliberately: Ingress/mesh-based weighted routing gives precise percentage control; replica-ratio-based canary is coarser but needs no service mesh.
Tune canary step count and pause duration to genuinely catch regressions rather than moving through steps too fast to catch anything.
Budget for Blue-Green's double compute cost explicitly -- it's a real, ongoing infrastructure expense, not a one-time setup cost.

Using Blue-Green for a workload where the extra compute cost isn't justified by the actual risk profile -- doubling infrastructure spend for a low-risk internal service.
Running a 'canary' with no automated analysis at all -- just a manually-watched percentage split with no rollback trigger tied to real metrics, so a slow regression is easy to miss.
Setting canary steps that move too fast (e.g. jumping straight to 100%) to give either humans or automated analysis meaningful time/traffic to detect a problem.
Forgetting that a native rolling update has no traffic-splitting concept at all -- assuming you get canary-like gradual exposure control when you're actually just doing a straightforward Pod-by-Pod replacement.
Not defining a clear automated rollback condition (AnalysisTemplate threshold) for Argo Rollouts canaries, so a degrading metric doesn't actually trigger anything until a human notices.
Switching a Blue-Green Service selector back and forth repeatedly during testing without confirming both environments are actually fully healthy first.

Blue-Green's traffic cutover (a Service selector change) is effectively instantaneous at the networking layer, but only as fast as new-environment readiness allows -- factor in full environment warm-up time (caches, connection pools) before considering it ready for 100% of traffic.
Canary analysis step duration is a direct trade-off between deployment speed and detection confidence -- too short a window under real traffic won't accumulate enough samples for a statistically meaningful automated decision.
Argo Rollouts' automated analysis adds a Prometheus query round-trip at each step -- keep AnalysisTemplate queries cheap and targeted so the rollout isn't gated on slow, expensive PromQL.
Rolling update's maxSurge directly trades deployment speed for extra transient resource consumption -- a higher maxSurge finishes faster but needs more spare cluster capacity during the rollout.

Treat canary analysis thresholds as tuned, reviewed configuration -- an overly loose threshold lets real regressions through, an overly tight one causes false-positive rollbacks that erode trust in automation.
Keep the previous stable ReplicaSet/environment available and quickly reachable for rollback across all three strategies -- verify rollback actually works in a drill, not just in theory.
For Blue-Green, automate the old-environment teardown on a delay (not immediately on cutover) so a delayed-symptom regression still has a fast, verified-safe rollback path.
Integrate Argo Rollouts' rollout status/analysis result into CI/CD gating (not just watched manually) so a failed canary blocks the pipeline the same way a failed test would.

Configure a Deployment's rollingUpdate strategy with a specific maxUnavailable/maxSurge and watch the rollout with kubectl rollout status while updating the image.
Manually implement Blue-Green: deploy two full Deployments (v1, v2) with a Service selector pointed at v1, then flip the selector to v2 and confirm instant traffic switch.
Install Argo Rollouts, convert a Deployment to a Rollout with a canary strategy (steps: setWeight 20, pause), and trigger a rollout to watch it pause at 20% traffic.
Define an Argo Rollouts AnalysisTemplate against a Prometheus error-rate query, trigger a deliberately-broken rollout, and confirm it's automatically rolled back.

Rolling update: native, incremental Pod replacement with no duplicate environment.
Blue-green: two full environments simultaneously, atomic traffic switch, instant rollback at double compute cost.
Canary: small real-traffic slice, gradual increase with measurement; precise splitting needs Ingress/mesh.
Argo Rollouts adds metric-gated promotion and automated rollback, replacing Deployment for advanced strategies.

Want a visual for this concept?

Generate a diagram tailored to “Deployment Strategies: Rolling, Blue-Green, Canary & Argo Rollouts” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to CI/CD & GitOps: Jenkins, GitHub Actions & ArgoCD →← Back to all Kubernetes chapters