Rollout strategies: rolling, blue-green and canary

What it is

Rolling: the Kubernetes documentation on Deployments describes the default strategy as creating new Pods and deleting old ones, with maxUnavailable and maxSurge (25 percent each by default) setting the lower bound of available Pods and the upper bound of additional Pods. Old Pods are terminated only once enough new ones are running. progressDeadlineSeconds flags a rollout that is not making progress, and kubectl rollout undo returns to the previous revision. While the rollout is in progress, both versions serve requests.

Blue-green: two complete environments exist, and traffic switches in a single step. Argo Rollouts implements this with an active service and an optional preview service. As soon as the new ReplicaSet is available, the controller points the active service at it and scales the old one down after scaleDownDelaySeconds. As long as the old one is still running, rolling back is just a matter of pointing the service back.

Canary: the new version receives a small percentage of production traffic. In Argo Rollouts this is a list of steps made up of setWeight (the share) and pause (a wait time or a manual approval), optionally backed by automated analysis of metrics. Without a traffic router, the controller approximates the share through replica counts: with ten replicas and ten percent, that means one new Pod and nine old ones.

Why it matters

The three strategies trade capacity against risk. Rolling needs hardly any spare capacity, but it forces the application to tolerate mixed versions for minutes at a time. Blue-green temporarily needs double the capacity and in return provides an instant switch and an instant rollback. Canary limits how many users see an error, but it requires a traffic split and a measurement signal that clearly separates good from bad within the observation window.

How to apply

• Get the basics right first: readiness probes that fail until initialization is finished; clean shutdown on SIGTERM; database changes following expand-contract, so that old and new versions can run side by side.
• Use rolling for stateless services with compatible versions; set maxUnavailable: 0 if capacity must not drop.
• Use blue-green when a version mix is ruled out (long-lived connections, incompatible caches) or when you want a dress rehearsal against real infrastructure.
• Use canary when an error only becomes visible under real traffic and a measurable signal exists; define the abort threshold before starting.
• Add feature flags as well: the rollout strategy decides which binary runs, the flag decides which behavior is active.

Pitfalls

Session stickiness, client caches and DNS TTLs make "switch everything at once" slower than planned. A canary with a few percent of traffic rarely sees rare errors, so the window must be long enough. Database migrations do not roll back along with the binary. On a single host without an orchestrator, all three can only be reproduced with extra tooling; the wiki has an open question on this.

What blue-green does not separate

Switching the service pointer separates only the processes. The database, caches, queues and the clients are shared by both environments: during scaleDownDelaySeconds (30 seconds by default in Argo Rollouts), blue is still handling in-flight requests while green is already writing, and browsers and mobile apps keep the old interface long after the switch. So blue-green does not rule out a version mix; it moves it from the server processes to the data layer and the clients. Expand-contract for schema changes and backward-compatible API responses remain mandatory for all three strategies. Blue-green pays off when the process state itself cannot tolerate a mix: long-lived connections, in-memory caches with a changed format, or a protocol change between components that are only shipped together. The instant rollback holds only as long as the old ReplicaSet is running; after that, going back is an ordinary rollout.