"failed calling webhook" error when creating namespace #147
Comments
|
Thanks for registering this issue @yogeek! I am experiencing the same behavior, and it is kinda expected. The excluded/included namespaces in HNC are processed by the webhook server in HNC. The namespace webhook in HNC is configured to fail closed, as it must be, so when the webhook endpoint is not available any namespace API request in the cluster will fail. 😞 I wonder if kubernetes/kubernetes#92157 (comment) can be used to improve the processing of the included/excluded namespace configuration in HNC? That will allow the API server to be aware of the namespace configuration in HNC. WDYT @adrianludwin? It will only be supported on K8s 1.21+, but should work as now on earlier versions.... |
|
Sorry the for delay in responding. This seems a bit weird to me because starting in HNC v0.9, the webhooks shouldn't touch any namespace that doesn't have the With that said, if this is happening during an update, that might make a lot more sense since the label will already be present. We're working on making the webhooks highly available which should help here, but we're not there yet. In the meantime, perhaps you could install the HNC webhooks as the last step in the pipeline? Simply take them out of the original manifest, wait for everything else to be installed (which, incidentally, will give HNC some time to start up) and then install the webhooks last? |
|
Oh wait, my bad - only the object webhook is restricted to certain namespaces. The webhook namespace operates over all namespaces. I agree that kubernetes/kubernetes#92157 (comment) could be used to improve this. |
|
Hmm, does HNC need to do anything to make this better? E.g. if you're using K8s 1.21+, you can simply modify the webhook manifests yourself to exclude the namespaces you want HNC to ignore. |
As a user, I would expect the |
|
They're not quite the same thing, since HNC enforces its own rules *on* the
namespaces (e.g. it prevents them from being arranged into hierarchies), it
just doesn't enforce policies *in* the namespace (i.e. the object
validator). Plus, even if it didn't work that way, there could be a period
of time during which the exclusion labels haven't yet been added to the
namespace, but the validator isn't awake yet.
IMO modifying the webhook config is far more understandable and
exponentially less work :)
…On Wed, Mar 16, 2022 at 7:08 PM Erik Godding Boye ***@***.***> wrote:
Hmm, does HNC need to do anything to make this better? E.g. if you're
using K8s 1.21+, you can simply modify the webhook manifests yourself to
exclude the namespaces you want HNC to ignore.
As a user, I would expect the excluded-namespace flag supplied to HNC to
fix this, but that might be a bit complicated to implement? 🤔
—
Reply to this email directly, view it on GitHub
<#147 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE43PZAJFVSF45M2ZWVBKPLVAJSWZANCNFSM5OVIFPMQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
lifecycle/rotten
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
When I create a K8S cluster, some addons are deployed with Jenkins (kubectl, kustomize or helm...) and others with argocd (we are currently migrating our addons deployment to argocd progressively)
The script installing external-dns is failing at the step of the namespace creation with this error :
If I launch the pipeline again, all is ok.
I guess this is because the webhook of HNC was not ready yet when the creation of namespace was executed...
Is it normal that commands like
kubectl create ns external-dnsfail whereas I explicitely added--excluded-namespace=external-dnsto exclude this namespace from the HNC scope ?The text was updated successfully, but these errors were encountered: