Progressive Delivery with Flux & Flagger

Progressive Delivery with Flux & Flagger Max Körbächer - Kubernetes & Cloud Native Advocate

Speaker Max Körbächer Kubernetes & Cloud Native Advocate Working @ Storm Reply K8s Release Team Comms Shadow Get connected: ● ● ● Linkedin /maxkoerbaecher Twitter /mkoerbi Github /mkorbi

Where are we now? CI/CD, DevOps, Agile and Co. icons by Eucaly/happy Agile CI/CD DevOps focused on process focused on software life-cycle focused on culture highlighting change highlighting tools highlighting roles accelerating delivery accelerating automation accelerating responsiveness

The complexity of full/high automation

The complexity of full/high automation Where we want to focus on

The complexity of full/high automation Where we have an impact on

The complexity of full/high automation The blast radius

What is the problem? Rolling Updates 1 The de facto standard of release strategies. Gives you no/less control of the rollout speed. No way back Once started, a rollout is hard to stop and even harder to rollback. This requires in nearly all cases several major manual steps. 2 Liveness/Readiness Probes 3 Liveness and readiness probes are best practice to use and helpful for the lifecycle management from K8s perspective. But they don’t deliver deep insights or can use external metrics.

“Progressive delivery is continuous delivery with fine-grained control over the blast radius.” — James Governor, RedMonk Photo by Jeremy Perkins on Unsplash

Progressive Delivery The next level of deployments Progressive delivery requires high automation and rollback capabilities Key element, and mostly identified with traﬃc shifting between different versions of the same application It utilizes controlled methods like canary or blue/green deployment Most powerful way to use: feature toggling - enable, disable or hide features

Progressive Delivery The next level of deployments Progressive deliver is often called “advanced deployment”, as it requires high automation Service Meshes - Key element, and mostly identified with traﬃc shifting between different versions of the same application Actively managing the traﬃc within a K8s cluster, allows isolation, tracing and shifting traﬃc mainly implemented by It utilizes controlled methods like canary or blue/green deployment Observability - Most powerful way to use: feature toggling - enable, disable or hide features Combining logs, metrics and tracing for deep insights of an application, function or component

In other words

In other words images

In other words images Progressive Delivery! X

What can I do with with PD? And how does it effect me? I “pay” for: ● ● ● ● auto. rollbacks with failing updates be precises when an update is failing and when it is successful utilize extern, in depth metrics using different versions or configurations of an application

What can I do with with PD? And how does it affect me? I “pay” for: ● ● ● ● auto. rollbacks with failing updates be precises when an update is failing and when it is successful utilize extern, in depth metrics using different versions or configurations of an application I get: ● ● ● ● end-to-end deployment of an application (and this time truly!) reducing/eliminating blast radius GitOps in heart, no pipeline dependencies Pure control based on metrics and configurations

Flux & Flagger GitOps - Progressive Delivery Flux Declarative description in Git Automate Deployment from a cluster not a pipeline Push and sync code

Flux & Flagger GitOps - Progressive Delivery Flux Declarative description in Git Flagger Implements deployment strategy for automatic release process Automate Deployment from a cluster not a pipeline Can query metrics to gather feedback Push and sync code Run tests for conformance