-
Notifications
You must be signed in to change notification settings - Fork 743
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Linkerd 2.13 #1417
Conversation
hey @alpeb, thanks for opening this PR! could you also bump the linkerd version used in the e2e tests (see |
I am thinking about how this change will impact users on Linkerd <= 2.11.x, since it looks like |
I would prefer to use the |
Thanks for all your feedback 👍 In my latest push I've changed the namespace to |
okay so tests are finally passing :))) |
Thanks for having taken care of that test! 😅 |
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>
Signed-off-by: Alejandro Pedraza <alejandro@buoyant.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! thanks @alpeb 🙇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks @alpeb
PS. @aryan9600 please make sure we document the breaking changes in the changelog, so people know they must delete the Flagger deployment from the linkerd namespace.
In Linkerd 2.13 the Prometheus instance in the
linkerd-viz
namespace is now locked behind anAuthorizationPolicy 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 newlinkerdAuthPolicy.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 injectedflagger-system
namespace.The
namespace
field inkustomization.yml
was resetting the namespace for the new AuthorizationPolicy resource, so that gets restored back tolinkerd-viz
using apatchesJson6902
entry. A better way to do this would have been to use theunsetOnly
field in a NamespaceTransformer (see kubernetes-sigs/kustomize#4708) but for the life of me I couldn't make that work...