Visualizing Canary Rollouts with Istio and Helm
summary
Demonstrates a Helm-based pipeline that uses Istio to split traffic and a Codefresh step to increment canary percentages (demo uses Codefresh). Deploys a color-coded app (open-source) with a clickable failure injection, sends 35% traffic to the canary, runs health checks on each increment, and automatically removes the failing version and rolls back when pods crash. Shows Helm releases as rollbacks, containerized pipeline steps, and how to inspect the failing commit and image.
AI-written summary · about
chapters (37)
- 0:00Introduction
- 0:39Dan Garfield
- 1:22What is Istio
- 2:09What is a Canary
- 2:25How a Canary works
- 3:06Canary is not about testing
- 4:55Microservices
- 7:19Usefulness
- 8:06The ultimate goal
- 9:50Helm
- 10:20Kubernetes
- 10:43How Istio works
- 11:49Helm chart
- 12:27A Helm chart
- 12:46How should this work
- 13:08How does Helm work
- 13:26What percentage of traffic to send
- 13:57Pipeline
- 14:23Demo Time
- 14:55Canary
- 15:57dashboard
- 16:17Emacs
- 16:34Yellow
- 17:35Home Page
- 17:50Canary Release
- 19:07Crash Loopback
- 19:17Health Check
- 19:59Demo
- 21:48Fix
- 22:21Traffic increment
- 22:40Kubernetes Plane
- 23:38Build
- 23:52Traffic Flow
- 24:02Pro Tip
- 24:33Twitter
- 24:50Free Images
- 25:04QA
related talks
26mCanary Deploys with Kubernetes, Istio and Envoy
43mCanary Deploys with Istio: Lessons Learned
01h 04mThe Fine Art of Canary Deployments
32mReducing Deployment Risks with Progressive Automated Canary and Spinnaker in a Reg...
36mProgressive Delivery in the Kubernetes era
40mProgressive Delivery with Kubernetes and Argo Rollouts
01h 06mIstio on Kubernetes: Smart Canaries, Dark Launches and Chaos
10mLightning Talk: Open Source Canary Deployments with Application Metric Analysis