mirror of
https://github.com/fluxcd/flagger.git
synced 2026-04-15 06:57:34 +00:00
Alejandro Pedraza
7242fa7d5c
In Linkerd 2.13 the Prometheus instance in the `linkerd-viz` namespace is now locked behind an [_AuthorizationPolicy_](https://github.com/linkerd/linkerd2/blob/stable-2.13.1/viz/charts/linkerd-viz/templates/prometheus-policy.yaml) that only allows access to the `metrics-api` _ServiceAccount_. This adds an extra _AuthorizationPolicy_ to authorize the `flagger` _ServiceAccount_. It's created by default when using Kustomize, but needs to be opted-in when using Helm via the new `linkerdAuthPolicy.create` value. This also implies that the Flagger workload has to be injected by the Linkerd proxy, and that can't happen in the same `linkerd` namespace where the control plane lives, so we're moving Flagger into the new injected `flagger-system` namespace. The `namespace` field in `kustomization.yml` was resetting the namespace for the new _AuthorizationPolicy_ resource, so that gets restored back to `linkerd-viz` using a `patchesJson6902` entry. A better way to do this would have been to use the `unsetOnly` field in a _NamespaceTransformer_ (see kubernetes-sigs/kustomize#4708) but for the life of me I couldn't make that work... Signed-off-by: Alejandro Pedraza <alejandro@buoyant.io>
Flagger end-to-end testing
The e2e testing infrastructure is powered by GitHub Actions and Kubernetes Kind.
e2e workflow
- create local Kubernetes cluster with KinD
- build Flagger container and load the image in KinD
- install the service mesh or ingress provider
- deploy Flagger
- create test namespace, workloads and load tester
- test the canary initialization (port discovery and metadata)
- test the canary release (progressive traffic shifting, headers routing, mirroring, analysis, promotion, rollback)
- test webhooks (conformance, load testing, pre/post rollout)