Exercise: The Canary Path

1. Setup Canary: Apply a Flagger Canary object for the backend service in the develop namespace.
2. Trigger Update: Push an image tag change to Git.
3. Simulate Health: While the canary is analysis phase, generate healthy traffic using a load test tool. Verify that traffic weight increases (e.g., from 5% to 10%).
4. Trigger Rollback: During the next traffic step, simulate failure by calling the /status/500 route on the canary service.
5. Verify Revert: Observe Flagger detecting the error rate spike and automatically reverting traffic to 100% stable.

Core Exercises (Required)

1. Inspect Weight: Use kubectl get canaries -n develop to see the current traffic weight and status of your release.
2. PromQL Match: Find the PromQL query in your canary manifest and run it manually in Prometheus. Verify that it correctly identifies the error rate.
3. Event Trace: Use kubectl describe canary <name> to trace the timeline of a successful deployment and an automated rollback.

Challenge Exercise (Optional)

Canary Regression Detection: Deploy a canary release with intentionally degraded response times. Verify that Flagger’s Prometheus-driven analysis detects the regression and automatically aborts the rollout before it reaches full traffic.

Done When

You have completed this module when:

• You can explain the difference between a “Big-Bang” and “Progressive” deployment.
• You have successfully executed a canary deployment with at least 3 traffic steps.
• You have successfully triggered and verified an automated metric-driven rollback.
• You understand how Flagger interacts with Prometheus to gate traffic shifting.