TT Lab
Get started
Learn Learning paths Courses

CAPA — Argo Project Associate

Watch a Canary Actually Roll

Continue in TT Lab

This lab runs on real Argo Rollouts

Inside the VM, the Rollouts controller is actually running. Pods really come up, the analysis starts a Job and judges, and when it fails it actually rolls back.

The Rollouts labs in the earlier module ran on a fake cluster. Since Pods did not come up, you could not see what percentage the canary was, and above all the analysis did not run — the analysis starts a Job and judges from its result, and since the Job did not run, there was no judgment at all. Automatic rollback is the heart of CAPA, and it was missing entirely.

It takes about 3 minutes to come up the first time.

What is prepared

네임스페이스   demo
컨트롤러       argo-rollouts 네임스페이스
CLI            kubectl argo rollouts
미리 받은 이미지 argoproj/rollouts-demo 의 blue · yellow · red, busybox:1.36

The Korean text in this code block says, in order, that the namespace is demo, that the controller is in the argo-rollouts namespace, that the CLI is kubectl argo rollouts, and that the pre-pulled images are the blue, yellow, and red images of argoproj/rollouts-demo plus busybox:1.36.

Goal

From a canary through automatic rollback, you confirm by actually running it.

Steps

  1. Create a Rollout and capture in /root/capa/first.txt how the first deployment is different.
  2. Change the image and capture in /root/capa/canary.txt that the canary shows up as an actual Pod count.
  3. Advance what has stopped and capture the record in /root/capa/promote.txt.
  4. Attach a successful analysis and capture in /root/capa/analysis.txt that it passes.
  5. Trigger an automatic rollback with a failing analysis and capture it in /root/capa/rollback.txt.
  6. Capture the difference between abort and undo in /root/capa/abort.txt.
  7. Capture in /root/capa/bluegreen.txt that two versions run at the same time with blue-green.
  8. In /root/capa/report.md, write the three lines canary_pods=, auto_rollback=yes, and bluegreen_paused=yes, plus an explanation.

Notes

The first deployment skips the canary

Create a Rollout and capture in /root/capa/first.txt how the first deployment is different.

Without a stable version to compare against, there is no traffic to split either.

How many Pods is 25%?

Change the image and capture in /root/capa/canary.txt that the canary shows up as an actual Pod count.

The weight is a traffic ratio, but without traffic routing it is approximated by the Pod count.

Advance what has stopped

Advance what has stopped and capture the record in /root/capa/promote.txt.

promote advances one step, and promote --full advances all the remaining steps.

Have it judge in place of a person

Attach a successful analysis and capture in /root/capa/analysis.txt that it passes.

The job provider of an AnalysisTemplate starts a Job and judges by its exit code.

If it fails, it goes back on its own

Trigger an automatic rollback with a failing analysis and capture it in /root/capa/rollback.txt.

If the analysis fails, the Rollout becomes Degraded and goes back to the stable version. The spec stays as it is.

abort and undo are different

Capture the difference between abort and undo in /root/capa/abort.txt.

One reverts only the traffic, and the other reverts the spec too.

Two versions run at the same time

Capture in /root/capa/bluegreen.txt that two versions run at the same time with blue-green.

If you create activeService and previewService, the controller adjusts the selectors for you.

What did you learn?

In /root/capa/report.md, write the three lines canary_pods=, auto_rollback=yes, and bluegreen_paused=yes, plus an explanation.

Write the three lines canary_pods=, auto_rollback=yes, and bluegreen_paused=yes, plus an explanation.