ci: Pin Helm and Cosign action version

Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>

.clomonitor.yml

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

.gitbook.yaml

@@ -13,3 +13,6 @@ redirects:
   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/dependabot.yml

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

.github/workflows/build.yaml

@@ -9,29 +9,34 @@ on:
     branches:
       - main
 
+permissions:
+  contents: read
+
 jobs:
-  container:
+  build-flagger:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@v2
       - name: Restore Go cache
-        uses: actions/cache@v1
+        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@v2
+        uses: actions/setup-go@v3
         with:
-          go-version: 1.15.x
+          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
@@ -42,7 +47,7 @@ jobs:
             exit 1
           fi
       - name: Upload coverage to Codecov
-        uses: codecov/codecov-action@v1
+        uses: codecov/codecov-action@v3
         with:
           file: ./coverage.txt
       - name: Build container image

.github/workflows/e2e.yaml

@@ -9,25 +9,38 @@ on:
     branches:
       - main
 
+permissions:
+  contents: read
+
 jobs:
-  kind:
+  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@v2
       - 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 .

.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@v2
+      - 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@v1
+        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@v2
+        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

@@ -4,34 +4,50 @@ on:
     tags:
       - 'v*'
 
+permissions:
+  contents: read
+
+env:
+  IMAGE: "ghcr.io/fluxcd/${{ github.event.repository.name }}"
+
 jobs:
-  build-push:
+  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@v2
+      - 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}
-          echo ::set-output name=CHANGELOG::${CHANGELOG}
       - name: Setup QEMU
-        uses: docker/setup-qemu-action@v1
-        with:
-          platforms: all
+        uses: docker/setup-qemu-action@v2
       - name: Setup Docker Buildx
         id: buildx
-        uses: docker/setup-buildx-action@v1
-        with:
-          buildkitd-flags: "--debug"
+        uses: docker/setup-buildx-action@v2
       - name: Login to GitHub Container Registry
-        uses: docker/login-action@v1
+        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@v2
         with:
@@ -42,33 +58,44 @@ jobs:
           platforms: linux/amd64,linux/arm64,linux/arm/v7
           build-args: |
             REVISON=${{ github.sha }}
-          tags: |
-            ghcr.io/fluxcd/flagger:${{ steps.prep.outputs.VERSION }}
-          labels: |
-            org.opencontainers.image.title=${{ github.event.repository.name }}
-            org.opencontainers.image.description=${{ github.event.repository.description }}
-            org.opencontainers.image.url=${{ github.event.repository.html_url }}
-            org.opencontainers.image.source=${{ github.event.repository.html_url }}
-            org.opencontainers.image.revision=${{ github.sha }}
-            org.opencontainers.image.version=${{ steps.prep.outputs.VERSION }}
-            org.opencontainers.image.created=${{ steps.prep.outputs.BUILD_DATE }}
-      - name: Check images
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+      - name: Sign image
+        env:
+          COSIGN_EXPERIMENTAL: 1
         run: |
-          docker buildx imagetools inspect ghcr.io/fluxcd/flagger:${{ steps.prep.outputs.VERSION }}
+          cosign sign ${{ env.IMAGE }}:${{ steps.prep.outputs.VERSION }}
       - name: Publish Helm charts
-        uses: stefanprodan/helm-gh-pages@v1.3.0
+        uses: stefanprodan/helm-gh-pages@v1.6.0
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           charts_url: https://flagger.app
           linting: off
-      - name: Create release
-        uses: actions/create-release@latest
+      - 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@v2
+        with:
+          version: latest
+          args: release --release-notes=notes.md --rm-dist --skip-validate
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        with:
-          tag_name: ${{ github.ref }}
-          release_name: ${{ github.ref }}
-          draft: false
-          prerelease: false
-          body: |
-            [CHANGELOG](${{ steps.prep.outputs.CHANGELOG }})

.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@v2
+      - 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@v2
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v1
+        with:
+          languages: go
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v1
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v1

.goreleaser.yml

@@ -1,14 +1,30 @@
+project_name: flagger
+
 builds:
-  - main: ./cmd/flagger
-    binary: flagger
-    ldflags: -s -w -X github.com/fluxcd/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*
+      - COSIGN_EXPERIMENTAL=1
+    certificate: '${artifact}.pem'
+    args:
+      - sign-blob
+      - '--output-certificate=${certificate}'
+      - '--output-signature=${signature}'
+      - '${artifact}'
+    artifacts: checksum
+    output: true

CHANGELOG.md

@@ -2,6 +2,682 @@
 
 All notable changes to this project are documented in this file.
 
+## 1.24.0
+
+**Release date:** 2022-10-23
+
+Starting with this version, the Flagger release artifacts are published to
+GitHub Container Registry, and they are signed with Cosign and GitHub ODIC.
+
+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
+
+To verify an OCI artifact with Cosign:
+
+```shell
+export COSIGN_EXPERIMENTAL=1
+cosign verify ghcr.io/fluxcd/flagger:1.24.0
+cosign verify ghcr.io/fluxcd/flagger-manifests:1.24.0
+cosign verify ghcr.io/fluxcd/charts/flagger:1.24.0
+```
+
+To deploy Flagger from its OCI artifacts the GitOps way,
+please see the [Flux installation guide](docs/gitbook/install/flagger-install-with-flux.md).
+
+#### Improvements:
+
+- docs: Add guide on how to install Flagger with Flux OCI
+  [#1294](https://github.com/fluxcd/flagger/pull/1294)
+- ci: Publish signed Helm charts and manifests to GHCR
+  [#1293](https://github.com/fluxcd/flagger/pull/1293)
+- ci: Sign release and containers with Cosign and GitHub OIDC
+  [#1292](https://github.com/fluxcd/flagger/pull/1292)
+- ci: Adjust GitHub workflow permissions
+  [#1286](https://github.com/fluxcd/flagger/pull/1286)
+- docs: Add link to Flux governance document
+  [#1286](https://github.com/fluxcd/flagger/pull/1286)
+
+## 1.23.0
+
+**Release date:** 2022-10-20
+
+This release comes with support for Slack bot token authentication.
+
+#### Improvements:
+
+- alerts: Add support for Slack bot token authentication
+  [#1270](https://github.com/fluxcd/flagger/pull/1270)
+- loadtester: logCmdOutput to logger instead of stdout
+  [#1267](https://github.com/fluxcd/flagger/pull/1267)
+- helm: Add app.kubernetes.io/version label to chart
+  [#1264](https://github.com/fluxcd/flagger/pull/1264)
+- Update Go to 1.19
+  [#1264](https://github.com/fluxcd/flagger/pull/1264)
+- Update Kubernetes packages to v1.25.3
+  [#1283](https://github.com/fluxcd/flagger/pull/1283)
+- Bump Contour to v1.22 in e2e tests
+  [#1282](https://github.com/fluxcd/flagger/pull/1282)
+
+#### Fixes:
+
+- gatewayapi: Fix reconciliation of nil hostnames
+  [#1276](https://github.com/fluxcd/flagger/pull/1276)
+- alerts: Include cluster name in all alerts
+  [#1275](https://github.com/fluxcd/flagger/pull/1275)
+
+## 1.22.2
+
+**Release date:** 2022-08-29
+
+This release fixes a bug related scaling up the canary deployment when a
+reference to an autoscaler is specified.
+
+Furthermore, it contains updates to packages used by the project, including
+updates to Helm and grpc-health-probe used in the loadtester.
+
+CVEs fixed (originating from dependencies):
+* CVE-2022-37434
+* CVE-2022-27191
+* CVE-2021-33194
+* CVE-2021-44716
+* CVE-2022-29526
+* CVE-2022-1996
+
+#### Fixes:
+
+- If HPA is set, it uses HPA minReplicas when scaling up the canary
+  [#1253](https://github.com/fluxcd/flagger/pull/1253)
+
+#### Improvements:
+
+- Release loadtester v0.23.0
+  [#1246](https://github.com/fluxcd/flagger/pull/1246)
+- Add target and script to keep crds in sync
+  [#1254](https://github.com/fluxcd/flagger/pull/1254)
+- docs: add knative support to roadmap
+  [#1258](https://github.com/fluxcd/flagger/pull/1258)
+- Update dependencies
+  [#1259](https://github.com/fluxcd/flagger/pull/1259)
+- Release loadtester v0.24.0
+  [#1261](https://github.com/fluxcd/flagger/pull/1261)
+
+## 1.22.1
+
+**Release date:** 2022-08-01
+
+This minor release fixes a bug related to the use of HPA v2beta2 and updates
+the KEDA ScaledObject API to include `MetricType` for `ScaleTriggers`.
+
+Furthermore, the project has been updated to use Go 1.18 and Alpine 3.16.
+
+#### Fixes:
+
+- Update KEDA ScaledObject API to include MetricType for Triggers
+  [#1241](https://github.com/fluxcd/flagger/pull/1241)
+- Fix fallback logic for HPAv2 to v2beta2
+  [#1242](https://github.com/fluxcd/flagger/pull/1242)
+
+#### Improvements:
+- Update Go to 1.18 and Alpine to 3.16
+  [#1243](https://github.com/fluxcd/flagger/pull/1243)
+- Clarify HPA API requirement
+  [#1239](https://github.com/fluxcd/flagger/pull/1239)
+- Update README
+  [#1233](https://github.com/fluxcd/flagger/pull/1233)
+
+## 1.22.0
+
+**Release date:** 2022-07-11
+
+This release with support for KEDA ScaledObjects as an alternative to HPAs. Check the
+[tutorial](https://docs.flagger.app/tutorials/keda-scaledobject) to understand it's usage
+with Flagger.
+
+The `.spec.service.appProtocol` field can now be used to specify the [`appProtocol`](https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol)
+of the services that Flagger generates.
+
+In addition, a bug related to the Contour prometheus query for when service name is overwritten
+along with a bug related to a Contour `HTTPProxy` annotations have been fixed.
+
+Furthermore, the installation guide for Alibaba ServiceMesh has been updated.
+
+#### Improvements:
+
+- feat: Add an optional `appProtocol` field to `spec.service`
+  [#1185](https://github.com/fluxcd/flagger/pull/1185)
+- Update Kubernetes packages to v1.24.1
+  [#1208](https://github.com/fluxcd/flagger/pull/1208)
+- charts: Add namespace parameter to parameters table
+  [#1210](https://github.com/fluxcd/flagger/pull/1210)
+- Introduce `ScalerReconciler` and refactor HPA reconciliation
+  [#1211](https://github.com/fluxcd/flagger/pull/1211)
+- e2e: Update providers and Kubernetes to v1.23
+  [#1212](https://github.com/fluxcd/flagger/pull/1212)
+- Add support for KEDA ScaledObjects as an auto scaler
+  [#1216](https://github.com/fluxcd/flagger/pull/1216)
+- include Contour retryOn in the sample canary
+  [#1223](https://github.com/fluxcd/flagger/pull/1223)
+
+#### Fixes:
+- fix contour prom query for when service name is overwritten
+  [#1204](https://github.com/fluxcd/flagger/pull/1204)
+- fix contour httproxy annotations overwrite
+  [#1205](https://github.com/fluxcd/flagger/pull/1205)
+- Fix primary HPA label reconciliation
+  [#1215](https://github.com/fluxcd/flagger/pull/1215)
+- fix: add finalizers to canaries
+  [#1219](https://github.com/fluxcd/flagger/pull/1219)
+- typo: boostrap -> bootstrap
+  [#1220](https://github.com/fluxcd/flagger/pull/1220)
+- typo: controller
+  [#1221](https://github.com/fluxcd/flagger/pull/1221)
+- update guide for flagger on aliyun ASM
+  [#1222](https://github.com/fluxcd/flagger/pull/1222)
+- Reintroducing empty check for metric template references.
+  [#1224](https://github.com/fluxcd/flagger/pull/1224)
+
+
+## 1.21.0
+
+**Release date:** 2022-05-06
+
+This release comes with an option to disable cross-namespace references to Kubernetes
+custom resources such as `AlertProivders` and `MetricProviders`. When running Flagger
+on multi-tenant environments it is advised to set the `-no-cross-namespace-refs=true` flag.
+
+In addition, this version enables Flagger to target Istio and Kuma multi-cluster setups.
+When installing Flagger with Helm, the service mesh control plane kubeconfig secret
+can be specified using `--set controlplane.kubeconfig.secretName`.
+
+#### Improvements
+
+- Add flag to disable cross namespace refs to custom resources
+  [#1181](https://github.com/fluxcd/flagger/pull/1181)
+- Rename kubeconfig section in helm values
+  [#1188](https://github.com/fluxcd/flagger/pull/1188)
+- Update Flagger overview diagram
+  [#1187](https://github.com/fluxcd/flagger/pull/1187)
+
+#### Fixes
+
+- Avoid setting owner refs if the service mesh/ingress is on a different cluster
+  [#1183](https://github.com/fluxcd/flagger/pull/1183)
+
+## 1.20.0
+
+**Release date:** 2022-04-15
+
+This release comes with improvements to the AppMesh, Contour and Istio integrations.
+
+#### Improvements
+
+- AppMesh: Add annotation to enable Envoy access logs
+  [#1156](https://github.com/fluxcd/flagger/pull/1156)
+- Contour: Update the httproxy API and enable RetryOn
+  [#1164](https://github.com/fluxcd/flagger/pull/1164)
+- Istio: Add destination port when port discovery and delegation are true
+  [#1145](https://github.com/fluxcd/flagger/pull/1145)
+- Metrics: Add canary analysis result as Prometheus metrics
+  [#1148](https://github.com/fluxcd/flagger/pull/1148)
+
+#### Fixes
+
+- Fix canary rollback behaviour
+  [#1171](https://github.com/fluxcd/flagger/pull/1171)
+- Shorten the metric analysis cycle after confirm promotion gate is open
+  [#1139](https://github.com/fluxcd/flagger/pull/1139)
+- Fix unit of time in the Istio Grafana dashboard
+  [#1162](https://github.com/fluxcd/flagger/pull/1162)
+- Fix the service toggle condition in the podinfo helm chart
+  [#1146](https://github.com/fluxcd/flagger/pull/1146)
+
+## 1.19.0
+
+**Release date:** 2022-03-14
+
+This release comes with support for Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/) v1alpha2.
+For more details see the [Gateway API Progressive Delivery tutorial](https://docs.flagger.app/tutorials/gatewayapi-progressive-delivery).
+
+#### Features
+
+- Add Gateway API as a provider
+  [#1108](https://github.com/fluxcd/flagger/pull/1108)
+
+#### Improvements
+
+- Add arm64 support for loadtester
+  [#1128](https://github.com/fluxcd/flagger/pull/1128)
+- Restrict source namespaces in flagger-loadtester
+  [#1119](https://github.com/fluxcd/flagger/pull/1119)
+- Remove support for Helm v2 in loadtester
+  [#1130](https://github.com/fluxcd/flagger/pull/1130)
+
+#### Fixes
+
+- Fix potential canary finalizer duplication
+  [#1125](https://github.com/fluxcd/flagger/pull/1125)
+- Use the primary replicas when scaling up the canary (no hpa)
+  [#1110](https://github.com/fluxcd/flagger/pull/1110)
+
+## 1.18.0
+
+**Release date:** 2022-02-14
+
+This release comes with a new API field called `canaryReadyThreshold`
+that allows setting the percentage of pods that need to be available
+to consider the canary deployment as ready.
+
+Starting with version, the canary deployment labels, annotations and
+replicas fields are copied to the primary deployment at promotion time.
+
+#### Features
+
+- Add field `spec.analysis.canaryReadyThreshold` for configuring canary threshold
+  [#1102](https://github.com/fluxcd/flagger/pull/1102)
+
+#### Improvements
+
+- Update metadata during subsequent promote
+  [#1092](https://github.com/fluxcd/flagger/pull/1092)
+- Set primary deployment `replicas` when autoscaler isn't used
+  [#1106](https://github.com/fluxcd/flagger/pull/1106)
+- Update `matchLabels` for `TopologySpreadContstraints` in Deployments
+  [#1041](https://github.com/fluxcd/flagger/pull/1041)
+
+#### Fixes
+
+- Send warning and error alerts correctly
+  [#1105](https://github.com/fluxcd/flagger/pull/1105)
+- Fix for when Prometheus returns NaN
+  [#1095](https://github.com/fluxcd/flagger/pull/1095)
+- docs: Fix typo ExternalDNS
+  [#1103](https://github.com/fluxcd/flagger/pull/1103)
+
+## 1.17.0
+
+**Release date:** 2022-01-11
+
+This release comes with support for [Kuma Service Mesh](https://kuma.io/).
+For more details see the [Kuma Progressive Delivery tutorial](https://docs.flagger.app/tutorials/kuma-progressive-delivery).
+
+To differentiate alerts based on the cluster name, you can configure Flagger with the `-cluster-name=my-cluster`
+command flag, or with Helm `--set clusterName=my-cluster`.
+
+#### Features
+
+- Add kuma support for progressive traffic shifting canaries
+  [#1085](https://github.com/fluxcd/flagger/pull/1085)
+  [#1093](https://github.com/fluxcd/flagger/pull/1093)
+
+#### Improvements
+
+- Publish a Software Bill of Materials (SBOM)
+  [#1094](https://github.com/fluxcd/flagger/pull/1094)
+- Add cluster name to flagger cmd args for altering
+  [#1041](https://github.com/fluxcd/flagger/pull/1041)
+
+## 1.16.1
+
+**Release date:** 2021-12-17
+
+This release contains updates to Kubernetes packages (1.23.0), Alpine (3.15)
+and load tester components.
+
+#### Improvements
+
+- Release loadtester v0.21.0
+  [#1083](https://github.com/fluxcd/flagger/pull/1083)
+- Add loadtester image pull secrets to Helm chart
+  [#1076](https://github.com/fluxcd/flagger/pull/1076)
+- Update libraries included in the load tester to newer versions
+  [#1063](https://github.com/fluxcd/flagger/pull/1063)
+  [#1080](https://github.com/fluxcd/flagger/pull/1080)
+- Update Kubernetes packages to v1.23.0
+  [#1078](https://github.com/fluxcd/flagger/pull/1078)
+- Update Alpine to 3.15
+  [#1081](https://github.com/fluxcd/flagger/pull/1081)
+- Update Go to v1.17
+  [#1077](https://github.com/fluxcd/flagger/pull/1077)
+
+## 1.16.0
+
+**Release date:** 2021-11-22
+
+This release comes with a new API field called `primaryReadyThreshold`
+that allows setting the percentage of pods that need to be available
+to consider the primary deployment as ready.
+
+#### Features
+
+- Allow configuring threshold for primary
+  [#1048](https://github.com/fluxcd/flagger/pull/1048)
+
+#### Improvements
+
+- Append to list of ownerReferences for primary configmaps and secrets
+  [#1052](https://github.com/fluxcd/flagger/pull/1052)
+- Prevent Flux from overriding Flagger managed objects
+  [#1049](https://github.com/fluxcd/flagger/pull/1049)
+- Add warning in docs about ExternalDNS + Istio configuration
+  [#1044](https://github.com/fluxcd/flagger/pull/1044)
+
+#### Fixes
+
+- Mark `CanaryMetric.Threshold` as omitempty
+  [#1047](https://github.com/fluxcd/flagger/pull/1047)
+- Replace `ioutil` in testing of gchat
+  [#1045](https://github.com/fluxcd/flagger/pull/1045)
+
+## 1.15.0
+
+**Release date:** 2021-10-28
+
+This release comes with support for NGINX ingress canary metrics.
+The nginx-ingress minimum supported version is now v1.0.2.
+
+Starting with version, Flagger will use the `spec.service.apex.annotations`
+to annotate the generated apex VirtualService, TrafficSplit or HTTPProxy.
+
+#### Features
+
+- Use nginx controller canary metrics
+  [#1023](https://github.com/fluxcd/flagger/pull/1023)
+- Add metadata annotations to generated apex objects
+  [#1034](https://github.com/fluxcd/flagger/pull/1034)
+
+#### Improvements
+
+- Update load tester binaries (CVEs fix)
+  [#1038](https://github.com/fluxcd/flagger/pull/1038)
+- Add podLabels to load tester Helm chart
+  [#1036](https://github.com/fluxcd/flagger/pull/1036)
+
+## 1.14.0
+
+**Release date:** 2021-09-20
+
+This release comes with support for extending the canary analysis with
+Dynatrace, InfluxDB and Google Cloud Monitoring (Stackdriver) metrics.
+
+#### Features
+
+- Add Stackdriver metric provider
+  [#991](https://github.com/fluxcd/flagger/pull/991)
+- Add Influxdb metric provider
+  [#1012](https://github.com/fluxcd/flagger/pull/1012)
+- Add Dynatrace metric provider
+  [#1013](https://github.com/fluxcd/flagger/pull/1013)
+
+#### Fixes
+
+- Fix inline promql query
+  [#1015](https://github.com/fluxcd/flagger/pull/1015)
+- Fix Istio load balancer settings mapping
+  [#1016](https://github.com/fluxcd/flagger/pull/1016)
+
+## 1.13.0
+
+**Release date:** 2021-08-25
+
+This release comes with support for [Open Service Mesh](https://openservicemesh.io).
+For more details see the [OSM Progressive Delivery tutorial](https://docs.flagger.app/tutorials/osm-progressive-delivery).
+
+Starting with this version, Flagger container images are signed with
+[sigstore/cosign](https://github.com/sigstore/cosign), for more details see the
+[Flagger cosign docs](https://github.com/fluxcd/flagger/blob/main/.cosign/README.md).
+
+#### Features
+
+- Support OSM progressive traffic shifting in Flagger
+  [#955](https://github.com/fluxcd/flagger/pull/955)
+  [#977](https://github.com/fluxcd/flagger/pull/977)
+- Add support for Google Chat alerts
+  [#953](https://github.com/fluxcd/flagger/pull/953)
+
+#### Improvements
+
+- Sign Flagger container images with cosign
+  [#983](https://github.com/fluxcd/flagger/pull/983)
+- Update Gloo APIs and e2e tests to Gloo v1.8.9
+  [#982](https://github.com/fluxcd/flagger/pull/982)
+- Update e2e tests to Istio v1.11, Contour v1.18, Linkerd v2.10.2 and NGINX v0.49.0
+  [#979](https://github.com/fluxcd/flagger/pull/979)
+- Update e2e tests to Traefik to 2.4.9
+  [#960](https://github.com/fluxcd/flagger/pull/960)
+- Add support for volumes/volumeMounts in loadtester Helm chart
+  [#975](https://github.com/fluxcd/flagger/pull/975)
+- Add extra podLabels options to Flagger Helm Chart
+  [#966](https://github.com/fluxcd/flagger/pull/966)
+
+#### Fixes
+
+- Fix for the http client proxy overriding the default client
+  [#943](https://github.com/fluxcd/flagger/pull/943)
+- Drop deprecated io/ioutil
+  [#964](https://github.com/fluxcd/flagger/pull/964)
+- Remove problematic nulls from Grafana dashboard
+  [#952](https://github.com/fluxcd/flagger/pull/952)
+
+## 1.12.1
+
+**Release date:** 2021-06-17
+
+This release comes with a fix to Flagger when used with Flux v2.
+
+#### Improvements
+
+- Update Go to v1.16 and Kubernetes packages to v1.21.1
+  [#940](https://github.com/fluxcd/flagger/pull/940)
+
+#### Fixes
+
+- Remove the GitOps Toolkit metadata from generated objects
+  [#939](https://github.com/fluxcd/flagger/pull/939)
+
+## 1.12.0
+
+**Release date:** 2021-06-16
+
+This release comes with support for disabling the SSL certificate verification
+for the Prometheus and Graphite metric providers.
+
+#### Improvements
+ 
+- Add `insecureSkipVerify` option for Prometheus and Graphite
+  [#935](https://github.com/fluxcd/flagger/pull/935)
+- Copy labels from Gloo upstreams
+  [#932](https://github.com/fluxcd/flagger/pull/932)
+- Improve language and correct typos in FAQs docs
+  [#925](https://github.com/fluxcd/flagger/pull/925)
+- Remove Flux GC markers from generated objects
+  [#936](https://github.com/fluxcd/flagger/pull/936)
+
+#### Fixes
+
+- Require SMI TrafficSplit Service and Weight
+  [#878](https://github.com/fluxcd/flagger/pull/878)
+ 
+## 1.11.0
+
+**Release date:** 2021-06-01
+
+**Breaking change:** the minimum supported version of Kubernetes is v1.19.0.
+
+This release comes with support for Kubernetes Ingress `networking.k8s.io/v1`.
+The Ingress from `networking.k8s.io/v1beta1` is no longer supported,
+affected integrations: **NGINX** and **Skipper** ingress controllers.
+
+#### Improvements
+
+- Upgrade Ingress to networking.k8s.io/v1
+  [#917](https://github.com/fluxcd/flagger/pull/917)
+- Update Kubernetes manifests to rbac.authorization.k8s.io/v1
+  [#920](https://github.com/fluxcd/flagger/pull/920)
+
+## 1.10.0
+
+**Release date:** 2021-05-28
+
+This release comes with support for [Graphite](https://docs.flagger.app/usage/metrics#graphite) metric templates.
+
+#### Features
+
+- Add Graphite metrics provider
+  [#915](https://github.com/fluxcd/flagger/pull/915)
+
+#### Improvements
+
+- ConfigTracker: Scan envFrom in init-containers
+  [#914](https://github.com/fluxcd/flagger/pull/914)
+- e2e: Update Istio to v1.10 and Contour to v1.15
+  [#914](https://github.com/fluxcd/flagger/pull/914)
+
+## 1.9.0
+
+**Release date:** 2021-05-14
+
+This release comes with improvements to the [Gloo Edge](https://docs.flagger.app/tutorials/gloo-progressive-delivery) integration.
+
+Starting with this version, Flagger no longer requires Gloo discovery to be enabled.
+Flagger generated the Gloo upstream objects on its own and optionally it can use an
+existing upstream (specified with `.spec.upstreamRef`) as a template. 
+
+#### Features
+
+- Gloo: Create gloo upstreams from non-discovered services
+  [#894](https://github.com/fluxcd/flagger/pull/894)
+- Gloo Upstream Ref for Upstream Config
+  [#908](https://github.com/fluxcd/flagger/pull/908)
+
+#### Improvements
+
+- Adjusted Nginx ingress canary headers on init and promotion
+  [#907](https://github.com/fluxcd/flagger/pull/907)
+
+## 1.8.0
+
+**Release date:** 2021-04-29
+
+This release comes with support for the SMI `v1alpha2` and `v1alpha3` TrafficSplit APIs.
+
+For SMI compatible service mesh solutions like Open Service Mesh, Consul Connect or 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.
+
+The desired SMI version can be set in the Canary object:
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: my-canary
+spec:
+  provider: "smi:v1alpha3" # or "smi:v1alpha2"
+```
+
+#### Features
+
+- Implement SMI v1alpha2 and v1alpha3 routers
+  [#896](https://github.com/fluxcd/flagger/pull/896)
+  [#879](https://github.com/fluxcd/flagger/pull/879)
+- Add alerting HTTP/S proxy option
+  [#872](https://github.com/fluxcd/flagger/pull/872)
+- Add option to mute alerts generated from webhooks
+  [#887](https://github.com/fluxcd/flagger/pull/887)
+
+#### Fixes
+
+- Scale up canary on confirm rollout
+  [#878](https://github.com/fluxcd/flagger/pull/878)
+
+## 1.7.0
+
+**Release date:** 2021-03-23
+
+This release comes with support for manually approving
+the traffic weight increase.
+
+#### Features
+
+- Add webhook for manually approving traffic weight increase
+  [#849](https://github.com/fluxcd/flagger/pull/849)
+- Add WaitingPromotion phase to canary status
+  [#859](https://github.com/fluxcd/flagger/pull/859)
+
+#### Improvements
+
+- linkerd: update prometheus URL based on the latest 2.10 changes
+  [#845](https://github.com/fluxcd/flagger/pull/845)
+- docs: update resources to disable mTLS in Istio
+  [#843](https://github.com/fluxcd/flagger/pull/843)
+- docs: updating slack alerting docs to point to legacy slack webhooks
+  [#833](https://github.com/fluxcd/flagger/pull/833)
+- chart: Add pull secret for Prometheus deployment
+  [#842](https://github.com/fluxcd/flagger/pull/842)
+- Update Kubernetes packages to v1.20.4
+  [#857](https://github.com/fluxcd/flagger/pull/857)
+
+## 1.6.4
+
+**Release date:** 2021-02-26
+
+This release comes with a bug fix to the AppMesh integration
+when using multiple backends.
+
+#### Improvements
+
+- Consolidate logos and add project name logos
+  [#829](https://github.com/fluxcd/flagger/pull/829)
+- chart: add env option to loadtester
+  [#821](https://github.com/fluxcd/flagger/pull/821)
+- chart: Added PodDisruptionBudget for the loadtester
+  [#819](https://github.com/fluxcd/flagger/pull/819)
+
+#### Fixes
+
+- Fix AWS AppMesh issue when providing multiple backends
+  [#831](https://github.com/fluxcd/flagger/pull/831)
+
+## 1.6.3
+
+**Release date:** 2021-02-15
+
+This release comes with support for Kubernetes pod topology spread constraints.
+
+Flagger has a new [logo](https://github.com/fluxcd/flagger/pull/812),
+many thanks to [Bianca](https://github.com/bia) for designed it.
+
+#### Improvements
+
+- Rewrite the primary Pod Topology Spread Constraints based on label selector
+  [#806](https://github.com/fluxcd/flagger/pull/806)
+
+#### Fixes
+
+- Suffix only the podAntiAffinity values that match the deployment name
+  [#805](https://github.com/fluxcd/flagger/pull/805)
+- Check if mandatory secrets/configmaps exist
+  [#799](https://github.com/fluxcd/flagger/pull/799)
+
+## 1.6.2
+
+**Release date:** 2021-01-28
+
+This release comes with support for Kubernetes anti-affinity rules.
+
+#### Improvements
+
+- Support for adding `-primary` suffix to Anti-Affinity values
+  [#788](https://github.com/fluxcd/flagger/pull/788)
+
+#### Fixes
+
+- Add missing alerts section to Canary CRD schema
+  [#794](https://github.com/fluxcd/flagger/pull/794)
+  
 ## 1.6.1
 
 **Release date:** 2021-01-19

CONTRIBUTING.md

@@ -29,7 +29,7 @@ you can sign your commit automatically with `git commit -s`.
 
 The project uses Slack: To join the conversation, simply join the
 [CNCF](https://slack.cncf.io/) Slack workspace and use the
-[#flux](https://cloud-native.slack.com/messages/flux/) channel.
+[#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)

Dockerfile

@@ -1,4 +1,4 @@
-FROM golang:1.15-alpine as builder
+FROM golang:1.19-alpine as builder
 
 ARG TARGETPLATFORM
 ARG REVISON
@@ -21,7 +21,7 @@ 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.12
+FROM alpine:3.16
 
 RUN apk --no-cache add ca-certificates
 

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).

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

@@ -5,7 +5,14 @@ LT_VERSION?=$(shell grep 'VERSION' cmd/loadtester/main.go | awk '{ print $$4 }'
 build:
 	CGO_ENABLED=0 go build -a -o ./bin/flagger ./cmd/flagger
 
+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 ./
 
@@ -26,15 +33,18 @@ 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:
@@ -42,7 +52,6 @@ release:
 	git push origin "v$(VERSION)"
 
 loadtester-build:
-	CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o ./bin/loadtester ./cmd/loadtester/*
 	docker build -t ghcr.io/fluxcd/flagger-loadtester:$(LT_VERSION) . -f Dockerfile.loadtester
 
 loadtester-push:

README.md

@@ -1,20 +1,22 @@
-# flagger
+ # flagger
 
-[![build](https://github.com/fluxcd/flagger/workflows/build/badge.svg)](https://github.com/fluxcd/flagger/actions)
-[![report](https://goreportcard.com/badge/github.com/fluxcd/flagger)](https://goreportcard.com/report/github.com/fluxcd/flagger)
-[![license](https://img.shields.io/github/license/fluxcd/flagger.svg)](https://github.com/fluxcd/flagger/blob/main/LICENSE)
 [![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/fluxcd/flagger/main/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, Traefik) 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
 
@@ -33,6 +35,8 @@ 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)
@@ -40,28 +44,21 @@ Flagger documentation can be found at [docs.flagger.app](https://docs.flagger.ap
   * [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)
-* [eLife](https://elifesciences.org/)
-
-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:
 
@@ -73,7 +70,8 @@ metadata:
   namespace: test
 spec:
   # service mesh provider (optional)
-  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, contour, gloo, supergloo, traefik
+  # 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:
@@ -85,7 +83,7 @@ spec:
   progressDeadlineSeconds: 60
   # HPA reference (optional)
   autoscalerRef:
-    apiVersion: autoscaling/v2beta1
+    apiVersion: autoscaling/v2beta2
     kind: HorizontalPodAutoscaler
     name: podinfo
   service:
@@ -184,69 +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            | 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: |
+| 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
 
 #### [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
+- 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 Kubernetes [Ingress v2](https://github.com/kubernetes-sigs/service-apis)
-* Add support for SMI compatible service mesh solutions like Open Service Mesh and Consul Connect
-* Add support for ingress controllers like HAProxy and ALB
-* Add support for metrics providers like InfluxDB, Stackdriver, SignalFX
+- 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/fluxcd/flagger/issues/new).
+- Slack: Join in and talk to us in the `#flagger` channel on [CNCF Slack](https://slack.cncf.io/).
+- Meetings: We run weekly, public 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/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
@@ -187,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/crd.yaml

@@ -104,7 +104,7 @@ spec:
                     name:
                       type: string
                 autoscalerRef:
-                  description: HPA selector
+                  description: Scaler selector
                   type: object
                   required: ["apiVersion", "kind", "name"]
                   properties:
@@ -114,8 +114,13 @@ spec:
                       type: string
                       enum:
                         - HorizontalPodAutoscaler
+                        - ScaledObject
                     name:
                       type: string
+                    primaryScalerQueries:
+                      type: object
+                      additionalProperties:
+                        type: string
                 ingressRef:
                   description: Ingress selector
                   type: object
@@ -129,6 +134,21 @@ spec:
                         - Ingress
                     name:
                       type: string
+                upstreamRef:
+                  description: Gloo Upstream selector
+                  type: object
+                  required: [ "apiVersion", "kind", "name" ]
+                  properties:
+                    apiVersion:
+                      type: string
+                    kind:
+                      type: string
+                      enum:
+                        - Upstream
+                    name:
+                      type: string
+                    namespace:
+                      type: string
                 service:
                   description: Kubernetes Service spec
                   type: object
@@ -143,6 +163,9 @@ spec:
                     portName:
                       description: Container port name
                       type: string
+                    appProtocol:
+                      description: Application protocol of the port
+                      type: string
                     targetPort:
                       description: Container target port name
                       x-kubernetes-int-or-string: true
@@ -480,6 +503,40 @@ spec:
                       type: array
                       items:
                         type: string
+                    gatewayRefs:
+                      description: The list of parent Gateways for a HTTPRoute
+                      maxItems: 32
+                      type: array
+                      items:
+                        required:
+                        - name
+                        type: object
+                        properties:
+                          group:
+                            default: gateway.networking.k8s.io
+                            maxLength: 253
+                            pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
+                            type: string
+                          kind:
+                            default: Gateway
+                            maxLength: 63
+                            minLength: 1
+                            pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
+                            type: string
+                          name:
+                            maxLength: 253
+                            minLength: 1
+                            type: string
+                          namespace:
+                            maxLength: 63
+                            minLength: 1
+                            pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
+                            type: string
+                          sectionName:
+                            maxLength: 253
+                            minLength: 1
+                            pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
+                            type: string
                     corsPolicy:
                       description: Istio Cross-Origin Resource Sharing policy (CORS)
                       type: object
@@ -811,6 +868,12 @@ spec:
                     mirrorWeight:
                       description: Weight of traffic to be mirrored
                       type: number
+                    primaryReadyThreshold:
+                      description: Percentage of pods that need to be available to consider primary as ready
+                      type: number
+                    canaryReadyThreshold:
+                      description: Percentage of pods that need to be available to consider canary as ready
+                      type: number
                     match:
                       description: A/B testing match conditions
                       type: array
@@ -887,6 +950,37 @@ spec:
                               namespace:
                                 description: Namespace of this metric template
                                 type: string
+                    alerts:
+                      description: Alert list for this canary analysis
+                      type: array
+                      items:
+                        type: object
+                        required:
+                          - providerRef
+                          - name
+                        properties:
+                          name:
+                            description: Name of the this alert
+                            type: string
+                          severity:
+                            description: Severity level can be info, warn, error (default info)
+                            type: string
+                            enum:
+                              - ""
+                              - info
+                              - warn
+                              - error
+                          providerRef:
+                            description: Alert provider reference
+                            type: object
+                            required: ["name"]
+                            properties:
+                              name:
+                                description: Name of the alert provider
+                                type: string
+                              namespace:
+                                description: Namespace of the alert provider
+                                type: string
                     webhooks:
                       description: Webhook list for this canary
                       type: array
@@ -909,6 +1003,10 @@ spec:
                               - post-rollout
                               - event
                               - rollback
+                              - confirm-traffic-increase
+                          muteAlert:
+                            description: Mute all alerts for the webhook
+                            type: boolean
                           url:
                             description: URL address of this webhook
                             type: string
@@ -935,29 +1033,33 @@ spec:
                     - Initialized
                     - Waiting
                     - Progressing
+                    - WaitingPromotion
                     - Promoting
                     - Finalising
                     - Succeeded
                     - Failed
                     - Terminating
                     - Terminated
+                failedChecks:
+                  description: Failed check count of the current canary analysis
+                  type: number
+                canaryWeight:
+                  description: Traffic weight routed to canary
+                  type: number
+                iterations:
+                  description: Iteration count of the current canary analysis
+                  type: number
                 trackedConfigs:
                   description: TrackedConfig of this canary
                   additionalProperties:
                     type: string
                   type: object
-                canaryWeight:
-                  description: Traffic weight routed to canary
-                  type: number
-                failedChecks:
-                  description: Failed check count of the current canary analysis
-                  type: number
-                iterations:
-                  description: Iteration count of the current canary analysis
-                  type: number
                 lastAppliedSpec:
                   description: LastAppliedSpec of this canary
                   type: string
+                lastPromotedSpec:
+                  description: LastPromotedSpec of this canary
+                  type: string
                 lastTransitionTime:
                   description: LastTransitionTime of this canary
                   format: date-time
@@ -1053,8 +1155,11 @@ spec:
                         - prometheus
                         - influxdb
                         - datadog
+                        - stackdriver
                         - cloudwatch
                         - newrelic
+                        - graphite
+                        - dynatrace
                     address:
                       description: API address of this provider
                       type: string
@@ -1070,6 +1175,9 @@ spec:
                     region:
                       description: Region of the provider
                       type: string
+                    insecureSkipVerify:
+                      description: Disable SSL certificate validation for the provider address
+                      type: boolean
                 query:
                   description: Query of this metric template
                   type: string
@@ -1136,9 +1244,19 @@ spec:
                     - msteams
                     - discord
                     - rocket
+                    - gchat
+                channel:
+                  description: Alert channel for this provider
+                  type: string
+                username:
+                  description: Bot username for this provider
+                  type: string
                 address:
                   description: Hook URL address of this provider
                   type: string
+                proxy:
+                  description: Http/s proxy of this provider
+                  type: string
                 secretRef:
                   description: Kubernetes secret reference containing the provider address
                   type: object

artifacts/flagger/deployment.yaml

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

charts/flagger/Chart.yaml

@@ -1,12 +1,12 @@
 apiVersion: v1
 name: flagger
-version: 1.6.1
-appVersion: 1.6.1
-kubeVersion: ">=1.16.0-0"
+version: 1.24.0
+appVersion: 1.24.0
+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/fluxcd/flagger/main/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 sources:
   - https://github.com/fluxcd/flagger
 maintainers:
@@ -18,8 +18,12 @@ keywords:
   - istio
   - appmesh
   - linkerd
+  - kuma
+  - osm
+  - smi
   - gloo
   - contour
   - nginx
+  - traefik
   - gitops
   - canary

charts/flagger/README.md

@@ -1,19 +1,18 @@
 # Flagger
 
-[Flagger](https://github.com/fluxcd/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, Traefik).
-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.16
+* Kubernetes >= 1.19
 
 ## Installing the Chart
 
@@ -38,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**:
@@ -56,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
@@ -65,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 \
@@ -109,51 +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 | `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.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`
-`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 | `[]`
-`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 | ""
-`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`
+| 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,
 

charts/flagger/crds/crd.yaml

@@ -104,7 +104,7 @@ spec:
                     name:
                       type: string
                 autoscalerRef:
-                  description: HPA selector
+                  description: Scaler selector
                   type: object
                   required: ["apiVersion", "kind", "name"]
                   properties:
@@ -114,8 +114,13 @@ spec:
                       type: string
                       enum:
                         - HorizontalPodAutoscaler
+                        - ScaledObject
                     name:
                       type: string
+                    primaryScalerQueries:
+                      type: object
+                      additionalProperties:
+                        type: string
                 ingressRef:
                   description: Ingress selector
                   type: object
@@ -129,6 +134,21 @@ spec:
                         - Ingress
                     name:
                       type: string
+                upstreamRef:
+                  description: Gloo Upstream selector
+                  type: object
+                  required: [ "apiVersion", "kind", "name" ]
+                  properties:
+                    apiVersion:
+                      type: string
+                    kind:
+                      type: string
+                      enum:
+                        - Upstream
+                    name:
+                      type: string
+                    namespace:
+                      type: string
                 service:
                   description: Kubernetes Service spec
                   type: object
@@ -143,6 +163,9 @@ spec:
                     portName:
                       description: Container port name
                       type: string
+                    appProtocol:
+                      description: Application protocol of the port
+                      type: string
                     targetPort:
                       description: Container target port name
                       x-kubernetes-int-or-string: true
@@ -480,6 +503,40 @@ spec:
                       type: array
                       items:
                         type: string
+                    gatewayRefs:
+                      description: The list of parent Gateways for a HTTPRoute
+                      maxItems: 32
+                      type: array
+                      items:
+                        required:
+                        - name
+                        type: object
+                        properties:
+                          group:
+                            default: gateway.networking.k8s.io
+                            maxLength: 253
+                            pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
+                            type: string
+                          kind:
+                            default: Gateway
+                            maxLength: 63
+                            minLength: 1
+                            pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
+                            type: string
+                          name:
+                            maxLength: 253
+                            minLength: 1
+                            type: string
+                          namespace:
+                            maxLength: 63
+                            minLength: 1
+                            pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
+                            type: string
+                          sectionName:
+                            maxLength: 253
+                            minLength: 1
+                            pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
+                            type: string
                     corsPolicy:
                       description: Istio Cross-Origin Resource Sharing policy (CORS)
                       type: object
@@ -811,6 +868,12 @@ spec:
                     mirrorWeight:
                       description: Weight of traffic to be mirrored
                       type: number
+                    primaryReadyThreshold:
+                      description: Percentage of pods that need to be available to consider primary as ready
+                      type: number
+                    canaryReadyThreshold:
+                      description: Percentage of pods that need to be available to consider canary as ready
+                      type: number
                     match:
                       description: A/B testing match conditions
                       type: array
@@ -887,6 +950,37 @@ spec:
                               namespace:
                                 description: Namespace of this metric template
                                 type: string
+                    alerts:
+                      description: Alert list for this canary analysis
+                      type: array
+                      items:
+                        type: object
+                        required:
+                          - providerRef
+                          - name
+                        properties:
+                          name:
+                            description: Name of the this alert
+                            type: string
+                          severity:
+                            description: Severity level can be info, warn, error (default info)
+                            type: string
+                            enum:
+                              - ""
+                              - info
+                              - warn
+                              - error
+                          providerRef:
+                            description: Alert provider reference
+                            type: object
+                            required: ["name"]
+                            properties:
+                              name:
+                                description: Name of the alert provider
+                                type: string
+                              namespace:
+                                description: Namespace of the alert provider
+                                type: string
                     webhooks:
                       description: Webhook list for this canary
                       type: array
@@ -909,6 +1003,10 @@ spec:
                               - post-rollout
                               - event
                               - rollback
+                              - confirm-traffic-increase
+                          muteAlert:
+                            description: Mute all alerts for the webhook
+                            type: boolean
                           url:
                             description: URL address of this webhook
                             type: string
@@ -935,29 +1033,33 @@ spec:
                     - Initialized
                     - Waiting
                     - Progressing
+                    - WaitingPromotion
                     - Promoting
                     - Finalising
                     - Succeeded
                     - Failed
                     - Terminating
                     - Terminated
+                failedChecks:
+                  description: Failed check count of the current canary analysis
+                  type: number
+                canaryWeight:
+                  description: Traffic weight routed to canary
+                  type: number
+                iterations:
+                  description: Iteration count of the current canary analysis
+                  type: number
                 trackedConfigs:
                   description: TrackedConfig of this canary
                   additionalProperties:
                     type: string
                   type: object
-                canaryWeight:
-                  description: Traffic weight routed to canary
-                  type: number
-                failedChecks:
-                  description: Failed check count of the current canary analysis
-                  type: number
-                iterations:
-                  description: Iteration count of the current canary analysis
-                  type: number
                 lastAppliedSpec:
                   description: LastAppliedSpec of this canary
                   type: string
+                lastPromotedSpec:
+                  description: LastPromotedSpec of this canary
+                  type: string
                 lastTransitionTime:
                   description: LastTransitionTime of this canary
                   format: date-time
@@ -1053,8 +1155,11 @@ spec:
                         - prometheus
                         - influxdb
                         - datadog
+                        - stackdriver
                         - cloudwatch
                         - newrelic
+                        - graphite
+                        - dynatrace
                     address:
                       description: API address of this provider
                       type: string
@@ -1070,6 +1175,9 @@ spec:
                     region:
                       description: Region of the provider
                       type: string
+                    insecureSkipVerify:
+                      description: Disable SSL certificate validation for the provider address
+                      type: boolean
                 query:
                   description: Query of this metric template
                   type: string
@@ -1136,9 +1244,19 @@ spec:
                     - msteams
                     - discord
                     - rocket
+                    - gchat
+                channel:
+                  description: Alert channel for this provider
+                  type: string
+                username:
+                  description: Bot username for this provider
+                  type: string
                 address:
                   description: Hook URL address of this provider
                   type: string
+                proxy:
+                  description: Http/s proxy of this provider
+                  type: string
                 secretRef:
                   description: Kubernetes secret reference containing the provider address
                   type: object

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 }}
@@ -121,12 +134,18 @@ spec:
           {{- if .Values.kubeconfigBurst }}
           - -kubeconfig-burst={{ .Values.kubeconfigBurst }}
           {{- end }}
-          {{- if .Values.istio.kubeconfig.secretName }}
-          - -kubeconfig-service-mesh=/tmp/istio-host/{{ .Values.istio.kubeconfig.key }}
+          {{- 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/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
@@ -195,12 +208,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: {{ template "flagger.fullname" . }}

charts/flagger/values.yaml

@@ -2,7 +2,7 @@
 
 image:
   repository: ghcr.io/fluxcd/flagger
-  tag: 1.6.1
+  tag: 1.24.0
   pullPolicy: IfNotPresent
   pullSecret:
 
@@ -19,7 +19,7 @@ podPriorityClassName: ""
 
 metricsServer: "http://prometheus:9090"
 
-# accepted values are kubernetes, istio, linkerd, appmesh, contour, nginx, gloo, skipper, traefik
+# 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,21 +138,31 @@ tolerations: []
 prometheus:
   # to be used with ingress controllers
   install: false
-  image: docker.io/prom/prometheus:v2.23.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
 
 kubeconfigQPS: ""
 kubeconfigBurst: ""
 
-#  Istio multi-cluster service mesh (shared control plane single-network)
-# https://istio.io/docs/setup/install/multicluster/shared-vpn/
-istio:
+#  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,9 +1,9 @@
 apiVersion: v1
 name: grafana
-version: 1.5.0
+version: 1.7.0
 appVersion: 7.2.0
 description: Grafana dashboards for monitoring Flagger canary deployments
-icon: https://raw.githubusercontent.com/fluxcd/flagger/main/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/fluxcd/flagger

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/loadtester/Chart.yaml

@@ -1,12 +1,12 @@
 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/fluxcd/flagger/main/docs/logo/weaveworks.png
+icon: https://raw.githubusercontent.com/fluxcd/flagger/main/docs/logo/flagger-icon.png
 sources:
   - https://github.com/fluxcd/flagger
 maintainers:
@@ -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/fluxcd/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

@@ -2,22 +2,28 @@ replicaCount: 1
 
 image:
   repository: ghcr.io/fluxcd/flagger-loadtester
-  tag: 0.18.0
+  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: 5.0.0
-appVersion: 5.0.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/fluxcd/flagger/main/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: ghcr.io/stefanprodan/podinfo
-  tag: 5.0.0
+  tag: 6.1.3
   pullPolicy: IfNotPresent
 
 podAnnotations: {}

cmd/flagger/main.go

@@ -63,8 +63,11 @@ var (
 	logLevel                 string
 	port                     string
 	msteamsURL               string
+	msteamsProxyURL          string
 	includeLabelPrefix       string
 	slackURL                 string
+	slackToken               string
+	slackProxyURL            string
 	slackUser                string
 	slackChannel             string
 	eventWebhook             string
@@ -81,6 +84,8 @@ var (
 	enableConfigTracking     bool
 	ver                      bool
 	kubeconfigServiceMesh    string
+	clusterName              string
+	noCrossNamespaceRefs     bool
 )
 
 func init() {
@@ -93,16 +98,19 @@ func init() {
 	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, skipper or traefik.")
+	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.")
@@ -111,6 +119,8 @@ 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() {
@@ -160,15 +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)
 	}
 
-	cfgHost.QPS = float32(kubeconfigQPS)
-	cfgHost.Burst = kubeconfigBurst
+	serviceMeshCfg.QPS = float32(kubeconfigQPS)
+	serviceMeshCfg.Burst = kubeconfigBurst
 
-	meshClient, err := clientset.NewForConfig(cfgHost)
+	meshClient, err := clientset.NewForConfig(serviceMeshCfg)
 	if err != nil {
 		logger.Fatalf("Error building mesh clientset: %v", err)
 	}
@@ -204,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 {
@@ -234,6 +251,8 @@ func main() {
 		meshProvider,
 		version.VERSION,
 		fromEnv("EVENT_WEBHOOK_URL", eventWebhook),
+		clusterName,
+		noCrossNamespaceRefs,
 	)
 
 	// leader election context
@@ -308,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(),
@@ -348,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,5 +1,5 @@
 /*
-Copyright 2020 The Flux authors
+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.
@@ -19,6 +19,7 @@ package main
 import (
 	"flag"
 	"log"
+	"regexp"
 	"time"
 
 	"github.com/fluxcd/flagger/pkg/loadtester"
@@ -27,11 +28,12 @@ import (
 	"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
 )
@@ -40,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.")
 }
@@ -66,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)
 }

docs/gitbook/README.md

@@ -4,39 +4,41 @@ description: Flagger is a progressive delivery Kubernetes operator
 
 # Introduction
 
-[Flagger](https://github.com/fluxcd/flagger) is a **Kubernetes** operator
-that automates the promotion of canary deployments using
-**Istio**, **Linkerd**, **App Mesh**, **NGINX**, **Skipper**, **Contour**, **Gloo** or **Traefik**
-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/fluxcd/flagger/main/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.
 
-Flagger is a [Cloud Native Computing Foundation](https://cncf.io/) project.
+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
+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 these tutorials to get started:
+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**
 

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
 
@@ -29,10 +31,13 @@
 * [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)
 * [Canary analysis with Prometheus Operator](tutorials/prometheus-operator.md)
+* [Canary analysis with KEDA ScaledObjects](tutorials/keda-scaledobject.md)
 * [Zero downtime deployments](tutorials/zero-downtime-deployments.md)
-* [Rollout Weights](tutorials/rollout-weights.md)
 
 ## Dev
 

docs/gitbook/dev/dev-guide.md

@@ -8,17 +8,17 @@ 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
-* bash >= 5.0
-* make >= 3.81
-* kubectl >= 1.16
-* kustomize >= 3.5
-* helm >= 3.0
-* docker >= 19.03
+* go >= 1.19
+* git >;= 2.20
+* bash >= 5.0
+* make >= 3.81
+* 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.16 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/fluxcd/flagger) on GitHub.
 
@@ -100,6 +100,8 @@ make codegen
 Run code formatters:
 
 ```bash
+go install golang.org/x/tools/cmd/goimports@latest
+
 make fmt
 ```
 
@@ -200,7 +202,7 @@ Run the Istio e2e tests:
 ./test/istio/run.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/fluxcd/flagger/tree/main/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/faq.md

@@ -2,7 +2,7 @@
 
 ## Deployment Strategies
 
-**Which deployment strategies are supported by Flagger?**
+#### Which deployment strategies are supported by Flagger?
 
 Flagger implements the following deployment strategies:
 
@@ -11,25 +11,25 @@ Flagger implements the following deployment strategies:
 * [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
+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.
 
-**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).
 
-**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:
 
@@ -49,11 +49,45 @@ spec:
         timestamp: "2020-03-10T14:24:48+0000"
 ```
 
+#### How to change replicas for a deployment when not using HPA?
+
+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.
+
+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?**
+#### How is an application exposed inside the cluster?
 
-Assuming the app name is podinfo you can define a canary like:
+Assuming the app name is `podinfo`, you can define a canary like:
 
 ```yaml
 apiVersion: flagger.app/v1beta1
@@ -79,19 +113,19 @@ spec:
 
 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.
+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>`
 
@@ -147,7 +181,7 @@ and can be used for conformance testing or load testing.
 
 ## 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.
@@ -195,7 +229,7 @@ Both port `8080` and `9090` will be added to the ClusterIP services.
 
 ## 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>`:
 
@@ -214,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
@@ -247,16 +360,16 @@ spec:
               labelSelector:
                 matchLabels:
                   affinity: podinfo
-              topologyKey: kubernetes.io/hostname
+              topologyKey: topology.kubernetes.io/zone
 ```
 
 ## Metrics
 
-**How does Flagger measure 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:
 
@@ -283,8 +396,8 @@ sum(
           response_code!~"5.*"
         }[$interval]
     )
-) 
-/ 
+)
+/
 sum(
     rate(
         istio_requests_total{
@@ -307,8 +420,8 @@ sum(
           envoy_response_code!~"5.*"
         }[$interval]
     )
-) 
-/ 
+)
+/
 sum(
     rate(
         envoy_cluster_upstream_rq{
@@ -340,7 +453,7 @@ sum(
 )
 ```
 
-**HTTP requests milliseconds duration P99**
+#### HTTP requests milliseconds duration P99
 
 Spec:
 
@@ -358,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"
@@ -374,7 +487,7 @@ histogram_quantile(0.99,
 Envoy query (App Mesh, Contour and Gloo):
 
 ```javascript
-histogram_quantile(0.99, 
+histogram_quantile(0.99,
   sum(
     irate(
       envoy_cluster_upstream_rq_time_bucket{
@@ -388,14 +501,41 @@ 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 Gateway API
+
+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:
+
+```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
+```
 
 ## Istio routing
 
-**How does Flagger interact with Istio?**
+#### 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,
@@ -634,7 +774,7 @@ spec:
       weight: 0
 ```
 
-Therefore, The following virtual service forward the traffic to `/podinfo` by the above delegate VirtualService.
+Therefore, the following virtual service forwards the traffic to `/podinfo` by the above delegate VirtualService.
 
 ```yaml
 apiVersion: networking.istio.io/v1alpha3
@@ -660,17 +800,17 @@ spec:
       namespace: test
 ```
 
-Note that pilot env `PILOT_ENABLE_VIRTUAL_SERVICE_DELEGATE` must also be set. 
+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?**
+#### How can I expose multiple canaries on the same external domain?
 
-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:
+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
@@ -714,11 +854,11 @@ 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
 
-**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`:
 
@@ -732,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
@@ -744,13 +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:
+you need to disable mTLS:
 
 ```yaml
-apiVersion: networking.istio.io/v1alpha3
+apiVersion: networking.istio.io/v1beta1
 kind: DestinationRule
 metadata:
   name: flagger-loadtester
@@ -761,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-kubernetes.md

@@ -43,8 +43,8 @@ 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`.
@@ -71,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:
@@ -173,6 +183,14 @@ kustomize build https://github.com/fluxcd/flagger/kustomize/linkerd?ref=main | k
 
 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
@@ -202,7 +220,7 @@ metadata:
   name: app
   namespace: test
 spec:
-  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, gloo, traefik
+  # can be: kubernetes, istio, linkerd, appmesh, nginx, skipper, gloo, traefik, osm
   # use the kubernetes provider for Blue/Green style deployments
   provider: nginx
 ```

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/tutorials/appmesh-progressive-delivery.md

@@ -62,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:
@@ -168,7 +171,7 @@ 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`
+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.
 
@@ -242,7 +245,7 @@ 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:
@@ -307,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:
@@ -399,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:

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

@@ -320,7 +320,7 @@ After a couple of seconds Flux will apply the Kubernetes resources from Git and
 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
@@ -337,7 +337,7 @@ 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 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

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

@@ -90,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)
@@ -157,7 +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
 
@@ -224,7 +226,7 @@ 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 +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:
@@ -369,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:

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.

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

@@ -10,8 +10,8 @@ and Flagger to automate canary releases and A/B testing.
 Flagger requires a Kubernetes cluster **v1.16** or newer and Gloo Edge ingress **1.6.0** or newer.
 
 This guide was written for Flagger version **1.6.0** or higher. Prior versions of Flagger
-used Gloo upstream groups to handle canaries, but newer versions of Flagger use Gloo
-route tables to handle canaries as well as A/B testing.
+used Gloo `UpstreamGroup`s to handle canaries, but newer versions of Flagger use Gloo
+`RouteTable`s to handle canaries as well as A/B testing.
 
 Install Gloo with Helm v3:
 
@@ -36,7 +36,7 @@ helm upgrade -i flagger flagger/flagger \
 ## Bootstrap
 
 Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
-then creates a series of objects (Kubernetes deployments, ClusterIP services and Gloo route tables groups).
+then creates a series of objects (Kubernetes deployments, ClusterIP services, Gloo route tables and upstreams).
 These objects expose the application outside the cluster and drive the canary analysis and promotion.
 
 Create a test namespace:
@@ -94,6 +94,14 @@ metadata:
   name: podinfo
   namespace: test
 spec:
+  # upstreamRef (optional)
+  # defines an upstream to copy the spec from when flagger generates new upstreams.
+  # necessary to copy over TLS config, circuit breakers, etc. (anything nonstandard)
+#  upstreamRef:
+#    apiVersion: gloo.solo.io/v1
+#    kind: Upstream
+#    name: podinfo-upstream
+#    namespace: gloo-system
   provider: gloo
   # deployment reference
   targetRef:
@@ -152,6 +160,8 @@ spec:
           cmd: "hey -z 2m -q 5 -c 2 -host app.example.com http://gateway-proxy.gloo-system"
 ```
 
+*Note: when using upstreamRef the following fields are copied over from the original upstream: `Labels, SslConfig, CircuitBreakers, ConnectionConfig, UseHttp2, InitialStreamWindowSize`*
+
 Save the above resource as podinfo-canary.yaml and then apply it:
 
 ```bash
@@ -174,6 +184,8 @@ service/podinfo
 service/podinfo-canary
 service/podinfo-primary
 routetables.gateway.solo.io/podinfo
+upstreams.gloo.solo.io/test-podinfo-canaryupstream-9898
+upstreams.gloo.solo.io/test-podinfo-primaryupstream-9898
 ```
 
 When the bootstrap finishes Flagger will set the canary status to initialized:
@@ -197,7 +209,7 @@ 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:
@@ -252,7 +264,7 @@ Trigger another canary deployment:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.2
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.2
 ```
 
 Generate HTTP 500 errors:
@@ -353,7 +365,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
 ```
 
 Generate 404s:
@@ -415,7 +427,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.4
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.4
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B test:

docs/gitbook/tutorials/istio-ab-testing.md

@@ -173,7 +173,7 @@ 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:

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

@@ -13,6 +13,7 @@ Install Istio with telemetry support and Prometheus:
 ```bash
 istioctl manifest install --set profile=default
 
+# Suggestion: Please change release-1.8 in below command, to your real istio version.
 kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.8/samples/addons/prometheus.yaml
 ```
 
@@ -185,7 +186,7 @@ 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:
@@ -245,7 +246,7 @@ Trigger another 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:

docs/gitbook/tutorials/keda-scaledobject.md

@@ -0,0 +1,234 @@
+# Canary analysis with KEDA ScaledObjects
+
+This guide shows you how to use Flagger with KEDA ScaledObjects to autoscale workloads during a Canary analysis run.
+We will be using a Blue/Green deployment strategy with the Kubernetes provider for the sake of this tutorial, but
+you can use any deployment strategy combined with any supported provider.
+
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.16** or newer. For this tutorial, we'll need KEDA **2.7.1** or newer.
+
+Install KEDA:
+
+```bash
+helm repo add kedacore https://kedacore.github.io/charts
+kubectl create namespace keda
+helm install keda kedacore/keda --namespace keda
+```
+
+Install Flagger:
+```bash
+helm repo add flagger https://flagger.app
+
+helm upgrade -i flagger flagger/flagger \
+--namespace flagger \
+--set prometheus.install=true \
+--set meshProvider=kubernetes
+```
+
+## Bootstrap
+
+Flagger takes a Kubernetes deployment and a KEDA ScaledObject targeting the deployment. It then creates a series of objects 
+(Kubernetes deployments, ClusterIP services and another KEDA ScaledObject targeting the created Deployment).
+These objects expose the application inside the mesh and drive the Canary analysis and Blue/Green promotion.
+
+Create a test namespace:
+
+```bash
+kubectl create ns test
+```
+
+Create a deployment named `podinfo`:
+
+```bash
+kubectl apply -n test -f https://raw.githubusercontent.com/fluxcd/flagger/main/kustomize/podinfo/deployment.yaml
+```
+
+Deploy the load testing service to generate traffic during the analysis:
+
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/tester?ref=main
+```
+
+Create a ScaledObject which targets the `podinfo` deployment and uses Prometheus as a trigger:
+```yaml
+apiVersion: keda.sh/v1alpha1
+kind: ScaledObject
+metadata:
+  name: podinfo-so
+  namespace: test
+spec:
+  scaleTargetRef:
+    name: podinfo
+  pollingInterval: 10
+  cooldownPeriod: 20
+  minReplicaCount: 1
+  maxReplicaCount: 3
+  triggers:
+  - type: prometheus
+    metadata:
+      name: prom-trigger
+      serverAddress: http://flagger-prometheus.flagger-system:9090
+      metricName: http_requests_total
+      query: sum(rate(http_requests_total{ app="podinfo" }[30s]))
+      threshold: '5'
+```
+
+Create a canary custom resource for the `podinfo` deployment:
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  provider: kubernetes
+  # deployment reference
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  # Scaler reference
+  autoscalerRef:
+    apiVersion: keda.sh/v1alpha1
+    kind: ScaledObject
+    # ScaledObject targeting the canary deployment
+    name: podinfo-so
+    # Mapping between trigger names and the related query to use for the generated 
+    # ScaledObject targeting the primary deployment. (Optional)
+    primaryScalerQueries:
+      prom-trigger: sum(rate(http_requests_total{ app="podinfo-primary" }[30s]))
+  # the maximum time in seconds for the canary deployment
+  # to make progress before rollback (default 600s)
+  progressDeadlineSeconds: 60
+  service:
+    port: 80
+    targetPort: 9898
+    name: podinfo-svc
+    portDiscovery: true
+  analysis:
+    # schedule interval (default 60s)
+    interval: 15s
+    # max number of failed checks before rollback
+    threshold: 5
+    # number of checks to run before promotion
+    iterations: 5
+    # Prometheus checks based on 
+    # http_request_duration_seconds histogram
+    metrics:
+      - name: request-success-rate
+        interval: 1m
+        thresholdRange:
+          min: 99
+      - name: request-duration
+        interval: 30s
+        thresholdRange:
+          max: 500
+    # load testing hooks
+    webhooks:
+      - name: load-test
+        url: http://flagger-loadtester.test/
+        timeout: 5s
+        metadata:
+          type: cmd
+          cmd: "hey -z 2m -q 20 -c 2 http://podinfo-svc-canary.test/"
+```
+
+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
+scaledobject.keda.sh/podinfo-so
+canary.flagger.app/podinfo
+
+# generated
+deployment.apps/podinfo-primary
+horizontalpodautoscaler.autoscaling/podinfo-primary
+service/podinfo
+service/podinfo-canary
+service/podinfo-primary
+scaledobject.keda.sh/podinfo-so-primary
+```
+
+We refer to our ScaledObject for the canary deployment using `.spec.autoscalerRef`. Flagger will use this to generate a ScaledObject which will scale the primary deployment.
+By default, Flagger will try to guess the query to use for the primary ScaledObject, by replacing all mentions of `.spec.targetRef.Name` and `{.spec.targetRef.Name}-canary`
+with `{.spec.targetRef.Name}-primary`, for all triggers.
+For eg, if your ScaledObject has a trigger query defined as: `sum(rate(http_requests_total{ app="podinfo" }[30s]))` or `sum(rate(http_requests_total{ app="podinfo-primary" }[30s]))`, then the primary ScaledObject will have the same trigger with a query defined as `sum(rate(http_requests_total{ app="podinfo-primary" }[30s]))`.
+
+If, the generated query does not meet your requirements, you can specify the query for autoscaling the primary deployment explicitly using 
+`.spec.autoscalerRef.primaryScalerQueries`, which lets you define a query for each trigger. Please note that, your ScaledObject's `.spec.triggers[@].name` must
+not be blank, as Flagger needs that to identify each trigger uniquely.
+
+After the boostrap, the podinfo deployment will be scaled to zero and the traffic to `podinfo.test` will be routed to the primary pods. To keep the podinfo deployment
+at 0 replicas and pause auto scaling, Flagger will add an annotation to your ScaledObject: `autoscaling.keda.sh/paused-replicas: 0`.
+During the canary analysis, the annotation is removed, to enable auto scaling for the podinfo deployment.
+The `podinfo-canary.test` address can be used to target directly the canary pods. 
+When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary. The Blue/Green deployment will run for five iterations while validating the HTTP metrics and rollout hooks every 15 seconds.
+
+
+## Automated Blue/Green promotion
+
+Trigger a deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.1
+```
+
+Flagger detects that the deployment revision changed and starts a new rollout:
+
+```text
+kubectl -n test describe canary/podinfo
+
+Events:
+
+New revision detected 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 iteration 1/10
+Advance podinfo.test canary iteration 2/10
+Advance podinfo.test canary iteration 3/10
+Advance podinfo.test canary iteration 4/10
+Advance podinfo.test canary iteration 5/10
+Advance podinfo.test canary iteration 6/10
+Advance podinfo.test canary iteration 7/10
+Advance podinfo.test canary iteration 8/10
+Advance podinfo.test canary iteration 9/10
+Advance podinfo.test canary iteration 10/10
+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.
+
+You can monitor all canaries with:
+
+```bash
+watch kubectl get canaries --all-namespaces
+
+NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
+test        podinfo   Progressing   100      2019-06-16T14:05:07Z
+```
+
+You can monitor the scaling of the deployments with:
+```bash
+watch kubectl -n test get deploy podinfo
+NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
+flagger-loadtester   1/1     1            1           4m21s
+podinfo              3/3     3            3           4m28s
+podinfo-primary      3/3     3            3           3m14s
+```
+
+You can mointor how Flagger edits the annotations of your ScaledObject with:
+```bash
+watch "kubectl get -n test scaledobjects podinfo-so -o=jsonpath='{.metadata.annotations}'"
+```

docs/gitbook/tutorials/kubernetes-blue-green.md

@@ -59,7 +59,8 @@ kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
 Deploy the load testing service to generate traffic during the analysis:
 
 ```bash
-kubectl apply -k https://github.com/fluxcd/flagger//kustomize/tester?ref=main
+helm upgrade -i flagger-loadtester flagger/loadtester \
+--namespace=test
 ```
 
 Create a canary custom resource:
@@ -171,7 +172,7 @@ Trigger a 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:
@@ -311,7 +312,7 @@ Trigger a 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
 ```
 
 Generate 404s:

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

@@ -0,0 +1,252 @@
+# Kuma Canary Deployments
+
+This guide shows you how to use Kuma and Flagger to automate canary deployments.
+
+![Flagger Kuma Canary](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-kuma-canary.png)
+
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.16** or newer and Kuma **1.3** or newer.
+
+Install Kuma and Prometheus (part of Kuma Metrics):
+
+```bash
+kumactl install control-plane | kubectl apply -f -
+kumactl install metrics | kubectl apply -f -
+```
+
+Install Flagger in the `kuma-system` namespace:
+
+```bash
+kubectl apply -k github.com/fluxcd/flagger//kustomize/kuma
+```
+
+## Bootstrap
+
+Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
+then creates a series of objects (Kubernetes deployments, ClusterIP services and Kuma `TrafficRoute`).
+These objects expose the application inside the mesh and drive the canary analysis and promotion.
+
+Create a test namespace and enable Kuma sidecar injection:
+
+```bash
+kubectl create ns test
+kubectl annotate namespace test kuma.io/sidecar-injection=enabled
+```
+
+Install 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 a deployment and a horizontal pod autoscaler:
+
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
+```
+
+Create a canary custom resource for the `podinfo` deployment:
+
+```yaml
+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:
+    # schedule interval (default 60s)
+    interval: 30s
+    # 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: 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/"
+```
+
+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 half a minute.
+
+After a couple of seconds Flagger will create the canary objects:
+
+```bash
+# applied
+deployment.apps/podinfo
+horizontalpodautoscaler.autoscaling/podinfo
+ingresses.extensions/podinfo
+canary.flagger.app/podinfo
+
+# generated
+deployment.apps/podinfo-primary
+horizontalpodautoscaler.autoscaling/podinfo-primary
+service/podinfo
+service/podinfo-canary
+service/podinfo-primary
+trafficroutes.kuma.io/podinfo
+```
+
+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.
+
+## 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/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png)
+
+Trigger a canary deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/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:
+ 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
+ Waiting for podinfo.test rollout to finish: 1 of 2 updated replicas are available
+ 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.
+
+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 all canaries with:
+
+```bash
+watch kubectl get canaries --all-namespaces
+
+NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
+test        podinfo   Progressing   15       2019-06-30T14:05:07Z
+prod        frontend  Succeeded     0        2019-06-30T16:15:07Z
+prod        backend   Failed        0        2019-06-30T17:05:07Z
+```
+
+## Automated rollback
+
+During the canary analysis you can generate HTTP 500 errors and high latency to test if Flagger pauses and rolls back the faulted version.
+
+Trigger another canary deployment:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/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 -n 1 curl http://podinfo-canary.test:9898/status/500
+```
+
+Generate latency:
+
+```bash
+watch -n 1 curl http://podinfo-canary.test: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:
+ Starting 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
+```
+
+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.

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

@@ -6,7 +6,14 @@ This guide shows you how to use Linkerd and Flagger to automate canary deploymen
 
 ## Prerequisites
 
-Flagger requires a Kubernetes cluster **v1.16** or newer and Linkerd **2.4** or newer.
+Flagger requires a Kubernetes cluster **v1.16** or newer and Linkerd **2.10** or newer.
+
+Install Linkerd the Promethues (part of Linkerd Viz):
+
+```bash
+linkerd install | kubectl apply -f -
+linkerd viz install | kubectl apply -f -
+```
 
 Install Flagger in the linkerd namespace:
 
@@ -14,11 +21,11 @@ Install Flagger in the linkerd namespace:
 kubectl apply -k github.com/fluxcd/flagger//kustomize/linkerd
 ```
 
-Note that you'll need kubectl 1.14 or newer to run the above command.
-
 ## Bootstrap
 
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services and SMI traffic split\). These objects expose the application inside the mesh 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 SMI traffic split).
+These objects expose the application inside the mesh and drive the canary analysis and promotion.
 
 Create a test namespace and enable Linkerd proxy injection:
 
@@ -133,7 +140,7 @@ 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.
+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.
 
 ## Automated canary promotion
 
@@ -145,7 +152,7 @@ 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:
@@ -204,7 +211,7 @@ Trigger another 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:
@@ -290,7 +297,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
 ```
 
 Generate 404s:
@@ -435,7 +442,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.4
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.4
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B testing:

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

@@ -6,7 +6,7 @@ This guide shows you how to use the NGINX ingress controller and Flagger to auto
 
 ## Prerequisites
 
-Flagger requires a Kubernetes cluster **v1.16** or newer and NGINX ingress **v0.41** or newer.
+Flagger requires a Kubernetes cluster **v1.19** or newer and NGINX ingress **v1.0.2** or newer.
 
 Install the NGINX ingress controller with Helm v3:
 
@@ -59,7 +59,7 @@ helm upgrade -i flagger-loadtester flagger/loadtester \
 Create an ingress definition (replace `app.example.com` with your own domain):
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: podinfo
@@ -70,12 +70,16 @@ metadata:
     kubernetes.io/ingress.class: "nginx"
 spec:
   rules:
-    - host: app.example.com
+    - host: "app.example.com"
       http:
         paths:
-          - backend:
-              serviceName: podinfo
-              servicePort: 80
+          - pathType: Prefix
+            path: "/"
+            backend:
+              service:
+                name: podinfo
+                port:
+                  number: 80
 ```
 
 Save the above resource as podinfo-ingress.yaml and then apply it:
@@ -101,7 +105,7 @@ spec:
     name: podinfo
   # ingress reference
   ingressRef:
-    apiVersion: networking.k8s.io/v1beta1
+    apiVersion: networking.k8s.io/v1
     kind: Ingress
     name: podinfo
   # HPA reference (optional)
@@ -188,7 +192,7 @@ 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:
@@ -242,7 +246,7 @@ Trigger another canary deployment:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.2
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.2
 ```
 
 Generate HTTP 500 errors:
@@ -330,7 +334,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
 ```
 
 Generate high response latency:
@@ -403,7 +407,7 @@ Trigger a canary deployment by updating the container image:
 
 ```bash
 kubectl -n test set image deployment/podinfo \
-podinfod=stefanprodan/podinfo:3.1.4
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.4
 ```
 
 Flagger detects that the deployment revision changed and starts the A/B testing:

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

@@ -0,0 +1,363 @@
+# Open Service Mesh Canary Deployments
+
+This guide shows you how to use Open Service Mesh (OSM) and Flagger to automate canary deployments.
+
+![Flagger OSM Traffic Split](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-osm-traffic-split.png)
+
+## Prerequisites
+
+Flagger requires a Kubernetes cluster **v1.16** or newer and Open Service Mesh **0.9.1** or newer.
+
+OSM must have permissive traffic policy enabled and have an instance of Prometheus for metrics.
+
+- If the OSM CLI is being used for installation, install OSM using the following command:
+    ```bash
+    osm install \
+    --set=OpenServiceMesh.deployPrometheus=true \
+    --set=OpenServiceMesh.enablePermissiveTrafficPolicy=true
+    ```
+- If a managed instance of OSM is being used:
+  - [Bring your own instance](docs.openservicemesh.io/docs/guides/observability/metrics/#byo-prometheus) of Prometheus, 
+    setting the namespace to match the managed OSM controller namespace
+  - Enable permissive traffic policy after installation by updating the OSM MeshConfig resource:
+    ```bash
+    # Replace <osm-namespace> with OSM controller's namespace
+    kubectl patch meshconfig osm-mesh-config -n <osm-namespace> -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}' --type=merge
+    ```   
+
+To install Flagger in the default `osm-system` namespace, use:
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/osm?ref=main
+```
+    
+Alternatively, if a non-default namespace or managed instance of OSM is in use, install Flagger with Helm, replacing the <osm-namespace>
+values as appropriate. If a custom instance of Prometheus is being used, replace `osm-prometheus` with the relevant Prometheus service name.
+```bash
+helm upgrade -i flagger flagger/flagger \
+--namespace=<osm-namespace> \
+--set meshProvider=osm \
+--set metricsServer=http://osm-prometheus.<osm-namespace>.svc:7070
+```
+
+## Bootstrap
+
+Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler (HPA),
+then creates a series of objects (Kubernetes deployments, ClusterIP services and SMI traffic split).
+These objects expose the application inside the mesh and drive the canary analysis and promotion.
+
+Create a `test` namespace and enable OSM namespace monitoring and metrics scraping for the namespace.
+
+```bash
+kubectl create namespace test
+osm namespace add test
+osm metrics enable --namespace test
+```
+
+Create a `podinfo` deployment and a horizontal pod autoscaler:
+
+```bash
+kubectl apply -k https://github.com/fluxcd/flagger//kustomize/podinfo?ref=main
+```
+
+Install 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 a canary custom resource for the `podinfo` deployment.
+The following `podinfo` canary custom resource instructs Flagger to:
+1. monitor any changes to the `podinfo` deployment created earlier,
+2. detect `podinfo` deployment revision changes, and
+3. start a Flagger canary analysis, rollout, and promotion if there were deployment revision changes.
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: Canary
+metadata:
+  name: podinfo
+  namespace: test
+spec:
+  provider: osm
+  # deployment reference
+  targetRef:
+    apiVersion: apps/v1
+    kind: Deployment
+    name: podinfo
+  # HPA reference (optional)
+  autoscalerRef:
+    apiVersion: autoscaling/v2beta2
+    kind: HorizontalPodAutoscaler
+    name: podinfo
+  # the maximum time in seconds for the canary deployment
+  # to make progress before it is rolled back (default 600s)
+  progressDeadlineSeconds: 60
+  service:
+    # ClusterIP port number
+    port: 9898
+    # container port number or name (optional)
+    targetPort: 9898
+  analysis:
+    # schedule interval (default 60s)
+    interval: 30s
+    # 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
+    # OSM Prometheus checks
+    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
+    # testing (optional)
+    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/
+        timeout: 5s
+        metadata:
+          cmd: "hey -z 2m -q 10 -c 2 http://podinfo-canary.test:9898/"
+```
+
+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 half a minute.
+
+After a couple of seconds Flagger will create the canary objects.
+
+```bash
+# applied
+deployment.apps/podinfo
+horizontalpodautoscaler.autoscaling/podinfo
+ingresses.extensions/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 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.
+
+## 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 Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png)
+
+Trigger a canary deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/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:
+ 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
+ Waiting for podinfo.test rollout to finish: 1 of 2 updated replicas are available
+ 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 any new changes to the `podinfo` 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 all canaries with:
+
+```bash
+watch kubectl get canaries --all-namespaces
+
+NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
+test        podinfo   Progressing   15       2019-06-30T14:05:07Z
+prod        frontend  Succeeded     0        2019-06-30T16:15:07Z
+prod        backend   Failed        0        2019-06-30T17:05:07Z
+```
+
+## Automated Rollback
+
+During the canary analysis you can generate HTTP 500 errors and high latency to test if Flagger pauses and rolls back the faulted version.
+
+Trigger another canary deployment:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.2
+```
+
+Exec into the load tester pod with:
+
+```bash
+kubectl -n test exec -it flagger-loadtester-xx-xx sh
+```
+
+Repeatedly generate HTTP 500 errors until the `kubectl describe` output below shows canary rollout failure:
+
+```bash
+watch -n 0.1 curl http://podinfo-canary.test:9898/status/500
+```
+
+Repeatedly generate latency until canary rollout fails:
+
+```bash
+watch -n 0.1 curl http://podinfo-canary.test:9898/delay/1
+```
+
+When the number of failed checks reaches the canary analysis thresholds defined in the `podinfo` canary custom resource earlier, 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:
+ Starting 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
+```
+
+## Custom Metrics
+
+The canary analysis can be extended with Prometheus queries.
+
+Let's define a check for 404 not found errors.
+Edit the canary analysis (`podinfo-canary.yaml` file) and add the following metric.
+For more information on creating additional custom metrics using OSM metrics, please check the [metrics available in OSM](https://docs.openservicemesh.io/docs/guides/observability/metrics/#available-metrics).
+
+```yaml
+  analysis:
+    metrics:
+    - name: "404s percentage"
+      threshold: 3
+      query: |
+        100 - (
+          sum(
+              rate(
+                  osm_request_total{
+                    destination_namespace="test",
+                    destination_kind="Deployment",
+                    destination_name="podinfo",
+                    response_code!="404"
+                  }[1m]
+              )
+          )
+          /
+          sum(
+              rate(
+                  osm_request_total{
+                    destination_namespace="test",
+                    destination_kind="Deployment",
+                    destination_name="podinfo"
+                  }[1m]
+              )
+          ) * 100
+        )
+```
+
+The above configuration validates the canary version by checking if the HTTP 404 req/sec percentage is below three percent of the total traffic.
+If the 404s rate reaches the 3% threshold, then the analysis is aborted and the canary is marked as failed.
+
+Trigger a canary deployment by updating the container image:
+
+```bash
+kubectl -n test set image deployment/podinfo \
+podinfod=ghcr.io/stefanprodan/podinfo:6.0.3
+```
+
+Exec into the load tester pod with:
+
+```bash
+kubectl -n test exec -it flagger-loadtester-xx-xx sh
+```
+
+Repeatedly generate 404s until canary rollout fails:
+
+```bash
+watch -n 0.1 curl http://podinfo-canary.test:9898/status/404
+```
+
+Watch Flagger logs to confirm successful canary rollback.
+
+```text
+kubectl -n osm-system logs deployment/flagger -f | jq .msg
+
+Starting canary deployment for podinfo.test
+Pre-rollout check acceptance-test passed
+Advance podinfo.test canary weight 5
+Halt podinfo.test advancement 404s percentage 6.20 > 3
+Halt podinfo.test advancement 404s percentage 6.45 > 3
+Halt podinfo.test advancement 404s percentage 7.22 > 3
+Halt podinfo.test advancement 404s percentage 6.50 > 3
+Halt podinfo.test advancement 404s percentage 6.34 > 3
+Rolling back podinfo.test failed checks threshold reached 5
+Canary failed! Scaling down podinfo.test
+```

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

@@ -6,7 +6,7 @@ This guide shows you how to use the [Skipper ingress controller](https://opensou
 
 ## Prerequisites
 
-Flagger requires a Kubernetes cluster **v1.16** or newer and Skipper ingress **0.11.40** or newer.
+Flagger requires a Kubernetes cluster **v1.19** or newer and Skipper ingress **v0.13** or newer.
 
 Install Skipper ingress-controller using [upstream definition](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/#install-skipper-as-ingress-controller).
 
@@ -36,7 +36,9 @@ kustomize build https://github.com/fluxcd/flagger/kustomize/kubernetes | kubectl
 
 ## Bootstrap
 
-Flagger takes a Kubernetes deployment and optionally a horizontal pod autoscaler \(HPA\), then creates a series of objects \(Kubernetes deployments, ClusterIP services and canary ingress\). These objects expose the application outside 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 canary ingress).
+These objects expose the application outside the cluster and drive the canary analysis and promotion.
 
 Create a test namespace:
 
@@ -60,7 +62,7 @@ helm upgrade -i flagger-loadtester flagger/loadtester \
 Create an ingress definition \(replace `app.example.com` with your own domain\):
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: podinfo
@@ -71,12 +73,16 @@ metadata:
     kubernetes.io/ingress.class: "skipper"
 spec:
   rules:
-    - host: app.example.com
+    - host: "app.example.com"
       http:
         paths:
-          - backend:
-              serviceName: podinfo
-              servicePort: 80
+          - pathType: Prefix
+            path: "/"
+            backend:
+              service:
+                name: podinfo
+                port:
+                  number: 80
 ```
 
 Save the above resource as podinfo-ingress.yaml and then apply it:
@@ -85,7 +91,7 @@ Save the above resource as podinfo-ingress.yaml and then apply it:
 kubectl apply -f ./podinfo-ingress.yaml
 ```
 
-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
@@ -102,7 +108,7 @@ spec:
     name: podinfo
   # ingress reference
   ingressRef:
-    apiVersion: networking.k8s.io/v1beta1
+    apiVersion: networking.k8s.io/v1
     kind: Ingress
     name: podinfo
   # HPA reference (optional)
@@ -190,7 +196,9 @@ ingress.networking.k8s.io/podinfo-canary
 
 ## 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 or MS Teams.
+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 or MS Teams.
 
 ![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png)
 
@@ -271,7 +279,8 @@ 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 flagger-system logs deploy/flagger -f | jq .msg
@@ -333,7 +342,8 @@ Edit the canary analysis and add the latency check:
       interval: 1m
 ```
 
-The threshold is set to 500ms so if the average request duration in the last minute goes over half a second then the analysis will fail and the canary will not be promoted.
+The threshold is set to 500ms so if the average request duration in the last minute goes over half a second
+then the analysis will fail and the canary will not be promoted.
 
 Trigger a canary deployment by updating the container image:
 
@@ -367,4 +377,3 @@ Canary failed! Scaling down podinfo.test
 ```
 
 If you have alerting configured, Flagger will send a notification with the reason why the canary failed.
-

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

@@ -2,6 +2,8 @@
 
 This guide shows you how to use the [Traefik](https://doc.traefik.io/traefik/) and Flagger to automate canary deployments.
 
+![Flagger Traefik Overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-traefik-overview.png)
+
 ## Prerequisites
 
 Flagger requires a Kubernetes cluster **v1.16** or newer and Traefik **v2.3** or newer.
@@ -11,9 +13,17 @@ Install Traefik with Helm v3:
 ```bash
 helm repo add traefik https://helm.traefik.io/traefik
 kubectl create ns traefik
-helm upgrade -i traefik traefik/traefik \
---namespace traefik \
---set additionalArguments="--metrics.prometheus=true"
+
+cat <<EOF | helm upgrade -i traefik traefik/traefik --namespace traefik -f -
+deployment:
+  podAnnotations:
+    prometheus.io/port: "9100"
+    prometheus.io/scrape: "true"
+    prometheus.io/path: "/metrics"
+metrics:
+  prometheus:
+    entryPoint: metrics
+EOF
 ```
 
 Install Flagger and the Prometheus add-on in the same namespace as Traefik:

docs/gitbook/usage/alerting.md

@@ -5,13 +5,25 @@ You can define a global alert provider at install time or configure alerts on a
 
 ## Global configuration
 
-Flagger can be configured to send Slack notifications:
+### Slack
+
+#### Slack Configuration
+
+Flagger requires a custom webhook integration from slack, instead of the new slack app system.
+
+The webhook can be generated by following the [legacy slack documentation](https://api.slack.com/legacy/custom-integrations/messaging/webhooks)
+
+#### Flagger configuration
+
+Once the webhook has been generated. Flagger can be configured to send Slack notifications:
 
 ```bash
 helm upgrade -i flagger flagger/flagger \
 --set slack.url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK \
+--set slack.proxy=my-http-proxy.com \ # optional http/s proxy
 --set slack.channel=general \
---set slack.user=flagger
+--set slack.user=flagger \
+--set clusterName=my-cluster
 ```
 
 Once configured with a Slack incoming **webhook**,
@@ -25,11 +37,16 @@ or if the analysis reached the maximum number of failed checks:
 
 ![Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png)
 
+For using a Slack bot token, you should add `token` to a secret and use **secretRef**.
+
+### Microsoft Teams
+
 Flagger can be configured to send notifications to Microsoft Teams:
 
 ```bash
 helm upgrade -i flagger flagger/flagger \
---set msteams.url=https://outlook.office.com/webhook/YOUR/TEAMS/WEBHOOK
+--set msteams.url=https://outlook.office.com/webhook/YOUR/TEAMS/WEBHOOK \
+--set msteams.proxy-url=my-http-proxy.com # optional http/s proxy
 ```
 
 Similar to Slack, Flagger alerts on canary analysis events:
@@ -58,7 +75,10 @@ spec:
   channel: on-call-alerts
   username: flagger
   # webhook address (ignored if secretRef is specified)
+  # or https://slack.com/api/chat.postMessage if you use token in the secret
   address: https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK
+  # optional http/s proxy
+  proxy: http://my-http-proxy.com
   # secret containing the webhook address (optional)
   secretRef:
     name: on-call-url
@@ -70,6 +90,7 @@ metadata:
   namespace: flagger
 data:
   address: <encoded-url>
+  token: <encoded-token>
 ```
 
 The alert provider **type** can be: `slack`, `msteams`, `rocket` or `discord`. When set to `discord`,
@@ -111,6 +132,9 @@ Alert fields:
 When the severity is set to `warn`, Flagger will alert when waiting on manual confirmation or if the analysis fails.
 When the severity is set to `error`, Flagger will alert only if the canary analysis fails.
 
+To differentiate alerts based on the cluster name, you can configure Flagger with the `-cluster-name=my-cluster`
+command flag, or with Helm `--set clusterName=my-cluster`.
+
 ## Prometheus Alert Manager
 
 You can use Alertmanager to trigger alerts when a canary deployment failed:

docs/gitbook/usage/deployment-strategies.md

@@ -3,11 +3,11 @@
 Flagger can run automated application analysis, promotion and rollback for the following deployment strategies:
 
 * **Canary Release** \(progressive traffic shifting\)
-  * Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo Edge, Traefik
+  * Istio, Linkerd, App Mesh, NGINX, Skipper, Contour, Gloo Edge, Traefik, Open Service Mesh, Kuma, Gateway API
 * **A/B Testing** \(HTTP headers and cookies traffic routing\)
-  * Istio, App Mesh, NGINX, Contour, Gloo Edge
+  * Istio, App Mesh, NGINX, Contour, Gloo Edge, Gateway API
 * **Blue/Green** \(traffic switching\)
-  * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo Edge
+  * Kubernetes CNI, Istio, Linkerd, App Mesh, NGINX, Contour, Gloo Edge, Open Service Mesh, Gateway API
 * **Blue/Green Mirroring** \(traffic shadowing\)
   * Istio
 
@@ -326,7 +326,7 @@ Blue/Green rollout steps for service mesh:
 * run conformance tests for the canary pods
 * run load tests and metric checks for the canary pods every minute
 * abort the canary release if the failure threshold is reached
-* route traffic to canary
+* route traffic to canary (This doesn't happen when using the kubernetes provider)
 * promote canary spec over primary (blue)
 * wait for primary rollout
 * route traffic to primary

docs/gitbook/usage/how-it-works.md

@@ -115,6 +115,12 @@ but disabling config-tracking using the per Secret/ConfigMap annotation may fit
 The autoscaler reference is optional, when specified,
 Flagger will pause the traffic increase while the target and primary deployments are scaled up or down.
 HPA can help reduce the resource usage during the canary analysis.
+When the autoscaler reference is specified, any changes made to the autoscaler are only made active 
+in the primary autoscaler when a rollout for the deployment starts and completes successfully.
+Optionally, you can create two HPAs, one for canary and one for the primary to update the HPA without
+doing a new rollout. As the canary deployment will be scaled to 0, the HPA on the canary will be inactive.
+
+**Note** Flagger requires `autoscaling/v2` or `autoscaling/v2beta2` API version for HPAs.
 
 The progress deadline represents the maximum time in seconds for the canary deployment to
 make progress before it is rolled back, defaults to ten minutes.
@@ -130,6 +136,7 @@ spec:
     name: podinfo
     port: 9898
     portName: http
+    appProtocol: http
     targetPort: 9898
     portDiscovery: true
 ```
@@ -138,6 +145,7 @@ The container port from the target workload should match the `service.port` or `
 The `service.name` is optional, defaults to `spec.targetRef.name`.
 The `service.targetPort` can be a container port number or name.
 The `service.portName` is optional (defaults to `http`), if your workload uses gRPC then set the port name to `grpc`.
+The `service.appProtocol` is optional, more details can be found [here](https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol).
 
 If port discovery is enabled, Flagger scans the target workload and extracts the containers ports
 excluding the port specified in the canary service and service mesh sidecar ports.
@@ -184,6 +192,10 @@ spec:
         test: "test"
 ```
 
+Note that the `apex` annotations are added to both the generated Kubernetes Service and the
+generated service mesh/ingress object. This allows using external-dns with Istio `VirtualServices`
+and `TraefikServices`. Beware of configuration conflicts [here](../faq.md#ExternalDNS).
+
 Besides port mapping and metadata, the service specification can
 contain URI match and rewrite rules, timeout and retry polices:
 
@@ -244,7 +256,7 @@ status:
 ```
 
 The `Promoted` status condition can have one of the following reasons:
-Initialized, Waiting, Progressing, Promoting, Finalising, Succeeded or Failed.
+Initialized, Waiting, Progressing, WaitingPromotion, Promoting, Finalising, Succeeded or Failed.
 A failed canary will have the promoted status set to `false`,
 the reason to `failed` and the last applied spec will be different to the last promoted one.
 
@@ -331,6 +343,14 @@ Spec:
     # total number of iterations
     # used for A/B Testing and Blue/Green
     iterations:
+    # threshold of primary pods that need to be available to consider it ready
+    # before starting rollout. this is optional and the default is 100
+    # percentage (0-100)
+    primaryReadyThreshold: 100
+    # threshold of canary pods that need to be available to consider it ready
+    # before starting rollout. this is optional and the default is 100
+    # percentage (0-100)
+    canaryReadyThreshold: 100
     # canary match conditions
     # used for A/B Testing
     match:

docs/gitbook/usage/metrics.md

@@ -29,7 +29,7 @@ Flagger comes with two builtin metric checks: HTTP request success rate and dura
 
 For each metric you can specify a range of accepted values with `thresholdRange` and
 the window size or the time series with `interval`.
-The builtin checks are available for every service mesh / ingress controlle
+The builtin checks are available for every service mesh / ingress controller
 and are implemented with [Prometheus queries](../faq.md#metrics).
 
 ## Custom metrics
@@ -46,8 +46,9 @@ metadata:
   name: my-metric
 spec:
   provider:
-    type: # can be prometheus or datadog
+    type: # can be prometheus, datadog, etc
     address: # API URL
+    insecureSkipVerify: # if set to true, disables the TLS cert validation
     secretRef:
       name: # name of the secret containing the API credentials
   query: # metric query
@@ -401,3 +402,212 @@ Reference the template in the canary analysis:
           max: 5
         interval: 1m
 ```
+
+## Graphite
+
+You can create custom metric checks using the Graphite provider.
+
+Graphite template example:
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: graphite-request-success-rate
+spec:
+  provider:
+    type: graphite
+    address: http://graphite.monitoring
+  query: |
+    target=summarize(
+      asPercent(
+        sumSeries(
+          stats.timers.httpServerRequests.app.{{target}}.exception.*.method.*.outcome.{CLIENT_ERROR,INFORMATIONAL,REDIRECTION,SUCCESS}.status.*.uri.*.count
+        ),
+        sumSeries(
+          stats.timers.httpServerRequests.app.{{target}}.exception.*.method.*.outcome.*.status.*.uri.*.count
+        )
+      ),
+      {{interval}},
+      'avg'
+    )
+```
+
+Reference the template in the canary analysis:
+
+```yaml
+  analysis:
+    metrics:
+      - name: "success rate"
+        templateRef:
+          name: graphite-request-success-rate
+        thresholdRange:
+          min: 90
+        interval: 1min
+```
+
+## Graphite authentication
+
+If your Graphite API requires basic authentication, you can create a secret in the same namespace
+as the `MetricTemplate` with the basic-auth credentials:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: graphite-basic-auth
+  namespace: flagger
+data:
+  username: your-user
+  password: your-password
+```
+
+Then, reference the secret in the `MetricTemplate`:
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: my-metric
+  namespace: flagger
+spec:
+  provider:
+    type: graphite
+    address: http://graphite.monitoring
+    secretRef:
+      name: graphite-basic-auth
+```
+
+## Google Cloud Monitoring (Stackdriver)
+
+Enable Workload Identity on your cluster, create a service account key that has read access to the
+Cloud Monitoring API and then create an IAM policy binding between the GCP service account and the Flagger 
+service account on Kubernetes. You can take a look at this [guide](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)
+
+Annotate the flagger service account
+```shell script
+kubectl annotate serviceaccount flagger \
+    --namespace <namespace> \
+    iam.gke.io/gcp-service-account=<gcp-serviceaccount-name>@<project-id>.iam.gserviceaccount.com
+```
+
+Alternatively, you can download the json keys and add it to your secret with the key `serviceAccountKey` (This method is not recommended).
+
+Create a secret that contains your project-id (and, if workload identity is not enabled on your cluster,
+your [service account json](https://cloud.google.com/docs/authentication/production#create_service_account)).
+
+```
+ kubectl create secret generic gcloud-sa --from-literal=project=<project-id>
+```
+
+Then reference the secret in the metric template. 
+Note: The particular MQL query used here works if [Istio is installed on GKE](https://cloud.google.com/istio/docs/istio-on-gke/installing).
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: bytes-sent
+  namespace: test
+spec:
+  provider:
+    type: stackdriver
+    secretRef: 
+      name: gcloud-sa
+  query: |
+    fetch k8s_container
+    | metric 'istio.io/service/server/response_latencies'
+    | filter
+        (metric.destination_service_name == '{{ service }}-canary'
+        && metric.destination_service_namespace == '{{ namespace }}')
+    | align delta(1m)
+    | every 1m
+    | group_by [],
+        [value_response_latencies_percentile:
+          percentile(value.response_latencies, 99)]
+```
+
+The reference for the query language can be found [here](https://cloud.google.com/monitoring/mql/reference)
+
+## InfluxDB
+
+The InfluxDB provider uses the [flux](https://docs.influxdata.com/influxdb/v2.0/query-data/get-started/) query language.
+
+Create a secret that contains your authentication token that can be found in the InfluxDB UI.
+
+```
+ kubectl create secret generic influx-token --from-literal=token=<token>
+```
+
+Then reference the secret in the metric template.
+
+Note: The particular MQL query used here works if [Istio is installed on GKE](https://cloud.google.com/istio/docs/istio-on-gke/installing).
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: not-found
+  namespace: test
+spec:
+  provider:
+    type: influxdb
+    secretRef:
+      name: influx-token
+  query: |
+    from(bucket: "default")
+    |> range(start: -2h)
+    |> filter(fn: (r) => r["_measurement"] == "istio_requests_total")
+    |> filter(fn: (r) => r[" destination_workload_namespace"] == "{{ namespace }}")
+    |> filter(fn: (r) => r["destination_workload"] == "{{ target }}")
+    |> filter(fn: (r) => r["response_code"] == "500")
+    |> count()
+    |> yield(name: "count")
+```
+
+## Dynatrace
+
+You can create custom metric checks using the Dynatrace provider.
+
+Create a secret with your Dynatrace token:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+  name: dynatrace
+  namespace: istio-system
+data:
+  dynatrace_token: ZHQwYz...
+```
+
+Dynatrace metric template example:
+
+```yaml
+apiVersion: flagger.app/v1beta1
+kind: MetricTemplate
+metadata:
+  name: response-time-95pct
+  namespace: istio-system
+spec:
+  provider:
+    type: dynatrace
+    address: https://xxxxxxxx.live.dynatrace.com
+    secretRef:
+      name: dynatrace
+  query: |
+    builtin:service.response.time:filter(eq(dt.entity.service,SERVICE-ABCDEFG0123456789)):percentile(95)
+```
+
+Reference the template in the canary analysis:
+
+```yaml
+  analysis:
+    metrics:
+      - name: "response-time-95pct"
+        templateRef:
+          name: response-time-95pct
+          namespace: istio-system
+        thresholdRange:
+          max: 1000
+        interval: 1m
+```

docs/gitbook/usage/monitoring.md

@@ -117,4 +117,8 @@ flagger_canary_duration_seconds_bucket{name="podinfo",namespace="test",le="10"}
 flagger_canary_duration_seconds_bucket{name="podinfo",namespace="test",le="+Inf"} 6
 flagger_canary_duration_seconds_sum{name="podinfo",namespace="test"} 17.3561329
 flagger_canary_duration_seconds_count{name="podinfo",namespace="test"} 6
+
+# Last canary metric analysis result per different metrics
+flagger_canary_metric_analysis{metric="podinfo-http-successful-rate",name="podinfo",namespace="test"} 1
+flagger_canary_metric_analysis{metric="podinfo-custom-metric",name="podinfo",namespace="test"} 0.918223108974359
 ```

docs/gitbook/usage/webhooks.md

@@ -16,6 +16,9 @@ There are several types of hooks:
 * **rollout** hooks are executed during the analysis on each iteration before the metric checks.
   If a rollout hook call fails the canary advancement is paused and eventfully rolled back.
 
+* **confirm-traffic-increase** hooks are executed right before the weight on the canary is increased. The canary
+  advancement is paused until this hook returns HTTP 200.
+
 * **confirm-promotion** hooks are executed before the promotion step.
   The canary promotion is paused until the hooks return HTTP 200.
   While the promotion is paused, Flagger will continue to run the metrics checks and rollout hooks.
@@ -51,6 +54,9 @@ Spec:
         timeout: 15s
         metadata:
           cmd: "hey -z 1m -q 5 -c 2 http://podinfo-canary.test:9898/"
+      - name: "traffic increase gate"
+        type: confirm-traffic-increase
+        url: http://flagger-loadtester.test/gate/approve
       - name: "promotion gate"
         type: confirm-promotion
         url: http://flagger-loadtester.test/gate/approve
@@ -66,6 +72,9 @@ Spec:
       - name: "send to Slack"
         type: event
         url: http://event-recevier.notifications/slack
+        metadata:
+          environment: "test"
+          cluster: "flagger-test"
 ```
 
 > **Note** that the sum of all rollout webhooks timeouts should be lower than the analysis interval.
@@ -134,7 +143,8 @@ helm repo add flagger https://flagger.app
 
 helm upgrade -i flagger-loadtester flagger/loadtester \
 --namespace=test \
---set cmd.timeout=1h
+--set cmd.timeout=1h \
+--set cmd.namespaceRegexp=''
 ```
 
 When deployed the load tester API will be available at `http://flagger-loadtester.test/`.
@@ -244,6 +254,42 @@ to the nGrinder server and start a new performance test. the load tester will pe
 poll the nGrinder server for the status of the test,
 and prevent duplicate requests from being sent in subsequent analysis loops.
 
+### K6 Load Tester
+
+You can also delegate load testing to a third-party webhook. An example of this is the [`k6 webhook`](https://github.com/grafana/flagger-k6-webhook). This webhook uses [`k6`](https://k6.io/), a very featureful load tester, to run load or smoke tests on canaries. For all features available, see the source repository. 
+
+Here's an example integrating this webhook as a `pre-rollout` step, to load test a service before any traffic is sent to it:
+
+```yaml
+webhooks:
+- name: k6-load-test
+  timeout: 5m
+  type: pre-rollout
+  url: http://k6-loadtester.flagger/launch-test
+  metadata:
+    script: |
+      import http from 'k6/http';
+      import { sleep } from 'k6';
+      export const options = {
+        vus: 2,
+        duration: '30s',
+        thresholds: {
+            http_req_duration: ['p(95)<50']
+        },
+        ext: {
+          loadimpact: {
+            name: '<cluster>/<your_service>',
+            projectID: <project id>,
+          },
+        },
+      };
+
+      export default function () {
+        http.get('http://<your_service>-canary.<namespace>:80/');
+        sleep(0.10);
+      }
+```
+
 ## Integration Testing
 
 Flagger comes with a testing service that can run Helm tests, Bats tests or Concord tests when configured as a webhook.
@@ -344,7 +390,8 @@ the web-hook will try to call Concord before timing out (Default is 30s).
 ## Manual Gating
 
 For manual approval of a canary deployment you can use the `confirm-rollout` and `confirm-promotion` webhooks.
-The confirmation rollout hooks are executed before the pre-rollout hooks.
+The confirmation rollout hooks are executed before the pre-rollout hooks. For manually approving traffic weight increase,
+you can use the `confirm-traffic-increase` webhook.
 Flagger will halt the canary traffic shifting and analysis until the confirm webhook returns HTTP status 200.
 
 For manual rollback of a canary deployment you can use the `rollback` webhook.
@@ -367,6 +414,17 @@ The `/gate/halt` returns HTTP 403 thus blocking the rollout.
 If you have notifications enabled, Flagger will post a message to
 Slack or MS Teams if a canary rollout is waiting for approval.
 
+The notifications can be disabled with:
+
+```yaml
+  analysis:
+    webhooks:
+      - name: "gate"
+        type: confirm-rollout
+        url: http://flagger-loadtester.test/gate/halt
+        muteAlert: true
+```
+
 Change the URL to `/gate/approve` to start the canary analysis:
 
 ```yaml

docs/logo/flagger-icon-black.svg

@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<svg width="64px" height="64px" viewBox="0 0 64 64" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
+    <title>flagger-icon-black</title>
+    <g id="flagger-icon-black" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
+        <path d="M11.7870673,17.7791346 C10.7376442,17.0966346 10.7376442,15.5602885 11.7870673,14.8783654 L31.1659135,2.27951923 C31.4527085,2.09313128 31.7809164,2 32.109115,2 C32.1144833,2 32.1144833,30.6577081 32.1144833,30.6577081 C31.7844966,30.658555 31.4542722,30.565385 31.1659135,30.3779808 L11.7870673,17.7791346 Z" id="Fill-1" fill="#000000"></path>
+        <path d="M1.78706731,24.2791346 C0.737644231,23.5966346 0.737644231,22.0602885 1.78706731,21.3783654 L21.1659135,8.77951923 C21.4527085,8.59313128 21.7809164,8.5 22.109147,8.5 C22.1144833,8.5 16.7504591,14.9302441 16.4621003,14.7428399 L1.78706731,24.2791346 Z" id="Fill-1-Copy" fill="#000000"></path>
+        <path d="M32.1005414,32.7999243 C32.4314477,32.7984255 32.7627112,32.8915919 33.051875,33.0795192 L52.4312981,45.6783654 C53.4807212,46.3602885 53.4807212,47.8966346 52.4312981,48.5791346 L33.051875,61.1779808 C32.7723427,61.3596486 32.4534685,61.452763 32.1336066,61.4575 C32.1336066,61.4575 32.1005414,32.7999243 32.1005414,32.7999243 Z" id="Fill-1" fill="#000000"></path>
+        <path d="M42.6594534,51.6821881 L62.4312981,39.1784411 C63.4807212,39.8603641 63.4807212,41.3967103 62.4312981,42.0792103 L43.051875,54.6780564 C42.7723427,54.8597243 42.4534685,54.9528387 42.1336066,54.9573995 C42.1336066,54.9573995 42.3702896,51.4942608 42.6594534,51.6821881 Z" id="Fill-1-Copy-2" fill="#000000"></path>
+        <g id="Group" transform="translate(11.000000, 32.000000)" fill="#000000">
+            <path d="M23.1648462,1.79890385 C22.7177486,1.57560653 21.9079818,0.775616463 21.12525,0.8 C20.4471662,0.8 20.1819808,1.07951923 19.08525,1.79890385 C20.6106346,2.45198077 26.2588846,4.40082692 27.8390769,4.83755769 C25.3252832,3.17403545 23.7672062,2.16115083 23.1648462,1.79890385 Z" id="Fill-5"></path>
+            <path d="M17.1629423,3.04898077 L15.4269808,4.17744231 C16.9371113,5.2881491 18.4473527,6.15609036 19.9577051,6.7812661 C23.0272183,8.05182074 26.9292047,8.86995809 27.8191154,9.08936538 C32.8706538,10.3349423 37.6418077,11.5107115 41.4783462,15.3478269 C41.6733462,15.54225 41.8562308,15.7407115 42.0373846,15.93975 C42.4308462,15.1880192 42.2335385,14.1957115 41.4466154,13.6845577 L33.8560385,8.74898077 C32.0133462,8.14090385 30.1360385,7.67590385 28.2806538,7.21898077 C26.5308462,6.78744231 23.5727919,6.02059898 21.9181765,5.49156052 C20.8150996,5.13886821 19.2300215,4.32467496 17.1629423,3.04898077 Z" id="Fill-7"></path>
+            <path d="M16.8750849,8.20483098 C15.6193488,7.62821266 14.2831279,6.83594208 12.8664221,5.82801923 L11.2119808,6.91782692 C12.8335577,8.16072333 14.2385577,9.07106402 15.4269808,9.648849 C17.2096154,10.5155265 24.0114808,12.3722308 24.4326346,12.4760769 C29.4841731,13.7210769 34.2553269,14.8968462 38.0924423,18.7339615 C38.0987885,18.7408846 38.1045577,18.7472308 38.1114808,18.7541538 L39.75225,17.6868462 C39.6524423,17.5824231 39.5584038,17.4751154 39.4545577,17.3718462 C35.2384038,13.1551154 29.9791731,11.8587692 24.8941731,10.6051154 C24.3137885,10.4620385 18.7586891,9.06975845 16.8750849,8.20483098 Z" id="Fill-11"></path>
+            <path d="M23.1650769,16.3935 C27.1175769,17.4140769 30.8341154,18.6342692 33.9823846,21.4381154 L35.6439231,20.3581154 C32.0465509,16.9762696 28.005918,15.3433009 23.4551919,14.4789663 C19.3757148,13.7041376 16.6984434,12.7436057 13.6520967,11.5324737 C11.621199,10.7250524 9.97648083,9.72718297 8.71794231,8.53886538 L7.04717308,9.62521154 C9.06194661,11.3700006 10.8411363,12.5664934 12.3847422,13.2146899 C14.4228927,14.0705575 18.0163376,15.1301608 23.1650769,16.3935 Z" id="Fill-17"></path>
+            <path d="M4.57875,11.2299231 L2.92990385,12.3018462 C2.98759615,12.3612692 3.04009615,12.423 3.09951923,12.4818462 C7.31625,16.6985769 12.5743269,17.9949231 17.6599038,19.2485769 C22.0641346,20.3337692 26.2543269,21.3687692 29.7989423,24.1581923 L31.4893269,23.0591538 C27.4958654,19.6968462 22.7385577,18.5158846 18.1214423,17.3781923 C13.1206731,16.1453077 8.39567308,14.9758846 4.57875,11.2299231" id="Fill-19"></path>
+            <path d="M1.07555769,14.5060962 C0.883442308,14.3139808 0.702865385,14.1184038 0.524019231,13.9216731 C-0.227711538,14.6745577 -0.139442308,15.9726346 0.80325,16.5853269 L6.50959615,20.2955192 C9.03536538,21.3409038 11.6765192,21.9945577 14.2738269,22.6349423 C18.3284423,23.6341731 22.2019038,24.5924423 25.5578654,26.9157115 L27.2834423,25.7930192 C23.4676731,22.9245577 19.0403654,21.8255192 14.7347885,20.7639808 C9.68382692,19.5189808 4.91267308,18.3432115 1.07555769,14.5060962" id="Fill-21"></path>
+            <path d="M19.6441154,28.8342692 C20.0243077,29.0188846 20.3998846,29.2133077 20.7691154,29.4221538 C21.2093077,29.5150385 21.6771923,29.4383077 22.0683462,29.1838846 L23.0260385,28.5613846 C19.9493077,26.5035 16.5287308,25.461 13.1196923,24.5927308 L19.6441154,28.8342692 Z" id="Fill-23"></path>
+        </g>
+        <g id="Group-Copy" transform="translate(11.000000, 1.200000)" fill="#000000">
+            <path d="M23.1648462,1.79890385 C22.7177486,1.57560653 21.9079818,0.775616463 21.12525,0.8 C20.4471662,0.8 20.1819808,1.07951923 19.08525,1.79890385 C20.6106346,2.45198077 26.2588846,4.40082692 27.8390769,4.83755769 C25.3252832,3.17403545 23.7672062,2.16115083 23.1648462,1.79890385 Z" id="Fill-5"></path>
+            <path d="M17.1629423,3.04898077 L15.4269808,4.17744231 C16.9371113,5.2881491 18.4473527,6.15609036 19.9577051,6.7812661 C23.0272183,8.05182074 26.9292047,8.86995809 27.8191154,9.08936538 C32.8706538,10.3349423 37.6418077,11.5107115 41.4783462,15.3478269 C41.6733462,15.54225 41.8562308,15.7407115 42.0373846,15.93975 C42.4308462,15.1880192 42.2335385,14.1957115 41.4466154,13.6845577 L33.8560385,8.74898077 C32.0133462,8.14090385 30.1360385,7.67590385 28.2806538,7.21898077 C26.5308462,6.78744231 23.5727919,6.02059898 21.9181765,5.49156052 C20.8150996,5.13886821 19.2300215,4.32467496 17.1629423,3.04898077 Z" id="Fill-7"></path>
+            <path d="M16.8750849,8.20483098 C15.6193488,7.62821266 14.2831279,6.83594208 12.8664221,5.82801923 L11.2119808,6.91782692 C12.8335577,8.16072333 14.2385577,9.07106402 15.4269808,9.648849 C17.2096154,10.5155265 24.0114808,12.3722308 24.4326346,12.4760769 C29.4841731,13.7210769 34.2553269,14.8968462 38.0924423,18.7339615 C38.0987885,18.7408846 38.1045577,18.7472308 38.1114808,18.7541538 L39.75225,17.6868462 C39.6524423,17.5824231 39.5584038,17.4751154 39.4545577,17.3718462 C35.2384038,13.1551154 29.9791731,11.8587692 24.8941731,10.6051154 C24.3137885,10.4620385 18.7586891,9.06975845 16.8750849,8.20483098 Z" id="Fill-11"></path>
+            <path d="M23.1650769,16.3935 C27.1175769,17.4140769 30.8341154,18.6342692 33.9823846,21.4381154 L35.6439231,20.3581154 C32.0465509,16.9762696 28.005918,15.3433009 23.4551919,14.4789663 C19.3757148,13.7041376 16.6984434,12.7436057 13.6520967,11.5324737 C11.621199,10.7250524 9.97648083,9.72718297 8.71794231,8.53886538 L7.04717308,9.62521154 C9.06194661,11.3700006 10.8411363,12.5664934 12.3847422,13.2146899 C14.4228927,14.0705575 18.0163376,15.1301608 23.1650769,16.3935 Z" id="Fill-17"></path>
+            <path d="M4.57875,11.2299231 L2.92990385,12.3018462 C2.98759615,12.3612692 3.04009615,12.423 3.09951923,12.4818462 C7.31625,16.6985769 12.5743269,17.9949231 17.6599038,19.2485769 C22.0641346,20.3337692 26.2543269,21.3687692 29.7989423,24.1581923 L31.4893269,23.0591538 C27.4958654,19.6968462 22.7385577,18.5158846 18.1214423,17.3781923 C13.1206731,16.1453077 8.39567308,14.9758846 4.57875,11.2299231" id="Fill-19"></path>
+            <path d="M1.07555769,14.5060962 C0.883442308,14.3139808 0.702865385,14.1184038 0.524019231,13.9216731 C-0.227711538,14.6745577 -0.139442308,15.9726346 0.80325,16.5853269 L6.50959615,20.2955192 C9.03536538,21.3409038 11.6765192,21.9945577 14.2738269,22.6349423 C18.3284423,23.6341731 22.2019038,24.5924423 25.5578654,26.9157115 L27.2834423,25.7930192 C23.4676731,22.9245577 19.0403654,21.8255192 14.7347885,20.7639808 C9.68382692,19.5189808 4.91267308,18.3432115 1.07555769,14.5060962" id="Fill-21"></path>
+            <path d="M19.6441154,28.8342692 C20.0243077,29.0188846 20.3998846,29.2133077 20.7691154,29.4221538 C21.2093077,29.5150385 21.6771923,29.4383077 22.0683462,29.1838846 L23.0260385,28.5613846 C19.9493077,26.5035 16.5287308,25.461 13.1196923,24.5927308 L19.6441154,28.8342692 Z" id="Fill-23"></path>
+        </g>
+    </g>
+</svg>