Flagger: Progressive Delivery for Kubernetes

WHY IT EXISTS Standard Kubernetes rollouts can be an all-or-nothing risk. A single buggy deployment can bring down a critical service. Progressive delivery was created to de-risk this process by making releases gradual, observable, and automated.

THE MENTAL MODEL Think of Flagger as an automated SRE for your deployments. It watches for a new container image, then starts a controlled experiment: it diverts a small percentage of users to the new version, watches key metrics like error rates and latency, and runs tests. If all looks good, it slowly increases traffic. If not, it automatically rolls back, all without human intervention.

HOW IT WORKS Flagger is a Kubernetes operator configured via a Custom Resource. You define a 'Canary' object specifying the deployment to watch, the traffic-shifting steps (e.g., 'increase by 10% every 5 minutes'), and success criteria (e.g., 'request success rate > 99%'). Flagger then manipulates a service mesh (like Istio) or an ingress controller (like NGINX) to split traffic. It queries a monitoring system (like Prometheus or Datadog) to validate the release against your criteria. If metrics degrade at any point, Flagger aborts the rollout and reverts traffic to the stable version.

WHEN TO USE IT Use Flagger for critical, high-traffic services in Kubernetes where you need to eliminate deployment-related downtime. It's especially powerful in a GitOps workflow, where a code merge can trigger a fully automated, safe rollout managed by Flagger.

WHEN NOT TO USE IT For simple, non-critical applications or early-stage development environments, the overhead of setting up Flagger, a service mesh, and a monitoring stack may be overkill. A standard Kubernetes rolling update is often sufficient in these cases.

ONE CANONICAL EXAMPLE A team uses Flux CD for GitOps. A developer's commit triggers a CI pipeline to build a new image. Flux updates the Kubernetes Deployment with the new image tag. Flagger, watching this deployment, intercepts the change. It provisions a canary version, uses Istio to route 5% of traffic to it, and queries Prometheus for 5 minutes. If error rates are low, it increases traffic to 25%, then 50%, and finally 100%, at which point it promotes the canary and decommissions the old version.