-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Better support for Helm installs #11341
Comments
This issue is currently awaiting triage. If Ingress contributors determines this is a relevant issue, they will accept it by applying the The 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. |
One example of handling this use-case shows how to simplify the use instead of changing the controller code ;
This example shows not one but multiple charts integration, instead of trying to change the chart itself |
Thanks - this doesn't address the original question which is - how to prevent the webhook from rejecting ingresses when the ingress references a secret created by a job and both the ingress AND the job are deployed in one helm chart. |
This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach |
Throwing support in for this issue - when bootstrapping new clusters this is a problem I come across frequently where a helm install leaves ingress-nginx in a bad state and prevents our gitops solution from properly bringing up clusters. Looking into manual alternatives now to solve the problem, but would prefer to be able to use the chart as intended. |
All - is there any way to elevate this? Thanks! |
Current status is acute shortage of developer time resources and a pivot to improving security as well as focus on sticking closer to the KEP of the Kubernetes Ingress API specs. I agree that having the kind of changes proposed in the description of this issue is extremely useful. But the instrumentation proposed in this issue is best suited as code that resides outside this project. While the changes would help the use case described, please do not expect any resources to be spent on making the kind of changes proposed here. |
When an application is installed from a Helm chart, Helm creates a list of manifests from the chart and simply sends the manifests into the cluster - leaving it to Kubernetes to handle. The following scenario doesn't currently allow the chart to successfully deploy because of the Nginx admission webhook:
Job
that creates aSecret
in the cluster.Ingress
with annotationnginx.ingress.kubernetes.io/auth-tls-secret: secret-created-by-job
.Job
manifest and theIngress
manifest go into the cluster at essentially the same time.nginx.ingress.kubernmetes.io/auth-tls-secret
annotation refs a secret that does not exist yet. And so the webhook rejects the ingress.I can think of a couple ways to address this:
If you think any of these approaches are valid I would be happy to look into submitting a PR. Thanks.
The text was updated successfully, but these errors were encountered: