Automating Canary Deployments with Flagger and Istio

Hey everyone, and welcome to a deep dive into modern deployment strategies! In today’s fast-paced software development landscape, releasing new features quickly and safely is paramount. Traditional “big bang” deployments can be nerve-wracking, often leading to customer-facing issues if something goes wrong.

This post, complementing our recent YouTube video and a comprehensive GitHub repository, will walk you through setting up automated Canary Deployments using two incredibly powerful open-source tools: Flagger and Istio. We’ll show you how to achieve seamless, risk-averse, and fully automated rollouts in your Kubernetes clusters.

Before we dive into the details, check out the video walkthrough:

What Exactly is a Canary Deployment?

Imagine releasing a new version of your application not to all your users at once, but to a small, isolated group first—like a “canary in the coal mine.” This small segment of traffic acts as an early warning system. If anything goes wrong—performance degradation, errors, or unexpected behavior—you detect it early, before it impacts your entire user base.

Unlike a simple rolling update (which gradually replaces instances) or a Blue/Green deployment (which switches all traffic at once), a canary strategy:

• Carefully shifts a tiny percentage of live traffic to the new version.
• Monitors its health rigorously using predefined metrics.
• Gradually increases traffic only if all checks pass.
• Automatically rolls back if checks fail, protecting users from potential issues.

It’s the ultimate risk mitigation strategy for continuous delivery, giving you confidence with every release.

Why Flagger and Istio? The Dynamic Duo

To orchestrate this delicate dance of traffic shifting and health checks, we need powerful tools:

• Istio: The Traffic Controller
  Istio, our service mesh, provides the intelligent routing capabilities that allow us to precisely direct small percentages of traffic to our canary pods. Think of it as the smart switchboard for your microservices, enabling fine-grained control over network traffic, including HTTP/TCP routing, retries, and circuit breakers.
• Flagger: The Automation Maestro
  Flagger is a progressive delivery tool that automates the release process for applications on Kubernetes. It observes your deployments, communicates with Istio to manage traffic routing rules, and continuously monitors performance metrics from Prometheus. Flagger automates the entire canary lifecycle: from initial traffic shift, through incremental promotion steps, to automated rollback if issues arise, or full promotion upon success.

Together, Flagger and Istio form a robust, automated deployment pipeline that significantly reduces manual effort and deployment risks.

Prerequisites

Before we jump into the setup, ensure you have the following:

• A Kubernetes cluster (version 1.20+ recommended).
• kubectl command-line tool configured to connect to your cluster.
• Helm 3 installed for package management.
• Istio service mesh installed and functional on your cluster. If you don’t have it, refer to Istio’s official documentation for installation instructions.
• A Prometheus instance integrated with Istio for metric collection. This is often part of a standard Istio installation or can be deployed via tools like kube-prometheus-stack.

For our demo, we’ll create a new namespace and enable Istio sidecar injection:

kubectl create namespace canary-demo
kubectl label namespace canary-demo istio-injection=enabled

Step-by-Step Implementation Guide

All the configuration files mentioned below are available in our GitHub repository. We highly recommend cloning it to follow along:

git clone https://github.com/aicoresynapseai/code.git
cd code/flagger-canary-demo

1. Install Flagger

Flagger is deployed via Helm, making its installation straightforward. First, add the Flagger Helm repository and update it:

helm repo add flagger https://flagger.app
helm repo update

Then, install Flagger into its dedicated namespace, typically `flagger-system`. The key parameters here are --set meshProvider=istio, which explicitly tells Flagger to integrate with Istio for traffic management, and --set metricsServer, which points to your Prometheus instance for metric queries.

helm install flagger flagger/flagger --namespace flagger-system --create-namespace \
  --set meshProvider=istio \
  --set metricsServer=http://prometheus-kube-prometheus-stack.monitoring:9090

Note: Adjust the metricsServer address if your Prometheus setup differs.

2. Deploy the Initial Application (v1)

We’ll deploy a simple web application called `podinfo`. This is our stable, version 1 (v1) application. We define the namespace, the deployment, and its service. Notice the `PODINFO_UI_COLOR: blue` environment variable, which helps us visually distinguish this version.

kubectl apply -f app/namespace.yaml
kubectl apply -f app/deployment-v1.yaml
kubectl apply -f app/service.yaml

Verify that your `podinfo-v1` pods are running:

kubectl get pods -n canary-demo

3. Exposing the Application with Istio Gateway & VirtualService

To make our `podinfo` application accessible from outside the Kubernetes cluster, we leverage Istio’s powerful networking capabilities. We define an Istio Gateway as the entry point and a VirtualService to route traffic for `podinfo.example.com`.

kubectl apply -f app/gateway.yaml
kubectl apply -f app/virtualservice.yaml

Initially, this VirtualService directs 100% of the traffic to our `podinfo` Kubernetes Service. Flagger will dynamically update this VirtualService during the canary deployment process to shift traffic between our stable (primary) and new (canary) versions.

4. Configure Flagger Canary for the Application

This is the heart of the automated canary process: Flagger’s `Canary` custom resource. By applying `flagger/canary.yaml`, we instruct Flagger on how to manage our `podinfo` application’s deployments.

kubectl apply -f flagger/canary.yaml

In this manifest, we:

• Specify `provider: istio`.
• Reference our `podinfo` Deployment, Service, Gateway, and VirtualService.
• Define the `analysis` section:
  • `interval`: How often Flagger checks metrics.
  • `threshold`: Number of failed checks before rollback.
  • `stepWeight`: Percentage of traffic to shift in each step (e.g., 10%).
  • `metrics`: Prometheus queries for `request-success-rate` (expecting 99% minimum) and `request-duration` (max 500ms). If these thresholds are breached, Flagger triggers an automatic rollback.

Flagger will now take control of your `podinfo` deployment. You’ll notice it creates a `podinfo-primary` deployment.

5. Trigger a Canary Deployment (Deploy v2)

With Flagger actively watching, triggering a new canary release is surprisingly simple. All you need to do is update your application’s deployment manifest with the new version. We’ll apply `deployment-v2.yaml`, which uses a new image and sets `PODINFO_UI_COLOR` to `green`.

kubectl apply -f app/deployment-v2.yaml

Flagger automatically detects this change. It immediately creates a new `podinfo-canary` deployment, scales it up, and then begins the step-by-step traffic shifting process defined in your `Canary` resource.

6. Observing the Canary in Action

Now comes the exciting part: observing the canary process in real-time. Use the following command to watch Flagger’s status updates:

watch kubectl get canary -n canary-demo

You’ll see the canary status transition from ‘Initializing’ to ‘Progressing’, and the percentage of traffic shift incrementally. Flagger meticulously monitors the defined metrics. If success rate drops or latency exceeds thresholds, Flagger automatically rolls back. If all checks pass, it promotes the new version, ensuring a safe rollout.

To generate traffic and see the metrics in action, you can continuously send requests to the application’s external IP/hostname. First, find your Istio ingress gateway’s external IP:

kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Then, use `curl` or a load generator to hit this IP with the appropriate host header:

INGRESS_IP=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -H "Host: podinfo.example.com" http://${INGRESS_IP}/

You can also view detailed logs from the Flagger controller for insights into its decision-making:

kubectl logs -f deploy/flagger -n flagger-system

Summary and Next Steps

Automating canary deployments with Flagger and Istio provides an incredibly robust and efficient way to release new software. It significantly reduces deployment risk, gives you real-time feedback on new versions, and automates the critical decision-making process of promotion or rollback based on objective metrics. This translates to faster, safer deployments and more confident teams.

We’ve demonstrated how Flagger leverages Istio’s traffic management and Prometheus’s monitoring insights to create a truly hands-free deployment pipeline. Beyond what we covered, Flagger offers advanced features like manual gates for human approval, custom metric integrations, and extensive webhook support for more complex pipeline integrations, fully embracing the spirit of GitOps and continuous delivery.

Cleanup

To remove all the resources created during this demonstration, simply run the provided cleanup script:

bash cleanup.sh

This script will systematically delete all application deployments, services, Istio resources, the Flagger Canary resource, and finally, the namespaces, ensuring a complete teardown of the demo environment.

Explore the Code and Contribute!

We encourage you to explore the full source code and manifests used in this demonstration. Fork the repository, experiment, and even contribute your improvements!

Explore the GitHub Repository

If you found this tutorial helpful, please give our YouTube video a like, share it with your colleagues, and subscribe to the channel for more deep dives into cloud-native technologies. Your support helps us create more content like this!