Towards Better Canary Releases With Flagger and Gateway API
summary
Demo shows Flagger plus Gateway API using cookie-based session affinity to turn weighted canaries into session-sticky canaries. It creates a primary cookie per analysis step (example progression 10% to 50% with 1m intervals and max-age ~60s) so users routed to V2 continue hitting V2, avoiding per-request bounce. Works on Kubernetes with clients that honor cookies; demo proves routing and cleanup succeed. Limits: Kubernetes-only and not suited for event-driven workloads.
AI-written summary · about
chapters (17)
- 0:00Introduction and thanks
- 0:21What is Flagger
- 1:28Progressive delivery modes
- 2:31Weighted routing explained
- 4:14Problem with random traffic
- 5:20Session affinity solution
- 7:07Combined strategy benefits
- 8:11How Flagger generates cookies
- 10:18Primary cookie for traffic control
- 13:12Demo introduction
- 15:09Deploying new application
- 17:17Flagger and non-Kubernetes setups
- 18:42Flagger limitations and API issues
- 19:48Flagger visibility and alerts
- 21:11Future of Flagger operator
- 21:54Event-driven workloads gap
- 22:37Q&A and closing
related talks
20mProgressive Delivery with the Kubernetes Gateway API
01h 04mThe Fine Art of Canary Deployments
33mProgressive Delivery Techniques with Flagger
16mProgressive Delivery with Flagger
13mCanary in the Internet Mine
34mSupercharge Your Microservices CI/CD with Service Mesh and Kubernetes
43mCanary Deploys with Istio: Lessons Learned
25mPushing Code: Don't Forget to Flag Your Canaries?