Argo Rollouts canary steps

A rollout is a controlled change

Argo Rollouts adds a Rollout resource and controller for strategies such as canary and blue-green. Argo CD can deliver its desired configuration; the Rollouts controller manages the progression. They have different jobs.

A basic canary without an integrated traffic router approximates exposure using replica counts. With two replicas, a 50% step is a useful teaching arrangement; a 1% setting cannot guarantee 1% of requests. Connections, client behavior, and Service balancing also affect observed traffic.

Compare rollout strategies by the decision they make

A normal rolling update replaces instances gradually according to availability/capacity settings. Blue-green prepares a second environment/version and switches the selected traffic path. A canary exposes a candidate in stages and uses observations to decide whether to continue. Each requires a data-compatibility and recovery plan; running two versions is not automatically safe for a shared database.

In this local model, the stable revision is the known-good Pod template. A candidate is a new template that has not yet completed promotion. A pause provides time to inspect it. An analysis step collects defined evidence. Promotion advances the rollout; abort stops that attempted progression. Argo CD chooses and applies desired configuration, while Argo Rollouts handles these release steps.

Paper rehearsal: draw the first baseline revision A, then candidate B. At the pause, a request through the stable-only Service reaches A. Even if it passes, that says nothing about B. Point a second Service at B and run the saved-case read there. A failed assertion must stop promotion; a test that could not run provides no passing evidence. After recovery, the stable path needs another check using the same saved transaction.

With two desired replicas, replica arithmetic is coarse. Without a traffic router, a step percentage cannot establish the exact fraction of requests processed by B. This lab's stable/candidate Services deliberately select revisions, so its direct candidate check is the evidence of interest.

Keep a MicroBank baseline first

Before adding a candidate, the baseline must pass its transaction check. Initial creation has no previous stable revision and does not exercise a meaningful old-versus-new canary. Create a second image/revision only after the first is healthy.

In the progressive-delivery lab, use a candidate-specific Service to check Ledger’s HTTP read behavior during a canary rollout. Keep Accounts at one replica: its inspected outbox publisher does not establish safe multi-publisher coordination. Do not infer concurrency safety from a successful sequential probe.

Ledger's candidate shares the disposable database and queue with stable Ledger. This teaches how rollout components work together. Schema isolation and safe database evolution need separate designs and tests. Avoid migrations and concurrent write-load experiments. The lab uses an existing case for read-only candidate verification.

Checkpoint

Draw the stable Service, candidate Service, Rollout, and AnalysisRun. Identify which endpoint the analysis calls. A passing request to the stable Service says nothing about the candidate. Record the limitations of replica-based weighting and shared dependencies before considering managed-cloud traffic routing in the later platform path.

Checkpoint answer: the Rollout references the analysis, the AnalysisRun records an evaluation, and its Job calls the candidate Service. Check the selected Pod hash before interpreting the result. The next bite introduces repeatable synthetic checks; scheduling a check and gating a release will remain separate operations.

Sources

Argo Rollouts canary strategy↗, traffic management↗, and MicroBank Ledger source↗.