Deploying new versions without breaking production is hard. You want quick releases and feedback but minimal risk to users. Canary deployments solve this by shifting traffic gradually, validating changes under real load before a full rollout.
Kubernetes supports progressive delivery patterns, and tools like Flagger or ArgoRollouts make them safer and easier to operate. This post explains what canary deployments are, how they work in Kubernetes, and how to implement them with Flagger.
What Are Canary Deployments
A canary deployment introduces a new version of an application to a small portion of traffic first. If it performs well — passes health checks, meets latency and error thresholds, behaves as expected — traffic is increased step by step until the new version serves everyone.
If problems appear, you stop or roll back early, limiting impact to the small group of users who hit the canary.
This progressive approach reduces release risk and gives engineers fast feedback on how changes behave in production conditions.
How It Works in Kubernetes
Kubernetes supports basic rollout strategies natively. Deployments update pods gradually and can roll back if something fails. But a true canary needs traffic control and automated checks:
- Deploy the new version alongside the old one.
- Route a small percentage of traffic to it (using a service mesh or ingress controller).
- Watch key signals — error rates, latency, custom business metrics.
- Promote gradually if things look good; stop or roll back if they don’t.
Kubernetes alone doesn’t manage the traffic split or metric-driven decisions — that’s where tools like Flagger come in.
Flagger: Automating Progressive Delivery
Flagger is a Kubernetes operator that handles canary promotion and rollback automatically. It integrates with service meshes such as Istio, Linkerd, and AWS App Mesh, as well as ingress controllers like NGINX or Gloo.
With Flagger you define:
- Rollout steps — traffic increment percentages and wait intervals.
- Metrics — success criteria (e.g., HTTP error rate < 1%, latency < 500ms, custom Prometheus metrics).
- Thresholds — when to stop, rollback, or advance.
Flagger observes the canary in real time. If metrics hold steady, it shifts more traffic. If thresholds are exceeded, it halts or reverts automatically.
Typical Setup
- Install Flagger and a supported service mesh or ingress controller.
- Add Flagger custom resources (
Canary,MetricTemplate) to your app’s manifests. - Deploy the new version. Flagger detects it and starts the canary process.
- Monitor progress through metrics and Flagger’s status output.
- If healthy, Flagger promotes to 100% traffic; if not, it rolls back.
This approach turns what is normally a manual and risky change into a controlled, observable process.
Benefits of Canary Deployments
- Lower risk — catch bad releases before they hit everyone.
- Fast production feedback — validate real-world behavior quickly.
- Controlled rollbacks — revert early and automatically when metrics degrade.
- Safer user experience — limit exposure to bugs and instability.
Canary deployments give you a safer, more data-driven way to release on Kubernetes. The platform’s rollout primitives get you partway there, but tools like Flagger automate the hard parts — traffic shifting, monitoring, and rollback.
Start simple: pick a key service, define a few critical metrics, and let Flagger manage the rollout. Over time, you can expand canary patterns to more workloads and integrate them with your platform’s delivery pipelines.