Rolling, blue-green and canary deployments compared

What it is

Rolling update: the Kubernetes Deployment documentation (cited) describes the default strategy as creating new Pods and deleting old ones within two bounds, maxUnavailable and maxSurge (both 25 percent by default); it does not kill old Pods until a sufficient number of new Pods have come up, and progressDeadlineSeconds marks a rollout that stalls. Both versions serve traffic during the rollout.

Blue-green: two complete stacks exist; traffic is switched from the active one to the new one in a single step. The Argo Rollouts documentation (cited) implements this by pointing an active Service and an optional preview Service at different ReplicaSets and, once the new ReplicaSet is available, modifying the active service to point at it, then scaling the old set down after a delay.

Canary: the new version receives a small percentage of production traffic, which is raised in steps. Argo's canary strategy (cited) expresses this as a list of setWeight and pause steps, optionally gated by automated analysis of metrics.

Why it matters

The strategies trade capacity against risk. Rolling needs little extra capacity but forces the application to tolerate mixed versions for minutes; blue-green needs double capacity briefly but gives an instant switch and an instant rollback while the old stack still runs; canary limits the number of users exposed to a defect but needs traffic splitting and a metric that reliably distinguishes good from bad within the observation window.

How to apply

• Make every strategy possible first: readiness checks that fail before the process is ready, graceful shutdown on SIGTERM, backward-compatible database changes and API responses so that old and new versions coexist.
• Use rolling for stateless services with compatible versions; tune maxUnavailable: 0 when capacity must not dip.
• Use blue-green when a version mix is unacceptable (long-lived connections, incompatible caches) or when a rehearsal against real infrastructure is wanted before the switch.
• Use canary when a defect would only show under real traffic and a measurable signal (error rate, latency, business metric) exists; define the abort threshold before starting.
• Combine with feature toggles: a deployment strategy controls which binary runs, a toggle controls which behaviour is on.

Pitfalls

Session stickiness, client caches and DNS TTLs make "switch traffic at once" slower than expected. A canary that receives a small share of traffic sees rare errors rarely, so its window must be long enough to be conclusive. Database migrations do not roll back with the binary.

Blue-green does not isolate shared state

Blue and green share the database, the queue and every other backing service, so from the moment the new stack starts (health checks, warm-up, rehearsal traffic) both versions read and write the same data, and after the switch the old stack stays connected for the rollback window. The version mix that blue-green removes is therefore only the process-local kind: in-memory caches, sticky sessions, long-lived connections, incompatible on-disk formats inside the instance. Schema and message-format changes need the same expand-and-contract discipline as a rolling update, and the instant rollback holds only until the new version has written something the old one cannot read. Choose blue-green for process-local incompatibilities or for a rehearsal against real infrastructure; do not choose it to avoid backward-compatible data changes.