Learning GitOps - FluxCD - Progressive Delivery with Flagger

#Introduction

In episode 14 you learned notifications: how every FluxCD controller produces events and how the Alert forwards them to Slack, Discord, or a webhook. Now we enter a new phase that leverages that observability: progressive delivery.

In this episode 15 we'll get to know Flagger, the progressive delivery tool that's part of the FluxCD ecosystem. We'll learn its concept, architecture, installation, and workflow — before dissecting canary, blue-green, and A/B testing strategies practically in episodes 16 and 17.

#What Is Progressive Delivery?

Progressive delivery is an approach to deploying a new version gradually while measuring its impact before all traffic is shifted. Unlike a rolling update, which only focuses on availability, progressive delivery focuses on quality verification during the deployment process.

Flagger supports all of the strategies above: canary, A/B testing, and blue-green, with configurable metrics analysis.

#Getting to Know Flagger

Flagger is an open-source progressive delivery tool developed by Weaveworks and a part of the FluxCD ecosystem. Flagger runs as a Kubernetes controller that watches Deployment or DaemonSet objects, then automates the whole analysis and traffic shifting cycle.

Some important things about Flagger:

• Works together with FluxCD, not as a replacement — FluxCD syncs manifests from Git, Flagger manages the deployment strategy
• Relies on a service mesh or ingress controller for traffic shifting
• Uses Prometheus as the main metrics source
• Supports canary, A/B, and blue-green in a single Canary CRD

#Flagger Architecture

Flagger consists of one controller and several CRDs. Here are its main components:

A minimal Canary CRD:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
  analysis:
    interval: 1m
    iterations: 10
    stepWeight: 10
    maxWeight: 50
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m

An example MetricTemplate for a custom metric:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: not-found-percentage
  namespace: test
spec:
  provider:
    type: prometheus
    address: http://prometheus.observability:9090
  query: |
    sum(rate(http_request_duration_seconds_count{status="404"}[2m]))
    /
    sum(rate(http_request_duration_seconds_count[2m]))

An example AlertProvider:

apiVersion: flagger.app/v1beta1
kind: AlertProvider
metadata:
  name: on-call
  namespace: flux-system
spec:
  type: slack
  channel: on-call
  secretRef:
    name: slack-url

#Installing Flagger

Flagger is installed through a Helm chart. Basic requirements: a Kubernetes cluster version 1.16 or later, kubectl, and Prometheus running in the cluster.

helm repo add flagger https://flagger.app
helm upgrade -i flagger flagger/flagger \
  --namespace flux-system \
  --set crd.create=true \
  --set meshProvider=nginx \
  --set metricsServer=http://prometheus.observability:9090

Flagger is usually installed in the flux-system namespace, while the application resources it manages live in other namespaces. The meshProvider parameter determines how Flagger shifts traffic, and metricsServer points to the Prometheus used for analysis.

#Supported Service Meshes and Ingresses

Flagger doesn't shift traffic itself — it delegates to the installed service mesh or ingress controller:

#How Flagger Works

When a new Deployment is applied, Flagger runs the following cycle:

1. Change detection — the spec of the Deployment referenced by the Canary changes
2. Create canary resources — the canary Deployment and canary service are created without traffic
3. Automated canary analysis — Flagger shifts traffic bit by bit according to stepWeight and iterations
4. Metrics analysis — each stage is checked against metrics such as request-success-rate and request-duration
5. Promotion or rollback — if all metrics pass, traffic is fully shifted; if they fail, traffic returns to the old version

During the process, Flagger sends notifications through the AlertProvider, for example when the canary is scaled up, promoted, or rolled back. The entire process runs automatically without human intervention.

kubectl get canaries.flagger.app -n test
kubectl describe canary podinfo -n test

#Closing

Episode 15 introduced Flagger as the progressive delivery engine in the FluxCD ecosystem.

The key takeaways:

• Progressive delivery shifts traffic gradually while measuring quality, not just replacing pods.
• Flagger works together with FluxCD: Flux syncs manifests, Flagger manages the deployment strategy.
• Four architecture components: the controller, Canary CRD, MetricTemplate, and AlertProvider.
• Traffic shifting is delegated to the installed service mesh, ingress controller, or Gateway API.
• Promote or rollback decisions are made automatically based on metrics analysis.

In the next episode, episode 16, we'll dissect Canary Deployments in depth: Canary CRD configuration, gradual traffic shifting strategy, metrics analysis, and the conditions that trigger automatic rollback. See you!