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
Problems with validating webhooks install with the official chart #1819
Comments
It's looking for a name called |
Hi @unb9rn - how did you install Kyverno using Helm? Can you share the steps? |
@chipzoller yep, you were right, changing release name kinda solved this problem. Shouldn't it be fixed? Or documented at least? Hardcoding release name is counter-intuitive and required modifying my terraform script with helm =) |
@realshuting I am installing everything with terraform helm provider. First I am generating some random string to distinguish installs between projects and teams and make them unique, then I append it to resource name and to release name as well. Looks like Kyverno helm chart just waits for hardocded release name to generate hardocded svc name and then constructs OwnerReference by accesing this service... |
Yes, this has been a common pain point for many and needs to be resolved. Kyverno should not look for any hard-coded names in anything. |
Hi @unb9rn - sorry for the late response.
Can you point me to the exact names that were changed? We'll have to investigate how can Kyverno takes custom names, as webhook configurations are created with the certificate that has these Subject Alternate Names, including Kyverno service's name, namespace, and resource's name |
The deployment's name is now configurable after #2066. Closing this issue. |
Hello!
I am trying to instal 1.3.5 chart to a 1.19.7 Kubernetes cluster (It is a Yandex Cloud managed cluster)
After running helm install I am having a ns with loop-crashing Kyverno pod.
The only parameter I gave it was
nodeselector
parameter.Logs reading some problem with creating ValidatingWebhook:
And then it crashes...
Is it because it waits for some hardcoded deployment name?
The text was updated successfully, but these errors were encountered: