Rollouts

The problem

Replacing every container at once is honest and cheap: the deployment is briefly down, and everybody knows it. Replacing them one at a time is what most people want — but it is only safe when three things are true, and each of them is easy to assume.

The new copy has to be observably ready, or traffic moves to something that is not serving. Two versions have to be able to run side by side, or the “graceful” rollout corrupts shared state. And the thing being handed over has to be something two copies can share at all: a read-write volume or a published port on the node is not.

How the platform solves it

The default replaces everything at once, because that is the only strategy with no preconditions.

Anything gentler has to state its preconditions and be checked against them. A gradual rollout is refused unless the deployment carries a health check that actually runs, unless it does not hold a read-write volume or a published node port, and unless you have declared in the description that two versions may briefly coexist. That declaration is never inferred: the platform cannot know whether your application tolerates it, and guessing wrong is a data problem rather than an availability problem.

The precondition on health is why an inert probe mattered so much. The check for it is a presence check — so before probes that do nothing were refused outright, a deployment could satisfy the readiness requirement while having no probe at all. See health checks and process reaping.

A rollout is bounded in time and has a stated failure action. How long a copy may take to become healthy, how long it must stay healthy before the next step, how long the whole rollout may take, and what happens when it does not finish are all fields you set — with defaults in the deployment reference.

A weighted rollout is a routing change. Sending a fraction of traffic to a new version requires the deployment to be routed at all, because the weights are applied at the routing edge.

Not this

This page does not list the strategies, the field names, the defaults or the exact preconditions. They are in the generated reference and in the refusal you get if you break one.

It also does not cover rolling back a promotion of the platform itself, which is an operational runbook rather than a property of a deployment.

Where to see it

• The update block, field by field: deployment manifest.
• Why a rollout was refused, by code: rejections and alterations.