DOCSEARCHbyAlgolia
Submit Docs

Flagger Documentation

repository·main·Indexed 26 days ago

https://github.com/fluxcd/flagger

Flagger is a progressive delivery tool for Kubernetes that automates the release process by gradually shifting traffic to new software versions. It supports Canary releases, A/B testing, and Blue/Green mirroring, integrating with service meshes (Istio, Linkerd, AWS App Mesh, Kuma), ingress controllers (NGINX, Gloo, Contour, Traefik), and monitoring solutions like Prometheus to validate releases against metrics and tests.

Tokens
71.1K
Snippets
172
Records
237
Agent score
88%

What's inside Flagger

  1. Overview of Flagger

    main
    Flagger is a progressive delivery tool for Kubernetes that automates the release process for applications. It reduces production risk by gradually shifting traffic to new software versions while simultaneously measuring metrics and running conformance tests. It supports deployment strategies such as Canary releases, A/B testing, and Blue/Green mirroring, and integrates with various ingress controllers, service meshes, and monitoring solutions.

  2. Introduction to Flagger

    main

    Flagger is a progressive delivery Kubernetes operator that automates the release process for applications. It reduces production risk by gradually shifting traffic to new software versions while performing metric analysis and conformance testing.

    Key Capabilities:

    • Deployment Strategies: Supports Canary releases, A/B testing, and Blue/Green mirroring.
    • Traffic Routing: Uses service meshes or ingress controllers to manage traffic shifts.
    • Release Analysis: Integrates with Prometheus, InfluxDB, Datadog, New Relic, CloudWatch, Stackdriver, or Graphite.
    • Alerting: Sends notifications via Slack, MS Teams, Discord, and Rocket.
    • GitOps Integration: Declarative configuration via Kubernetes Custom Resources, making it compatible with GitOps tools like Flux CD.

  3. Supported Deployment Strategies

    main

    Flagger supports several automated deployment strategies for application analysis, promotion, and rollback:

    • Canary Release (progressive traffic shifting): Supported by Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo Edge, Traefik, Kuma, Gateway API, Apache APISIX, and Knative.
    • A/B Testing (HTTP headers and cookies traffic routing): Supported by Istio, App Mesh, NGINX, Contour, Gloo Edge, and Gateway API.
    • Blue/Green (traffic switching): Supported by Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo Edge, and Gateway API.
    • Blue/Green Mirroring (traffic shadowing): Supported by Istio and Gateway API.
    • Canary Release with Session Affinity (progressive traffic shifting combined with cookie-based routing): Supported by Istio and Gateway API.

    Note: Canary releases and A/B testing require a Layer 7 traffic management solution (service mesh or ingress controller). Blue/Green deployments do not require a service mesh or ingress controller.

  4. Supported Deployment Strategies in Flagger

    main

    Flagger supports the following deployment strategies:

    • Canary Release: Progressive traffic shifting to a new version.
    • A/B Testing: Useful for frontend applications requiring session affinity via HTTP headers or cookie match conditions.
    • Blue/Green: Switching traffic between two identical environments.
    • Blue/Green Mirroring: A variation of Blue/Green where traffic is copied to the canary service. Note: Mirroring should only be used for idempotent requests that can be processed twice.

  8. Run Flagger integration tests with Kind

    main

    Flagger provides end-to-end (e2e) integration tests that can be run locally using Kubernetes Kind.

    Steps:

    1. Create a Kind cluster.
    2. Build the Flagger image and load it into the Kind cluster.
    3. Execute the e2e test script for your specific service mesh or ingress controller (e.g., ./test/istio/run.sh).
    # Create cluster
kind create cluster

# Build and load image
make build
docker build -t test/flagger:latest .
kind load docker-image test/flagger:latest

# Run Istio e2e tests
./test/istio/run.sh

  9. Install Gloo Edge and Flagger for Canary Deployments

    main

    To use Flagger with Gloo Edge, you must first install Gloo Edge and then install Flagger with the gloo mesh provider and Prometheus enabled.

    Prerequisites:

    • Kubernetes v1.16 or newer
    • Gloo Edge 1.6.0 or newer
    • Flagger 1.6.0 or newer

    Installation Steps:

    1. Install Gloo using Helm.
    2. Install Flagger in the same namespace as Gloo, ensuring meshProvider is set to gloo and prometheus.install is set to true.
    # Install Gloo
helm repo add gloo https://storage.googleapis.com/solo-public-helm
kubectl create ns gloo-system
helm upgrade -i gloo gloo/gloo --namespace gloo-system

# Install Flagger with Gloo provider
helm repo add flagger https://flagger.app
helm upgrade -i flagger flagger/flagger \
  --namespace gloo-system \
  --set prometheus.install=true \
  --set meshProvider=gloo

  10. Install Flagger with Istio

    main

    To use Flagger with Istio, ensure you have Kubernetes v1.16+ and Istio v1.5+.

    1. Install Istio with the default profile:
    istioctl manifest install --set profile=default
    1. Install Prometheus (replace release-1.18 with your actual Istio version):
    kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/prometheus.yaml
    1. Install Flagger into the istio-system namespace:
    kubectl apply -k github.com/fluxcd/flagger//kustomize/istio
    istioctl manifest install --set profile=default

# Suggestion: Please change release-1.18 in below command, to your real istio version.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/prometheus.yaml

kubectl apply -k github.com/fluxcd/flagger//kustomize/istio

  11. Implement Graceful shutdown with preStop hooks

    main

    When a pod is terminated, Kubernetes sends a SIGTERM. If the app doesn't handle this or exits too quickly, in-flight requests will fail.

    To allow the service mesh to drain traffic and remove the pod from Envoy sidecars before the app becomes unavailable, add a preStop hook to delay the container shutdown.

    apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: app
        lifecycle:
          preStop:
            exec:
              command:
              - sleep
              - "10"