Creating Canary Deployments with Flagger in Kubernetes

Shipping code straight to production is fast—until it isn’t. One bad release can take down your service, and rollback isn’t always instant. This is exactly where canary deployments come in, and tools like Flagger make the process automated, observable, and far less stressful.

In this guide, we’ll walk through how to create canary resources with Flagger, and where Jenkins fits into the picture for triggering and managing deployments.

What Flagger Actually Does

Flagger is a Kubernetes operator that automates progressive delivery. Instead of pushing 100% of traffic to a new version, it gradually shifts traffic while monitoring metrics.

Under the hood, Flagger:

• Creates and manages canary resources
• Shifts traffic incrementally (via Istio, Linkerd, NGINX, etc.)
• Evaluates metrics like error rate and latency
• Rolls forward or rolls back automatically

It turns deployment risk into a controlled experiment.

Quick Look: A Canary Resource

Here’s a minimal Flagger Canary resource definition:

1apiVersion: flagger.app/v1beta1
2kind: Canary
3metadata:
4  name: app-canary
5  namespace: default
6spec:
7  targetRef:
8    apiVersion: apps/v1
9    kind: Deployment
10    name: my-app
11  progressDeadlineSeconds: 60
12  service:
13    port: 80
14  analysis:
15    interval: 30s
16    threshold: 5
17    maxWeight: 50
18    stepWeight: 10
19    metrics:
20      - name: request-success-rate
21        thresholdRange:
22          min: 99
23        interval: 1m
24      - name: request-duration
25        thresholdRange:
26          max: 500
27        interval: 1m
28

This is where things get interesting: Flagger doesn’t just deploy—it watches your app like a hawk.

Breaking Down the Key Fields

targetRef

This points to your Kubernetes Deployment. Flagger will clone it into a canary version behind the scenes.

analysis

This section defines how the rollout behaves:

• interval: how often metrics are checked
• threshold: how many failed checks before rollback
• stepWeight: traffic increase per step
• maxWeight: maximum traffic before full promotion

metrics

Flagger integrates with Prometheus (or similar) to validate your release. If metrics degrade, rollout stops immediately.

Where Jenkins Fits In

Flagger handles rollout logic, but you still need a CI/CD system to trigger deployments. That’s where Jenkins comes in.

A typical Jenkins pipeline:

1. Build Docker image
2. Push to registry
3. Update Kubernetes deployment image
4. Let Flagger take over

Example Jenkins Pipeline Snippet

1pipeline {
2  agent any
3
4  stages {
5    stage('Build Image') {
6      steps {
7        sh 'docker build -t my-app:${BUILD_NUMBER} .'
8      }
9    }
10
11    stage('Push Image') {
12      steps {
13        sh 'docker push my-app:${BUILD_NUMBER}'
14      }
15    }
16
17    stage('Deploy') {
18      steps {
19        sh "kubectl set image deployment/my-app my-app=my-app:${BUILD_NUMBER}"
20      }
21    }
22  }
23}
24

Once the image is updated, Flagger detects the change and starts the canary process automatically.

How Traffic Shifting Works

Flagger relies on a service mesh or ingress controller to split traffic.

For example, with Istio:

• 90% traffic → stable version
• 10% traffic → canary

Then gradually:

• 20% → 30% → 40% → 50%

If metrics remain healthy, Flagger promotes the canary to primary.

No manual approvals required—unless you explicitly configure them.

Common Mistakes (and How to Avoid Them)

1. Ignoring Metrics Quality

If your Prometheus metrics are noisy or incomplete, Flagger decisions will be unreliable.

Fix: Ensure stable, meaningful metrics before rollout.

2. Too Aggressive Step Weights

Jumping from 0% to 50% traffic defeats the purpose of canary testing.

Fix: Use smaller increments like 5–10%.

3. Short Analysis Intervals

Checking metrics too frequently can cause false positives.

Fix: Align intervals with real traffic patterns.

4. Forgetting Resource Limits

Your canary pod needs enough resources to handle partial traffic.

Fix: Match production-like resource requests.

Adding Manual Gates (Optional)

If you want Jenkins to approve promotion steps, Flagger supports webhooks.

Example:

1analysis:
2  webhooks:
3    - name: manual-approval
4      type: confirm-rollout
5      url: http://jenkins.example.com/approve

This allows human-in-the-loop deployments without sacrificing automation.

Why Teams Adopt Flagger for Canary Releases

There’s a reason Flagger is popular in Kubernetes environments:

• Native Kubernetes integration
• Automated rollback decisions
• Works with multiple service meshes
• Reduces deployment risk significantly

Compared to manual canary scripts, it removes a lot of operational overhead.

A Practical Flow (End-to-End)

Let’s stitch everything together:

1. Developer pushes code
2. Jenkins builds and pushes image
3. Jenkins updates Kubernetes deployment
4. Flagger detects change
5. Creates canary deployment
6. Gradually shifts traffic
7. Monitors metrics
8. Promotes or rolls back

No custom scripts. No manual traffic juggling.

Final Thoughts

Creating canary resources with Flagger is less about YAML and more about confidence in your releases. Once it’s wired into your Jenkins pipeline, deployments stop being risky events and become controlled experiments.

If you’re already running Kubernetes and still doing full rollouts, adding Flagger is one of the highest-impact upgrades you can make to your delivery pipeline.