Merge pull request #1301 from fluxcd/release-v1.24.1

Release v1.24.1

.circleci/config.yml

@@ -1,275 +0,0 @@
-version: 2.1
-jobs:
-
-  build-binary:
-    docker:
-      - image: circleci/golang:1.14
-    working_directory: ~/build
-    steps:
-      - checkout
-      - restore_cache:
-          keys:
-            - go-mod-v3-{{ checksum "go.sum" }}
-      - run:
-          name: Run go mod download
-          command: go mod download
-      - run:
-          name: Check code formatting
-          command: go install golang.org/x/tools/cmd/goimports && make test-fmt
-      - run:
-          name: Build Flagger
-          command: |
-            CGO_ENABLED=0 GOOS=linux go build \
-                -ldflags "-s -w -X github.com/weaveworks/flagger/pkg/version.REVISION=${CIRCLE_SHA1}" \
-                -a -installsuffix cgo -o bin/flagger ./cmd/flagger/*.go
-      - run:
-          name: Build Flagger load tester
-          command: |
-            CGO_ENABLED=0 GOOS=linux go build \
-                -a -installsuffix cgo -o bin/loadtester ./cmd/loadtester/*.go
-      - run:
-          name: Run unit tests
-          command: |
-            go test -race -coverprofile=coverage.txt -covermode=atomic $(go list ./pkg/...)
-            bash <(curl -s https://codecov.io/bash)
-      - run:
-          name: Verify code gen
-          command: make test-codegen
-      - save_cache:
-          key: go-mod-v3-{{ checksum "go.sum" }}
-          paths:
-            - "/go/pkg/mod/"
-      - persist_to_workspace:
-          root: bin
-          paths:
-            - flagger
-            - loadtester
-
-  push-container:
-    docker:
-      - image: circleci/golang:1.14
-    steps:
-      - checkout
-      - setup_remote_docker:
-          docker_layer_caching: true
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/container-push.sh
-
-  push-binary:
-    docker:
-      - image: circleci/golang:1.14
-    working_directory: ~/build
-    steps:
-      - checkout
-      - setup_remote_docker:
-          docker_layer_caching: true
-      - restore_cache:
-          keys:
-            - go-mod-v3-{{ checksum "go.sum" }}
-      - run: make release-notes
-      - run: github-release-notes -org weaveworks -repo flagger -since-latest-release -include-author > /tmp/release.txt
-      - run: test/goreleaser.sh
-
-  e2e-kubernetes-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh v1.18.2
-      - run: test/e2e-kubernetes.sh
-      - run: test/e2e-kubernetes-tests-deployment.sh
-      - run: test/e2e-kubernetes-cleanup.sh
-      - run: test/e2e-kubernetes-tests-daemonset.sh
-
-  e2e-istio-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh v1.18.2
-      - run: test/e2e-istio.sh
-      - run: test/e2e-istio-tests.sh
-
-  e2e-gloo-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh
-      - run: test/e2e-gloo.sh
-      - run: test/e2e-gloo-tests.sh
-
-  e2e-nginx-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh
-      - run: test/e2e-nginx.sh
-      - run: test/e2e-nginx-tests.sh
-      - run: test/e2e-nginx-cleanup.sh
-      - run: test/e2e-nginx-custom-annotations.sh
-      - run: test/e2e-nginx-tests.sh
-
-  e2e-linkerd-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh
-      - run: test/e2e-linkerd.sh
-      - run: test/e2e-linkerd-tests.sh
-
-  e2e-contour-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh
-      - run: test/e2e-contour.sh
-      - run: test/e2e-contour-tests.sh
-
-  e2e-skipper-testing:
-    machine: true
-    steps:
-      - checkout
-      - attach_workspace:
-          at: /tmp/bin
-      - run: test/container-build.sh
-      - run: test/e2e-kind.sh
-      - run: test/e2e-skipper.sh
-      - run: test/e2e-skipper-tests.sh
-      - run: test/e2e-skipper-cleanup.sh
-
-  push-helm-charts:
-    docker:
-      - image: circleci/golang:1.14
-    steps:
-      - checkout
-      - run:
-          name: Install kubectl
-          command: sudo curl -L https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl && sudo chmod +x /usr/local/bin/kubectl
-      - run:
-          name: Install helm
-          command: sudo curl -L https://storage.googleapis.com/kubernetes-helm/helm-v2.14.2-linux-amd64.tar.gz | tar xz && sudo mv linux-amd64/helm /bin/helm && sudo rm -rf linux-amd64
-      - run:
-          name: Initialize helm
-          command:  helm init --client-only --kubeconfig=$HOME/.kube/kubeconfig
-      - run:
-          name: Lint charts
-          command: |
-            helm lint ./charts/*
-      - run:
-          name: Package charts
-          command: |
-            mkdir $HOME/charts
-            helm package ./charts/* --destination $HOME/charts
-      - run:
-          name: Publish charts
-          command: |
-            if echo "${CIRCLE_TAG}" | grep v; then
-              REPOSITORY="https://weaveworksbot:${GITHUB_TOKEN}@github.com/weaveworks/flagger.git"
-              git config user.email weaveworksbot@users.noreply.github.com
-              git config user.name weaveworksbot
-              git remote set-url origin ${REPOSITORY}
-              git checkout gh-pages
-              mv -f $HOME/charts/*.tgz .
-              helm repo index . --url https://flagger.app
-              git add .
-              git commit -m "Publish Helm charts v${CIRCLE_TAG}"
-              git push origin gh-pages
-            else
-              echo "Not a release! Skip charts publish"
-            fi
-
-workflows:
-  version: 2
-  build-test-push:
-    jobs:
-      - build-binary:
-          filters:
-            branches:
-              ignore:
-                - gh-pages
-                - /^user-.*/
-      - e2e-kubernetes-testing:
-          requires:
-            - build-binary
-      - e2e-istio-testing:
-          requires:
-            - build-binary
-      - e2e-gloo-testing:
-          requires:
-            - build-binary
-      - e2e-nginx-testing:
-          requires:
-            - build-binary
-      - e2e-linkerd-testing:
-          requires:
-            - build-binary
-      - e2e-contour-testing:
-          requires:
-            - build-binary
-      - e2e-skipper-testing:
-          requires:
-            - build-binary
-      - push-container:
-          requires:
-            - build-binary
-            - e2e-kubernetes-testing
-            - e2e-istio-testing
-            - e2e-gloo-testing
-            - e2e-nginx-testing
-            - e2e-linkerd-testing
-            - e2e-skipper-testing
-          filters:
-            branches:
-              only:
-                - master
-
-  release:
-    jobs:
-      - build-binary:
-          filters:
-            branches:
-              ignore: /.*/
-            tags:
-              ignore: /^chart.*/
-      - push-container:
-          requires:
-            - build-binary
-          filters:
-            branches:
-              ignore: /.*/
-            tags:
-              ignore: /^chart.*/
-      - push-binary:
-          requires:
-            - push-container
-          filters:
-            branches:
-              ignore: /.*/
-            tags:
-              ignore: /^chart.*/
-      - push-helm-charts:
-          requires:
-            - push-container
-          filters:
-            branches:
-              ignore: /.*/
-            tags:
-              ignore: /^chart.*/

.clomonitor.yml

@@ -0,0 +1,3 @@
+exemptions:
+  - check: analytics
+    reason: "We don't track people"

.gitbook.yaml

@@ -12,3 +12,7 @@ redirects:
   usage/nginx-progressive-delivery: tutorials/nginx-progressive-delivery.md
   usage/skipper-progressive-delivery: tutorials/skipper-progressive-delivery.md
   usage/crossover-progressive-delivery: tutorials/crossover-progressive-delivery.md
+  usage/traefik-progressive-delivery: tutorials/traefik-progressive-delivery.md
+  usage/osm-progressive-delivery: tutorials/osm-progressive-delivery.md
+  usage/kuma-progressive-delivery: tutorials/kuma-progressive-delivery.md
+  usage/gatewayapi-progressive-delivery: tutorials/gatewayapi-progressive-delivery.md

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,29 @@
+---
+name: Bug report
+about: Create a report to help us improve this project
+title: ''
+assignees: ''
+
+---
+
+### Describe the bug
+
+A clear and concise description of what the bug is.
+Please provide the Canary definition and Flagger logs.
+
+### To Reproduce
+
+<!--
+Steps to reproduce the behaviour
+-->
+
+### Expected behavior
+
+A clear and concise description of what you expected to happen.
+
+### Additional context
+
+- Flagger version:
+- Kubernetes version:   
+- Service Mesh provider:
+- Ingress provider:

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,2 @@
+blank_issues_enabled: true
+

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,19 @@
+---
+name: Feature Request
+about: I have a suggestion (and may want to implement it 🙂)!
+title: ''
+assignees: ''
+
+---
+
+## Describe the feature
+
+What problem are you trying to solve?
+
+### Proposed solution
+
+What do you want to happen? Add any considered drawbacks.
+
+### Any alternatives you've considered?
+
+Is there another way to solve this problem that isn't as good a solution?

.github/_main.workflow

@@ -1,17 +0,0 @@
-workflow "Publish Helm charts" {
-  on = "push"
-  resolves = ["helm-push"]
-}
-
-action "helm-lint" {
-  uses = "stefanprodan/gh-actions/helm@master"
-  args = ["lint charts/*"]
-}
-
-action "helm-push" {
-  needs = ["helm-lint"]
-  uses = "stefanprodan/gh-actions/helm-gh-pages@master"
-  args = ["charts/*","https://flagger.app"]
-  secrets = ["GITHUB_TOKEN"]
-}
-

.github/dependabot.yml

@@ -0,0 +1,7 @@
+version: 2
+
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

.github/workflows/build.yaml

@@ -0,0 +1,54 @@
+name: build
+
+on:
+  workflow_dispatch:
+  pull_request:
+    branches:
+      - main
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  build-flagger:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: Restore Go cache
+        uses: actions/cache@v3.0.11
+        with:
+          path: ~/go/pkg/mod
+          key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
+          restore-keys: |
+            ${{ runner.os }}-go-
+      - name: Setup Go
+        uses: actions/setup-go@v3
+        with:
+          go-version: 1.19.x
+      - name: Download modules
+        run: |
+          go mod download
+          go install golang.org/x/tools/cmd/goimports
+      - name: Run linters
+        run: make test-fmt test-codegen
+      - name: Verify CRDs
+        run: make verify-crd
+      - name: Run tests
+        run: go test -race -coverprofile=coverage.txt -covermode=atomic $(go list ./pkg/...)
+      - name: Check if working tree is dirty
+        run: |
+          if [[ $(git diff --stat) != '' ]]; then
+            git --no-pager diff
+            echo 'run make test and commit changes'
+            exit 1
+          fi
+      - name: Upload coverage to Codecov
+        uses: codecov/codecov-action@v3
+        with:
+          file: ./coverage.txt
+      - name: Build container image
+        run: docker build -t test/flagger:latest .

.github/workflows/e2e.yaml

@@ -0,0 +1,50 @@
+name: e2e
+
+on:
+  workflow_dispatch:
+  pull_request:
+    branches:
+      - main
+  push:
+    branches:
+      - main
+
+permissions:
+  contents: read
+
+jobs:
+  e2e-test:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        provider:
+          # service mesh
+          - istio
+          - linkerd
+          - osm
+          - kuma
+          # ingress controllers
+          - contour
+          - nginx
+          - traefik
+          - gloo
+          - skipper
+          - kubernetes
+          - gatewayapi
+          - keda
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+      - name: Setup Kubernetes
+        uses: engineerd/setup-kind@v0.5.0
+        with:
+          version: "v0.14.0"
+          image: kindest/node:v1.23.6@sha256:b1fa224cc6c7ff32455e0b1fd9cbfd3d3bc87ecaa8fcb06961ed1afb3db0f9ae
+      - name: Build container image
+        run: |
+          docker build -t test/flagger:latest .
+          kind load docker-image test/flagger:latest
+      - name: Run tests
+        run: |
+          ./test/${{ matrix['provider'] }}/run.sh

.github/workflows/helm.yaml

@@ -0,0 +1,20 @@
+name: helm
+
+on:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  release-charts:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@v3
+      - name: Publish Helm charts
+        uses: stefanprodan/helm-gh-pages@v1.6.0
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          charts_url: https://flagger.app

.github/workflows/push-ld.yml

@@ -0,0 +1,61 @@
+name: push-ld
+on:
+  workflow_dispatch:
+
+env:
+  IMAGE: "ghcr.io/fluxcd/flagger-loadtester"
+
+permissions:
+  contents: read
+
+jobs:
+  release-load-tester:
+    runs-on: ubuntu-latest
+    permissions:
+      id-token: write
+      packages: write
+    steps:
+      - uses: actions/checkout@v3
+      - uses: sigstore/cosign-installer@v2.8.1
+      - name: Prepare
+        id: prep
+        run: |
+          VERSION=$(grep 'VERSION' cmd/loadtester/main.go | head -1 | awk '{ print $4 }' | tr -d '"')
+          echo ::set-output name=BUILD_DATE::$(date -u +'%Y-%m-%dT%H:%M:%SZ')
+          echo ::set-output name=VERSION::${VERSION}
+      - name: Setup QEMU
+        uses: docker/setup-qemu-action@v2
+      - name: Setup Docker Buildx
+        id: buildx
+        uses: docker/setup-buildx-action@v2
+      - name: Login to GitHub Container Registry
+        uses: docker/login-action@v2
+        with:
+          registry: ghcr.io
+          username: fluxcdbot
+          password: ${{ secrets.GHCR_TOKEN }}
+      - name: Generate image meta
+        id: meta
+        uses: docker/metadata-action@v4
+        with:
+          images: |
+            ${{ env.IMAGE }}
+          tags: |
+            type=raw,value=${{ steps.prep.outputs.VERSION }}
+      - name: Publish image
+        uses: docker/build-push-action@v3
+        with:
+          push: true
+          builder: ${{ steps.buildx.outputs.name }}
+          context: .
+          file: ./Dockerfile.loadtester
+          platforms: linux/amd64,linux/arm64
+          build-args: |
+            REVISION=${{ github.sha }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+      - name: Sign image
+        env:
+          COSIGN_EXPERIMENTAL: 1
+        run: |
+          cosign sign ${{ env.IMAGE }}:${{ steps.prep.outputs.VERSION }}

.github/workflows/release.yml

@@ -0,0 +1,101 @@
+name: release
+on:
+  push:
+    tags:
+      - 'v*'
+
+permissions:
+  contents: read
+
+env:
+  IMAGE: "ghcr.io/fluxcd/${{ github.event.repository.name }}"
+
+jobs:
+  release-flagger:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write # needed to write releases
+      id-token: write # needed for keyless signing
+      packages: write # needed for ghcr access
+    steps:
+      - uses: actions/checkout@v3
+      - uses: fluxcd/flux2/action@main
+      - uses: sigstore/cosign-installer@v2.8.1
+      - name: Prepare
+        id: prep
+        run: |
+          VERSION=$(grep 'VERSION' pkg/version/version.go | awk '{ print $4 }' | tr -d '"')
+          CHANGELOG="https://github.com/fluxcd/flagger/blob/main/CHANGELOG.md#$(echo $VERSION | tr -d '.')"
+          echo "[CHANGELOG](${CHANGELOG})" > notes.md
+          echo ::set-output name=BUILD_DATE::$(date -u +'%Y-%m-%dT%H:%M:%SZ')
+          echo ::set-output name=VERSION::${VERSION}
+      - name: Setup QEMU
+        uses: docker/setup-qemu-action@v2
+      - name: Setup Docker Buildx
+        id: buildx
+        uses: docker/setup-buildx-action@v2
+      - name: Login to GitHub Container Registry
+        uses: docker/login-action@v2
+        with:
+          registry: ghcr.io
+          username: fluxcdbot
+          password: ${{ secrets.GHCR_TOKEN }}
+      - name: Generate image meta
+        id: meta
+        uses: docker/metadata-action@v4
+        with:
+          images: |
+            ${{ env.IMAGE }}
+          tags: |
+            type=raw,value=${{ steps.prep.outputs.VERSION }}
+      - name: Publish image
+        uses: docker/build-push-action@v3
+        with:
+          push: true
+          builder: ${{ steps.buildx.outputs.name }}
+          context: .
+          file: ./Dockerfile
+          platforms: linux/amd64,linux/arm64,linux/arm/v7
+          build-args: |
+            REVISON=${{ github.sha }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+      - name: Sign image
+        env:
+          COSIGN_EXPERIMENTAL: 1
+        run: |
+          cosign sign ${{ env.IMAGE }}:${{ steps.prep.outputs.VERSION }}
+      - name: Publish Helm charts
+        uses: stefanprodan/helm-gh-pages@v1.6.0
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          charts_url: https://flagger.app
+          linting: off
+      - uses: fluxcd/pkg/actions/helm@main
+        with:
+          version: 3.10.1
+      - name: Publish signed Helm chart to GHCR
+        env:
+          COSIGN_EXPERIMENTAL: 1
+        run: |
+          helm package charts/flagger
+          helm push flagger-${{ steps.prep.outputs.VERSION }}.tgz oci://ghcr.io/fluxcd/charts
+          cosign sign ghcr.io/fluxcd/charts/flagger:${{ steps.prep.outputs.VERSION }}
+          rm flagger-${{ steps.prep.outputs.VERSION }}.tgz
+      - name: Publish signed manifests to GHCR
+        env:
+          COSIGN_EXPERIMENTAL: 1
+        run: |
+          flux push artifact oci://ghcr.io/fluxcd/flagger-manifests:${{ steps.prep.outputs.VERSION }} \
+          --path="./kustomize" \
+          --source="$(git config --get remote.origin.url)" \
+          --revision="${{ steps.prep.outputs.VERSION }}/$(git rev-parse HEAD)"
+          cosign sign ghcr.io/fluxcd/flagger-manifests:${{ steps.prep.outputs.VERSION }}
+      - uses: anchore/sbom-action/download-syft@v0
+      - name: Create release and SBOM
+        uses: goreleaser/goreleaser-action@v3
+        with:
+          version: latest
+          args: release --release-notes=notes.md --rm-dist --skip-validate
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/scan.yml

@@ -0,0 +1,41 @@
+name: scan
+
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+  schedule:
+    - cron: '18 10 * * 3'
+
+permissions:
+  contents: read
+
+jobs:
+  scan-fossa:
+    runs-on: ubuntu-latest
+    permissions:
+      security-events: write
+    steps:
+      - uses: actions/checkout@v3
+      - name: Run FOSSA scan and upload build data
+        uses: fossa-contrib/fossa-action@v1
+        with:
+          # FOSSA Push-Only API Token
+          fossa-api-key: 5ee8bf422db1471e0bcf2bcb289185de
+          github-token: ${{ github.token }}
+  scan-codeql:
+    runs-on: ubuntu-latest
+    permissions:
+      security-events: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v3
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v2
+        with:
+          languages: go
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v2
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v2

.gitignore

@@ -20,3 +20,4 @@ artifacts/gcloud/
 Makefile.dev
 
 vendor
+coverage.txt

.goreleaser.yml

@@ -1,18 +1,30 @@
+project_name: flagger
+
 builds:
-  - main: ./cmd/flagger
-    binary: flagger
-    ldflags: -s -w -X github.com/weaveworks/flagger/pkg/version.REVISION={{.Commit}}
-    goos:
-      - linux
-    goarch:
-      - amd64
+  - skip: true
+
+release:
+  prerelease: auto
+
+source:
+  enabled: true
+  name_template: "{{ .ProjectName }}_{{ .Version }}_source_code"
+
+sboms:
+  - id: source
+    artifacts: source
+    documents:
+      - "{{ .ProjectName }}_{{ .Version }}_sbom.spdx.json"
+
+signs:
+  - cmd: cosign
     env:
-      - CGO_ENABLED=0
-archives:
-  - name_template: "{{ .Binary }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}"
-    files:
-    - none*
-changelog:
-  filters:
-    exclude:
-      - '^CircleCI'
+      - COSIGN_EXPERIMENTAL=1
+    certificate: '${artifact}.pem'
+    args:
+      - sign-blob
+      - '--output-certificate=${certificate}'
+      - '--output-signature=${signature}'
+      - '${artifact}'
+    artifacts: checksum
+    output: true

CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+## Code of Conduct
+
+Flagger follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

CONTRIBUTING.md

@@ -14,10 +14,28 @@ Origin (DCO). This document was created by the Linux Kernel community and is a
 simple statement that you, as a contributor, have the legal right to make the
 contribution.
 
-## Chat
+We require all commits to be signed. By signing off with your signature, you
+certify that you wrote the patch or otherwise have the right to contribute the
+material by the rules of the [DCO](DCO):
+
+`Signed-off-by: Jane Doe <jane.doe@example.com>`
+
+The signature must contain your real name
+(sorry, no pseudonyms or anonymous contributions)
+If your `user.name` and `user.email` are configured in your Git config,
+you can sign your commit automatically with `git commit -s`.
+
+## Communications
 
 The project uses Slack: To join the conversation, simply join the
-[Weave community](https://slack.weave.works/) Slack workspace #flagger channel.
+[CNCF](https://slack.cncf.io/) Slack workspace and use the
+[#flagger](https://cloud-native.slack.com/messages/flagger/) channel.
+
+The developers use a mailing list to discuss development as well.
+Simply subscribe to [flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev)
+to join the conversation (this will also add an invitation to your
+Google calendar for our [Flux
+meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/edit#)).
 
 ## Getting Started
 
@@ -69,4 +87,3 @@ For Flagger we prefer the following rules for good commit messages:
 The [following article](https://chris.beams.io/posts/git-commit/#seven-rules)
 has some more helpful advice on documenting your work.
 
-This doc is adapted from [FluxCD](https://github.com/fluxcd/flux/blob/master/CONTRIBUTING.md).

DCO

@@ -0,0 +1,36 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

Dockerfile

@@ -1,9 +1,32 @@
-FROM alpine:3.12
+FROM golang:1.19-alpine as builder
+
+ARG TARGETPLATFORM
+ARG REVISON
+
+WORKDIR /workspace
+
+# copy modules manifests
+COPY go.mod go.mod
+COPY go.sum go.sum
+
+# cache modules
+RUN go mod download
+
+# copy source code
+COPY cmd/ cmd/
+COPY pkg/ pkg/
+
+# build
+RUN CGO_ENABLED=0 go build \
+    -ldflags "-s -w -X github.com/fluxcd/flagger/pkg/version.REVISION=${REVISON}" \
+    -a -o flagger ./cmd/flagger
+
+FROM alpine:3.16
 
 RUN apk --no-cache add ca-certificates
 
 USER nobody
 
-COPY --chown=nobody:nobody /bin/flagger .
+COPY --from=builder --chown=nobody:nobody /workspace/flagger .
 
 ENTRYPOINT ["./flagger"]

Dockerfile.loadtester

@@ -1,59 +1,59 @@
-FROM alpine:3.11 as build
+FROM golang:1.19-alpine as builder
 
-RUN apk --no-cache add alpine-sdk perl curl
+ARG TARGETPLATFORM
+ARG TARGETARCH
+ARG REVISION
 
-RUN curl -sSLo hey "https://storage.googleapis.com/hey-release/hey_linux_amd64" && \
-chmod +x hey && mv hey /usr/local/bin/hey
+RUN apk --no-cache add alpine-sdk perl curl bash tar
 
-RUN HELM2_VERSION=2.16.8 && \
-curl -sSL "https://get.helm.sh/helm-v${HELM2_VERSION}-linux-amd64.tar.gz" | tar xvz && \
-chmod +x linux-amd64/helm && mv linux-amd64/helm /usr/local/bin/helm && \
-chmod +x linux-amd64/tiller && mv linux-amd64/tiller /usr/local/bin/tiller
+RUN HELM3_VERSION=3.9.4 && \
+curl -sSL "https://get.helm.sh/helm-v${HELM3_VERSION}-linux-${TARGETARCH}.tar.gz" | tar xvz && \
+chmod +x linux-${TARGETARCH}/helm && mv linux-${TARGETARCH}/helm /usr/local/bin/helm
 
-RUN HELM3_VERSION=3.2.3 && \
-curl -sSL "https://get.helm.sh/helm-v${HELM3_VERSION}-linux-amd64.tar.gz" | tar xvz && \
-chmod +x linux-amd64/helm && mv linux-amd64/helm /usr/local/bin/helmv3
-
-RUN GRPC_HEALTH_PROBE_VERSION=v0.3.1 && \
-wget -qO /usr/local/bin/grpc_health_probe https://github.com/grpc-ecosystem/grpc-health-probe/releases/download/${GRPC_HEALTH_PROBE_VERSION}/grpc_health_probe-linux-amd64 && \
+RUN GRPC_HEALTH_PROBE_VERSION=v0.4.12 && \
+wget -qO /usr/local/bin/grpc_health_probe https://github.com/grpc-ecosystem/grpc-health-probe/releases/download/${GRPC_HEALTH_PROBE_VERSION}/grpc_health_probe-linux-${TARGETARCH} && \
 chmod +x /usr/local/bin/grpc_health_probe
 
-RUN GHZ_VERSION=0.39.0 && \
-curl -sSL "https://github.com/bojand/ghz/releases/download/v${GHZ_VERSION}/ghz_${GHZ_VERSION}_Linux_x86_64.tar.gz" | tar xz -C /tmp && \
-mv /tmp/ghz /usr/local/bin && chmod +x /usr/local/bin/ghz
+RUN GHZ_VERSION=0.109.0 && \
+curl -sSL "https://github.com/bojand/ghz/archive/refs/tags/v${GHZ_VERSION}.tar.gz" | tar xz -C /tmp && \
+cd /tmp/ghz-${GHZ_VERSION}/cmd/ghz && GOARCH=$TARGETARCH go build . && mv ghz /usr/local/bin && \
+chmod +x /usr/local/bin/ghz
 
-RUN HELM_TILLER_VERSION=0.9.3 && \
-curl -sSL "https://github.com/rimusz/helm-tiller/archive/v${HELM_TILLER_VERSION}.tar.gz" | tar xz -C /tmp && \
-mv /tmp/helm-tiller-${HELM_TILLER_VERSION} /tmp/helm-tiller
+WORKDIR /workspace
 
-RUN WRK_VERSION=4.0.2 && \
-cd /tmp && git clone -b ${WRK_VERSION} https://github.com/wg/wrk
-RUN cd /tmp/wrk && make
+# copy modules manifests
+COPY go.mod go.mod
+COPY go.sum go.sum
+
+# cache modules
+RUN go mod download
+
+# copy source code
+COPY cmd/ cmd/
+COPY pkg/ pkg/
+
+# build
+RUN CGO_ENABLED=0 go build -o loadtester ./cmd/loadtester/*
 
 FROM bash:5.0
 
+ARG TARGETPLATFORM
+
 RUN addgroup -S app && \
 adduser -S -g app app && \
-apk --no-cache add ca-certificates curl jq libgcc
+apk --no-cache add ca-certificates curl jq libgcc wrk hey
 
 WORKDIR /home/app
 
 COPY --from=bats/bats:v1.1.0 /opt/bats/ /opt/bats/
 RUN ln -s /opt/bats/bin/bats /usr/local/bin/
 
-COPY --from=build /usr/local/bin/hey /usr/local/bin/
-COPY --from=build /tmp/wrk/wrk /usr/local/bin/
-COPY --from=build /usr/local/bin/helm /usr/local/bin/
-COPY --from=build /usr/local/bin/tiller /usr/local/bin/
-COPY --from=build /usr/local/bin/ghz /usr/local/bin/
-COPY --from=build /usr/local/bin/helmv3 /usr/local/bin/
-COPY --from=build /usr/local/bin/grpc_health_probe /usr/local/bin/
-COPY --from=build /tmp/helm-tiller /tmp/helm-tiller
+COPY --from=builder /usr/local/bin/helm /usr/local/bin/
+COPY --from=builder /usr/local/bin/ghz /usr/local/bin/
+COPY --from=builder /usr/local/bin/grpc_health_probe /usr/local/bin/
 
 ADD https://raw.githubusercontent.com/grpc/grpc-proto/master/grpc/health/v1/health.proto /tmp/ghz/health.proto
 
-COPY ./bin/loadtester .
-
 RUN chown -R app:app ./
 RUN chown -R app:app /tmp/ghz
 
@@ -63,7 +63,6 @@ USER app
 RUN hey -n 1 -c 1 https://flagger.app > /dev/null && echo $? | grep 0
 RUN wrk -d 1s -c 1 -t 1 https://flagger.app > /dev/null && echo $? | grep 0
 
-# install Helm v2 plugins
-RUN helm init --client-only && helm plugin install /tmp/helm-tiller
+COPY --from=builder --chown=app:app /workspace/loadtester .
 
 ENTRYPOINT ["./loadtester"]

GOVERNANCE.md

@@ -0,0 +1,5 @@
+# Flagger Governance
+
+The Flagger project is governed by the [Flux governance document](https://github.com/fluxcd/community/blob/main/GOVERNANCE.md),
+involvement is defined in the [Flux community roles document](chttps://github.com/fluxcd/community/blob/main/community-roles.md),
+and processes can be found in the [Flux process document](https://github.com/fluxcd/community/blob/main/PROCESS.md).

LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2018 Weaveworks. All rights reserved.
+   Copyright [yyyy] [name of copyright owner]
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

MAINTAINERS

@@ -1,6 +1,9 @@
 The maintainers are generally available in Slack at
-https://weave-community.slack.com/messages/flagger/ (obtain an invitation
-at https://slack.weave.works/).
+https://cloud-native.slack.com/messages/flagger/ (obtain an invitation
+at https://slack.cncf.io/).
 
-Stefan Prodan, Weaveworks <stefan@weave.works> (Slack: @stefan Twitter: @stefanprodan)
-Takeshi Yoneda, DMM.com <cz.rk.t0415y.g@gmail.com> (Slack: @mathetake Twitter: @mathetake)
+In alphabetical order:
+
+Stefan Prodan, Weaveworks <stefan@weave.works> (github: @stefanprodan, slack: stefanprodan)
+Takeshi Yoneda, Tetrate <takeshi@tetrate.io> (github: @mathetake, slack: mathetake)
+Sanskar Jaiswal, Weaveworks <sanskar.jaiswal@weave.works> (github: @aryan9600, slack: aryan9600)

Makefile

@@ -3,16 +3,16 @@ VERSION?=$(shell grep 'VERSION' pkg/version/version.go | awk '{ print $$4 }' | t
 LT_VERSION?=$(shell grep 'VERSION' cmd/loadtester/main.go | awk '{ print $$4 }' | tr -d '"' | head -n1)
 
 build:
-	GIT_COMMIT=$$(git rev-list -1 HEAD) && CGO_ENABLED=0 GOOS=linux go build  \
-		-ldflags "-s -w -X github.com/weaveworks/flagger/pkg/version.REVISION=$${GIT_COMMIT}" \
-		-a -installsuffix cgo -o ./bin/flagger ./cmd/flagger/*
-	docker build -t weaveworks/flagger:$(TAG) . -f Dockerfile
+	CGO_ENABLED=0 go build -a -o ./bin/flagger ./cmd/flagger
 
-push:
-	docker tag weaveworks/flagger:$(TAG) weaveworks/flagger:$(VERSION)
-	docker push weaveworks/flagger:$(VERSION)
+tidy:
+	rm -f go.sum; go mod tidy -compat=1.19
+
+vet:
+	go vet ./...
 
 fmt:
+	go mod tidy
 	gofmt -l -s -w ./
 	goimports -l -w ./
 
@@ -33,28 +33,26 @@ crd:
 	cat artifacts/flagger/crd.yaml > charts/flagger/crds/crd.yaml
 	cat artifacts/flagger/crd.yaml > kustomize/base/flagger/crd.yaml
 
+verify-crd:
+	./hack/verify-crd.sh
+
 version-set:
 	@next="$(TAG)" && \
 	current="$(VERSION)" && \
-	sed -i '' "s/$$current/$$next/g" pkg/version/version.go && \
-	sed -i '' "s/flagger:$$current/flagger:$$next/g" artifacts/flagger/deployment.yaml && \
-	sed -i '' "s/tag: $$current/tag: $$next/g" charts/flagger/values.yaml && \
-	sed -i '' "s/appVersion: $$current/appVersion: $$next/g" charts/flagger/Chart.yaml && \
-	sed -i '' "s/version: $$current/version: $$next/g" charts/flagger/Chart.yaml && \
-	sed -i '' "s/newTag: $$current/newTag: $$next/g" kustomize/base/flagger/kustomization.yaml && \
+	sed -i "s/$$current/$$next/g" pkg/version/version.go && \
+	sed -i "s/flagger:$$current/flagger:$$next/g" artifacts/flagger/deployment.yaml && \
+	sed -i "s/tag: $$current/tag: $$next/g" charts/flagger/values.yaml && \
+	sed -i "s/appVersion: $$current/appVersion: $$next/g" charts/flagger/Chart.yaml && \
+	sed -i "s/version: $$current/version: $$next/g" charts/flagger/Chart.yaml && \
+	sed -i "s/newTag: $$current/newTag: $$next/g" kustomize/base/flagger/kustomization.yaml && \
 	echo "Version $$next set in code, deployment, chart and kustomize"
 
 release:
 	git tag "v$(VERSION)"
 	git push origin "v$(VERSION)"
 
-release-notes:
-	cd /tmp && GH_REL_URL="https://github.com/buchanae/github-release-notes/releases/download/0.2.0/github-release-notes-linux-amd64-0.2.0.tar.gz" && \
-    curl -sSL $${GH_REL_URL} | tar xz && sudo mv github-release-notes /usr/local/bin/
-
 loadtester-build:
-	CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o ./bin/loadtester ./cmd/loadtester/*
-	docker build -t weaveworks/flagger-loadtester:$(LT_VERSION) . -f Dockerfile.loadtester
+	docker build -t ghcr.io/fluxcd/flagger-loadtester:$(LT_VERSION) . -f Dockerfile.loadtester
 
 loadtester-push:
-	docker push weaveworks/flagger-loadtester:$(LT_VERSION)
+	docker push ghcr.io/fluxcd/flagger-loadtester:$(LT_VERSION)

README.md

@@ -1,21 +1,22 @@
-# flagger
+ # flagger
 
-[![build](https://img.shields.io/circleci/build/github/weaveworks/flagger/master.svg)](https://circleci.com/gh/weaveworks/flagger)
-[![report](https://goreportcard.com/badge/github.com/weaveworks/flagger)](https://goreportcard.com/report/github.com/weaveworks/flagger)
-[![codecov](https://codecov.io/gh/weaveworks/flagger/branch/master/graph/badge.svg)](https://codecov.io/gh/weaveworks/flagger)
-[![license](https://img.shields.io/github/license/weaveworks/flagger.svg)](https://github.com/weaveworks/flagger/blob/master/LICENSE)
-[![release](https://img.shields.io/github/release/weaveworks/flagger/all.svg)](https://github.com/weaveworks/flagger/releases)
+[![release](https://img.shields.io/github/release/fluxcd/flagger/all.svg)](https://github.com/fluxcd/flagger/releases)
+[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/4783/badge)](https://bestpractices.coreinfrastructure.org/projects/4783)
+[![report](https://goreportcard.com/badge/github.com/fluxcd/flagger)](https://goreportcard.com/report/github.com/fluxcd/flagger)
+[![FOSSA Status](https://app.fossa.com/api/projects/custom%2B162%2Fgithub.com%2Ffluxcd%2Fflagger.svg?type=shield)](https://app.fossa.com/projects/custom%2B162%2Fgithub.com%2Ffluxcd%2Fflagger?ref=badge_shield)
+[![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/flagger)](https://artifacthub.io/packages/search?repo=flagger)
 
 Flagger is a progressive delivery tool that automates the release process for applications running on Kubernetes. 
 It reduces the risk of introducing a new software version in production
 by gradually shifting traffic to the new version while measuring metrics and running conformance tests.
 
-![flagger-overview](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-overview.png)
+![flagger-overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-overview.png)
 
 Flagger implements several deployment strategies (Canary releases, A/B testing, Blue/Green mirroring)
-using a service mesh (App Mesh, Istio, Linkerd) or an ingress controller (Contour, Gloo, NGINX, Skipper) for traffic routing.
-For release analysis, Flagger can query Prometheus, Datadog or CloudWatch
-and for alerting it uses Slack, MS Teams, Discord and Rocket.
+and integrates with various Kubernetes ingress controllers, service mesh, and monitoring solutions.
+
+Flagger is a [Cloud Native Computing Foundation](https://cncf.io/) project
+and part of the [Flux](https://fluxcd.io) family of GitOps tools.
 
 ### Documentation
 
@@ -34,33 +35,30 @@ Flagger documentation can be found at [docs.flagger.app](https://docs.flagger.ap
   * [App Mesh](https://docs.flagger.app/tutorials/appmesh-progressive-delivery)
   * [Istio](https://docs.flagger.app/tutorials/istio-progressive-delivery)
   * [Linkerd](https://docs.flagger.app/tutorials/linkerd-progressive-delivery)
+  * [Open Service Mesh (OSM)](https://docs.flagger.app/tutorials/osm-progressive-delivery)
+  * [Kuma Service Mesh](https://docs.flagger.app/tutorials/kuma-progressive-delivery)
   * [Contour](https://docs.flagger.app/tutorials/contour-progressive-delivery)
   * [Gloo](https://docs.flagger.app/tutorials/gloo-progressive-delivery)
   * [NGINX Ingress](https://docs.flagger.app/tutorials/nginx-progressive-delivery)
   * [Skipper](https://docs.flagger.app/tutorials/skipper-progressive-delivery)
+  * [Traefik](https://docs.flagger.app/tutorials/traefik-progressive-delivery)
   * [Kubernetes Blue/Green](https://docs.flagger.app/tutorials/kubernetes-blue-green)
 
-### Who is using Flagger
+### Adopters
 
-List of organizations using Flagger:
+**Our list of production users has moved to <https://fluxcd.io/adopters/#flagger>**.
 
-* [Chick-fil-A](https://www.chick-fil-a.com)
-* [Capra Consulting](https://www.capraconsulting.no)
-* [DMM.com](https://dmm-corp.com)
-* [MediaMarktSaturn](https://www.mediamarktsaturn.com)
-* [Weaveworks](https://weave.works)
-* [Jumia Group](https://group.jumia.com)
-
-If you are using Flagger, please submit a PR to add your organization to the list!
+If you are using Flagger, please
+[submit a PR to add your organization](https://github.com/fluxcd/website/tree/main/adopters#readme) to the list!
 
 ### Canary CRD
 
 Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
-then creates a series of objects (Kubernetes deployments, ClusterIP services, service mesh or ingress routes).
+then creates a series of objects (Kubernetes deployments, ClusterIP services, service mesh, or ingress routes).
 These objects expose the application on the mesh and drive the canary analysis and promotion.
 
 Flagger keeps track of ConfigMaps and Secrets referenced by a Kubernetes Deployment and triggers a canary analysis if any of those objects change.
-When promoting a workload in production, both code (container images) and configuration (config maps and secrets) are being synchronised.
+When promoting a workload in production, both code (container images) and configuration (config maps and secrets) are being synchronized.
 
 For a deployment named _podinfo_, a canary promotion can be defined using Flagger's custom resource:
 
@@ -72,7 +70,8 @@ metadata:
   namespace: test
 spec:
   # service mesh provider (optional)
-  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, contour, gloo, supergloo
+  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, contour, gloo, supergloo, traefik, osm
+  # for SMI TrafficSplit can be: smi:v1alpha1, smi:v1alpha2, smi:v1alpha3
   provider: istio
   # deployment reference
   targetRef:
@@ -84,7 +83,7 @@ spec:
   progressDeadlineSeconds: 60
   # HPA reference (optional)
   autoscalerRef:
-    apiVersion: autoscaling/v2beta1
+    apiVersion: autoscaling/v2beta2
     kind: HorizontalPodAutoscaler
     name: podinfo
   service:
@@ -183,60 +182,97 @@ For more details on how the canary analysis and promotion works please [read the
 
 **Service Mesh**
 
-| Feature                                    | App Mesh           | Istio              | Linkerd            |  Kubernetes CNI    |
-| ------------------------------------------ | ------------------ | ------------------ | ------------------ |  ----------------- |
-| Canary deployments (weighted traffic)      | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| A/B testing (headers and cookies routing)  | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: |
-| Blue/Green deployments (traffic switch)    | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Blue/Green deployments (traffic mirroring) | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: |
-| Webhooks (acceptance/load testing)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Manual gating (approve/pause/resume)       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Request success rate check (L7 metric)     | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| Request duration check (L7 metric)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
-| Custom metric checks                       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Feature                                    | App Mesh           | Istio              | Linkerd            | Kuma               | OSM                | Kubernetes CNI     |
+|--------------------------------------------|--------------------|--------------------|--------------------|--------------------|--------------------|--------------------|
+| Canary deployments (weighted traffic)      | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| A/B testing (headers and cookies routing)  | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: |
+| Blue/Green deployments (traffic switch)    | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Blue/Green deployments (traffic mirroring) | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: | :heavy_minus_sign: |
+| Webhooks (acceptance/load testing)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Manual gating (approve/pause/resume)       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Request success rate check (L7 metric)     | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| Request duration check (L7 metric)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: |
+| Custom metric checks                       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
 
 **Ingress**
 
-| Feature                                    | Contour            | Gloo               | NGINX              | Skipper            |
-| ------------------------------------------ | ------------------ | ------------------ | ------------------ | ------------------ |
-| Canary deployments (weighted traffic)      | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| A/B testing (headers and cookies routing)  | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_minus_sign: |
-| Blue/Green deployments (traffic switch)    | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Webhooks (acceptance/load testing)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Manual gating (approve/pause/resume)       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
-| Request success rate check (L7 metric)     | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
-| Request duration check (L7 metric)         | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: |
-| Custom metric checks                       | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Feature                                   | Contour            | Gloo               | NGINX              | Skipper            | Traefik            |
+|-------------------------------------------|--------------------|--------------------|--------------------|--------------------|--------------------|
+| Canary deployments (weighted traffic)     | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| A/B testing (headers and cookies routing) | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_minus_sign: |
+| Blue/Green deployments (traffic switch)   | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Webhooks (acceptance/load testing)        | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Manual gating (approve/pause/resume)      | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+| Request success rate check (L7 metric)    | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: |
+| Request duration check (L7 metric)        | :heavy_check_mark: | :heavy_check_mark: | :heavy_minus_sign: | :heavy_check_mark: | :heavy_check_mark: |
+| Custom metric checks                      | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
+
+**Networking Interface**
+
+| Feature                                       | Gateway API        | SMI                |
+|-----------------------------------------------|--------------------|--------------------|
+| Canary deployments (weighted traffic)         | :heavy_check_mark: | :heavy_check_mark: |
+| A/B testing (headers and cookies routing)     | :heavy_check_mark: | :heavy_minus_sign: |
+| Blue/Green deployments (traffic switch)       | :heavy_check_mark: | :heavy_check_mark: |
+| Blue/Green deployments (traffic mirrroring)   | :heavy_minus_sign: | :heavy_minus_sign: |
+| Webhooks (acceptance/load testing)            | :heavy_check_mark: | :heavy_check_mark: |
+| Manual gating (approve/pause/resume)          | :heavy_check_mark: | :heavy_check_mark: |
+| Request success rate check (L7 metric)        | :heavy_minus_sign: | :heavy_minus_sign: |
+| Request duration check (L7 metric)            | :heavy_minus_sign: | :heavy_minus_sign: |
+| Custom metric checks                          | :heavy_check_mark: | :heavy_check_mark: |
+
+For all [Gateway API](https://gateway-api.sigs.k8s.io/) implementations like
+[Contour](https://projectcontour.io/guides/gateway-api/) or
+[Istio](https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/)
+and [SMI](https://smi-spec.io) compatible service mesh solutions like 
+[Nginx Service Mesh](https://docs.nginx.com/nginx-service-mesh/),
+[Prometheus MetricTemplates](https://docs.flagger.app/usage/metrics#prometheus)
+can be used to implement the request success rate and request duration checks.
 
 ### Roadmap
 
-* Add support for Kubernetes [Ingress v2](https://github.com/kubernetes-sigs/service-apis)
-* Integrate with other service mesh like Consul Connect and ingress controllers like HAProxy, ALB
-* Integrate with other metrics providers like InfluxDB, Stackdriver, SignalFX
-* Add support for comparing the canary metrics to the primary ones and do the validation based on the derivation between the two
+#### [GitOps Toolkit](https://github.com/fluxcd/flux2) compatibility
+
+- Migrate Flagger to Kubernetes controller-runtime and [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder)
+- Make the Canary status compatible with [kstatus](https://github.com/kubernetes-sigs/cli-utils)
+- Make Flagger emit Kubernetes events compatible with Flux v2 notification API
+- Integrate Flagger into Flux v2 as the progressive delivery component
+
+#### Integrations
+
+- Add support for ingress controllers like HAProxy, ALB, and Apache APISIX
+- Add support for Knative Serving
 
 ### Contributing
 
 Flagger is Apache 2.0 licensed and accepts contributions via GitHub pull requests.
 To start contributing please read the [development guide](https://docs.flagger.app/dev/dev-guide).
 
-When submitting bug reports please include as much details as possible:
+When submitting bug reports please include as many details as possible:
 
-* which Flagger version
-* which Flagger CRD version
-* which Kubernetes version
-* what configuration (canary, ingress and workloads definitions)
-* what happened (Flagger and Proxy logs)
+- which Flagger version
+- which Kubernetes version
+- what configuration (canary, ingress and workloads definitions)
+- what happened (Flagger and Proxy logs)
 
-### Getting Help
+### Communication
 
-If you have any questions about Flagger and progressive delivery:
+Here is a list of good entry points into our community, how we stay in touch and how you can meet us as a team.
 
-* Read the Flagger [docs](https://docs.flagger.app).
-* Invite yourself to the [Weave community slack](https://slack.weave.works/)
-  and join the [#flagger](https://weave-community.slack.com/messages/flagger/) channel.
-* Join the [Weave User Group](https://www.meetup.com/pro/Weave/) and get invited to online talks,
-  hands-on training and meetups in your area.
-* File an [issue](https://github.com/weaveworks/flagger/issues/new).
+- Slack: Join in and talk to us in the `#flagger` channel on [CNCF Slack](https://slack.cncf.io/).
+- Public meetings: We run weekly meetings - join one of the upcoming dev meetings from the [Flux calendar](https://fluxcd.io/#calendar).
+- Blog: Stay up to date with the latest news on [the Flux blog](https://fluxcd.io/blog/).
+- Mailing list: To be updated on Flux and Flagger progress regularly, please [join the flux-dev mailing list](https://lists.cncf.io/g/cncf-flux-dev).
 
-Your feedback is always welcome!
+#### Subscribing to the flux-dev calendar
+
+To add the meetings to your e.g. Google calendar
+
+1. visit the [Flux calendar](https://lists.cncf.io/g/cncf-flux-dev/calendar)
+2. click on "Subscribe to Calendar" at the very bottom of the page
+3. copy the iCalendar URL
+4. open e.g. your Google calendar
+5. find the "add calendar" option
+6. choose "add by URL"
+7. paste iCalendar URL (ends with `.ics`)
+8. done

artifacts/examples/kuma-canary.yaml

@@ -0,0 +1,50 @@
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+  annotations:
+    kuma.io/mesh: default
+spec:
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  progressDeadlineSeconds: 60
+  service:
+    port: 9898
+    targetPort: 9898
+    apex:
+      annotations:
+        9898.service.kuma.io/protocol: "http"
+    canary:
+      annotations:
+        9898.service.kuma.io/protocol: "http"
+    primary:
+      annotations:
+        9898.service.kuma.io/protocol: "http"
+  analysis:
+    interval: 15s
+    threshold: 15
+    maxWeight: 50
+    stepWeight: 10
+    metrics:
+      - name: request-success-rate
+        threshold: 99
+        interval: 1m
+      - name: request-duration
+        threshold: 500
+        interval: 30s
+    webhooks:
+      - name: acceptance-test
+        type: pre-rollout
+        url: http://flagger-loadtester.test/
+        timeout: 30s
+        metadata:
+          type: bash
+          cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token"
+      - name: load-test
+        type: rollout
+        url: http://flagger-loadtester.test/
+        metadata:
+          cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.test:9898/"

artifacts/examples/linkerd-canary-steps.yaml

@@ -0,0 +1,51 @@
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  provider: linkerd
+  progressDeadlineSeconds: 600
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  autoscalerRef:
+    apiVersion: autoscaling/v2beta1
+    kind: HorizontalPodAutoscaler
+    name: podinfo
+  service:
+    name: podinfo
+    port: 80
+    targetPort: 9898
+    portName: http
+    portDiscovery: true
+  skipAnalysis: false
+  analysis:
+    interval: 15s
+    threshold: 10
+    stepWeights: [5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55]
+    metrics:
+    - name: request-success-rate
+      thresholdRange:
+        min: 99
+      interval: 1m
+    - name: request-duration
+      thresholdRange:
+        max: 500
+      interval: 30s
+    webhooks:
+    - name: conformance-test
+      type: pre-rollout
+      url: http://flagger-loadtester.test/
+      timeout: 15s
+      metadata:
+        type: "bash"
+        cmd: "curl -sd 'test' http://podinfo-canary.test/token | grep token"
+    - name: load-test
+      type: rollout
+      url: http://flagger-loadtester.test/
+      timeout: 5s
+      metadata:
+        type: cmd
+        cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test/"

artifacts/examples/osm-canary-steps.yaml

@@ -0,0 +1,42 @@
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  provider: osm
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  progressDeadlineSeconds: 600
+  service:
+    port: 9898
+    targetPort: 9898
+  analysis:
+    interval: 15s
+    threshold: 10
+    stepWeights: [5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55]
+    metrics:
+    - name: request-success-rate
+      thresholdRange:
+        min: 99
+      interval: 1m
+    - name: request-duration
+      thresholdRange:
+        max: 500
+      interval: 30s
+    webhooks:
+      - name: acceptance-test
+        type: pre-rollout
+        url: http://flagger-loadtester.test/
+        timeout: 15s
+        metadata:
+          type: bash
+          cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token"
+      - name: load-test
+        type: rollout
+        url: http://flagger-loadtester.test/
+        timeout: 5s
+        metadata:
+          cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"

artifacts/examples/osm-canary.yaml

@@ -0,0 +1,43 @@
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  provider: osm
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  progressDeadlineSeconds: 600
+  service:
+    port: 9898
+    targetPort: 9898
+  analysis:
+    interval: 15s
+    threshold: 10
+    maxWeight: 50
+    stepWeight: 5
+    metrics:
+    - name: request-success-rate
+      thresholdRange:
+        min: 99
+      interval: 1m
+    - name: request-duration
+      thresholdRange:
+        max: 500
+      interval: 30s
+    webhooks:
+      - name: acceptance-test
+        type: pre-rollout
+        url: http://flagger-loadtester.test/
+        timeout: 15s
+        metadata:
+          type: bash
+          cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token"
+      - name: load-test
+        type: rollout
+        url: http://flagger-loadtester.test/
+        timeout: 5s
+        metadata:
+          cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"

artifacts/flagger/account.yaml

@@ -6,7 +6,7 @@ metadata:
   labels:
     app: flagger
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: flagger
@@ -31,6 +31,18 @@ rules:
       - update
       - patch
       - delete
+  - apiGroups:
+      - "coordination.k8s.io"
+    resources:
+      - leases
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
   - apiGroups:
       - apps
     resources:
@@ -78,6 +90,7 @@ rules:
     resources:
       - canaries
       - canaries/status
+      - canaries/finalizers
       - metrictemplates
       - metrictemplates/status
       - alertproviders
@@ -153,8 +166,19 @@ rules:
     resources:
       - upstreams
       - upstreams/finalizers
-      - upstreamgroups
-      - upstreamgroups/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - gateway.solo.io
+    resources:
+      - routetables
+      - routetables/finalizers
     verbs:
       - get
       - list
@@ -176,12 +200,51 @@ rules:
       - update
       - patch
       - delete
+  - apiGroups:
+      - kuma.io
+    resources:
+      - trafficroutes
+      - trafficroutes/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - gateway.networking.k8s.io
+    resources:
+      - httproutes
+      - httproutes/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - keda.sh
+    resources:
+      - scaledobjects
+      - scaledobjects/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
   - nonResourceURLs:
       - /version
     verbs:
       - get
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: flagger

artifacts/flagger/deployment.yaml

@@ -22,7 +22,7 @@ spec:
       serviceAccountName: flagger
       containers:
       - name: flagger
-        image: weaveworks/flagger:1.1.0
+        image: ghcr.io/fluxcd/flagger:1.24.1
         imagePullPolicy: IfNotPresent
         ports:
         - name: http

charts/flagger/Chart.yaml

@@ -1,14 +1,14 @@
 apiVersion: v1
 name: flagger
-version: 1.1.0
-appVersion: 1.1.0
-kubeVersion: ">=1.11.0-0"
+version: 1.24.1
+appVersion: 1.24.1
+kubeVersion: ">=1.19.0-0"
 engine: gotpl
 description: Flagger is a progressive delivery operator for Kubernetes
 home: https://flagger.app
-icon: https://raw.githubusercontent.com/weaveworks/flagger/master/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 sources:
-  - https://github.com/weaveworks/flagger
+  - https://github.com/fluxcd/flagger
 maintainers:
   - name: stefanprodan
     url: https://github.com/stefanprodan
@@ -18,8 +18,12 @@ keywords:
   - istio
   - appmesh
   - linkerd
+  - kuma
+  - osm
+  - smi
   - gloo
   - contour
   - nginx
+  - traefik
   - gitops
   - canary

charts/flagger/LICENSE

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright 2018 Weaveworks. All rights reserved.
+   Copyright [yyyy] [name of copyright owner]
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

charts/flagger/README.md

@@ -1,18 +1,18 @@
 # Flagger
 
-[Flagger](https://github.com/weaveworks/flagger) is an operator that automates the release process of applications on Kubernetes. 
+[Flagger](https://github.com/fluxcd/flagger) is a progressive delivery tool that automates the release process
+for applications running on Kubernetes. It reduces the risk of introducing a new software version in production
+by gradually shifting traffic to the new version while measuring metrics and running conformance tests.
 
-Flagger can run automated application analysis, testing, promotion and rollback for the following deployment strategies:
-* Canary Release (progressive traffic shifting)
-* A/B Testing (HTTP headers and cookies traffic routing)
-* Blue/Green (traffic switching and mirroring)
+Flagger implements several deployment strategies (Canary releases, A/B testing, Blue/Green mirroring)
+and integrates with various Kubernetes ingress controllers, service mesh and monitoring solutions.
 
-Flagger works with service mesh solutions (Istio, Linkerd, AWS App Mesh) and with Kubernetes ingress controllers (NGINX, Skipper, Gloo, Contour).
-Flagger can be configured to send alerts to various chat platforms such as Slack, Microsoft Teams, Discord and Rocket.
+Flagger is a [Cloud Native Computing Foundation](https://cncf.io/) project
+and part of [Flux](https://fluxcd.io) family of GitOps tools.
 
 ## Prerequisites
 
-* Kubernetes >= 1.14
+* Kubernetes >= 1.19
 
 ## Installing the Chart
 
@@ -25,7 +25,7 @@ $ helm repo add flagger https://flagger.app
 Install Flagger's custom resource definitions:
 
 ```console
-$ kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
+$ kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
 ```
 
 To install Flagger for **Istio**:
@@ -37,13 +37,13 @@ $ helm upgrade -i flagger flagger/flagger \
     --set metricsServer=http://prometheus:9090
 ```
 
-To install Flagger for **Linkerd**:
+To install Flagger for **Linkerd** (requires Linkerd Viz extension):
 
 ```console
 $ helm upgrade -i flagger flagger/flagger \
     --namespace=linkerd \
     --set meshProvider=linkerd \
-    --set metricsServer=http://linkerd-prometheus:9090
+    --set metricsServer=http://prometheus.linkerd-viz:9090
 ```
 
 To install Flagger for **AWS App Mesh**:
@@ -55,6 +55,25 @@ $ helm upgrade -i flagger flagger/flagger \
     --set metricsServer=http://appmesh-prometheus:9090
 ```
 
+
+To install Flagger for **Open Service Mesh** (requires OSM to have been installed with Prometheus):
+
+```console
+$ helm upgrade -i flagger flagger/flagger \
+    --namespace=osm-system \
+    --set meshProvider=osm \
+    --set metricsServer=http://osm-prometheus.osm-system.svc:7070
+```
+
+To install Flagger for **Kuma Service Mesh** (requires Kuma to have been installed with Prometheus):
+
+```console
+$ helm upgrade -i flagger flagger/flagger \
+    --namespace=kuma-system \
+    --set meshProvider=kuma \
+    --set metricsServer=http://prometheus-server.kuma-metrics:80
+```
+
 To install Flagger and Prometheus for **NGINX** Ingress (requires controller metrics enabled):
 
 ```console
@@ -64,7 +83,7 @@ $ helm upgrade -i flagger flagger/flagger \
     --set prometheus.install=true
 ```
 
-To install Flagger and Prometheus for **Gloo** (requires Gloo discovery enabled):
+To install Flagger and Prometheus for **Gloo** (no longer requires Gloo discovery):
 
 ```console
 $ helm upgrade -i flagger flagger/flagger \
@@ -83,6 +102,15 @@ $ helm upgrade -i flagger flagger/flagger \
     --set prometheus.install=true
 ```
 
+To install Flagger and Prometheus for **Traefik**:
+
+```console
+$ helm upgrade -i flagger flagger/flagger \
+    --namespace=traefik \
+    --set prometheus.install=true \
+    --set meshProvider=traefik
+```
+
 The [configuration](#configuration) section lists the parameters that can be configured during installation.
 
 ## Uninstalling the Chart
@@ -99,48 +127,57 @@ The command removes all the Kubernetes components associated with the chart and
 
 The following tables lists the configurable parameters of the Flagger chart and their default values.
 
-Parameter | Description | Default
---- | --- | ---
-`image.repository` | Image repository | `weaveworks/flagger`
-`image.tag` | Image tag | `<VERSION>`
-`image.pullPolicy` | Image pull policy | `IfNotPresent`
-`logLevel` | Log level | `info`
-`metricsServer` | Prometheus URL, used when `prometheus.install` is `false` | `http://prometheus.istio-system:9090`
-`prometheus.install` | If `true`, installs Prometheus configured to scrape all pods in the custer | `false`
-`prometheus.retention` |  Prometheus data retention | `2h`
-`selectorLabels` | List of labels that Flagger uses to create pod selectors | `app,name,app.kubernetes.io/name`
-`configTracking.enabled` | If `true`, flagger will track changes in Secrets and ConfigMaps referenced in the target deployment | `true`
-`eventWebhook` | If set, Flagger will publish events to the given webhook | None
-`slack.url` | Slack incoming webhook | None
-`slack.channel` | Slack channel | None
-`slack.user` | Slack username | `flagger`
-`msteams.url` | Microsoft Teams incoming webhook | None
-`podMonitor.enabled` | If `true`, create a PodMonitor for [monitoring the metrics](https://docs.flagger.app/usage/monitoring#metrics) | `false`
-`podMonitor.namespace` | Namespace where the PodMonitor is created | the same namespace 
-`podMonitor.interval` | Interval at which metrics should be scraped | `15s` 
-`podMonitor.podMonitor` | Additional labels to add to the PodMonitor | `{}`
-`leaderElection.enabled` | If `true`, Flagger will run in HA mode | `false`
-`leaderElection.replicaCount` | Number of replicas | `1`
-`serviceAccount.create` | If `true`, Flagger will create service account | `true`
-`serviceAccount.name` | The name of the service account to create or use. If not set and `serviceAccount.create` is `true`, a name is generated using the Flagger fullname | `""`
-`serviceAccount.annotations` | Annotations for service account | `{}`
-`ingressAnnotationsPrefix` | Annotations prefix for ingresses | `custom.ingress.kubernetes.io`
-`rbac.create` | If `true`, create and use RBAC resources | `true`
-`rbac.pspEnabled` | If `true`, create and use a restricted pod security policy | `false`
-`crd.create` | If `true`, create Flagger's CRDs (should be enabled for Helm v2 only) | `false`
-`resources.requests/cpu` | Pod CPU request | `10m`
-`resources.requests/memory` | Pod memory request | `32Mi`
-`resources.limits/cpu` | Pod CPU limit | `1000m`
-`resources.limits/memory` | Pod memory limit | `512Mi`
-`affinity` | Node/pod affinities | None
-`nodeSelector` | Node labels for pod assignment | `{}`
-`threadiness` | Number of controller workers | `2`
-`tolerations` | List of node taints to tolerate | `[]`
-`istio.kubeconfig.secretName` | The name of the Kubernetes secret containing the Istio shared control plane kubeconfig | None
-`istio.kubeconfig.key` | The name of Kubernetes secret data key that contains the Istio control plane kubeconfig | `kubeconfig`
-`ingressAnnotationsPrefix` | Annotations prefix for NGINX ingresses | None
-`ingressClass` | Ingress class used for annotating HTTPProxy objects, e.g. `contour` | None
-`podPriorityClassName` | PriorityClass name for pod priority configuration | ""
+| Parameter                            | Description                                                                                                                                        | Default                               |
+|--------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------|
+| `image.repository`                   | Image repository                                                                                                                                   | `ghcr.io/fluxcd/flagger`              |
+| `image.tag`                          | Image tag                                                                                                                                          | `<VERSION>`                           |
+| `image.pullPolicy`                   | Image pull policy                                                                                                                                  | `IfNotPresent`                        |
+| `logLevel`                           | Log level                                                                                                                                          | `info`                                |
+| `metricsServer`                      | Prometheus URL, used when `prometheus.install` is `false`                                                                                          | `http://prometheus.istio-system:9090` |
+| `prometheus.install`                 | If `true`, installs Prometheus configured to scrape all pods in the custer                                                                         | `false`                               |
+| `prometheus.retention`               | Prometheus data retention                                                                                                                          | `2h`                                  |
+| `selectorLabels`                     | List of labels that Flagger uses to create pod selectors                                                                                           | `app,name,app.kubernetes.io/name`     |
+| `configTracking.enabled`             | If `true`, flagger will track changes in Secrets and ConfigMaps referenced in the target deployment                                                | `true`                                |
+| `eventWebhook`                       | If set, Flagger will publish events to the given webhook                                                                                           | None                                  |
+| `slack.url`                          | Slack incoming webhook                                                                                                                             | None                                  |
+| `slack.proxyUrl`                     | Slack proxy url                                                                                                                                    | None                                  |
+| `slack.channel`                      | Slack channel                                                                                                                                      | None                                  |
+| `slack.user`                         | Slack username                                                                                                                                     | `flagger`                             |
+| `msteams.url`                        | Microsoft Teams incoming webhook                                                                                                                   | None                                  |
+| `msteams.proxyUrl`                   | Microsoft Teams proxy url                                                                                                                          | None                                  |
+| `clusterName`                        | When specified, Flagger will add the cluster name to alerts                                                                                        | `""`                                  |
+| `podMonitor.enabled`                 | If `true`, create a PodMonitor for [monitoring the metrics](https://docs.flagger.app/usage/monitoring#metrics)                                     | `false`                               |
+| `podMonitor.namespace`               | Namespace where the PodMonitor is created                                                                                                          | the same namespace                    |
+| `podMonitor.interval`                | Interval at which metrics should be scraped                                                                                                        | `15s`                                 |
+| `podMonitor.podMonitor`              | Additional labels to add to the PodMonitor                                                                                                         | `{}`                                  |
+| `leaderElection.enabled`             | If `true`, Flagger will run in HA mode                                                                                                             | `false`                               |
+| `leaderElection.replicaCount`        | Number of replicas                                                                                                                                 | `1`                                   |
+| `serviceAccount.create`              | If `true`, Flagger will create service account                                                                                                     | `true`                                |
+| `serviceAccount.name`                | The name of the service account to create or use. If not set and `serviceAccount.create` is `true`, a name is generated using the Flagger fullname | `""`                                  |
+| `serviceAccount.annotations`         | Annotations for service account                                                                                                                    | `{}`                                  |
+| `ingressAnnotationsPrefix`           | Annotations prefix for ingresses                                                                                                                   | `custom.ingress.kubernetes.io`        |
+| `includeLabelPrefix`                 | List of prefixes of labels that are copied when creating primary deployments or daemonsets. Use * to include all                                   | `""`                                  |
+| `rbac.create`                        | If `true`, create and use RBAC resources                                                                                                           | `true`                                |
+| `rbac.pspEnabled`                    | If `true`, create and use a restricted pod security policy                                                                                         | `false`                               |
+| `crd.create`                         | If `true`, create Flagger's CRDs (should be enabled for Helm v2 only)                                                                              | `false`                               |
+| `resources.requests/cpu`             | Pod CPU request                                                                                                                                    | `10m`                                 |
+| `resources.requests/memory`          | Pod memory request                                                                                                                                 | `32Mi`                                |
+| `resources.limits/cpu`               | Pod CPU limit                                                                                                                                      | `1000m`                               |
+| `resources.limits/memory`            | Pod memory limit                                                                                                                                   | `512Mi`                               |
+| `affinity`                           | Node/pod affinities                                                                                                                                | None                                  |
+| `nodeSelector`                       | Node labels for pod assignment                                                                                                                     | `{}`                                  |
+| `threadiness`                        | Number of controller workers                                                                                                                       | `2`                                   |
+| `tolerations`                        | List of node taints to tolerate                                                                                                                    | `[]`                                  |
+| `controlplane.kubeconfig.secretName` | The name of the Kubernetes secret containing the service mesh control plane kubeconfig                                                             | None                                  |
+| `controlplane.kubeconfig.key`        | The name of Kubernetes secret data key that contains the service mesh control plane kubeconfig                                                     | `kubeconfig`                          |
+| `ingressAnnotationsPrefix`           | Annotations prefix for NGINX ingresses                                                                                                             | None                                  |
+| `ingressClass`                       | Ingress class used for annotating HTTPProxy objects, e.g. `contour`                                                                                | None                                  |
+| `podPriorityClassName`               | PriorityClass name for pod priority configuration                                                                                                  | ""                                    |
+| `podDisruptionBudget.enabled`        | A PodDisruptionBudget will be created if `true`                                                                                                    | `false`                               |
+| `podDisruptionBudget.minAvailable`   | The minimal number of available replicas that will be set in the PodDisruptionBudget                                                               | `1`                                   |
+| `podDisruptionBudget.minAvailable`   | The minimal number of available replicas that will be set in the PodDisruptionBudget                                                               | `1`                                   |
+| `noCrossNamespaceRefs`               | If `true`, cross namespace references to custom resources will be disabled                                                                         | `false`                               |
+| `namespace`                          | When specified, Flagger will restrict itself to watching Canary objects from that namespace                                                                   | `""`                                  |
 
 Specify each parameter using the `--set key=value[,key=value]` argument to `helm upgrade`. For example,
 
@@ -160,5 +197,3 @@ $ helm upgrade -i flagger flagger/flagger \
 ```
 
 > **Tip**: You can use the default [values.yaml](values.yaml)
-
-

charts/flagger/templates/deployment.yaml

@@ -7,6 +7,7 @@ metadata:
     app.kubernetes.io/name: {{ template "flagger.name" . }}
     app.kubernetes.io/managed-by: {{ .Release.Service }}
     app.kubernetes.io/instance: {{ .Release.Name }}
+    app.kubernetes.io/version: {{ .Chart.AppVersion }}
 spec:
   replicas: {{ .Values.leaderElection.replicaCount }}
   {{- if eq .Values.leaderElection.enabled false }}
@@ -22,6 +23,12 @@ spec:
       labels:
         app.kubernetes.io/name: {{ template "flagger.name" . }}
         app.kubernetes.io/instance: {{ .Release.Name }}
+        app.kubernetes.io/version: {{ .Chart.AppVersion }}
+      {{- if .Values.podLabels }}
+      {{- range $key, $value := .Values.podLabels }}
+        {{ $key }}: {{ $value | quote }}
+      {{- end }}
+      {{- end }}
       annotations:
         {{- if .Values.podAnnotations }}
 {{ toYaml .Values.podAnnotations | indent 8 }}
@@ -43,10 +50,10 @@ spec:
         - name: {{ .Values.image.pullSecret }}
       {{- end }}
       volumes:
-        {{- if .Values.istio.kubeconfig.secretName }}
+        {{- if .Values.controlplane.kubeconfig.secretName }}
         - name: kubeconfig
           secret:
-            secretName: "{{ .Values.istio.kubeconfig.secretName }}"
+            secretName: "{{ .Values.controlplane.kubeconfig.secretName }}"
         {{- end }}
       {{- if .Values.podPriorityClassName }}
       priorityClassName: {{ .Values.podPriorityClassName }}
@@ -58,9 +65,9 @@ spec:
 {{ toYaml .Values.securityContext.context | indent 12 }}
           {{- end }}
           volumeMounts:
-            {{- if .Values.istio.kubeconfig.secretName }}
+            {{- if .Values.controlplane.kubeconfig.secretName }}
             - name: kubeconfig
-              mountPath: "/tmp/istio-host"
+              mountPath: "/tmp/controlplane"
             {{- end }}
           image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
           imagePullPolicy: {{ .Values.image.pullPolicy }}
@@ -90,6 +97,9 @@ spec:
           {{- if .Values.slack.url }}
           - -slack-url={{ .Values.slack.url }}
           {{- end }}
+          {{- if .Values.slack.proxyUrl }}
+          - -slack-proxy-url={{ .Values.slack.proxyUrl }}
+          {{- end }}
           {{- if .Values.slack.user }}
           - -slack-user={{ .Values.slack.user }}
           {{- end }}
@@ -99,6 +109,9 @@ spec:
           {{- if .Values.msteams.url }}
           - -msteams-url={{ .Values.msteams.url }}
           {{- end }}
+          {{- if .Values.msteams.proxyUrl }}
+          - -msteams-proxy-url={{ .Values.msteams.proxyUrl }}
+          {{- end }}
           {{- if .Values.leaderElection.enabled }}
           - -enable-leader-election=true
           - -leader-election-namespace={{ .Release.Namespace }}
@@ -106,18 +119,33 @@ spec:
           {{- if .Values.ingressAnnotationsPrefix }}
           - -ingress-annotations-prefix={{ .Values.ingressAnnotationsPrefix }}
           {{- end }}
+          {{- if .Values.includeLabelPrefix }}
+          - -include-label-prefix={{ .Values.includeLabelPrefix }}
+          {{- end }}
           {{- if .Values.ingressClass }}
           - -ingress-class={{ .Values.ingressClass }}
           {{- end }}
           {{- if .Values.eventWebhook }}
           - -event-webhook={{ .Values.eventWebhook }}
           {{- end }}
-          {{- if .Values.istio.kubeconfig.secretName }}
-          - -kubeconfig-service-mesh=/tmp/istio-host/{{ .Values.istio.kubeconfig.key }}
+          {{- if .Values.kubeconfigQPS }}
+          - -kubeconfig-qps={{ .Values.kubeconfigQPS }}
+          {{- end }}
+          {{- if .Values.kubeconfigBurst }}
+          - -kubeconfig-burst={{ .Values.kubeconfigBurst }}
+          {{- end }}
+          {{- if .Values.controlplane.kubeconfig.secretName }}
+          - -kubeconfig-service-mesh=/tmp/controlplane/{{ .Values.controlplane.kubeconfig.key }}
           {{- end }}
           {{- if .Values.threadiness }}
           - -threadiness={{ .Values.threadiness }}
           {{- end }}
+          {{- if .Values.clusterName }}
+          - -cluster-name={{ .Values.clusterName }}
+          {{- end }}
+          {{- if .Values.noCrossNamespaceRefs }}
+          - -no-cross-namespace-refs={{ .Values.noCrossNamespaceRefs }}
+          {{- end }}
           livenessProbe:
             exec:
               command:

charts/flagger/templates/pdb.yaml

@@ -0,0 +1,11 @@
+{{- if .Values.podDisruptionBudget.enabled }}
+apiVersion: policy/v1beta1
+kind: PodDisruptionBudget
+metadata:
+  name: {{ template "flagger.name" . }}
+spec:
+  minAvailable: {{ .Values.podDisruptionBudget.minAvailable }}
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: {{ template "flagger.name" . }}
+{{- end }}

charts/flagger/templates/prometheus.yaml

@@ -1,5 +1,5 @@
 {{- if .Values.prometheus.install }}
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: {{ template "flagger.fullname" . }}-prometheus
@@ -24,7 +24,7 @@ rules:
   - nonResourceURLs: ["/metrics"]
     verbs: ["get"]
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: {{ template "flagger.fullname" . }}-prometheus
@@ -255,7 +255,14 @@ spec:
               mountPath: /etc/prometheus
             - name: data-volume
               mountPath: /prometheus/data
-
+          {{- if .Values.prometheus.securityContext.enabled }}
+          securityContext:
+{{ toYaml .Values.prometheus.securityContext.context | indent 12 }}
+          {{- end }}
+      {{- if .Values.prometheus.pullSecret }}
+      imagePullSecrets:
+        - name: {{ .Values.prometheus.pullSecret }}
+      {{- end }}
       volumes:
         - name: config-volume
           configMap:

charts/flagger/templates/rbac.yaml

@@ -1,5 +1,5 @@
 {{- if .Values.rbac.create }}
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
   name: {{ template "flagger.fullname" . }}
@@ -27,6 +27,18 @@ rules:
       - update
       - patch
       - delete
+  - apiGroups:
+      - "coordination.k8s.io"
+    resources:
+      - leases
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
   - apiGroups:
       - apps
     resources:
@@ -74,6 +86,7 @@ rules:
     resources:
       - canaries
       - canaries/status
+      - canaries/finalizers
       - metrictemplates
       - metrictemplates/status
       - alertproviders
@@ -149,8 +162,19 @@ rules:
     resources:
       - upstreams
       - upstreams/finalizers
-      - upstreamgroups
-      - upstreamgroups/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - gateway.solo.io
+    resources:
+      - routetables
+      - routetables/finalizers
     verbs:
       - get
       - list
@@ -172,12 +196,63 @@ rules:
       - update
       - patch
       - delete
+  - apiGroups:
+    - traefik.containo.us
+    resources:
+    - traefikservices
+    verbs:
+    - get
+    - list
+    - watch
+    - create
+    - update
+    - patch
+    - delete
+  - apiGroups:
+      - kuma.io
+    resources:
+      - trafficroutes
+      - trafficroutes/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - gateway.networking.k8s.io
+    resources:
+      - httproutes
+      - httproutes/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
+  - apiGroups:
+      - keda.sh
+    resources:
+      - scaledobjects
+      - scaledobjects/finalizers
+    verbs:
+      - get
+      - list
+      - watch
+      - create
+      - update
+      - patch
+      - delete
   - nonResourceURLs:
       - /version
     verbs:
       - get
 ---
-apiVersion: rbac.authorization.k8s.io/v1beta1
+apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: {{ template "flagger.fullname" . }}

charts/flagger/values.yaml

@@ -1,8 +1,8 @@
 # Default values for flagger.
 
 image:
-  repository: weaveworks/flagger
-  tag: 1.1.0
+  repository: ghcr.io/fluxcd/flagger
+  tag: 1.24.1
   pullPolicy: IfNotPresent
   pullSecret:
 
@@ -19,7 +19,7 @@ podPriorityClassName: ""
 
 metricsServer: "http://prometheus:9090"
 
-# accepted values are kubernetes, istio, linkerd, appmesh, nginx, gloo or supergloo:mesh.namespace (defaults to istio)
+# accepted values are kubernetes, istio, linkerd, appmesh, contour, nginx, gloo, skipper, traefik, osm
 meshProvider: ""
 
 # single namespace restriction
@@ -50,11 +50,15 @@ securityContext:
 # when specified, flagger will publish events to the provided webhook
 eventWebhook: ""
 
+# when specified, flagger will add the cluster name to alerts
+clusterName: ""
+
 slack:
   user: flagger
   channel:
   # incoming webhook https://api.slack.com/incoming-webhooks
   url:
+  proxy:
 
 msteams:
   # MS Teams incoming webhook URL
@@ -72,11 +76,21 @@ podMonitor:
 #    secretKeyRef:
 #      name: slack
 #      key: url
+#- name: SLACK_PROXY_URL
+#  valueFrom:
+#    secretKeyRef:
+#      name: slack
+#      key: proxy-url
 #- name: MSTEAMS_URL
 #  valueFrom:
 #    secretKeyRef:
 #      name: msteams
 #      key: url
+#- name: MSTEAMS_PROXY_URL
+#  valueFrom:
+#    secretKeyRef:
+#      name: msteams
+#      key: proxy-url
 #- name: EVENT_WEBHOOK_URL
 #  valueFrom:
 #    secretKeyRef:
@@ -124,14 +138,31 @@ tolerations: []
 prometheus:
   # to be used with ingress controllers
   install: false
-  image: docker.io/prom/prometheus:v2.19.0
+  image: docker.io/prom/prometheus:v2.39.1
+  pullSecret:
   retention: 2h
+  # when enabled, it will add a security context for the prometheus pod
+  securityContext:
+    enabled: false
+    context:
+      readOnlyRootFilesystem: true
+      runAsUser: 10001
 
-#  Istio multi-cluster service mesh (shared control plane single-network)
-# https://istio.io/docs/setup/install/multicluster/shared-vpn/
-istio:
+kubeconfigQPS: ""
+kubeconfigBurst: ""
+
+#  Multi-cluster service mesh (shared control plane single-network)
+controlplane:
   kubeconfig:
-    # istio.kubeconfig.secretName: The name of the secret containing the Istio control plane kubeconfig
+    # controlplane.kubeconfig.secretName: The name of the secret containing the mesh control plane kubeconfig
     secretName: ""
-    # istio.kubeconfig.key: The name of secret data key that contains the Istio control plane kubeconfig
+    # controlplane.kubeconfig.key: The name of secret data key that contains the mesh control plane kubeconfig
     key: "kubeconfig"
+
+podDisruptionBudget:
+  enabled: false
+  minAvailable: 1
+
+podLabels: {}
+
+noCrossNamespaceRefs: false

charts/grafana/Chart.yaml

@@ -1,12 +1,12 @@
 apiVersion: v1
 name: grafana
-version: 1.4.0
-appVersion: 6.5.1
+version: 1.7.0
+appVersion: 7.2.0
 description: Grafana dashboards for monitoring Flagger canary deployments
-icon: https://raw.githubusercontent.com/weaveworks/flagger/master/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 home: https://flagger.app
 sources:
-  - https://github.com/weaveworks/flagger
+  - https://github.com/fluxcd/flagger
 maintainers:
   - name: stefanprodan
     url: https://github.com/stefanprodan

charts/grafana/README.md

@@ -2,7 +2,7 @@
 
 Grafana dashboards for monitoring progressive deployments powered by Flagger and Prometheus.
 
-![flagger-grafana](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/grafana-canary-analysis.png)
+![flagger-grafana](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/grafana-canary-analysis.png)
 
 ## Prerequisites
 

charts/grafana/dashboards/appmesh.json

@@ -1146,7 +1146,6 @@
     "list": [
       {
         "allValue": null,
-        "current": null,
         "datasource": "prometheus",
         "definition": "query_result(sum(envoy_cluster_upstream_rq) by (kubernetes_namespace))",
         "hide": 0,
@@ -1168,7 +1167,6 @@
       },
       {
         "allValue": null,
-        "current": null,
         "datasource": "prometheus",
         "definition": "query_result(sum(envoy_cluster_upstream_rq{kubernetes_namespace=\"$namespace\",app=~\".*-primary\"}) by (app))",
         "hide": 0,
@@ -1190,7 +1188,6 @@
       },
       {
         "allValue": null,
-        "current": null,
         "datasource": "prometheus",
         "definition": "query_result(sum(envoy_cluster_upstream_rq{kubernetes_namespace=\"$namespace\",app!~\".*-primary\"}) by (app))",
         "hide": 0,

charts/grafana/dashboards/istio.json

@@ -403,7 +403,7 @@
       "steppedLine": false,
       "targets": [
         {
-          "expr": "histogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "interval": "",
           "intervalFactor": 1,
@@ -411,7 +411,7 @@
           "refId": "A"
         },
         {
-          "expr": "histogram_quantile(0.90, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.90, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "hide": false,
           "intervalFactor": 1,
@@ -419,7 +419,7 @@
           "refId": "B"
         },
         {
-          "expr": "histogram_quantile(0.99, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.99, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$primary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "hide": false,
           "intervalFactor": 1,
@@ -509,7 +509,7 @@
       "steppedLine": false,
       "targets": [
         {
-          "expr": "histogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "interval": "",
           "intervalFactor": 1,
@@ -517,7 +517,7 @@
           "refId": "A"
         },
         {
-          "expr": "histogram_quantile(0.90, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.90, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "hide": false,
           "intervalFactor": 1,
@@ -525,7 +525,7 @@
           "refId": "B"
         },
         {
-          "expr": "histogram_quantile(0.99, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le))",
+          "expr": "histogram_quantile(0.99, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\"destination\",destination_workload=~\"$canary\", destination_workload_namespace=~\"$namespace\"}[1m])) by (le)) / 1000",
           "format": "time_series",
           "hide": false,
           "intervalFactor": 1,

charts/grafana/values.yaml

@@ -6,7 +6,7 @@ replicaCount: 1
 
 image:
   repository: grafana/grafana
-  tag: 6.5.1
+  tag: 7.3.4
   pullPolicy: IfNotPresent
 
 podAnnotations: {}
@@ -32,7 +32,7 @@ affinity: {}
 user: admin
 password:
 
-# Istio Prometheus instance
+# Prometheus instance
 url: http://prometheus:9090
 
 # Weave Cloud instance token

charts/loadtester/Chart.yaml

@@ -1,14 +1,14 @@
 apiVersion: v1
 name: loadtester
-version: 0.18.0
-appVersion: 0.18.0
-kubeVersion: ">=1.11.0-0"
+version: 0.26.0
+appVersion: 0.26.0
+kubeVersion: ">=1.19.0-0"
 engine: gotpl
 description: Flagger's load testing services based on rakyll/hey and bojand/ghz that generates traffic during canary analysis when configured as a webhook.
 home: https://docs.flagger.app
-icon: https://raw.githubusercontent.com/weaveworks/flagger/master/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 sources:
-  - https://github.com/weaveworks/flagger
+  - https://github.com/fluxcd/flagger
 maintainers:
   - name: stefanprodan
     url: https://github.com/stefanprodan
@@ -19,5 +19,7 @@ keywords:
   - appmesh
   - linkerd
   - gloo
+  - osm
+  - smi
   - gitops
   - load testing

charts/loadtester/README.md

@@ -1,13 +1,13 @@
 # Flagger load testing service
 
-[Flagger's](https://github.com/weaveworks/flagger) load testing service is based on 
-[rakyll/hey](https://github.com/rakyll/hey) and 
+[Flagger's](https://github.com/fluxcd/flagger) load testing service is based on
+[rakyll/hey](https://github.com/rakyll/hey) and
 [bojand/ghz](https://github.com/bojand/ghz).
 It can be used to generate HTTP and gRPC traffic during canary analysis when configured as a webhook.
 
 ## Prerequisites
 
-* Kubernetes >= 1.11
+* Kubernetes >= 1.19
 
 ## Installing the Chart
 
@@ -26,7 +26,7 @@ helm upgrade -i flagger-loadtester flagger/loadtester
 The command deploys loadtester on the Kubernetes cluster in the default namespace.
 
 > **Tip**: Note that the namespace where you deploy the load tester should
-> have the Istio, App Mesh or Linkerd sidecar injection enabled
+> have the Istio, App Mesh, Linkerd or Open Service Mesh sidecar injection enabled
 
 The [configuration](#configuration) section lists the parameters that can be configured during installation.
 
@@ -44,32 +44,35 @@ The command removes all the Kubernetes components associated with the chart and
 
 The following tables lists the configurable parameters of the load tester chart and their default values.
 
-Parameter | Description | Default
---- | --- | ---
-`image.repository` | Image repository | `quay.io/stefanprodan/flagger-loadtester`
-`image.pullPolicy` | Image pull policy | `IfNotPresent`
-`image.tag` | Image tag | `<VERSION>`
-`replicaCount` | Desired number of pods | `1`
-`serviceAccountName` | Kubernetes service account name | `none` 
-`resources.requests.cpu` | CPU requests | `10m`
-`resources.requests.memory` | Memory requests | `64Mi`
-`tolerations` | List of node taints to tolerate | `[]`
-`affinity` | node/pod affinities | `node`
-`nodeSelector` | Node labels for pod assignment | `{}`
-`service.type` | Type of service | `ClusterIP`
-`service.port` | ClusterIP port | `80`
-`cmd.timeout` | Command execution timeout | `1h`
-`logLevel` | Log level can be debug, info, warning, error or panic | `info`
-`appmesh.enabled` | Create AWS App Mesh v1beta2 virtual node | `false`
-`appmesh.backends` | AWS App Mesh virtual services | `none`
-`istio.enabled` | Create Istio virtual service | `false`
-`istio.host` | Loadtester hostname  | `flagger-loadtester.flagger`
-`istio.gateway.enabled` | Create Istio gateway in namespace | `false`
-`istio.tls.enabled` | Enable TLS in gateway ( TLS secrets should be in namespace ) | `false`
-`istio.tls.httpsRedirect` | Redirect traffic to TLS port | `false`
-`podPriorityClassName` | PriorityClass name for pod priority configuration | ""
-`securityContext.enabled` | Add securityContext to container | ""
-`securityContext.context` | securityContext to add | ""
+| Parameter                          | Description                                                                          | Default                             |
+|------------------------------------|--------------------------------------------------------------------------------------|-------------------------------------|
+| `image.repository`                 | Image repository                                                                     | `ghcr.io/fluxcd/flagger-loadtester` |
+| `image.pullPolicy`                 | Image pull policy                                                                    | `IfNotPresent`                      |
+| `image.tag`                        | Image tag                                                                            | `<VERSION>`                         |
+| `replicaCount`                     | Desired number of pods                                                               | `1`                                 |
+| `serviceAccountName`               | Kubernetes service account name                                                      | `none`                              |
+| `resources.requests.cpu`           | CPU requests                                                                         | `10m`                               |
+| `resources.requests.memory`        | Memory requests                                                                      | `64Mi`                              |
+| `tolerations`                      | List of node taints to tolerate                                                      | `[]`                                |
+| `affinity`                         | node/pod affinities                                                                  | `node`                              |
+| `nodeSelector`                     | Node labels for pod assignment                                                       | `{}`                                |
+| `service.type`                     | Type of service                                                                      | `ClusterIP`                         |
+| `service.port`                     | ClusterIP port                                                                       | `80`                                |
+| `cmd.timeout`                      | Command execution timeout                                                            | `1h`                                |
+| `cmd.namespaceRegexp`              | Restrict access to canaries in matching namespaces                                   | ""                                  |
+| `logLevel`                         | Log level can be debug, info, warning, error or panic                                | `info`                              |
+| `appmesh.enabled`                  | Create AWS App Mesh v1beta2 virtual node                                             | `false`                             |
+| `appmesh.backends`                 | AWS App Mesh virtual services                                                        | `none`                              |
+| `istio.enabled`                    | Create Istio virtual service                                                         | `false`                             |
+| `istio.host`                       | Loadtester hostname                                                                  | `flagger-loadtester.flagger`        |
+| `istio.gateway.enabled`            | Create Istio gateway in namespace                                                    | `false`                             |
+| `istio.tls.enabled`                | Enable TLS in gateway ( TLS secrets should be in namespace )                         | `false`                             |
+| `istio.tls.httpsRedirect`          | Redirect traffic to TLS port                                                         | `false`                             |
+| `podPriorityClassName`             | PriorityClass name for pod priority configuration                                    | ""                                  |
+| `securityContext.enabled`          | Add securityContext to container                                                     | ""                                  |
+| `securityContext.context`          | securityContext to add                                                               | ""                                  |
+| `podDisruptionBudget.enabled`      | A PodDisruptionBudget will be created if `true`                                      | `false`                             |
+| `podDisruptionBudget.minAvailable` | The minimal number of available replicas that will be set in the PodDisruptionBudget | `1`                                 |
 
 Specify each parameter using the `--set key=value[,key=value]` argument to `helm upgrade`. For example,
 
@@ -87,5 +90,3 @@ helm install flagger/loadtester --name flagger-loadtester -f values.yaml
 ```
 
 > **Tip**: You can use the default [values.yaml](values.yaml)
-
-

charts/loadtester/templates/deployment.yaml

@@ -16,8 +16,13 @@ spec:
     metadata:
       labels:
         app: {{ include "loadtester.name" . }}
+        app.kubernetes.io/name: {{ include "loadtester.name" . }}
+      {{- range $key, $value := .Values.podLabels }}
+        {{ $key }}: {{ $value | quote }}
+      {{- end }}
       annotations:
         appmesh.k8s.aws/ports: "444"
+        openservicemesh.io/inbound-port-exclusion-list: "80, 8080"
         {{- if .Values.podAnnotations }}
 {{ toYaml .Values.podAnnotations | indent 8 }}
         {{- end }}
@@ -29,7 +34,7 @@ spec:
       {{- end }}
       {{- if .Values.podPriorityClassName }}
       priorityClassName: {{ .Values.podPriorityClassName }}
-      {{- end }}           
+      {{- end }}
       containers:
         - name: {{ .Chart.Name }}
           {{- if .Values.securityContext.enabled }}
@@ -46,6 +51,7 @@ spec:
             - -port=8080
             - -log-level={{ .Values.logLevel }}
             - -timeout={{ .Values.cmd.timeout }}
+            - -namespace-regexp={{ .Values.cmd.namespaceRegexp }}
           livenessProbe:
             exec:
               command:
@@ -66,8 +72,24 @@ spec:
                 - --spider
                 - http://localhost:8080/healthz
             timeoutSeconds: 5
+          {{- if .Values.env }}
+          env:
+            {{- toYaml .Values.env | nindent 12 }}
+          {{- end }}
           resources:
             {{- toYaml .Values.resources | nindent 12 }}
+          {{- with .Values.volumeMounts }}
+          volumeMounts:
+            {{- toYaml . | nindent 12 }}
+          {{- end }}
+      {{- if .Values.image.pullSecret }}
+      imagePullSecrets:
+        - name: {{ .Values.image.pullSecret }}
+      {{- end }}
+      {{ with .Values.volumes }}
+      volumes:
+        {{- toYaml . | nindent 8 }}
+      {{- end }}
       {{- with .Values.nodeSelector }}
       nodeSelector:
         {{- toYaml . | nindent 8 }}

charts/loadtester/templates/pdb.yaml

@@ -0,0 +1,11 @@
+{{- if .Values.podDisruptionBudget.enabled }}
+apiVersion: policy/v1beta1
+kind: PodDisruptionBudget
+metadata:
+  name: {{ include "loadtester.fullname" . }}
+spec:
+  minAvailable: {{ .Values.podDisruptionBudget.minAvailable }}
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: {{ include "loadtester.name" . }}
+{{- end }}

charts/loadtester/values.yaml

@@ -1,23 +1,29 @@
 replicaCount: 1
 
 image:
-  repository: weaveworks/flagger-loadtester
-  tag: 0.18.0
+  repository: ghcr.io/fluxcd/flagger-loadtester
+  tag: 0.26.0
   pullPolicy: IfNotPresent
+  pullSecret:
+
+podLabels: {}
 
 podAnnotations:
   prometheus.io/scrape: "true"
   prometheus.io/port: "8080"
 
-podPriorityClassName: ""  
+podPriorityClassName: ""
 
 logLevel: info
 cmd:
   timeout: 1h
+  namespaceRegexp: ""
 
 nameOverride: ""
 fullnameOverride: ""
 
+env: []
+
 service:
   type: ClusterIP
   port: 80
@@ -27,6 +33,9 @@ resources:
     cpu: 10m
     memory: 64Mi
 
+volumes: []
+volumeMounts: []
+
 nodeSelector: {}
 
 tolerations: []
@@ -62,15 +71,15 @@ appmesh:
   - podinfo
   - podinfo-canary
 
-#Istio virtual service and gatway settings. TLS secrets should be in namespace before enbaled it. ( secret format loadtester.fullname ) 
+#Istio virtual service and gatway settings. TLS secrets should be in namespace before enbaled it. ( secret format loadtester.fullname )
 istio:
   enabled: false
   host: flagger-loadtester.flagger
   gateway:
-    enabled: false  
+    enabled: false
   tls:
     enabled: false
-    httpsRedirect: false 
+    httpsRedirect: false
 
 # when enabled, it will add a security context for the loadtester pod
 securityContext:
@@ -79,3 +88,7 @@ securityContext:
     readOnlyRootFilesystem: true
     runAsUser: 100
     runAsGroup: 101
+
+podDisruptionBudget:
+  enabled: false
+  minAvailable: 1

charts/podinfo/Chart.yaml

@@ -1,11 +1,11 @@
 apiVersion: v1
-version: 3.1.1
-appVersion: 3.1.0
+version: 6.1.3
+appVersion: 6.1.3
 name: podinfo
 engine: gotpl
 description: Flagger canary deployment demo application
 home: https://docs.flagger.app
-icon: https://raw.githubusercontent.com/weaveworks/flagger/master/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 sources:
   - https://github.com/stefanprodan/podinfo
 maintainers:

charts/podinfo/templates/service.yaml

@@ -1,4 +1,4 @@
-{{- if not .Values.canary.enabled }}
+{{- if and .Values.service.enabled (not .Values.canary.enabled) }}
 apiVersion: v1
 kind: Service
 metadata:

charts/podinfo/templates/tests/jwt.yaml

@@ -12,6 +12,7 @@ metadata:
     sidecar.istio.io/inject: "false"
     linkerd.io/inject: disabled
     appmesh.k8s.aws/sidecarInjectorWebhook: disabled
+    openservicemesh.io/sidecar-injection: disabled
 spec:
   containers:
     - name: tools

charts/podinfo/values.yaml

@@ -1,7 +1,7 @@
 # Default values for podinfo.
 image:
-  repository: stefanprodan/podinfo
-  tag: 3.1.0
+  repository: ghcr.io/stefanprodan/podinfo
+  tag: 6.1.3
   pullPolicy: IfNotPresent
 
 podAnnotations: {}

cmd/flagger/main.go

@@ -1,3 +1,19 @@
+/*
+Copyright 2020 The Flux authors
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+*/
+
 package main
 
 import (
@@ -9,7 +25,8 @@ import (
 	"strings"
 	"time"
 
-	semver "github.com/Masterminds/semver/v3"
+	"github.com/Masterminds/semver/v3"
+	"github.com/go-logr/zapr"
 	"go.uber.org/zap"
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 	"k8s.io/apimachinery/pkg/util/uuid"
@@ -21,29 +38,36 @@ import (
 	"k8s.io/client-go/tools/leaderelection/resourcelock"
 	"k8s.io/client-go/transport"
 	_ "k8s.io/code-generator/cmd/client-gen/generators"
+	"k8s.io/klog/v2"
 
-	"github.com/weaveworks/flagger/pkg/canary"
-	clientset "github.com/weaveworks/flagger/pkg/client/clientset/versioned"
-	informers "github.com/weaveworks/flagger/pkg/client/informers/externalversions"
-	"github.com/weaveworks/flagger/pkg/controller"
-	"github.com/weaveworks/flagger/pkg/logger"
-	"github.com/weaveworks/flagger/pkg/metrics/observers"
-	"github.com/weaveworks/flagger/pkg/notifier"
-	"github.com/weaveworks/flagger/pkg/router"
-	"github.com/weaveworks/flagger/pkg/server"
-	"github.com/weaveworks/flagger/pkg/signals"
-	"github.com/weaveworks/flagger/pkg/version"
+	"github.com/fluxcd/flagger/pkg/canary"
+	clientset "github.com/fluxcd/flagger/pkg/client/clientset/versioned"
+	informers "github.com/fluxcd/flagger/pkg/client/informers/externalversions"
+	"github.com/fluxcd/flagger/pkg/controller"
+	"github.com/fluxcd/flagger/pkg/logger"
+	"github.com/fluxcd/flagger/pkg/metrics/observers"
+	"github.com/fluxcd/flagger/pkg/notifier"
+	"github.com/fluxcd/flagger/pkg/router"
+	"github.com/fluxcd/flagger/pkg/server"
+	"github.com/fluxcd/flagger/pkg/signals"
+	"github.com/fluxcd/flagger/pkg/version"
 )
 
 var (
 	masterURL                string
 	kubeconfig               string
+	kubeconfigQPS            int
+	kubeconfigBurst          int
 	metricsServer            string
 	controlLoopInterval      time.Duration
 	logLevel                 string
 	port                     string
 	msteamsURL               string
+	msteamsProxyURL          string
+	includeLabelPrefix       string
 	slackURL                 string
+	slackToken               string
+	slackProxyURL            string
 	slackUser                string
 	slackChannel             string
 	eventWebhook             string
@@ -60,25 +84,33 @@ var (
 	enableConfigTracking     bool
 	ver                      bool
 	kubeconfigServiceMesh    string
+	clusterName              string
+	noCrossNamespaceRefs     bool
 )
 
 func init() {
 	flag.StringVar(&kubeconfig, "kubeconfig", "", "Path to a kubeconfig. Only required if out-of-cluster.")
+	flag.IntVar(&kubeconfigQPS, "kubeconfig-qps", 100, "Set QPS for kubeconfig.")
+	flag.IntVar(&kubeconfigBurst, "kubeconfig-burst", 250, "Set Burst for kubeconfig.")
 	flag.StringVar(&masterURL, "master", "", "The address of the Kubernetes API server. Overrides any value in kubeconfig. Only required if out-of-cluster.")
 	flag.StringVar(&metricsServer, "metrics-server", "http://prometheus:9090", "Prometheus URL.")
 	flag.DurationVar(&controlLoopInterval, "control-loop-interval", 10*time.Second, "Kubernetes API sync interval.")
 	flag.StringVar(&logLevel, "log-level", "debug", "Log level can be: debug, info, warning, error.")
 	flag.StringVar(&port, "port", "8080", "Port to listen on.")
 	flag.StringVar(&slackURL, "slack-url", "", "Slack hook URL.")
+	flag.StringVar(&slackToken, "slack-token", "", "Slack bot token.")
+	flag.StringVar(&slackProxyURL, "slack-proxy-url", "", "Slack proxy URL.")
 	flag.StringVar(&slackUser, "slack-user", "flagger", "Slack user name.")
 	flag.StringVar(&slackChannel, "slack-channel", "", "Slack channel.")
 	flag.StringVar(&eventWebhook, "event-webhook", "", "Webhook for publishing flagger events")
 	flag.StringVar(&msteamsURL, "msteams-url", "", "MS Teams incoming webhook URL.")
+	flag.StringVar(&msteamsProxyURL, "msteams-proxy-url", "", "MS Teams proxy URL.")
+	flag.StringVar(&includeLabelPrefix, "include-label-prefix", "", "List of prefixes of labels that are copied when creating primary deployments or daemonsets. Use * to include all.")
 	flag.IntVar(&threadiness, "threadiness", 2, "Worker concurrency.")
 	flag.BoolVar(&zapReplaceGlobals, "zap-replace-globals", false, "Whether to change the logging level of the global zap logger.")
 	flag.StringVar(&zapEncoding, "zap-encoding", "json", "Zap logger encoding.")
 	flag.StringVar(&namespace, "namespace", "", "Namespace that flagger would watch canary object.")
-	flag.StringVar(&meshProvider, "mesh-provider", "istio", "Service mesh provider, can be istio, linkerd, appmesh, contour, gloo, nginx or skipper.")
+	flag.StringVar(&meshProvider, "mesh-provider", "istio", "Service mesh provider, can be istio, linkerd, appmesh, contour, gloo, nginx, skipper, traefik, osm or kuma.")
 	flag.StringVar(&selectorLabels, "selector-labels", "app,name,app.kubernetes.io/name", "List of pod labels that Flagger uses to create pod selectors.")
 	flag.StringVar(&ingressAnnotationsPrefix, "ingress-annotations-prefix", "nginx.ingress.kubernetes.io", "Annotations prefix for NGINX ingresses.")
 	flag.StringVar(&ingressClass, "ingress-class", "", "Ingress class used for annotating HTTPProxy objects.")
@@ -87,9 +119,12 @@ func init() {
 	flag.BoolVar(&enableConfigTracking, "enable-config-tracking", true, "Enable secrets and configmaps tracking.")
 	flag.BoolVar(&ver, "version", false, "Print version")
 	flag.StringVar(&kubeconfigServiceMesh, "kubeconfig-service-mesh", "", "Path to a kubeconfig for the service mesh control plane cluster.")
+	flag.StringVar(&clusterName, "cluster-name", "", "Cluster name to be included in alert msgs.")
+	flag.BoolVar(&noCrossNamespaceRefs, "no-cross-namespace-refs", false, "When set to true, Flagger can only refer to resources in the same namespace.")
 }
 
 func main() {
+	klog.InitFlags(nil)
 	flag.Parse()
 
 	if ver {
@@ -105,6 +140,8 @@ func main() {
 		zap.ReplaceGlobals(logger.Desugar())
 	}
 
+	klog.SetLogger(zapr.NewLogger(logger.Desugar()))
+
 	defer logger.Sync()
 
 	stopCh := signals.SetupSignalHandler()
@@ -116,6 +153,9 @@ func main() {
 		logger.Fatalf("Error building kubeconfig: %v", err)
 	}
 
+	cfg.QPS = float32(kubeconfigQPS)
+	cfg.Burst = kubeconfigBurst
+
 	kubeClient, err := kubernetes.NewForConfig(cfg)
 	if err != nil {
 		logger.Fatalf("Error building kubernetes clientset: %v", err)
@@ -130,12 +170,15 @@ func main() {
 	if kubeconfigServiceMesh == "" {
 		kubeconfigServiceMesh = kubeconfig
 	}
-	cfgHost, err := clientcmd.BuildConfigFromFlags(masterURL, kubeconfigServiceMesh)
+	serviceMeshCfg, err := clientcmd.BuildConfigFromFlags(masterURL, kubeconfigServiceMesh)
 	if err != nil {
 		logger.Fatalf("Error building host kubeconfig: %v", err)
 	}
 
-	meshClient, err := clientset.NewForConfig(cfgHost)
+	serviceMeshCfg.QPS = float32(kubeconfigQPS)
+	serviceMeshCfg.Burst = kubeconfigBurst
+
+	meshClient, err := clientset.NewForConfig(serviceMeshCfg)
 	if err != nil {
 		logger.Fatalf("Error building mesh clientset: %v", err)
 	}
@@ -171,7 +214,14 @@ func main() {
 	// start HTTP server
 	go server.ListenAndServe(port, 3*time.Second, logger, stopCh)
 
-	routerFactory := router.NewFactory(cfg, kubeClient, flaggerClient, ingressAnnotationsPrefix, ingressClass, logger, meshClient)
+	setOwnerRefs := true
+	// Router shouldn't set OwnerRefs on resources that they create since the
+	// service mesh/ingress controller is in a different cluster.
+	if cfg.Host != serviceMeshCfg.Host {
+		setOwnerRefs = false
+	}
+
+	routerFactory := router.NewFactory(cfg, kubeClient, flaggerClient, ingressAnnotationsPrefix, ingressClass, logger, meshClient, setOwnerRefs)
 
 	var configTracker canary.Tracker
 	if enableConfigTracking {
@@ -184,7 +234,9 @@ func main() {
 		configTracker = &canary.NopTracker{}
 	}
 
-	canaryFactory := canary.NewFactory(kubeClient, flaggerClient, configTracker, labels, logger)
+	includeLabelPrefixArray := strings.Split(includeLabelPrefix, ",")
+
+	canaryFactory := canary.NewFactory(kubeClient, flaggerClient, configTracker, labels, includeLabelPrefixArray, logger)
 
 	c := controller.NewController(
 		kubeClient,
@@ -199,6 +251,8 @@ func main() {
 		meshProvider,
 		version.VERSION,
 		fromEnv("EVENT_WEBHOOK_URL", eventWebhook),
+		clusterName,
+		noCrossNamespaceRefs,
 	)
 
 	// leader election context
@@ -273,7 +327,7 @@ func startLeaderElection(ctx context.Context, run func(), ns string, kubeClient
 	id = id + "_" + string(uuid.NewUUID())
 
 	lock, err := resourcelock.New(
-		resourcelock.ConfigMapsResourceLock,
+		resourcelock.ConfigMapsLeasesResourceLock,
 		ns,
 		configMapName,
 		kubeClient.CoreV1(),
@@ -313,12 +367,15 @@ func startLeaderElection(ctx context.Context, run func(), ns string, kubeClient
 
 func initNotifier(logger *zap.SugaredLogger) (client notifier.Interface) {
 	provider := "slack"
+	token := fromEnv("SLACK_TOKEN", slackToken)
 	notifierURL := fromEnv("SLACK_URL", slackURL)
+	notifierProxyURL := fromEnv("SLACK_PROXY_URL", slackProxyURL)
 	if msteamsURL != "" || os.Getenv("MSTEAMS_URL") != "" {
 		provider = "msteams"
 		notifierURL = fromEnv("MSTEAMS_URL", msteamsURL)
+		notifierProxyURL = fromEnv("MSTEAMS_PROXY_URL", msteamsProxyURL)
 	}
-	notifierFactory := notifier.NewFactory(notifierURL, slackUser, slackChannel)
+	notifierFactory := notifier.NewFactory(notifierURL, token, notifierProxyURL, slackUser, slackChannel)
 
 	var err error
 	client, err = notifierFactory.Notifier(provider)

cmd/loadtester/main.go

@@ -1,21 +1,39 @@
+/*
+Copyright 2020, 2022 The Flux authors
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+*/
+
 package main
 
 import (
 	"flag"
 	"log"
+	"regexp"
 	"time"
 
-	"github.com/weaveworks/flagger/pkg/loadtester"
-	"github.com/weaveworks/flagger/pkg/logger"
-	"github.com/weaveworks/flagger/pkg/signals"
+	"github.com/fluxcd/flagger/pkg/loadtester"
+	"github.com/fluxcd/flagger/pkg/logger"
+	"github.com/fluxcd/flagger/pkg/signals"
 	"go.uber.org/zap"
 )
 
-var VERSION = "0.18.0"
+var VERSION = "0.26.0"
 var (
 	logLevel          string
 	port              string
 	timeout           time.Duration
+	namespaceRegexp   string
 	zapReplaceGlobals bool
 	zapEncoding       string
 )
@@ -24,6 +42,7 @@ func init() {
 	flag.StringVar(&logLevel, "log-level", "debug", "Log level can be: debug, info, warning, error.")
 	flag.StringVar(&port, "port", "9090", "Port to listen on.")
 	flag.DurationVar(&timeout, "timeout", time.Hour, "Load test exec timeout.")
+	flag.StringVar(&namespaceRegexp, "namespace-regexp", "", "Restrict access to canaries in matching namespaces.")
 	flag.BoolVar(&zapReplaceGlobals, "zap-replace-globals", false, "Whether to change the logging level of the global zap logger.")
 	flag.StringVar(&zapEncoding, "zap-encoding", "json", "Zap logger encoding.")
 }
@@ -50,5 +69,12 @@ func main() {
 	logger.Infof("Starting load tester v%s API on port %s", VERSION, port)
 
 	gateStorage := loadtester.NewGateStorage("in-memory")
-	loadtester.ListenAndServe(port, time.Minute, logger, taskRunner, gateStorage, stopCh)
+
+	var namespaceRegexpCompiled *regexp.Regexp
+	if namespaceRegexp != "" {
+		namespaceRegexpCompiled = regexp.MustCompile(namespaceRegexp)
+	}
+	authorizer := loadtester.NewAuthorizer(namespaceRegexpCompiled)
+
+	loadtester.ListenAndServe(port, time.Minute, logger, taskRunner, gateStorage, authorizer, stopCh)
 }

code-of-conduct.md

@@ -1,73 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, gender identity and expression, level of experience,
-education, socio-economic status, nationality, personal appearance, race,
-religion, or sexual identity and orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
-  advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
-  address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior
-may be reported by contacting stefan.prodan(at)gmail.com. 
-All complaints will be reviewed and investigated and will result in a response that is deemed
-necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of
-an incident. Further details of specific enforcement policies may be
-posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-

docs/gitbook/README.md

@@ -4,35 +4,41 @@ description: Flagger is a progressive delivery Kubernetes operator
 
 # Introduction
 
-[Flagger](https://github.com/weaveworks/flagger) is a **Kubernetes** operator that automates the promotion of
-canary deployments using **Istio**, **Linkerd**, **App Mesh**, **NGINX**, **Skipper**, **Contour** or **Gloo** routing for
-traffic shifting and **Prometheus** metrics for canary analysis. The canary analysis can be extended with webhooks for
-running system integration/acceptance tests, load tests, or any other custom validation.
+[Flagger](https://github.com/fluxcd/flagger) is a progressive delivery tool that automates the release
+process for applications running on Kubernetes. It reduces the risk of introducing a new software
+version in production by gradually shifting traffic to the new version while measuring metrics
+and running conformance tests.
 
-Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators
-like HTTP requests success rate, requests average duration and pods health.
-Based on analysis of the **KPIs** a canary is promoted or aborted, and the analysis result is published to **Slack** or **MS Teams**.
+Flagger implements several deployment strategies (Canary releases, A/B testing, Blue/Green mirroring)
+using a service mesh (App Mesh, Istio, Linkerd, Kuma, Open Service Mesh)
+or an ingress controller (Contour, Gloo, NGINX, Skipper, Traefik) for traffic routing.
+For release analysis, Flagger can query Prometheus, InfluxDB, Datadog, New Relic, CloudWatch, Stackdriver
+or Graphite and for alerting it uses Slack, MS Teams, Discord and Rocket.
 
-![Flagger overview diagram](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-overview.png)
+![Flagger overview diagram](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-overview.png)
 
-Flagger can be configured with Kubernetes custom resources and is compatible with any CI/CD solutions made for Kubernetes.
-Since Flagger is declarative and reacts to Kubernetes events,
-it can be used in **GitOps** pipelines together with Flux CD or JenkinsX.
+Flagger can be configured with Kubernetes custom resources and is compatible with
+any CI/CD solutions made for Kubernetes. Since Flagger is declarative and reacts to Kubernetes events,
+it can be used in **GitOps** pipelines together with tools like [Flux](install/flagger-install-with-flux.md),
+JenkinsX, Carvel, Argo, etc.
 
-This project is sponsored by [Weaveworks](https://www.weave.works/)
+Flagger is a [Cloud Native Computing Foundation](https://cncf.io/) project
+and part of [Flux](https://fluxcd.io) family of GitOps tools.
 
 ## Getting started
 
-To get started with Flagger, chose one of the supported routing providers
-and [install](install/flagger-install-on-kubernetes.md) Flagger with Helm or Kustomize.
+To get started with Flagger, choose one of the supported routing providers and
+[install](install/flagger-install-on-kubernetes.md) Flagger with Helm or Kustomize.
 
-After install Flagger, you can follow one of the tutorials:
+After installing Flagger, you can follow one of these tutorials to get started:
 
 **Service mesh tutorials**
 
 * [Istio](tutorials/istio-progressive-delivery.md)
 * [Linkerd](tutorials/linkerd-progressive-delivery.md)
 * [AWS App Mesh](tutorials/appmesh-progressive-delivery.md)
+* [Open Service Mesh](tutorials/osm-progressive-delivery.md)
+* [Kuma](tutorials/kuma-progressive-delivery.md)
 
 **Ingress controller tutorials**
 
@@ -40,6 +46,7 @@ After install Flagger, you can follow one of the tutorials:
 * [Gloo](tutorials/gloo-progressive-delivery.md)
 * [NGINX Ingress](tutorials/nginx-progressive-delivery.md)
 * [Skipper Ingress](tutorials/skipper-progressive-delivery.md)
+* [Traefik](tutorials/traefik-progressive-delivery.md)
 
 **Hands-on GitOps workshops**
 

docs/gitbook/SUMMARY.md

@@ -6,8 +6,10 @@
 ## Install
 
 * [Flagger Install on Kubernetes](install/flagger-install-on-kubernetes.md)
+* [Flagger Install with Flux](install/flagger-install-with-flux.md)
 * [Flagger Install on GKE Istio](install/flagger-install-on-google-cloud.md)
 * [Flagger Install on EKS App Mesh](install/flagger-install-on-eks-appmesh.md)
+* [Flagger Install on Alibaba ServiceMesh](install/flagger-install-on-alibaba-servicemesh.md)
 
 ## Usage
 
@@ -28,10 +30,13 @@
 * [Gloo Canary Deployments](tutorials/gloo-progressive-delivery.md)
 * [NGINX Canary Deployments](tutorials/nginx-progressive-delivery.md)
 * [Skipper Canary Deployments](tutorials/skipper-progressive-delivery.md)
+* [Traefik Canary Deployments](tutorials/traefik-progressive-delivery.md)
+* [Open Service Mesh Deployments](tutorials/osm-progressive-delivery.md)
+* [Kuma Canary Deployments](tutorials/kuma-progressive-delivery.md)
+* [Gateway API Canary Deployments](tutorials/gatewayapi-progressive-delivery.md)
 * [Blue/Green Deployments](tutorials/kubernetes-blue-green.md)
-* [Crossover Canary Deployments](tutorials/crossover-progressive-delivery.md)
 * [Canary analysis with Prometheus Operator](tutorials/prometheus-operator.md)
-* [Canaries with Helm charts and GitOps](tutorials/canary-helm-gitops.md)
+* [Canary analysis with KEDA ScaledObjects](tutorials/keda-scaledobject.md)
 * [Zero downtime deployments](tutorials/zero-downtime-deployments.md)
 
 ## Dev
@@ -39,3 +44,4 @@
 * [Development Guide](dev/dev-guide.md)
 * [Release Guide](dev/release-guide.md)
 * [Upgrade Guide](dev/upgrade-guide.md)
+

docs/gitbook/dev/dev-guide.md

@@ -2,36 +2,36 @@
 
 This document describes how to build, test and run Flagger from source.
 
-### Setup dev environment
+## Setup dev environment
 
 Flagger is written in Go and uses Go modules for dependency management.
 
 On your dev machine install the following tools:
-* go >= 1.14
-* git >= 2.20
+
+* go >= 1.19
+* git >;= 2.20
 * bash >= 5.0
 * make >= 3.81
-* kubectl >= 1.16
-* kustomize >= 3.5
+* kubectl >= 1.22
+* kustomize >= 4.4
 * helm >= 3.0
 * docker >= 19.03
 
 You'll also need a Kubernetes cluster for testing Flagger.
-You can use Minikube, Kind, Docker desktop or any remote cluster
-(AKS/EKS/GKE/etc) Kubernetes version 1.14 or newer.
+You can use Minikube, Kind, Docker desktop or any remote cluster (AKS/EKS/GKE/etc) Kubernetes version 1.22 or newer.
 
-To start contributing to Flagger, fork the [repository](https://github.com/weaveworks/flagger) on GitHub.
+To start contributing to Flagger, fork the [repository](https://github.com/fluxcd/flagger) on GitHub.
 
 Create a dir inside your `GOPATH`:
 
 ```bash
-mkdir -p $GOPATH/src/github.com/weaveworks
+mkdir -p $GOPATH/src/github.com/fluxcd
 ```
 
 Clone your fork:
 
 ```bash
-cd $GOPATH/src/github.com/weaveworks
+cd $GOPATH/src/github.com/fluxcd
 git clone https://github.com/YOUR_USERNAME/flagger
 cd flagger
 ```
@@ -39,18 +39,18 @@ cd flagger
 Set Flagger repository as upstream:
 
 ```bash
-git remote add upstream https://github.com/weaveworks/flagger.git
+git remote add upstream https://github.com/fluxcd/flagger.git
 ```
 
 Sync your fork regularly to keep it up-to-date with upstream:
 
 ```bash
 git fetch upstream
-git checkout master
-git merge upstream/master
+git checkout main
+git merge upstream/main
 ```
 
-### Build
+## Build
 
 Download Go modules:
 
@@ -58,19 +58,30 @@ Download Go modules:
 go mod download
 ```
 
-Build Flagger binary and container image:
+Build Flagger binary:
 
 ```bash
 make build
 ```
 
-Build load tester binary and container image:
+Build load tester binary:
 
 ```bash
 make loadtester-build
 ```
 
-### Code changes
+## Code changes
+
+We require all commits to be signed. By signing off with your signature, you
+certify that you wrote the patch or otherwise have the right to contribute the
+material by the rules of the [DCO](https://raw.githubusercontent.com/fluxcd/flagger/main/DCO).
+
+If your `user.name` and `user.email` are configured in your Git config,
+you can sign your commit automatically with:
+
+```bash
+git commit -s
+```
 
 Before submitting a PR, make sure your changes are covered by unit tests.
 
@@ -89,6 +100,8 @@ make codegen
 Run code formatters:
 
 ```bash
+go install golang.org/x/tools/cmd/goimports@latest
+
 make fmt
 ```
 
@@ -98,7 +111,7 @@ Run unit tests:
 make test
 ```
 
-### API changes
+## API changes
 
 If you made changes to `pkg/apis` regenerate the Kubernetes client sets with:
 
@@ -114,10 +127,11 @@ make crd
 
 Note that any change to the CRDs must be accompanied by an update to the Open API schema.
 
-### Manual testing
+## Manual testing
 
-Install a service mesh and/or an ingress controller on your cluster and deploy Flagger
-using one of the install options [listed here](https://docs.flagger.app/install/flagger-install-on-kubernetes).
+Install a service mesh and/or an ingress controller on your cluster
+and deploy Flagger using one of the install options
+[listed here](https://docs.flagger.app/install/flagger-install-on-kubernetes).
 
 If you made changes to the CRDs, apply your local copy with:
 
@@ -150,7 +164,7 @@ Another option to manually test your changes is to build and push the image to y
 
 ```bash
 make build
-docker tag weaveworks/flagger:latest <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG>
+docker build -t <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG> .
 docker push <YOUR-DOCKERHUB-USERNAME>/flagger:<YOUR-TAG>
 ```
 
@@ -163,7 +177,7 @@ kubectl -n istio-system scale deployment/flagger --replicas=1
 
 Now you can use one of the [tutorials](https://docs.flagger.app/) to manually test your changes.
 
-### Integration testing
+## Integration testing
 
 Flagger end-to-end tests can be run locally with [Kubernetes Kind](https://github.com/kubernetes-sigs/kind).
 
@@ -173,39 +187,22 @@ Create a Kind cluster:
 kind create cluster
 ```
 
-Install a service mesh and/or an ingress controller in Kind.
-
-Linkerd example:
-
-```bash
-linkerd install | kubectl apply -f -
-linkerd check
-```
-
 Build Flagger container image and load it on the cluster:
 
 ```bash
 make build
-docker tag weaveworks/flagger:latest test/flagger:latest
+docker build -t test/flagger:latest .
 kind load docker-image test/flagger:latest
 ```
 
-Install Flagger on the cluster and set the test image:
+
+Run the Istio e2e tests:
 
 ```bash
-kubectl apply -k ./kustomize/linkerd
-kubectl -n linkerd set image deployment/flagger flagger=test/flagger:latest
-kubectl -n linkerd rollout status deployment/flagger
+./test/istio/run.sh
 ```
 
-Run the Linkerd e2e tests:
-
-```bash
-./test/e2e-linkerd-tests.sh
-```
-
-For each service mesh and ingress controller there is a dedicated e2e test suite,
-chose one that matches your changes from this [list](https://github.com/weaveworks/flagger/tree/master/test).
+For each service mesh and ingress controller, there is a dedicated e2e test suite,
+choose one that matches your changes from this [list](https://github.com/fluxcd/flagger/tree/main/test).
 
 When you open a pull request on Flagger repo, the unit and integration tests will be run in CI.
-

docs/gitbook/dev/release-guide.md

@@ -2,33 +2,33 @@
 
 This document describes how to release Flagger.
 
-### Release
+## Release
 
 To release a new Flagger version (e.g. `2.0.0`) follow these steps:
+
 * create a branch `git checkout -b prep-2.0.0`
 * set the version in code and manifests `TAG=2.0.0 make version-set`
 * commit changes and merge PR
-* checkout master `git checkout master && git pull`
+* checkout master `git checkout main && git pull`
 * tag master `make release`
 
-### CI
+## CI
 
 After the tag has been pushed to GitHub, the CI release pipeline does the following:
+
 * creates a GitHub release
 * pushes the Flagger binary and change log to GitHub release
 * pushes the Flagger container image to Docker Hub
 * pushes the Helm chart to github-pages branch
 * GitHub pages publishes the new chart version on the Helm repository
 
-### Docs
+## Docs
 
 The documentation [website](https://docs.flagger.app) is built from the `docs` branch.
 
 After a Flagger release, publish the docs with:
-* `git checkout master && git pull`
+
+* `git checkout main && git pull`
 * `git checkout docs`
-* `git rebase master`
+* `git rebase main`
 * `git push origin docs`
-
-
-

docs/gitbook/dev/upgrade-guide.md

@@ -2,9 +2,10 @@
 
 This document describes how to upgrade Flagger.
 
-### Upgrade canaries v1alpha3 to v1beta1
+## Upgrade canaries v1alpha3 to v1beta1
 
 Canary CRD changes in `canaries.flagger.app/v1beta1`:
+
 * the `spec.canaryAnalysis` field has been deprecated and replaced with `spec.analysis`
 * the `spec.analysis.interval` and `spec.analysis.threshold` fields are required
 * the `status.lastAppliedSpec` and `status.lastPromotedSpec` hashing algorithm changed to `hash/fnv`
@@ -17,17 +18,17 @@ Canary CRD changes in `canaries.flagger.app/v1beta1`:
 * the `spec.service.meshName` field has been deprecated and no longer used for `provider: appmesh:v1beta2`
 
 Upgrade procedure:
+
 * install the `v1beta1` CRDs
 * update Flagger deployment
 * replace `apiVersion: flagger.app/v1alpha3` with `apiVersion: flagger.app/v1beta1` in all canary manifests
 * replace `spec.canaryAnalysis` with `spec.analysis` in all canary manifests
 * update canary manifests in cluster
 
-**Note** that after upgrading Flagger, all canaries will be triggered as the hash value used for tracking changes
-is computed differently. You can set `spec.skipAnalysis: true` in all canary manifests before upgrading Flagger,
-do the upgrade, wait for Flagger to finish the no-op promotions and finally set `skipAnalysis` to `false`.
+**Note** that after upgrading Flagger, all canaries will be triggered as the hash value used for tracking changes is computed differently. You can set `spec.skipAnalysis: true` in all canary manifests before upgrading Flagger, do the upgrade, wait for Flagger to finish the no-op promotions and finally set `skipAnalysis` to `false`.
 
 Update builtin metrics:
+
 * replace `threshold` with `thresholdRange.min` for request-success-rate
 * replace `threshold` with `thresholdRange.max` for request-duration
 
@@ -43,11 +44,9 @@ metrics:
   interval: 1m
 ```
 
-### Istio telemetry v2
+## Istio telemetry v2
 
-Istio 1.5 comes with a breaking change for Flagger uses. In Istio telemetry v2 the metric 
-`istio_request_duration_seconds_bucket` has been removed and replaced with `istio_request_duration_milliseconds_bucket`
-and this breaks the `request-duration` metric check.
+Istio 1.5 comes with a breaking change for Flagger uses. In Istio telemetry v2 the metric `istio_request_duration_seconds_bucket` has been removed and replaced with `istio_request_duration_milliseconds_bucket` and this breaks the `request-duration` metric check.
 
 If are using **Istio 1.4**, you can create a metric template using the old duration metric like this:
 
@@ -88,3 +87,4 @@ metrics:
     max: 0.500
   interval: 1m
 ```
+

docs/gitbook/faq.md

@@ -1,32 +1,35 @@
-# Frequently asked questions
+# FAQ
 
-### Deployment Strategies
+## Deployment Strategies
 
-**Which deployment strategies are supported by Flagger?**
+#### Which deployment strategies are supported by Flagger?
 
 Flagger implements the following deployment strategies:
+
 * [Canary Release](usage/deployment-strategies.md#canary-release)
-* [A/B Testing](usage/deployment-strategies.md#a-b-testing)
-* [Blue/Green](usage/deployment-strategies.md#blue-green-deployments)
-* [Blue/Green Mirroring](usage/deployment-strategies.md#blue-green-with-traffic-mirroring)
+* [A/B Testing](usage/deployment-strategies.md#ab-testing)
+* [Blue/Green](usage/deployment-strategies.md#bluegreen-deployments)
+* [Blue/Green Mirroring](usage/deployment-strategies.md#bluegreen-with-traffic-mirroring)
 
-**When should I use A/B testing instead of progressive traffic shifting?**
+#### When should I use A/B testing instead of progressive traffic shifting?
 
-For frontend applications that require session affinity you should use HTTP headers or cookies match conditions
-to ensure a set of users will stay on the same version for the whole duration of the canary analysis.
+For frontend applications that require session affinity, you should use HTTP headers or
+cookie match conditions to ensure a set of users will stay on the same version for
+the whole duration of the canary analysis.
 
-**Can I use Flagger to manage applications that live outside of a service mesh?**
+#### Can I use Flagger to manage applications that live outside of a service mesh?
 
-For applications that are not deployed on a service mesh, Flagger can orchestrate Blue/Green style deployments 
-with Kubernetes L4 networking. 
+For applications that are not deployed on a service mesh,
+Flagger can orchestrate Blue/Green style deployments with Kubernetes L4 networking.
 
-**When can I use traffic mirroring?**
+#### When can I use traffic mirroring?
 
 Traffic mirroring can be used for Blue/Green deployment strategy or a pre-stage in a Canary release.
 Traffic mirroring will copy each incoming request, sending one request to the primary and one to the canary service.
-Mirroring should be used for requests that are **idempotent** or capable of being processed twice (once by the primary and once by the canary).
+Mirroring should be used for requests that are **idempotent**
+or capable of being processed twice (once by the primary and once by the canary).
 
-**How to retry a failed release?**
+#### How to retry a failed release?
 
 A canary analysis is triggered by changes in any of the following objects:
 
@@ -46,11 +49,45 @@ spec:
         timestamp: "2020-03-10T14:24:48+0000"
 ```
 
-### Kubernetes services
+#### How to change replicas for a deployment when not using HPA?
 
-**How is an application exposed inside the cluster?**
+To change replicas for a deployment when not using HPA, you have to update the canary deployment with the desired replica count
+and trigger an analysis by annotating the template. After the analysis finishes, Flagger will promote the `spec.replicas` changes to the primary deployment.
 
-Assuming the app name is podinfo you can define a canary like:
+Example:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+spec:
+  replicas: 4  #update replicas
+  template:
+    metadata:
+      annotations:
+        timestamp: "2022-02-10T14:24:48+0000" #add annotation to trigger analysis
+```
+
+#### Why is there a window of downtime during the canary initializing process when analysis is disabled?
+
+A window of downtime is the intended behavior when the analysis is disabled. This allows instant rollback and also mimics the way
+a Kubernetes deployment initialization works. To avoid this, enable the analysis (`skipAnalysis: true`), wait for the initialization
+to finish, and disable it afterward (`skipAnalysis: false`).
+
+#### How to disable cross namespace references?
+
+Flagger by default can access resources across namespaces (`AlertProivder`, `MetricProvider` and Gloo `Upsteream`).
+If you're in a multi-tenant environment and wish to disable this, you can do so through the `no-cross-namespace-refs` flag.
+
+```
+flagger \
+  -no-cross-namespace-refs=true \
+  ...
+```
+
+## Kubernetes services
+
+#### How is an application exposed inside the cluster?
+
+Assuming the app name is `podinfo`, you can define a canary like:
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -74,20 +111,26 @@ spec:
     portName: http
 ```
 
-If the `service.name` is not specified, then `targetRef.name` is used for the apex domain and canary/primary services name prefix.
-You should treat the service name as an immutable field, changing it could result in routing conflicts.
+If the `service.name` is not specified, then `targetRef.name` is used for
+the apex domain and canary/primary services name prefix.
+You should treat the service name as an immutable field; changing its could result in routing conflicts.
 
 Based on the canary spec service, Flagger generates the following Kubernetes ClusterIP service:
 
-* `<service.name>.<namespace>.svc.cluster.local`  
+* `<service.name>.<namespace>.svc.cluster.local`
+
     selector `app=<name>-primary`
-* `<service.name>-primary.<namespace>.svc.cluster.local`  
+
+* `<service.name>-primary.<namespace>.svc.cluster.local`
+
     selector `app=<name>-primary`
-* `<service.name>-canary.<namespace>.svc.cluster.local`  
+
+* `<service.name>-canary.<namespace>.svc.cluster.local`
+
     selector `app=<name>`
 
 This ensures that traffic coming from a namespace outside the mesh to `podinfo.test:9898`
-will be routed to the latest stable release of your app. 
+will be routed to the latest stable release of your app.
 
 ```yaml
 apiVersion: v1
@@ -133,15 +176,15 @@ spec:
     targetPort: http
 ```
 
-The `podinfo-canary.test:9898` address is available only during the 
-canary analysis and can be used for conformance testing or load testing.
+The `podinfo-canary.test:9898` address is available only during the canary analysis
+and can be used for conformance testing or load testing.
 
-### Multiple ports
+## Multiple ports
 
-**My application listens on multiple ports, how can I expose them inside the cluster?**
+#### My application listens on multiple ports. How can I expose them inside the cluster?
 
-If port discovery is enabled, Flagger scans the deployment spec and extracts the containers 
-ports excluding the port specified in the canary service and Envoy sidecar ports. 
+If port discovery is enabled, Flagger scans the deployment spec and extracts the containers ports excluding
+the port specified in the canary service and Envoy sidecar ports.
 These ports will be used when generating the ClusterIP services.
 
 For a deployment that exposes two ports:
@@ -184,9 +227,9 @@ spec:
 
 Both port `8080` and `9090` will be added to the ClusterIP services.
 
-### Label selectors
+## Label selectors
 
-**What labels selectors are supported by Flagger?**
+#### What labels selectors are supported by Flagger?
 
 The target deployment must have a single label selector in the format `app: <DEPLOYMENT-NAME>`:
 
@@ -205,14 +248,93 @@ spec:
         app: podinfo
 ```
 
-Besides `app` Flagger supports `name` and `app.kubernetes.io/name` selectors. If you use a different 
-convention you can specify your label with the `-selector-labels` flag.
+Besides `app`, Flagger supports `name` and `app.kubernetes.io/name` selectors.
+If you use a different convention, you can specify your label with the `-selector-labels` flag.
+For example:
 
-**Is pod affinity and anti affinity supported?**
+```
+flagger \
+  -selector-labels=service,name,app.kubernetes.io/name \
+  ...
+```
 
-For pod affinity to work you need to use a different label than the `app`, `name` or `app.kubernetes.io/name`.
+#### Is pod affinity and anti affinity supported?
 
-Anti affinity example:
+Flagger will rewrite the first value in each match expression,
+defined in the target deployment's pod anti-affinity and topology spread constraints,
+satisfying the following two requirements when creating, or updating, the primary deployment:
+
+* The key in the match expression must be one of the labels specified by the parameter selector-labels.
+  The default labels are `app`,`name`,`app.kubernetes.io/name`.
+* The value must match the name of the target deployment.
+
+The rewrite done by Flagger in these cases is to suffix the value with `-primary`.
+This rewrite can be used to spread the pods created by the canary
+and primary deployments across different availability zones.
+
+Example target deployment:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: podinfo
+spec:
+  selector:
+    matchLabels:
+      app: podinfo
+  template:
+    metadata:
+      labels:
+        app: podinfo
+    spec:
+      affinity:
+        podAntiAffinity:
+          preferredDuringSchedulingIgnoredDuringExecution:
+          - weight: 100
+            podAffinityTerm:
+              labelSelector:
+                matchExpressions:
+                - key: app
+                  operator: In
+                  values:
+                    - podinfo
+              topologyKey: topology.kubernetes.io/zone
+```
+
+Example of generated primary deployment:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: podinfo-primary
+spec:
+  selector:
+    matchLabels:
+      app: podinfo-primary
+  template:
+    metadata:
+      labels:
+        app: podinfo-primary
+    spec:
+      affinity:
+        podAntiAffinity:
+          preferredDuringSchedulingIgnoredDuringExecution:
+          - weight: 100
+            podAffinityTerm:
+              labelSelector:
+                matchExpressions:
+                - key: app
+                  operator: In
+                  values:
+                    - podinfo-primary
+              topologyKey: topology.kubernetes.io/zone
+```
+
+It is also possible to use a different label than the `app`, `name` or `app.kubernetes.io/name`.
+
+Anti affinity example(using a different label):
 
 ```yaml
 apiVersion: apps/v1
@@ -238,16 +360,16 @@ spec:
               labelSelector:
                 matchLabels:
                   affinity: podinfo
-              topologyKey: kubernetes.io/hostname
+              topologyKey: topology.kubernetes.io/zone
 ```
 
-### Metrics
+## Metrics
 
-**How does Flagger measures the request success rate and duration?**
+#### How does Flagger measure the request success rate and duration?
 
-Flagger measures the request success rate and duration using Prometheus queries.
+By default, Flagger measures the request success rate and duration using Prometheus queries.
 
-**HTTP requests success rate percentage**
+#### HTTP requests success rate percentage
 
 Spec:
 
@@ -274,8 +396,8 @@ sum(
           response_code!~"5.*"
         }[$interval]
     )
-) 
-/ 
+)
+/
 sum(
     rate(
         istio_requests_total{
@@ -287,7 +409,7 @@ sum(
 )
 ```
 
-Envoy query (App Mesh, Contour or Gloo):
+Envoy query (App Mesh):
 
 ```javascript
 sum(
@@ -298,8 +420,8 @@ sum(
           envoy_response_code!~"5.*"
         }[$interval]
     )
-) 
-/ 
+)
+/
 sum(
     rate(
         envoy_cluster_upstream_rq{
@@ -310,7 +432,28 @@ sum(
 )
 ```
 
-**HTTP requests milliseconds duration P99**
+Envoy query (Contour and Gloo):
+
+```javascript
+sum(
+    rate(
+        envoy_cluster_upstream_rq{
+            envoy_cluster_name=~"$namespace-$workload",
+            envoy_response_code!~"5.*"
+        }[$interval]
+    )
+)
+/
+sum(
+    rate(
+        envoy_cluster_upstream_rq{
+            envoy_cluster_name=~"$namespace-$workload",
+        }[$interval]
+    )
+)
+```
+
+#### HTTP requests milliseconds duration P99
 
 Spec:
 
@@ -328,10 +471,10 @@ Spec:
 Istio query:
 
 ```javascript
-histogram_quantile(0.99, 
+histogram_quantile(0.99,
   sum(
     irate(
-      istio_request_duration_seconds_bucket{
+      istio_request_duration_milliseconds_bucket{
         reporter="destination",
         destination_workload=~"$workload",
         destination_workload_namespace=~"$namespace"
@@ -341,10 +484,10 @@ histogram_quantile(0.99,
 )
 ```
 
-Envoy query (App Mesh, Contour or Gloo):
+Envoy query (App Mesh, Contour and Gloo):
 
 ```javascript
-histogram_quantile(0.99, 
+histogram_quantile(0.99,
   sum(
     irate(
       envoy_cluster_upstream_rq_time_bucket{
@@ -358,20 +501,47 @@ histogram_quantile(0.99,
 
 > **Note** that the metric interval should be lower or equal to the control loop interval.
 
-**Can I use custom metrics?**
+#### Can I use custom metrics?
 
-The analysis can be extended with metrics provided by Prometheus, Datadog and AWS CloudWatch. For more details 
-on how custom metrics can be used please read the [metrics docs](usage/metrics.md).
+The analysis can be extended with metrics provided by Prometheus, Datadog, AWS CloudWatch, New Relic and Graphite.
+For more details on how custom metrics can be used, please read the [metrics docs](usage/metrics.md).
 
-### Istio routing
+#### Istio Gateway API
 
-**How does Flagger interact with Istio?**
+If you're using Istio with Gateway API, the Prometheus query needs to include `reporter="source"`. For example, to calculate HTTP requests error percentage, the query would be:
 
-Flagger creates an Istio Virtual Service and Destination Rules based on the Canary service spec. 
-The service configuration lets you expose an app inside or outside the mesh.
-You can also define traffic policies, HTTP match conditions, URI rewrite rules, CORS policies, timeout and retries.
+```javascript
+100 - sum(
+    rate(
+        istio_requests_total{
+          reporter="source",
+          destination_workload_namespace=~"$namespace",
+          destination_workload=~"$workload",
+          response_code!~"5.*"
+        }[$interval]
+    )
+)
+/
+sum(
+    rate(
+        istio_requests_total{
+          reporter="source",
+          destination_workload_namespace=~"$namespace",
+          destination_workload=~"$workload"
+        }[$interval]
+    )
+) * 100
+```
 
-The following spec exposes the `frontend` workload inside the mesh on `frontend.test.svc.cluster.local:9898` 
+## Istio routing
+
+#### How does Flagger interact with Istio?
+
+Flagger creates an Istio Virtual Service and Destination Rules based on the Canary service spec.
+The service configuration lets you expose an app inside or outside the mesh. You can also define traffic policies,
+HTTP match conditions, URI rewrite rules, CORS policies, timeout and retries.
+
+The following spec exposes the `frontend` workload inside the mesh on `frontend.test.svc.cluster.local:9898`
 and outside the mesh on `frontend.example.com`. You'll have to specify an Istio ingress gateway for external hosts.
 
 ```yaml
@@ -551,15 +721,96 @@ spec:
     app: backend-primary
 ```
 
-Flagger works for user facing apps exposed outside the cluster via an ingress gateway
-and for backend HTTP APIs that are accessible only from inside the mesh.
+Flagger works for user facing apps exposed outside the cluster via an ingress gateway and for backend HTTP APIs
+that are accessible only from inside the mesh.
 
-### Istio Ingress Gateway
+If `Delegation` is enabled, Flagger would generate Istio VirtualService without hosts and gateway,
+making the service compatible with Istio delegation.
 
-**How can I expose multiple canaries on the same external domain?**
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: backend
+  namespace: test
+spec:
+  service:
+    delegation: true
+    port: 9898
+  targetRef:
+    apiVersion: v1
+    kind: Deployment
+    name: podinfo
+  analysis:
+    interval: 15s
+    threshold: 15
+    maxWeight: 30
+    stepWeight: 10
+```
 
-Assuming you have two apps, one that servers the main website and one that serves the REST API.
-For each app you can define a canary object as:
+Based on the above spec, Flagger will create the following virtual service:
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+  name: backend
+  namespace: test
+  ownerReferences:
+  - apiVersion: flagger.app/v1beta1
+    blockOwnerDeletion: true
+    controller: true
+    kind: Canary
+    name: backend
+    uid: 58562662-5e10-4512-b269-2b789c1b30fe
+spec:
+  http:
+  - route:
+    - destination:
+        host: podinfo-primary
+      weight: 100
+    - destination:
+        host: podinfo-canary
+      weight: 0
+```
+
+Therefore, the following virtual service forwards the traffic to `/podinfo` by the above delegate VirtualService.
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: VirtualService
+metadata:
+  name: frontend
+  namespace: test
+spec:
+  gateways:
+    - public-gateway.istio-system.svc.cluster.local
+    - mesh
+  hosts:
+    - frontend.example.com
+    - frontend
+  http:
+  - match:
+    - uri:
+        prefix: /podinfo
+    rewrite:
+      uri: /
+    delegate:
+      name: backend
+      namespace: test
+```
+
+Note that pilot env `PILOT_ENABLE_VIRTUAL_SERVICE_DELEGATE` must also be set.
+For the use of Istio Delegation, you can refer to the documentation of
+[Virtual Service](https://istio.io/latest/docs/reference/config/networking/virtual-service/#Delegate)
+and [pilot environment variables](https://istio.io/latest/docs/reference/commands/pilot-discovery/#envvars).
+
+## Istio Ingress Gateway
+
+#### How can I expose multiple canaries on the same external domain?
+
+Assuming you have two apps -- one that serves the main website and one that serves its REST API --
+you can define a canary object for each app as:
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -597,15 +848,17 @@ spec:
       uri: /
 ```
 
-Based on the above configuration, Flagger will create two virtual services bounded to the same ingress gateway and external host.
-Istio Pilot will [merge](https://istio.io/help/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host)
-the two services and the website rule will be moved to the end of the list in the merged configuration. 
+Based on the above configuration, Flagger will create two virtual services bounded
+to the same ingress gateway and external host.
+Istio Pilot will
+[merge](https://istio.io/help/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host)
+the two services and the website rule will be moved to the end of the list in the merged configuration.
 
-Note that host merging only works if the canaries are bounded to a ingress gateway other than the `mesh` gateway.
+Note that host merging only works if the canaries are bounded to an ingress gateway other than the `mesh` gateway.
 
-### Istio Mutual TLS
+## Istio Mutual TLS
 
-**How can I enable mTLS for a canary?**
+#### How can I enable mTLS for a canary?
 
 When deploying Istio with global mTLS enabled, you have to set the TLS mode to `ISTIO_MUTUAL`:
 
@@ -619,7 +872,7 @@ spec:
         mode: ISTIO_MUTUAL
 ```
 
-If you run Istio in permissive mode you can disable TLS:
+If you run Istio in permissive mode, you can disable TLS:
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -631,12 +884,13 @@ spec:
         mode: DISABLE
 ```
 
-**If Flagger is outside of the mesh, how can it start the load test?**
+#### If Flagger is outside of the mesh, how can it start the load test?
 
-In order for Flagger to be able to call the load tester service from outside the mesh, you need to disable mTLS on port 80:
+In order for Flagger to be able to call the load tester service from outside the mesh,
+you need to disable mTLS:
 
 ```yaml
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1beta1
 kind: DestinationRule
 metadata:
   name: flagger-loadtester
@@ -647,14 +901,54 @@ spec:
     tls:
       mode: DISABLE
 ---
-apiVersion: authentication.istio.io/v1alpha1
-kind: Policy
+apiVersion: security.istio.io/v1beta1
+kind: PeerAuthentication
 metadata:
   name: flagger-loadtester
   namespace: test
 spec:
-  targets:
-  - name: flagger-loadtester
-    ports:
-    - number: 80
+  selector:
+    matchLabels:
+      app: flagger-loadtester
+  mtls:
+    mode: DISABLE
 ```
+
+## ExternalDNS
+
+### Can I use annotations?
+
+Flagger propagates annotations (and labels) to all the generated apex,
+primary and canary objects. This allows using external-dns annotations.
+
+You can configure Flagger to set annotations with:
+
+```yaml
+spec:
+  service:
+    apex:
+      annotations:
+        external-dns.alpha.kubernetes.io/hostname: "mydomain.com"
+    primary:
+      annotations:
+        external-dns.alpha.kubernetes.io/hostname: "primary.mydomain.com"
+    canary:
+      annotations:
+        external-dns.alpha.kubernetes.io/hostname: "canary.mydomain.com"
+```
+
+### Multiple sources and Istio
+
+**/!\\** The apex annotations are added to both the generated Kubernetes Services and the generated Istio
+VirtualServices objects. If you have configured external-dns to use both sources,
+this will create conflicts!
+
+```yaml
+    spec:
+      containers:
+        args:
+        - --source=service              # choose only one
+        - --source=istio-virtualservice # of these two
+```
+
+[Checkout ExternalDNS documentation](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/istio.md)

docs/gitbook/install/flagger-install-on-alibaba-servicemesh.md

@@ -0,0 +1,57 @@
+# Flagger Install on Alibaba ServiceMesh
+
+This guide walks you through setting up Flagger on Alibaba ServiceMesh.
+
+## Prerequisites
+- Created an ACK([Alibabacloud Container Service for Kubernetes](https://cs.console.aliyun.com)) cluster instance.
+- Create an ASM([Alibaba ServiceMesh](https://servicemesh.console.aliyun.com)) enterprise instance and add ACK cluster.
+
+### Variables declaration
+- `$ACK_CONFIG`: the kubeconfig file path of ACK, which be treated as`$HOME/.kube/config` in the rest of guide.
+- `$MESH_CONFIG`: the kubeconfig file path of ASM.
+
+### Enable Data-plane KubeAPI access in ASM
+
+In the Alibaba Cloud Service Mesh (ASM) console, on the basic information page, make sure Data-plane KubeAPI access is enabled. When enabled, the Istio resources of the control plane can be managed through the Kubeconfig of the data plane cluster.
+
+## Enable Prometheus
+
+In the Alibaba Cloud Service Mesh (ASM) console, click  Settings to enable the collection of Prometheus monitoring metrics. You can use the self-built Prometheus monitoring, or you can use the Alibaba Cloud ARMS Prometheus monitoring plug-in that has joined the ACK cluster, and use ARMS Prometheus to collect monitoring indicators.
+
+## Install Flagger
+
+Add Flagger Helm repository:
+
+```bash
+helm repo add flagger https://flagger.app
+```
+
+Install Flagger's Canary CRD:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/v1.21.0/artifacts/flagger/crd.yaml
+```
+## Deploy Flagger for Istio
+
+### Add data plane cluster to Alibaba Cloud Service Mesh (ASM)
+
+In the Alibaba Cloud Service Mesh (ASM) console, click Cluster & Workload Management, select the Kubernetes cluster, select the target ACK cluster, and add it to ASM.
+
+### Prometheus address
+
+If you are using Alibaba Cloud Container Service for Kubernetes (ACK) ARMS Prometheus monitoring, replace {Region-ID} in the link below with your region ID, such as cn-hangzhou. {ACKID} is the ACK ID of the data plane cluster that you added to Alibaba Cloud Service Mesh (ASM). Visit the following links to query the public and intranet addresses monitored by ACK's ARMS Prometheus:
+[https://arms.console.aliyun.com/#/promDetail/{Region-ID}/{ACK-ID}/setting](https://arms.console.aliyun.com/)
+
+An example of an intranet address is as follows:
+[http://{Region-ID}-intranet.arms.aliyuncs.com:9090/api/v1/prometheus/{Prometheus-ID}/{u-id}/{ACK-ID}/{Region-ID}](https://arms.console.aliyun.com/)
+
+## Deploy Flagger
+Replace the value of metricsServer with your Prometheus address.
+
+```bash
+helm upgrade -i flagger flagger/flagger \
+--namespace=istio-system \
+--set crd.create=false \
+--set meshProvider=istio \
+--set metricsServer=http://prometheus:9090
+```

docs/gitbook/install/flagger-install-on-eks-appmesh.md

@@ -62,7 +62,7 @@ helm repo add eks https://aws.github.io/eks-charts
 
 ## Enable horizontal pod auto-scaling
 
-Install the Horizontal Pod Autoscaler \(HPA\) metrics provider:
+Install the Horizontal Pod Autoscaler (HPA) metrics provider:
 
 ```bash
 helm upgrade -i metrics-server stable/metrics-server \
@@ -118,7 +118,7 @@ helm repo add flagger https://flagger.app
 Install Flagger's Canary CRD:
 
 ```yaml
-kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
+kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
 ```
 
 Deploy Flagger in the _**appmesh-system**_ namespace:
@@ -146,6 +146,6 @@ You can access Grafana using port forwarding:
 kubectl -n appmesh-system port-forward svc/appmesh-grafana 3000:3000
 ```
 
-Now that you have Flagger running,
-you can try the [App Mesh canary deployments tutorial](https://docs.flagger.app/usage/appmesh-progressive-delivery).
+Now that you have Flagger running, you can try the
+[App Mesh canary deployments tutorial](https://docs.flagger.app/usage/appmesh-progressive-delivery).
 

docs/gitbook/install/flagger-install-on-google-cloud.md

@@ -2,7 +2,7 @@
 
 This guide walks you through setting up Flagger and Istio on Google Kubernetes Engine.
 
-![GKE Cluster Overview](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-gke-istio.png)
+![GKE Cluster Overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-gke-istio.png)
 
 ## Prerequisites
 
@@ -205,12 +205,12 @@ jetstack/cert-manager
 
 ## Istio Gateway TLS setup
 
-![Istio Let's Encrypt](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/istio-cert-manager-gke.png)
+![Istio Let's Encrypt](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/istio-cert-manager-gke.png)
 
 Create a generic Istio Gateway to expose services outside the mesh on HTTPS:
 
 ```bash
-REPO=https://raw.githubusercontent.com/weaveworks/flagger/master
+REPO=https://raw.githubusercontent.com/fluxcd/flagger/main
 
 kubectl apply -f ${REPO}/artifacts/gke/istio-gateway.yaml
 ```
@@ -346,7 +346,7 @@ helm repo add flagger https://flagger.app
 Install Flagger's Canary CRD:
 
 ```yaml
-kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
+kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
 ```
 
 Deploy Flagger in the `istio-system` namespace with Slack notifications enabled:

docs/gitbook/install/flagger-install-on-kubernetes.md

@@ -4,7 +4,7 @@ This guide walks you through setting up Flagger on a Kubernetes cluster with Hel
 
 ## Prerequisites
 
-Flagger requires a Kubernetes cluster **v1.14** or newer.
+Flagger requires a Kubernetes cluster **v1.16** or newer.
 
 ## Install Flagger with Helm
 
@@ -17,7 +17,7 @@ helm repo add flagger https://flagger.app
 Install Flagger's Canary CRD:
 
 ```yaml
-kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
+kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml
 ```
 
 Deploy Flagger for Istio:
@@ -30,11 +30,12 @@ helm upgrade -i flagger flagger/flagger \
 --set metricsServer=http://prometheus:9090
 ```
 
-Note that Flagger depends on Istio telemetry and Prometheus, if you're installing Istio with istioctl
-then you should be using the [default profile](https://istio.io/docs/setup/additional-setup/config-profiles/).
+Note that Flagger depends on Istio telemetry and Prometheus, if you're installing
+Istio with istioctl then you should be using the
+[default profile](https://istio.io/docs/setup/additional-setup/config-profiles/).
 
-For Istio multi-cluster shared control plane you can install Flagger
-on each remote cluster and set the Istio control plane host cluster kubeconfig:
+For Istio multi-cluster shared control plane you can install Flagger on each remote cluster and set the
+Istio control plane host cluster kubeconfig:
 
 ```bash
 helm upgrade -i flagger flagger/flagger \
@@ -42,13 +43,13 @@ helm upgrade -i flagger flagger/flagger \
 --set crd.create=false \
 --set meshProvider=istio \
 --set metricsServer=http://istio-cluster-prometheus:9090 \
---set istio.kubeconfig.secretName=istio-kubeconfig \
---set istio.kubeconfig.key=kubeconfig
+--set controlplane.kubeconfig.secretName=istio-kubeconfig \
+--set controlplane.kubeconfig.key=kubeconfig
 ```
 
 Note that the Istio kubeconfig must be stored in a Kubernetes secret with a data key named `kubeconfig`.
-For more details on how to configure Istio multi-cluster credentials
-read the [Istio docs](https://istio.io/docs/setup/install/multicluster/shared-vpn/#credentials).
+For more details on how to configure Istio multi-cluster
+credentials read the [Istio docs](https://istio.io/docs/setup/install/multicluster/shared-vpn/#credentials).
 
 Deploy Flagger for Linkerd:
 
@@ -70,6 +71,16 @@ helm upgrade -i flagger flagger/flagger \
 --set metricsServer=http://appmesh-prometheus:9090
 ```
 
+Deploy Flagger for **Open Service Mesh (OSM)** (requires OSM to have been installed with Prometheus):
+
+```console
+$ helm upgrade -i flagger flagger/flagger \
+--namespace=osm-system \
+--set crd.create=false \
+--set meshProvider=osm \
+--set metricsServer=http://osm-prometheus.osm-system.svc:7070
+```
+
 You can install Flagger in any namespace as long as it can talk to the Prometheus service on port 9090.
 
 For ingress controllers, the install instructions are:
@@ -78,26 +89,7 @@ For ingress controllers, the install instructions are:
 * [Gloo](https://docs.flagger.app/tutorials/gloo-progressive-delivery)
 * [NGINX](https://docs.flagger.app/tutorials/nginx-progressive-delivery)
 * [Skipper](https://docs.flagger.app/tutorials/skipper-progressive-delivery)
-
-Enable **Slack** notifications:
-
-```bash
-helm upgrade -i flagger flagger/flagger \
---namespace=istio-system \
---set crd.create=false \
---set slack.url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK \
---set slack.channel=general \
---set slack.user=flagger
-```
-
-Enable **Microsoft Teams** notifications:
-
-```bash
-helm upgrade -i flagger flagger/flagger \
---namespace=istio-system \
---set crd.create=false \
---set msteams.url=https://outlook.office.com/webhook/YOUR/TEAMS/WEBHOOK
-```
+* [Traefik](https://docs.flagger.app/tutorials/traefik-progressive-delivery)
 
 You can use the helm template command and apply the generated yaml with kubectl:
 
@@ -122,7 +114,7 @@ helm delete flagger
 The command removes all the Kubernetes components associated with the chart and deletes the release.
 
 > **Note** that on uninstall the Canary CRD will not be removed. Deleting the CRD will make Kubernetes
->remove all the objects owned by Flagger like Istio virtual services, Kubernetes deployments and ClusterIP services.
+> remove all the objects owned by Flagger like Istio virtual services, Kubernetes deployments and ClusterIP services.
 
 If you want to remove all the objects created by Flagger you have delete the Canary CRD with kubectl:
 
@@ -172,13 +164,13 @@ As an alternative to Helm, Flagger can be installed with Kustomize **3.5.0** or
 Install Flagger for Istio:
 
 ```bash
-kustomize build https://github.com/weaveworks/flagger/kustomize/istio | kubectl apply -f -
+kustomize build https://github.com/fluxcd/flagger/kustomize/istio?ref=main | kubectl apply -f -
 ```
 
 Install Flagger for AWS App Mesh:
 
 ```bash
-kustomize build https://github.com/weaveworks/flagger/kustomize/appmesh | kubectl apply -f -
+kustomize build https://github.com/fluxcd/flagger/kustomize/appmesh?ref=main | kubectl apply -f -
 ```
 
 This deploys Flagger and sets the metrics server URL to App Mesh's Prometheus instance.
@@ -186,27 +178,35 @@ This deploys Flagger and sets the metrics server URL to App Mesh's Prometheus in
 Install Flagger for Linkerd:
 
 ```bash
-kustomize build https://github.com/weaveworks/flagger/kustomize/linkerd | kubectl apply -f -
+kustomize build https://github.com/fluxcd/flagger/kustomize/linkerd?ref=main | kubectl apply -f -
 ```
 
 This deploys Flagger in the `linkerd` namespace and sets the metrics server URL to Linkerd's Prometheus instance.
 
+Install Flagger for Open Service Mesh:
+
+```bash
+kustomize build https://github.com/fluxcd/flagger/kustomize/osm?ref=main | kubectl apply -f -
+```
+
+This deploys Flagger in the `osm-system` namespace and sets the metrics server URL to OSM's Prometheus instance.
+
 If you want to install a specific Flagger release, add the version number to the URL:
 
 ```bash
-kustomize build https://github.com/weaveworks/flagger/kustomize/linkerd?ref=v1.0.0 | kubectl apply -f -
+kustomize build https://github.com/fluxcd/flagger/kustomize/linkerd?ref=v1.0.0 | kubectl apply -f -
 ```
 
 **Generic installer**
 
-Install Flagger and Prometheus for Contour, Gloo, NGINX or Skipper ingress:
+Install Flagger and Prometheus for Contour, Gloo, NGINX, Skipper, or Traefik ingress:
 
 ```bash
-kustomize build https://github.com/weaveworks/flagger/kustomize/kubernetes | kubectl apply -f -
+kustomize build https://github.com/fluxcd/flagger/kustomize/kubernetes?ref=main | kubectl apply -f -
 ```
 
-This deploys Flagger and Prometheus in the `flagger-system` namespace, sets the metrics server URL
-to `http://flagger-prometheus.flagger-system:9090` and the mesh provider to `kubernetes`.
+This deploys Flagger and Prometheus in the `flagger-system` namespace,
+sets the metrics server URL to `http://flagger-prometheus.flagger-system:9090` and the mesh provider to `kubernetes`.
 
 The Prometheus instance has a two hours data retention and is configured to scrape all pods in your cluster
 that have the `prometheus.io/scrape: "true"` annotation.
@@ -220,7 +220,7 @@ metadata:
   name: app
   namespace: test
 spec:
-  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, gloo
+  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, gloo, traefik, osm
   # use the kubernetes provider for Blue/Green style deployments
   provider: nginx
 ```
@@ -233,7 +233,7 @@ Create a kustomization file using Flagger as base and patch the container args:
 cat > kustomization.yaml <<EOF
 namespace: istio-system
 bases:
-  - github.com/weaveworks/flagger/kustomize/base/flagger
+  - https://github.com/fluxcd/flagger/kustomize/kubernetes?ref=main
 patches:
 - target:
     kind: Deployment
@@ -251,19 +251,6 @@ patches:
             args:
               - -mesh-provider=istio
               - -metrics-server=http://prometheus.istio-system:9090
-              - -slack-user=flagger
-              - -slack-channel=alerts
-              - -slack-url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
+              - -include-label-prefix=app.kubernetes.io
 EOF
 ```
-
-Install Flagger for Istio with Slack notifications:
-
-```bash
-kustomize build . | kubectl apply -f -
-```
-
-If you want to use MS Teams instead of Slack, replace `-slack-url` with `-msteams-url` and set the webhook address
-to `https://outlook.office.com/webhook/YOUR/TEAMS/WEBHOOK`.
-
-

docs/gitbook/install/flagger-install-with-flux.md

@@ -0,0 +1,158 @@
+# Flagger Install on Kubernetes with Flux
+
+This guide walks you through setting up Flagger on a Kubernetes cluster the GitOps way.
+You'll configure Flux to scan the Flagger OCI artifacts and deploy the
+latest stable version on Kubernetes.
+
+## Flagger OCI artifacts
+
+Flagger OCI artifacts (container images, Helm charts, Kustomize overlays) are published to
+GitHub Container Registry, and they are signed with Cosign at every release.
+
+OCI artifacts
+
+- `ghcr.io/fluxcd/flagger:<version>` multi-arch container images
+- `ghcr.io/fluxcd/flagger-manifest:<version>` Kubernetes manifests
+- `ghcr.io/fluxcd/charts/flagger:<version>` Helm charts
+
+## Prerequisites
+
+To follow this guide you’ll need a Kubernetes cluster with Flux installed on it.
+Please see the Flux [get started guide](https://fluxcd.io/flux/get-started/)
+or the Flux [installation guide](https://fluxcd.io/flux/installation/).
+
+## Deploy Flagger with Flux
+
+First define the namespace where Flagger will be installed:
+
+```yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: flagger-system
+  labels:
+    toolkit.fluxcd.io/tenant: sre-team
+```
+
+Define a Flux `HelmRepository` that points to where the Flagger Helm charts are stored:
+
+```yaml
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+  name: flagger
+  namespace: flux-system
+spec:
+  interval: 1h
+  url: oci://ghcr.io/fluxcd/charts
+  type: oci
+```
+
+Define a Flux `HelmRelease` that verifies and installs Flagger's latest version on the cluster:
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+  name: flagger
+  namespace: flagger-system
+spec:
+  interval: 1h
+  releaseName: flagger
+  install: # override existing Flagger CRDs
+    crds: CreateReplace
+  upgrade: # update Flagger CRDs
+    crds: CreateReplace
+  chart:
+    spec:
+      chart: flagger
+      version: 1.x # update Flagger to the latest minor version
+      interval: 6h # scan for new versions every six hours
+      sourceRef:
+        kind: HelmRepository
+        name: flagger
+      verify: # verify the chart signature with Cosign keyless
+        provider: cosign 
+  values:
+    nodeSelector:
+      kubernetes.io/os: linux
+```
+
+Copy the above manifests into a file called `flagger.yaml`, place the YAML file
+in the Git repository bootstrapped with Flux, then commit and push it to upstream.
+
+After Flux reconciles the changes on your cluster, you can check if Flagger got deployed with:
+
+```console
+$ helm list -n flagger-system 
+NAME    NAMESPACE       REVISION        STATUS          CHART           APP VERSION
+flagger flagger-system  1               deployed        flagger-1.23.0  1.23.0  
+```
+
+To uninstall Flagger, delete the `flagger.yaml` from your repository, then Flux will uninstall
+the Helm release and will remove the namespace from your cluster.
+
+## Deploy Flagger load tester with Flux
+
+Flagger comes with a load testing service that generates traffic during analysis when configured as a webhook.
+
+The load tester container images and deployment manifests are published to GitHub Container Registry.
+The container images and the manifests are signed with Cosign and GitHub Actions OIDC.
+
+Assuming the applications managed by Flagger are in the `apps` namespace, you can configure Flux to
+deploy the load tester there.
+
+Define a Flux `OCIRepository` that points to where the Flagger Kustomize overlays are stored:
+
+```yaml
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: OCIRepository
+metadata:
+  name: flagger-loadtester
+  namespace: apps
+spec:
+  interval: 6h # scan for new versions every six hours
+  url: oci://ghcr.io/fluxcd/flagger-manifests
+  ref:
+    semver: 1.x # update to the latest version 
+  verify: # verify the artifact signature with Cosign keyless
+    provider: cosign
+```
+
+Define a Flux `Kustomization` that deploys the Flagger load tester to the `apps` namespace:
+
+```yaml
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+kind: Kustomization
+metadata:
+  name: flagger-loadtester
+  namespace: apps
+spec:
+  interval: 6h
+  wait: true
+  timeout: 5m
+  prune: true
+  sourceRef:
+    kind: OCIRepository
+    name: flagger-loadtester
+  path: ./kustomize/tester
+  targetNamespace: apps
+```
+
+Copy the above manifests into a file called `flagger-loadtester.yaml`, place the YAML file
+in the Git repository bootstrapped with Flux, then commit and push it to upstream.
+
+After Flux reconciles the changes on your cluster, you can check if the load tester got deployed with:
+
+```console
+$ flux -n apps get kustomization flagger-loadtester 
+NAME              	READY	MESSAGE                                                                                    
+flagger-loadtester	True 	Applied revision: v1.23.0/a80af71e001
+```
+
+To uninstall the load tester, delete the `flagger-loadtester.yaml` from your repository, 
+and Flux will delete the load tester deployment from the cluster.

docs/gitbook/install/flagger-install-with-supergloo.md

@@ -1,188 +0,0 @@
-# Flagger Install with SuperGloo
-
-This guide walks you through setting up Flagger on a Kubernetes cluster using [SuperGloo](https://github.com/solo-io/supergloo).
-
-SuperGloo by [Solo.io](https://solo.io) is an opinionated abstraction layer that simplifies the installation, management, and operation of your service mesh. It supports running multiple ingresses with multiple meshes \(Istio, App Mesh, Consul Connect and Linkerd 2\) in the same cluster.
-
-## Prerequisites
-
-Flagger requires a Kubernetes cluster **v1.11** or newer with the following admission controllers enabled:
-
-* MutatingAdmissionWebhook
-* ValidatingAdmissionWebhook
-
-## Install Istio with SuperGloo
-
-### Install SuperGloo command line interface helper
-
-SuperGloo includes a command line helper \(CLI\) that makes operation of SuperGloo easier. The CLI is not required for SuperGloo to function correctly.
-
-If you use [Homebrew](https://brew.sh) package manager run the following commands to install the SuperGloo CLI.
-
-```bash
-brew tap solo-io/tap
-brew solo-io/tap/supergloo
-```
-
-Or you can download SuperGloo CLI and add it to your path:
-
-```bash
-curl -sL https://run.solo.io/supergloo/install | sh
-export PATH=$HOME/.supergloo/bin:$PATH
-```
-
-### Install SuperGloo controller
-
-Deploy the SuperGloo controller in the `supergloo-system` namespace:
-
-```bash
-supergloo init
-```
-
-This is equivalent to installing SuperGloo using its Helm chart
-
-```bash
-helm repo add supergloo http://storage.googleapis.com/supergloo-helm
-helm upgrade --install supergloo supergloo/supergloo --namespace supergloo-system
-```
-
-### Install Istio using SuperGloo
-
-Create the `istio-system` namespace and install Istio with traffic management, telemetry and Prometheus enabled:
-
-```bash
-ISTIO_VER="1.0.6"
-
-kubectl create namespace istio-system
-
-supergloo install istio --name istio \
---namespace=supergloo-system \
---auto-inject=true \
---installation-namespace=istio-system \
---mtls=false \
---prometheus=true \
---version=${ISTIO_VER}
-```
-
-This creates a Kubernetes Custom Resource \(CRD\) like the following.
-
-```yaml
-apiVersion: supergloo.solo.io/v1
-kind: Install
-metadata:
-  name: istio
-  namespace: supergloo-system
-spec:
-  installationNamespace: istio-system
-  mesh:
-    installedMesh:
-      name: istio
-      namespace: supergloo-system
-    istioMesh:
-      enableAutoInject: true
-      enableMtls: false
-      installGrafana: false
-      installJaeger: false
-      installPrometheus: true
-      istioVersion: 1.0.6
-```
-
-### Allow Flagger to manipulate SuperGloo
-
-Create a cluster role binding so that Flagger can manipulate SuperGloo custom resources:
-
-```bash
-kubectl create clusterrolebinding flagger-supergloo \
---clusterrole=mesh-discovery \
---serviceaccount=istio-system:flagger
-```
-
-Wait for the Istio control plane to become available:
-
-```bash
-kubectl --namespace istio-system rollout status deployment/istio-sidecar-injector
-kubectl --namespace istio-system rollout status deployment/prometheus
-```
-
-## Install Flagger
-
-Add Flagger Helm repository:
-
-```bash
-helm repo add flagger https://flagger.app
-```
-
-Install Flagger's Canary CRD:
-
-```yaml
-kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
-```
-
-Deploy Flagger in the _**istio-system**_ namespace and set the service mesh provider to SuperGloo:
-
-```bash
-helm upgrade -i flagger flagger/flagger \
---namespace=istio-system \
---set crd.create=false \
---set metricsServer=http://prometheus.istio-system:9090 \
---set meshProvider=supergloo:istio.supergloo-system
-```
-
-When using SuperGloo the mesh provider format is `supergloo:<MESH-NAME>.<SUPERGLOO-NAMESPACE>`.
-
-Optionally you can enable **Slack** notifications:
-
-```bash
-helm upgrade -i flagger flagger/flagger \
---reuse-values \
---namespace=istio-system \
---set slack.url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK \
---set slack.channel=general \
---set slack.user=flagger
-```
-
-## Install Grafana
-
-Flagger comes with a Grafana dashboard made for monitoring the canary analysis.
-
-Deploy Grafana in the _**istio-system**_ namespace:
-
-```bash
-helm upgrade -i flagger-grafana flagger/grafana \
---namespace=istio-system \
---set url=http://prometheus.istio-system:9090
-```
-
-You can access Grafana using port forwarding:
-
-```bash
-kubectl -n istio-system port-forward svc/flagger-grafana 3000:80
-```
-
-## Install Load Tester
-
-Flagger comes with an optional load testing service that generates traffic during canary analysis when configured as a webhook.
-
-Deploy the load test runner with Helm:
-
-```bash
-helm upgrade -i flagger-loadtester flagger/loadtester \
---namespace=test \
---set cmd.timeout=1h
-```
-
-Deploy with kubectl:
-
-```bash
-helm fetch --untar --untardir . flagger/loadtester &&
-helm template loadtester \
---name flagger-loadtester \
---namespace=test
-> $HOME/flagger-loadtester.yaml
-
-# apply
-kubectl apply -f $HOME/flagger-loadtester.yaml
-```
-
-> **Note** that the load tester should be deployed in a namespace with Istio sidecar injection enabled.
-

docs/gitbook/tutorials/appmesh-progressive-delivery.md

@@ -1,13 +1,14 @@
 # App Mesh Canary Deployments
 
 This guide shows you how to use App Mesh and Flagger to automate canary deployments.
-You'll need an EKS cluster configured with App Mesh,
-you can find the installion guide [here](https://docs.flagger.app/install/flagger-install-on-eks-appmesh).
+You'll need an EKS cluster (Kubernetes >= 1.16) configured with App Mesh,
+you can find the installation guide [here](https://docs.flagger.app/install/flagger-install-on-eks-appmesh).
 
 ## Bootstrap
 
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\),
-then creates a series of objects \(Kubernetes deployments, ClusterIP services, App Mesh virtual nodes and services\).
+Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
+then creates a series of objects (Kubernetes deployments, ClusterIP services,
+App Mesh virtual nodes and services).
 These objects expose the application on the mesh and drive the canary analysis and promotion.
 The only App Mesh object you need to create by yourself is the mesh resource.
 
@@ -42,7 +43,7 @@ EOF
 Create a deployment and a horizontal pod autoscaler:
 
 ```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
 ```
 
 Deploy the load testing service to generate traffic during the canary analysis:
@@ -61,6 +62,9 @@ Create a canary definition:
 apiVersion: flagger.app/v1beta1
 kind: Canary
 metadata:
+  annotations:
+    # Enable Envoy access logging to stdout.
+    appmesh.flagger.app/accesslog: enabled
   name: podinfo
   namespace: test
 spec:
@@ -76,7 +80,7 @@ spec:
   progressDeadlineSeconds: 60
   # HPA reference (optional)
   autoscalerRef:
-    apiVersion: autoscaling/v2beta1
+    apiVersion: autoscaling/v2beta2
     kind: HorizontalPodAutoscaler
     name: podinfo
   service:
@@ -167,20 +171,20 @@ virtualservice.appmesh.k8s.aws/podinfo
 virtualservice.appmesh.k8s.aws/podinfo-canary
 ```
 
-After the boostrap, the podinfo deployment will be scaled to zero and the traffic to
-`podinfo.test` will be routed to the primary pods.
+After the bootstrap, the podinfo deployment will be scaled to zero and the traffic to `podinfo.test`
+will be routed to the primary pods.
 During the canary analysis, the `podinfo-canary.test` address can be used to target directly the canary pods.
 
 App Mesh blocks all egress traffic by default.
-If your application needs to call another service, you have to
-create an App Mesh virtual service for it and add the virtual service name to the backend list.
+If your application needs to call another service, you have to create an App Mesh virtual service for it
+and add the virtual service name to the backend list.
 
 ```yaml
   service:
     port: 9898
     backends:
       - backend1
-      - backend2
+      - arn:aws:appmesh:eu-west-1:12345678910:mesh/my-mesh/virtualService/backend2
 ```
 
 ## Setup App Mesh Gateway (optional)
@@ -234,14 +238,14 @@ Open your browser and navigate to the ingress address to access podinfo UI.
 
 A canary deployment is triggered by changes in any of the following objects:
 
-* Deployment PodSpec \(container image, command, ports, env, resources, etc\)
+* Deployment PodSpec (container image, command, ports, env, resources, etc)
 * ConfigMaps and Secrets mounted as volumes or mapped to environment variables
 
 Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.1
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.1
 ```
 
 Flagger detects that the deployment revision changed and starts a new rollout:
@@ -281,7 +285,7 @@ During the analysis the canary’s progress can be monitored with Grafana.
 The App Mesh dashboard URL is
 [http://localhost:3000/d/flagger-appmesh/appmesh-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo](http://localhost:3000/d/flagger-appmesh/appmesh-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo).
 
-![App Mesh Canary Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-grafana-appmesh.png)
+![App Mesh Canary Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/flagger-grafana-appmesh.png)
 
 You can monitor all canaries with:
 
@@ -296,7 +300,7 @@ prod        backend   Failed        0
 
 If you’ve enabled the Slack notifications, you should receive the following messages:
 
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png)
+![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png)
 
 ## Automated rollback
 
@@ -306,7 +310,7 @@ Trigger a canary deployment:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.2
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.2
 ```
 
 Exec into the load tester pod with:
@@ -350,7 +354,7 @@ Canary failed! Scaling down podinfo.test
 If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded,
 or if the analysis reached the maximum number of failed checks:
 
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png)
+![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png)
 
 ## A/B Testing
 
@@ -358,7 +362,7 @@ Besides weighted routing, Flagger can be configured to route traffic to the cana
 In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users.
 This is particularly useful for frontend applications that require session affinity.
 
-![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png)
+![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png)
 
 Edit the canary analysis, remove the max/step weight and add the match conditions and iterations:
 
@@ -398,7 +402,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.3
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.3
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B test:
@@ -423,4 +427,8 @@ Routing all traffic to primary
 Promotion completed! Scaling down podinfo.test
 ```
 
-For an in-depth look at the analysis process read the [usage docs](../usage/how-it-works.md).
+The above procedure can be extended with
+[custom metrics](../usage/metrics.md) checks,
+[webhooks](../usage/webhooks.md),
+[manual promotion](../usage/webhooks.md#manual-gating) approval and
+[Slack or MS Teams](../usage/alerting.md) notifications.

docs/gitbook/tutorials/canary-helm-gitops.md

@@ -30,7 +30,7 @@ You can find the chart source [here](https://github.com/stefanprodan/flagger/tre
 Create a test namespace with Istio sidecar injection enabled:
 
 ```bash
-export REPO=https://raw.githubusercontent.com/weaveworks/flagger/master
+export REPO=https://raw.githubusercontent.com/fluxcd/flagger/main
 
 kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml
 ```
@@ -77,7 +77,7 @@ When the `frontend-primary` deployment comes online, Flagger will route all traf
 
 Open your browser and navigate to the frontend URL:
 
-![Podinfo Frontend](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend.png)
+![Podinfo Frontend](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend.png)
 
 Now let's install the `backend` release without exposing it outside the mesh:
 
@@ -101,7 +101,7 @@ frontend   Initialized   0        2019-02-12T17:50:50Z
 
 Click on the ping button in the `frontend` UI to trigger a HTTP POST request that will reach the `backend` app:
 
-![Jaeger Tracing](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend-jaeger.png)
+![Jaeger Tracing](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend-jaeger.png)
 
 We'll use the `/echo` endpoint \(same as the one the ping button calls\) to generate load on both apps during a canary deployment.
 
@@ -159,7 +159,7 @@ Promotion completed! Scaling down frontend.test
 
 You can monitor the canary deployment with Grafana. Open the Flagger dashboard, select `test` from the namespace dropdown, `frontend-primary` from the primary dropdown and `frontend` from the canary dropdown.
 
-![Flagger Grafana Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend-dashboard.png)
+![Flagger Grafana Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend-dashboard.png)
 
 Now trigger a canary deployment for the `backend` app, but this time you'll change a value in the configmap:
 
@@ -217,7 +217,7 @@ Copying backend.test template spec to backend-primary.test
 Promotion completed! Scaling down backend.test
 ```
 
-![Flagger Grafana Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-backend-dashboard.png)
+![Flagger Grafana Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-backend-dashboard.png)
 
 If the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed.
 
@@ -235,7 +235,7 @@ If you've enabled the Slack notifications, you'll receive an alert with the reas
 
 Instead of using Helm CLI from a CI tool to perform the install and upgrade, you could use a Git based approach. GitOps is a way to do Continuous Delivery, it works by using Git as a source of truth for declarative infrastructure and workloads. In the [GitOps model](https://www.weave.works/technologies/gitops/), any change to production must be committed in source control prior to being applied on the cluster. This way rollback and audit logs are provided by Git.
 
-![Helm GitOps Canary Deployment](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-flux-gitops.png)
+![Helm GitOps Canary Deployment](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-flux-gitops.png)
 
 In order to apply the GitOps pipeline model to Flagger canary deployments you'll need a Git repository with your workloads definitions in YAML format, a container registry where your CI system pushes immutable images and an operator that synchronizes the Git repo with the cluster state.
 
@@ -286,15 +286,11 @@ spec:
           enabled: true
 ```
 
-In the `chart` section I've defined the release source by specifying the Helm repository (hosted on GitHub Pages),
-chart name and version. In the `values` section I've overwritten the defaults set in values.yaml.
+In the `chart` section I've defined the release source by specifying the Helm repository \(hosted on GitHub Pages\), chart name and version. In the `values` section I've overwritten the defaults set in values.yaml.
 
-With the `fluxcd.io` annotations I instruct Flux to automate this release.
-When an image tag in the sem ver range of `3.1.0 - 3.1.99` is pushed to Docker Hub,
-Flux will upgrade the Helm release and from there Flagger will pick up the change and start a canary deployment.
+With the `fluxcd.io` annotations I instruct Flux to automate this release. When an image tag in the sem ver range of `3.1.0 - 3.1.99` is pushed to Docker Hub, Flux will upgrade the Helm release and from there Flagger will pick up the change and start a canary deployment.
 
-Install [Flux](https://github.com/fluxcd/flux) and its
-[Helm Operator](https://github.com/fluxcd/helm-operator) by specifying your Git repo URL:
+Install [Flux](https://github.com/fluxcd/flux) and its [Helm Operator](https://github.com/fluxcd/helm-operator) by specifying your Git repo URL:
 
 ```bash
 helm repo add fluxcd https://charts.fluxcd.io
@@ -315,19 +311,16 @@ At startup Flux generates a SSH key and logs the public key. Find the SSH public
 kubectl -n fluxcd logs deployment/flux | grep identity.pub | cut -d '"' -f2
 ```
 
-In order to sync your cluster state with Git you need to copy the public key
-and create a deploy key with write access on your GitHub repository.
+In order to sync your cluster state with Git you need to copy the public key and create a deploy key with write access on your GitHub repository.
 
-Open GitHub, navigate to your fork, go to _Setting > Deploy keys_ click on _Add deploy key_, check _Allow write access_,
-paste the Flux public key and click _Add key_.
+Open GitHub, navigate to your fork, go to _Setting > Deploy keys_ click on _Add deploy key_, check _Allow write access_, paste the Flux public key and click _Add key_.
 
-After a couple of seconds Flux will apply the Kubernetes resources from Git and
-Flagger will launch the `frontend` and `backend` apps.
+After a couple of seconds Flux will apply the Kubernetes resources from Git and Flagger will launch the `frontend` and `backend` apps.
 
 A CI/CD pipeline for the `frontend` release could look like this:
 
 * cut a release from the master branch of the podinfo code repo with the git tag `3.1.1`
-* CI builds the image and pushes the `podinfo:3.1.1` image to the container registry
+* CI builds the image and pushes the `podinfo:6.0.1` image to the container registry
 * Flux scans the registry and updates the Helm release `image.tag` to `3.1.1`
 * Flux commits and push the change to the cluster repo
 * Flux applies the updated Helm release on the cluster
@@ -343,14 +336,12 @@ If the canary fails, fix the bug, do another patch release eg `3.1.2` and the wh
 A canary deployment can fail due to any of the following reasons:
 
 * the container image can't be downloaded 
-* the deployment replica set is stuck for more then ten minutes (eg. due to a container crash loop)
-* the webooks (acceptance tests, helm tests, load tests, etc) are returning a non 2xx response
-* the HTTP success rate (non 5xx responses) metric drops under the threshold
+* the deployment replica set is stuck for more then ten minutes \(eg. due to a container crash loop\)
+* the webhooks \(acceptance tests, helm tests, load tests, etc\) are returning a non 2xx response
+* the HTTP success rate \(non 5xx responses\) metric drops under the threshold
 * the HTTP average duration metric goes over the threshold
 * the Istio telemetry service is unable to collect traffic metrics
-* the metrics server (Prometheus) can't be reached
+* the metrics server \(Prometheus\) can't be reached
 
-If you want to find out more about managing Helm releases with Flux here are two in-depth guides:
-[gitops-helm](https://github.com/stefanprodan/gitops-helm)
-and [gitops-istio](https://github.com/stefanprodan/gitops-istio).
+If you want to find out more about managing Helm releases with Flux here are two in-depth guides: [gitops-helm](https://github.com/stefanprodan/gitops-helm) and [gitops-istio](https://github.com/stefanprodan/gitops-istio).
 

docs/gitbook/tutorials/contour-progressive-delivery.md

@@ -2,11 +2,11 @@
 
 This guide shows you how to use [Contour](https://projectcontour.io/) ingress controller and Flagger to automate canary releases and A/B testing.
 
-![Flagger Contour Overview](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-contour-overview.png)
+![Flagger Contour Overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-contour-overview.png)
 
 ## Prerequisites
 
-Flagger requires a Kubernetes cluster **v1.11** or newer and Contour **v1.0** or newer.
+Flagger requires a Kubernetes cluster **v1.16** or newer and Contour **v1.0** or newer.
 
 Install Contour on a cluster with LoadBalancer support:
 
@@ -19,7 +19,7 @@ The above command will deploy Contour and an Envoy daemonset in the `projectcont
 Install Flagger using Kustomize (kubectl 1.14) in the `projectcontour` namespace:
 
 ```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/contour
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/contour?ref=main
 ```
 
 The above command will deploy Flagger and Prometheus configured to scrape the Contour's Envoy instances.
@@ -36,14 +36,11 @@ helm upgrade -i flagger flagger/flagger \
 --set prometheus.install=true
 ```
 
-You can also enable Slack, Discord, Rocket or MS Teams notifications,
-see the alerting [docs](../usage/alerting.md).
+You can also enable Slack, Discord, Rocket or MS Teams notifications, see the alerting [docs](../usage/alerting.md).
 
 ## Bootstrap
 
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
-then creates a series of objects (Kubernetes deployments, ClusterIP services and Contour HTTPProxy).
-These objects expose the application in the cluster and drive the canary analysis and promotion.
+Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services and Contour HTTPProxy\). These objects expose the application in the cluster and drive the canary analysis and promotion.
 
 Create a test namespace:
 
@@ -54,16 +51,16 @@ kubectl create ns test
 Install the load testing service to generate traffic during the canary analysis:
 
 ```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/tester
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/tester?ref=main
 ```
 
 Create a deployment and a horizontal pod autoscaler:
 
 ```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
 ```
 
-Create a canary custom resource (replace `app.example.com` with your own domain):
+Create a canary custom resource \(replace `app.example.com` with your own domain\):
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -79,7 +76,7 @@ spec:
     name: podinfo
   # HPA reference
   autoscalerRef:
-    apiVersion: autoscaling/v2beta1
+    apiVersion: autoscaling/v2beta2
     kind: HorizontalPodAutoscaler
     name: podinfo
   service:
@@ -93,6 +90,8 @@ spec:
     retries:
       attempts: 3
       perTryTimeout: 5s
+      # supported values for retryOn - https://projectcontour.io/docs/main/config/api/#projectcontour.io/v1.RetryOn
+      retryOn: "5xx"
   # define the canary analysis timing and KPIs
   analysis:
     # schedule interval (default 60s)
@@ -160,9 +159,7 @@ service/podinfo-primary
 httpproxy.projectcontour.io/podinfo
 ```
 
-After the boostrap, the podinfo deployment will be scaled to zero and the traffic to `podinfo.test`
-will be routed to the primary pods.
-During the canary analysis, the `podinfo-canary.test` address can be used to target directly the canary pods.
+After the bootstrap, the podinfo deployment will be scaled to zero and the traffic to `podinfo.test` will be routed to the primary pods. During the canary analysis, the `podinfo-canary.test` address can be used to target directly the canary pods.
 
 ## Expose the app outside the cluster
 
@@ -174,11 +171,9 @@ export ADDRESS="$(kubectl -n projectcontour get svc/envoy -ojson \
 echo $ADDRESS
 ```
 
-Configure your DNS server with a CNAME record \(AWS\) or A record (GKE/AKS/DOKS)
-and point a domain e.g. `app.example.com` to the LB address.
+Configure your DNS server with a CNAME record \(AWS\) or A record \(GKE/AKS/DOKS\) and point a domain e.g. `app.example.com` to the LB address.
 
-Create a HTTPProxy definition and include the podinfo proxy generated by Flagger
-(replace `app.example.com` with your own domain):
+Create a HTTPProxy definition and include the podinfo proxy generated by Flagger \(replace `app.example.com` with your own domain\):
 
 ```yaml
 apiVersion: projectcontour.io/v1
@@ -214,28 +209,24 @@ podinfo-ingress   app.example.com     valid
 
 Now you can access podinfo UI using your domain address.
 
-Note that you should be using HTTPS when exposing production workloads on internet.
-You can obtain free TLS certs from Let's Encrypt, read this [guide](https://github.com/stefanprodan/eks-contour-ingress)
-on how to configure cert-manager to secure Contour with TLS certificates.
+Note that you should be using HTTPS when exposing production workloads on internet. You can obtain free TLS certs from Let's Encrypt, read this [guide](https://github.com/stefanprodan/eks-contour-ingress) on how to configure cert-manager to secure Contour with TLS certificates.
 
 ## Automated canary promotion
 
-Flagger implements a control loop that gradually shifts traffic to the canary while measuring
-key performance indicators like HTTP requests success rate, requests average duration and pod health.
-Based on analysis of the KPIs a canary is promoted or aborted.
+Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted.
 
-![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png)
+![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png)
 
 A canary deployment is triggered by changes in any of the following objects:
 
-* Deployment PodSpec (container image, command, ports, env, resources, etc)
+* Deployment PodSpec \(container image, command, ports, env, resources, etc\)
 * ConfigMaps and Secrets mounted as volumes or mapped to environment variables
 
 Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.1
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.1
 ```
 
 Flagger detects that the deployment revision changed and starts a new rollout:
@@ -282,7 +273,7 @@ test        podinfo   Progressing   15       2019-12-20T14:05:07Z
 
 If you’ve enabled the Slack notifications, you should receive the following messages:
 
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png)
+![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png)
 
 ## Automated rollback
 
@@ -292,7 +283,7 @@ Trigger a canary deployment:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.2
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.2
 ```
 
 Exec into the load tester pod with:
@@ -313,8 +304,7 @@ Generate latency:
 watch -n 1 curl http://app.example.com/delay/1
 ```
 
-When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary,
-the canary is scaled to zero and the rollout is marked as failed.
+When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed.
 
 ```text
 kubectl -n projectcontour logs deploy/flagger -f | jq .msg
@@ -333,18 +323,15 @@ Rolling back podinfo.test failed checks threshold reached 5
 Canary failed! Scaling down podinfo.test
 ```
 
-If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded,
-or if the analysis reached the maximum number of failed checks:
+If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded, or if the analysis reached the maximum number of failed checks:
 
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png)
+![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png)
 
 ## A/B Testing
 
-Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions.
-In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users.
-This is particularly useful for frontend applications that require session affinity.
+Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity.
 
-![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png)
+![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png)
 
 Edit the canary analysis, remove the max/step weight and add the match conditions and iterations:
 
@@ -384,7 +371,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.3
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.3
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B test:
@@ -439,3 +426,4 @@ match:
 ```
 
 For an in-depth look at the analysis process read the [usage docs](../usage/how-it-works.md).
+

docs/gitbook/tutorials/crossover-progressive-delivery.md

@@ -1,358 +0,0 @@
-# Crossover Canary Deployments
-
-This guide shows you how to use Envoy, [Crossover](https://github.com/mumoshu/crossover) and Flagger to automate canary deployments.
-
-Crossover is a minimal Envoy xDS implementation supports [Service Mesh Interface](https://smi-spec.io/).
-
-## Prerequisites
-
-Flagger requires a Kubernetes cluster **v1.11** or newer and Envoy paired with [Crossover](https://github.com/mumoshu/crossover) sidecar.
-
-Create a test namespace:
-
-```bash
-kubectl create ns test
-```
-
-Install Envoy along with the Crossover sidecar with Helm:
-
-```bash
-helm repo add crossover https://mumoshu.github.io/crossover
-
-helm upgrade --install envoy crossover/envoy \
-  --namespace test \
-  -f <(cat <<EOF
-smi:
-  apiVersions:
-    trafficSplits: v1alpha1
-upstreams:
-  podinfo:
-    smi:
-      enabled: true
-    backends:
-      podinfo-primary:
-        port: 9898
-        weight: 100
-      podinfo-canary:
-        port: 9898
-        weight: 0
-EOF
-)
-```
-
-Install Flagger and the Prometheus add-on in the same namespace as Envoy:
-
-```bash
-helm repo add flagger https://flagger.app
-
-helm upgrade -i flagger flagger/flagger \
---namespace test \
---set prometheus.install=true \
---set meshProvider=smi:crossover
-```
-
-## Bootstrap
-
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
-then creates a series of objects (Kubernetes deployments, ClusterIP services, SMI traffic splits).
-These objects expose the application on the mesh and drive the canary analysis and promotion.
-There's no SMI object you need to create by yourself.
-
-Create a deployment and a horizontal pod autoscaler:
-
-```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo
-```
-
-Deploy the load testing service to generate traffic during the canary analysis:
-
-```bash
-helm upgrade -i flagger-loadtester flagger/loadtester \
---namespace=test
-```
-
-Create a metric template to measure the HTTP requests error rate:
-
-```yaml
-apiVersion: flagger.app/v1beta1
-kind: MetricTemplate
-metadata:
-  name: error-rate
-  namespace: test
-spec:
-  provider:
-    address: http://flagger-prometheus:9090
-    type: prometheus
-  query: |
-    100 - rate(
-      envoy_cluster_upstream_rq{
-        kubernetes_namespace="{{ namespace }}",
-        envoy_cluster_name="{{ target }}-canary",
-        envoy_response_code!~"5.*"
-      }[{{ interval }}]) 
-    / 
-    rate(
-      envoy_cluster_upstream_rq{
-        kubernetes_namespace="{{ namespace }}",
-        envoy_cluster_name="{{ target }}-canary"
-      }[{{ interval }}]
-    ) * 100
-```
-
-Create a metric template to measure the HTTP requests average duration:
-
-```yaml
-apiVersion: flagger.app/v1beta1
-kind: MetricTemplate
-metadata:
-  name: latency
-  namespace: test
-spec:
-  provider:
-    address: http://flagger-prometheus:9090
-    type: prometheus
-  query: |
-    histogram_quantile(0.99,
-      sum(
-        rate(
-          envoy_cluster_upstream_rq_time_bucket{
-            kubernetes_namespace="{{ namespace }}",
-            envoy_cluster_name="{{ target }}-canary"
-          }[{{ interval }}]
-        )
-      ) by (le)
-    )
-```
-
-Create a canary custom resource:
-
-```yaml
-apiVersion: flagger.app/v1beta1
-kind: Canary
-metadata:
-  name: podinfo
-  namespace: test
-spec:
-  provider: "smi:crossover"
-  # deployment reference
-  targetRef:
-    apiVersion: apps/v1
-    kind: Deployment
-    name: podinfo
-  progressDeadlineSeconds: 60
-  # HPA reference (optional)
-  autoscalerRef:
-    apiVersion: autoscaling/v2beta1
-    kind: HorizontalPodAutoscaler
-    name: podinfo
-  service:
-    port: 9898
-  # define the canary analysis timing and KPIs
-  analysis:
-    # schedule interval (default 60s)
-    interval: 1m
-    # max number of failed metric checks before rollback
-    threshold: 5
-    # max traffic percentage routed to canary
-    # percentage (0-100)
-    maxWeight: 50
-    # canary increment step
-    # percentage (0-100)
-    stepWeight: 5
-    metrics:
-    - name: error-rate
-      templateRef:
-        name: error-rate
-      thresholdRange:
-        max: 1
-      interval: 30s
-    - name: latency
-      templateRef:
-        name: latency
-      thresholdRange:
-        max: 0.5
-      interval: 30s
-    webhooks:
-    - name: acceptance-test
-      type: pre-rollout
-      url: http://flagger-loadtester.test/
-      timeout: 30s
-      metadata:
-        type: bash
-        cmd: "curl -sd 'test' http://podinfo-canary.test:9898/token | grep token"
-    - name: load-test
-      url: http://flagger-loadtester.test/
-      timeout: 5s
-      metadata:
-        cmd: "hey -z 1m -q 10 -c 2 -H 'Host: podinfo.test' http://envoy.test:10000/"
-```
-
-Save the above resource as podinfo-canary.yaml and then apply it:
-
-```bash
-kubectl apply -f ./podinfo-canary.yaml
-```
-
-After a couple of seconds Flagger will create the canary objects:
-
-```bash
-# applied 
-deployment.apps/podinfo
-horizontalpodautoscaler.autoscaling/podinfo
-canary.flagger.app/podinfo
-
-# generated
-deployment.apps/podinfo-primary
-horizontalpodautoscaler.autoscaling/podinfo-primary
-service/podinfo
-service/podinfo-canary
-service/podinfo-primary
-trafficsplits.split.smi-spec.io/podinfo
-```
-
-After the boostrap, the podinfo deployment will be scaled to zero and the traffic to `podinfo.test`
-will be routed to the primary pods. During the canary analysis,
-the `podinfo-canary.test` address can be used to target directly the canary pods.
-
-## Automated canary promotion
-
-Flagger implements a control loop that gradually shifts traffic to the canary while measuring
-key performance indicators like HTTP requests success rate, requests average duration and pod health.
-Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack.
-
-![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png)
-
-A canary deployment is triggered by changes in any of the following objects:
-
-* Deployment PodSpec (container image, command, ports, env, resources, etc)
-* ConfigMaps and Secrets mounted as volumes or mapped to environment variables
-
-Trigger a canary deployment by updating the container image:
-
-```bash
-kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.5
-```
-
-Flagger detects that the deployment revision changed and starts a new rollout:
-
-```text
-kubectl -n test describe canary/podinfo
-
-Status:
-  Canary Weight:         0
-  Failed Checks:         0
-  Phase:                 Succeeded
-Events:
- New revision detected! Scaling up podinfo.test
- Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
- Pre-rollout check acceptance-test passed
- Advance podinfo.test canary weight 5
- Advance podinfo.test canary weight 10
- Advance podinfo.test canary weight 15
- Advance podinfo.test canary weight 20
- Advance podinfo.test canary weight 25
- Advance podinfo.test canary weight 30
- Advance podinfo.test canary weight 35
- Advance podinfo.test canary weight 40
- Advance podinfo.test canary weight 45
- Advance podinfo.test canary weight 50
- Copying podinfo.test template spec to podinfo-primary.test
- Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
- Routing all traffic to primary
- Promotion completed! Scaling down podinfo.test
-```
-
-When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary.
-
-**Note** that if you apply new changes to the deployment during the canary analysis, Flagger will restart the analysis.
-
-During the analysis the canary’s progress can be monitored with Grafana.
-
-Flagger comes with a Grafana dashboard made for canary analysis. Install Grafana with Helm:
-
-```bash
-helm upgrade -i flagger-grafana flagger/grafana \
---namespace=test \
---set url=http://flagger-prometheus:9090
-```
-
-Run:
-
-```bash
-kubectl port-forward --namespace test svc/flagger-grafana 3000:80
-```
-
-The Envoy dashboard URL is [http://localhost:3000/d/flagger-envoy/envoy-canary?refresh=10s&orgId=1&var-namespace=test&var-target=podinfo](http://localhost:3000/d/flagger-envoy/envoy-canary?refresh=10s&orgId=1&var-namespace=test&var-target=podinfo)
-
-![Envoy Canary Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-grafana-appmesh.png)
-
-You can monitor all canaries with:
-
-```bash
-watch kubectl get canaries --all-namespaces
-
-NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
-test        podinfo   Progressing   15       2019-10-02T14:05:07Z
-prod        frontend  Succeeded     0        2019-10-02T16:15:07Z
-prod        backend   Failed        0        2019-10-02T17:05:07Z
-```
-
-If you’ve enabled the Slack notifications, you should receive the following messages:
-
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png)
-
-## Automated rollback
-
-During the canary analysis you can generate HTTP 500 errors or high latency to test if Flagger pauses the rollout.
-
-Trigger a canary deployment:
-
-```bash
-kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.2
-```
-
-Exec into the load tester pod with:
-
-```bash
-kubectl -n test exec -it deploy/flagger-loadtester bash
-```
-
-Generate HTTP 500 errors:
-
-```bash
-hey -z 1m -c 5 -q 5 -H 'Host: podinfo.test' http://envoy.test:10000/status/500
-```
-
-Generate latency:
-
-```bash
-watch -n 1 curl -H 'Host: podinfo.test' http://envoy.test:10000/delay/1
-```
-
-When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary,
-the canary is scaled to zero and the rollout is marked as failed.
-
-```text
-kubectl -n test logs deploy/flagger -f | jq .msg
-
-New revision detected! progressing canary analysis for podinfo.test
-Pre-rollout check acceptance-test passed
-Advance podinfo.test canary weight 5
-Advance podinfo.test canary weight 10
-Advance podinfo.test canary weight 15
-Halt podinfo.test advancement success rate 69.17% < 99%
-Halt podinfo.test advancement success rate 61.39% < 99%
-Halt podinfo.test advancement success rate 55.06% < 99%
-Halt podinfo.test advancement request duration 1.20s > 0.5s
-Halt podinfo.test advancement request duration 1.45s > 0.5s
-Rolling back podinfo.test failed checks threshold reached 5
-Canary failed! Scaling down podinfo.test
-```
-
-If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded,
-or if the analysis reached the maximum number of failed checks:
-
-![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png)
-

docs/gitbook/tutorials/flagger-smi-istio.md

@@ -1,295 +0,0 @@
-# SMI Istio Canary Deployments
-
-This guide shows you how to use the SMI Istio adapter and Flagger to automate canary deployments.
-
-## Prerequisites
-
-* Kubernetes > 1.13
-* Istio > 1.0
-
-## Install Istio SMI adapter
-
-Install the SMI adapter:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/deislabs/smi-adapter-istio/master/deploy/crds/crds.yaml
-kubectl apply -f https://raw.githubusercontent.com/deislabs/smi-adapter-istio/master/deploy/operator-and-rbac.yaml
-```
-
-Create a generic Istio gateway to expose services outside the mesh on HTTP:
-
-```yaml
-apiVersion: networking.istio.io/v1alpha3
-kind: Gateway
-metadata:
-  name: public-gateway
-  namespace: istio-system
-spec:
-  selector:
-    istio: ingressgateway
-  servers:
-    - port:
-        number: 80
-        name: http
-        protocol: HTTP
-      hosts:
-        - "*"
-```
-
-Save the above resource as public-gateway.yaml and then apply it:
-
-```bash
-kubectl apply -f ./public-gateway.yaml
-```
-
-Find the Gateway load balancer IP and add a DNS record for it:
-
-```bash
-kubectl -n istio-system get svc/istio-ingressgateway -ojson | jq -r .status.loadBalancer.ingress[0].ip
-```
-
-## Install Flagger and Grafana
-
-Add Flagger Helm repository:
-
-```bash
-helm repo add flagger https://flagger.app
-```
-
-Deploy Flagger in the _**istio-system**_ namespace:
-
-```bash
-helm upgrade -i flagger flagger/flagger \
---namespace=istio-system \
---set meshProvider=smi:istio
-```
-
-Flagger comes with a Grafana dashboard made for monitoring the canary deployments.
-
-Deploy Grafana in the _**istio-system**_ namespace:
-
-```bash
-helm upgrade -i flagger-grafana flagger/grafana \
---namespace=istio-system \
---set url=http://prometheus.istio-system:9090
-```
-
-You can access Grafana using port forwarding:
-
-```bash
-kubectl -n istio-system port-forward svc/flagger-grafana 3000:80
-```
-
-## Workloads bootstrap
-
-Create a test namespace with Istio sidecar injection enabled:
-
-Create a test namespace and enable Linkerd proxy injection:
-
-```bash
-kubectl create ns test
-kubectl label namespace test istio-injection=enabled
-```
-
-Create a deployment and a horizontal pod autoscaler:
-
-```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo
-```
-
-Deploy the load testing service to generate traffic during the canary analysis:
-
-```bash
-kubectl apply -k github.com/weaveworks/flagger//kustomize/tester
-```
-
-Create a canary custom resource \(replace example.com with your own domain\):
-
-```yaml
-apiVersion: flagger.app/v1beta1
-kind: Canary
-metadata:
-  name: podinfo
-  namespace: test
-spec:
-  # deployment reference
-  targetRef:
-    apiVersion: apps/v1
-    kind: Deployment
-    name: podinfo
-  # the maximum time in seconds for the canary deployment
-  # to make progress before it is rollback (default 600s)
-  progressDeadlineSeconds: 60
-  # HPA reference (optional)
-  autoscalerRef:
-    apiVersion: autoscaling/v2beta1
-    kind: HorizontalPodAutoscaler
-    name: podinfo
-  service:
-    # container port
-    port: 9898
-    # Istio gateways (optional)
-    gateways:
-    - public-gateway.istio-system.svc.cluster.local
-    # Istio virtual service host names (optional)
-    hosts:
-    - app.example.com
-  analysis:
-    # schedule interval (default 60s)
-    interval: 10s
-    # max number of failed metric checks before rollback
-    threshold: 5
-    # max traffic percentage routed to canary
-    # percentage (0-100)
-    maxWeight: 50
-    # canary increment step
-    # percentage (0-100)
-    stepWeight: 10
-    metrics:
-    - name: request-success-rate
-      # minimum req success rate (non 5xx responses)
-      # percentage (0-100)
-      thresholdRange:
-        min: 99
-      interval: 1m
-    - name: request-duration
-      # maximum req duration P99
-      # milliseconds
-      thresholdRange:
-        max: 500
-      interval: 30s
-    # generate traffic during analysis
-    webhooks:
-      - name: load-test
-        url: http://flagger-loadtester.test/
-        timeout: 5s
-        metadata:
-          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"
-```
-
-Save the above resource as podinfo-canary.yaml and then apply it:
-
-```bash
-kubectl apply -f ./podinfo-canary.yaml
-```
-
-After a couple of seconds Flagger will create the canary objects:
-
-```bash
-# applied 
-deployment.apps/podinfo
-horizontalpodautoscaler.autoscaling/podinfo
-canary.flagger.app/podinfo
-
-# generated 
-deployment.apps/podinfo-primary
-horizontalpodautoscaler.autoscaling/podinfo-primary
-service/podinfo
-service/podinfo-canary
-service/podinfo-primary
-trafficsplits.split.smi-spec.io/podinfo
-```
-
-## Automated canary promotion
-
-Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack.
-
-![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png)
-
-Trigger a canary deployment by updating the container image:
-
-```bash
-kubectl -n test set image deployment/podinfo \
-podinfod=quay.io/stefanprodan/podinfo:3.1.1
-```
-
-Flagger detects that the deployment revision changed and starts a new rollout:
-
-```text
-kubectl -n istio-system logs deployment/flagger -f | jq .msg
-
-
-New revision detected podinfo.test
-Scaling up podinfo.test
-Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
-Advance podinfo.test canary weight 5
-Advance podinfo.test canary weight 10
-Advance podinfo.test canary weight 15
-Advance podinfo.test canary weight 20
-Advance podinfo.test canary weight 25
-Advance podinfo.test canary weight 30
-Advance podinfo.test canary weight 35
-Advance podinfo.test canary weight 40
-Advance podinfo.test canary weight 45
-Advance podinfo.test canary weight 50
-Copying podinfo.test template spec to podinfo-primary.test
-Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
-Promotion completed! Scaling down podinfo.test
-```
-
-**Note** that if you apply new changes to the deployment during the canary analysis, Flagger will restart the analysis.
-
-During the analysis the canary’s progress can be monitored with Grafana. The Istio dashboard URL is [http://localhost:3000/d/flagger-istio/istio-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo](http://localhost:3000/d/flagger-istio/istio-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo)
-
-You can monitor all canaries with:
-
-```bash
-watch kubectl get canaries --all-namespaces
-
-NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
-test        podinfo   Progressing   15       2019-05-16T14:05:07Z
-prod        frontend  Succeeded     0        2019-05-15T16:15:07Z
-prod        backend   Failed        0        2019-05-14T17:05:07Z
-```
-
-## Automated rollback
-
-During the canary analysis you can generate HTTP 500 errors and high latency to test if Flagger pauses the rollout.
-
-Create a tester pod and exec into it:
-
-```bash
-kubectl -n test run tester \
---image=quay.io/stefanprodan/podinfo:3.1.2 \
--- ./podinfo --port=9898
-
-kubectl -n test exec -it tester-xx-xx sh
-```
-
-Generate HTTP 500 errors:
-
-```bash
-watch curl http://podinfo-canary:9898/status/500
-```
-
-Generate latency:
-
-```bash
-watch curl http://podinfo-canary:9898/delay/1
-```
-
-When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed.
-
-```text
-kubectl -n test describe canary/podinfo
-
-Status:
-  Canary Weight:         0
-  Failed Checks:         10
-  Phase:                 Failed
-Events:
-  Type     Reason  Age   From     Message
-  ----     ------  ----  ----     -------
-  Normal   Synced  3m    flagger  Starting canary deployment for podinfo.test
-  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 5
-  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 10
-  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 15
-  Normal   Synced  3m    flagger  Halt podinfo.test advancement success rate 69.17% < 99%
-  Normal   Synced  2m    flagger  Halt podinfo.test advancement success rate 61.39% < 99%
-  Normal   Synced  2m    flagger  Halt podinfo.test advancement success rate 55.06% < 99%
-  Normal   Synced  2m    flagger  Halt podinfo.test advancement success rate 47.00% < 99%
-  Normal   Synced  2m    flagger  (combined from similar events): Halt podinfo.test advancement success rate 38.08% < 99%
-  Warning  Synced  1m    flagger  Rolling back podinfo.test failed checks threshold reached 10
-  Warning  Synced  1m    flagger  Canary failed! Scaling down podinfo.test
-```
-

docs/gitbook/tutorials/gatewayapi-progressive-delivery.md

@@ -0,0 +1,484 @@
+# Gateway API Canary Deployments
+
+This guide shows you how to use [Gateway API](https://gateway-api.sigs.k8s.io/) and Flagger to automate canary deployments and A/B testing.
+
+![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-gatewayapi-canary.png)
+
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.16** or newer and any mesh/ingress that implements the `v1alpha2` of Gateway API. We'll be using Contour for the sake of this tutorial, but you can use any other implementation. 
+
+Install the GatewayAPI CRDs:
+
+```bash
+kubectl apply -k github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.1
+```
+
+Install a cluster-wide GatewayClass; a Gateway belonging to the GatewayClass and Contour components in the `projectcontour` namespace:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/release-1.20/examples/render/contour-gateway.yaml
+```
+
+Install Flagger in the `flagger-system` namespace:
+
+```bash
+kubectl apply -k github.com/fluxcd/flagger//kustomize/gatewayapi
+```
+
+## Bootstrap
+
+Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services, HTTPRoutes for the Gateway\). These objects expose the application inside the mesh and drive the canary analysis and promotion.
+
+Create a test namespace:
+
+```bash
+kubectl create ns test
+```
+
+Create a deployment and a horizontal pod autoscaler:
+
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
+```
+
+Deploy the load testing service to generate traffic during the canary analysis:
+
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/tester?ref=main
+```
+
+Create metric templates targeting the Prometheus server in the `flagger-system` namespace. The PromQL queries below are meant for `Envoy`, but you can [change it to your ingress/mesh provider](https://docs.flagger.app/faq#metrics) accordingly.
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: latency
+  namespace: flagger-system
+spec:
+  provider:
+    type: prometheus
+    address: http://flagger-prometheus:9090
+  query: |
+    histogram_quantile(0.99,
+      sum(
+        rate(
+          envoy_cluster_upstream_rq_time_bucket{
+            envoy_cluster_name=~"{{ namespace }}_{{ target }}-canary_[0-9a-zA-Z-]+",
+          }[{{ interval }}]
+        )
+      ) by (le)
+    )/1000
+---
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: error-rate
+  namespace: flagger-system
+spec:
+  provider:
+    type: prometheus
+    address: http://flagger-prometheus:9090
+  query: |
+    100 - sum(
+      rate(
+        envoy_cluster_upstream_rq{
+          envoy_cluster_name=~"{{ namespace }}_{{ target }}-canary_[0-9a-zA-Z-]+",
+          envoy_response_code!~"5.*"
+        }[{{ interval }}]
+      )
+    )
+    /
+    sum(
+      rate(
+        envoy_cluster_upstream_rq{
+          envoy_cluster_name=~"{{ namespace }}_{{ target }}-canary_[0-9a-zA-Z-]+",
+        }[{{ interval }}]
+      )
+    )
+    * 100
+```
+
+Save the above resource as metric-templates.yaml and then apply it:
+
+```bash
+kubectl apply -f metric-templates.yaml
+```
+
+Create a canary custom resource \(replace "loaclproject.contour.io" with your own domain\):
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  # deployment reference
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  # the maximum time in seconds for the canary deployment
+  # to make progress before it is rollback (default 600s)
+  progressDeadlineSeconds: 60
+  # HPA reference (optional)
+  autoscalerRef:
+    apiVersion: autoscaling/v2beta2
+    kind: HorizontalPodAutoscaler
+    name: podinfo
+  service:
+    # service port number
+    port: 9898
+    # container port number or name (optional)
+    targetPort: 9898
+    # Gateway API HTTPRoute host names
+    hosts:
+     - localproject.contour.io
+    # Reference to the Gateway that the generated HTTPRoute would attach to.
+    gatewayRefs:
+      - name: contour
+        namespace: projectcontour
+  analysis:
+    # schedule interval (default 60s)
+    interval: 1m
+    # max number of failed metric checks before rollback
+    threshold: 5
+    # max traffic percentage routed to canary
+    # percentage (0-100)
+    maxWeight: 50
+    # canary increment step
+    # percentage (0-100)
+    stepWeight: 10
+    metrics:
+    - name: error-rate
+      # max error rate (5xx responses)
+      # percentage (0-100)
+      templateRef:
+        name: error-rate
+        namespace: flagger-system
+      thresholdRange:
+        max: 1
+      interval: 1m
+    - name: latency
+      templateRef:
+        name: latency
+        namespace: flagger-system
+      # seconds
+      thresholdRange:
+         max: 0.5
+      interval: 30s
+    # testing (optional)
+    webhooks:
+      - name: smoke-test
+        type: pre-rollout
+        url: http://flagger-loadtester.test/
+        timeout: 15s
+        metadata:
+          type: bash
+          cmd: "curl -sd 'anon' http://podinfo-canary.test:9898/token | grep token"
+      - name: load-test
+        url: http://flagger-loadtester.test/
+        timeout: 5s
+        metadata:
+          cmd: "hey -z 2m -q 10 -c 2 -host localproject.contour.io http://envoy.projectcontour/"
+```
+
+Save the above resource as podinfo-canary.yaml and then apply it:
+
+```bash
+kubectl apply -f ./podinfo-canary.yaml
+```
+
+When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary. The canary analysis will run for five minutes while validating the HTTP metrics and rollout hooks every minute.
+
+After a couple of seconds Flagger will create the canary objects:
+
+```bash
+# applied 
+deployment.apps/podinfo
+horizontalpodautoscaler.autoscaling/podinfo
+canary.flagger.app/podinfo
+
+# generated 
+deployment.apps/podinfo-primary
+horizontalpodautoscaler.autoscaling/podinfo-primary
+service/podinfo
+service/podinfo-canary
+service/podinfo-primary
+httproutes.gateway.networking.k8s.io/podinfo
+```
+
+## Expose the app outside the cluster
+
+Find the external address of Contour's Envoy load balancer:
+
+```bash
+export ADDRESS="$(kubectl -n projectcontour get svc/envoy -ojson \
+| jq -r ".status.loadBalancer.ingress[].hostname")"
+echo $ADDRESS
+```
+
+Configure your DNS server with a CNAME record \(AWS\) or A record \(GKE/AKS/DOKS\) and point a domain e.g. `localproject.contour.io` to the LB address.
+
+Now you can access the podinfo UI using your domain address.
+
+Note that you should be using HTTPS when exposing production workloads on internet. You can obtain free TLS certs from Let's Encrypt, read this [guide](https://github.com/stefanprodan/eks-contour-ingress) on how to configure cert-manager to secure Contour with TLS certificates.
+
+If you're using a local cluster via kind/k3s you can port forward the Envoy LoadBalancer service:
+```bash
+kubectl port-forward -n projectcontour svc/envoy 8080:80
+```
+
+Now you can access podinfo via `curl -H "Host: localproject.contour.io" localhost:8080`
+
+## Automated canary promotion
+
+Trigger a canary deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=stefanprodan/podinfo:6.0.1
+```
+
+Flagger detects that the deployment revision changed and starts a new rollout:
+
+```text
+kubectl -n test describe canary/podinfo
+
+Status:
+  Canary Weight:         0
+  Failed Checks:         0
+  Phase:                 Succeeded
+Events:
+  Type     Reason  Age   From     Message
+  ----     ------  ----  ----     -------
+  Normal   Synced  3m    flagger  New revision detected podinfo.test
+  Normal   Synced  3m    flagger  Scaling up podinfo.test
+  Warning  Synced  3m    flagger  Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 5
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 10
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 15
+  Normal   Synced  2m    flagger  Advance podinfo.test canary weight 20
+  Normal   Synced  2m    flagger  Advance podinfo.test canary weight 25
+  Normal   Synced  1m    flagger  Advance podinfo.test canary weight 30
+  Normal   Synced  1m    flagger  Advance podinfo.test canary weight 35
+  Normal   Synced  55s   flagger  Advance podinfo.test canary weight 40
+  Normal   Synced  45s   flagger  Advance podinfo.test canary weight 45
+  Normal   Synced  35s   flagger  Advance podinfo.test canary weight 50
+  Normal   Synced  25s   flagger  Copying podinfo.test template spec to podinfo-primary.test
+  Warning  Synced  15s   flagger  Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
+  Normal   Synced  5s    flagger  Promotion completed! Scaling down podinfo.test
+```
+
+**Note** that if you apply new changes to the deployment during the canary analysis, Flagger will restart the analysis.
+
+A canary deployment is triggered by changes in any of the following objects:
+
+* Deployment PodSpec \(container image, command, ports, env, resources, etc\)
+* ConfigMaps mounted as volumes or mapped to environment variables
+* Secrets mounted as volumes or mapped to environment variables
+
+You can monitor how Flagger progressively changes the weights of the HTTPRoute object that is attahed to the Gateway with:
+
+```bash
+watch kubectl get httproute -n test podinfo -o=jsonpath='{.spec.rules}'
+```
+
+You can monitor all canaries with:
+
+```bash
+watch kubectl get canaries --all-namespaces
+
+NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
+test        podinfo   Progressing   15       2022-01-16T14:05:07Z
+prod        frontend  Succeeded     0        2022-01-15T16:15:07Z
+prod        backend   Failed        0        2022-01-14T17:05:07Z
+```
+
+## Automated rollback
+
+During the canary analysis you can generate HTTP 500 errors and high latency to test if Flagger pauses the rollout.
+
+Trigger another canary deployment:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=stefanprodan/podinfo:6.0.2
+```
+
+Exec into the load tester pod with:
+
+```bash
+kubectl -n test exec -it flagger-loadtester-xx-xx sh
+```
+
+Generate HTTP 500 errors:
+
+```bash
+watch curl http://podinfo-canary:9898/status/500
+```
+
+Generate latency:
+
+```bash
+watch curl http://podinfo-canary:9898/delay/1
+```
+
+When the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed.
+
+```text
+kubectl -n test describe canary/podinfo
+
+Status:
+  Canary Weight:         0
+  Failed Checks:         10
+  Phase:                 Failed
+Events:
+  Type     Reason  Age   From     Message
+  ----     ------  ----  ----     -------
+  Normal   Synced  3m    flagger  Starting canary deployment for podinfo.test
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 5
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 10
+  Normal   Synced  3m    flagger  Advance podinfo.test canary weight 15
+  Normal   Synced  3m    flagger  Halt podinfo.test advancement error rate 69.17% > 1%
+  Normal   Synced  2m    flagger  Halt podinfo.test advancement error rate 61.39% > 1%
+  Normal   Synced  2m    flagger  Halt podinfo.test advancement error rate 55.06% > 1%
+  Normal   Synced  2m    flagger  Halt podinfo.test advancement error rate 47.00% > 1%
+  Normal   Synced  2m    flagger  (combined from similar events): Halt podinfo.test advancement error rate 38.08% > 1%
+  Warning  Synced  1m    flagger  Rolling back podinfo.test failed checks threshold reached 10
+  Warning  Synced  1m    flagger  Canary failed! Scaling down podinfo.test
+```
+
+# A/B Testing
+
+Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity.
+
+![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png)
+
+Create a canary custom resource \(replace "loaclproject.contour.io" with your own domain\):
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  # deployment reference
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  # the maximum time in seconds for the canary deployment
+  # to make progress before it is rollback (default 600s)
+  progressDeadlineSeconds: 60
+  # HPA reference (optional)
+  autoscalerRef:
+    apiVersion: autoscaling/v2beta2
+    kind: HorizontalPodAutoscaler
+    name: podinfo
+  service:
+    # service port number
+    port: 9898
+    # container port number or name (optional)
+    targetPort: 9898
+    # Gateway API HTTPRoute host names
+    hosts:
+     - localproject.contour.io
+    # Reference to the Gateway that the generated HTTPRoute would attach to.
+    gatewayRefs:
+      - name: contour
+        namespace: projectcontour
+  analysis:
+    # schedule interval (default 60s)
+    interval: 1m
+    # max number of failed metric checks before rollback
+    threshold: 5
+    # max traffic percentage routed to canary
+    # percentage (0-100)
+    maxWeight: 50
+    # canary increment step
+    # percentage (0-100)
+    stepWeight: 10
+    metrics:
+    - name: error-rate
+      # max error rate (5xx responses)
+      # percentage (0-100)
+      templateRef:
+        name: error-rate
+        namespace: flagger-system
+      thresholdRange:
+        max: 1
+      interval: 1m
+    - name: latency
+      templateRef:
+        name: latency
+        namespace: flagger-system
+      # seconds
+      thresholdRange:
+         max: 0.5
+      interval: 30s
+    # testing (optional)
+    webhooks:
+      - name: smoke-test
+        type: pre-rollout
+        url: http://flagger-loadtester.test/
+        timeout: 15s
+        metadata:
+          type: bash
+          cmd: "curl -sd 'anon' http://podinfo-canary.test:9898/token | grep token"
+      - name: load-test
+        url: http://flagger-loadtester.test/
+        timeout: 5s
+        metadata:
+          cmd: "hey -z 2m -q 10 -c 2 -host localproject.contour.io -H 'X-Canary: insider' http://envoy.projectcontour/"
+```
+
+The above configuration will run an analysis for ten minutes targeting those users that have an insider cookie.
+
+Save the above resource as podinfo-ab-canary.yaml and then apply it:
+
+```bash
+kubectl apply -f ./podinfo-ab-canary.yaml
+```
+
+Trigger a canary deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=stefanprodan/podinfo:6.0.3
+```
+
+Flagger detects that the deployment revision changed and starts a new rollout:
+
+```text
+kubectl -n test describe canary/abtest
+
+Status:
+  Failed Checks:         0
+  Phase:                 Succeeded
+Events:
+  Type     Reason  Age   From     Message
+  ----     ------  ----  ----     -------
+  Normal   Synced  3m    flagger  New revision detected podinfo.test
+  Normal   Synced  3m    flagger  Scaling up podinfo.test
+  Warning  Synced  3m    flagger  Waiting for podinfo.test rollout to finish: 0 of 1 updated replicas are available
+  Normal   Synced  3m    flagger  Advance podinfo.test canary iteration 1/10
+  Normal   Synced  3m    flagger  Advance podinfo.test canary iteration 2/10
+  Normal   Synced  3m    flagger  Advance podinfo.test canary iteration 3/10
+  Normal   Synced  2m    flagger  Advance podinfo.test canary iteration 4/10
+  Normal   Synced  2m    flagger  Advance podinfo.test canary iteration 5/10
+  Normal   Synced  1m    flagger  Advance podinfo.test canary iteration 6/10
+  Normal   Synced  1m    flagger  Advance podinfo.test canary iteration 7/10
+  Normal   Synced  55s   flagger  Advance podinfo.test canary iteration 8/10
+  Normal   Synced  45s   flagger  Advance podinfo.test canary iteration 9/10
+  Normal   Synced  35s   flagger  Advance podinfo.test canary iteration 10/10
+  Normal   Synced  25s   flagger  Copying podinfo.test template spec to podinfo-primary.test
+  Warning  Synced  15s   flagger  Waiting for podinfo-primary.test rollout to finish: 1 of 2 updated replicas are available
+  Normal   Synced  5s    flagger  Promotion completed! Scaling down podinfo.test
+```
+
+
+The above procedures can be extended with [custom metrics](../usage/metrics.md) checks, [webhooks](../usage/webhooks.md), [manual promotion](../usage/webhooks.md#manual-gating) approval and [Slack or MS Teams](../usage/alerting.md) notifications.