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
kube-inject: support XDS address directly #29270
Comments
cc @esnible any thoughts? I will probably put this on UX agenda |
@howardjohn Makes sense. Just to confirm, the plan is to read the MutatingWebhookConfig, and proxy a call as if Kube API did it, using the caBundle? Will the Istiod user always have the ability to read the webhook config and caBundle? |
well, technically they can have whatever permissions they want - including lack of configmap permissions. But I don't see why |
Maybe revision is not needed since we have the revision as part of the URL |
Thanks @howardjohn, this makes sense and aligns with users need to specify XDS discovery address for certain istioctl cmds when interacting with remote clusters. |
@carolynhu are you working on this? if not please let us know so we can find someone |
Currently,
kube-inject
has 3 modes:--injectConfigMapName
This leads to our multicluster install needlessly installing these configmaps in the remote cluster, which is complex, confusing for users, and likely to fall out of sync.
Additionally, none of these support revisions.
I propose we make these changes:
Deprecate (2)
Re-implement (1) to call the Istiod service, rather than reading the configmaps (ie implementation details)
This will be done by reading the mutating webhook configurations. If its a Service, we will do a port-forward, and call /inject. If its a URL (external istiod), we will call it directly.
An additional flag, like
--injection-url
will be added, to not look at webhook configs.If there are no webhooks and
--injection-url
is not set, we will continue to use configmaps and display a deprecation warningAn additional flag,
--revision
will be added. When this is set, we will look at the revision webhook rather thanThe text was updated successfully, but these errors were encountered: