-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Ingresses with auth-url annotation add authentication configuration to default backend. #5995
Comments
Do you see this behavior consistently? We are seeing slightly different behavior, but might be the same bug. If we have for example 5 different |
@kd7lxl I was able to see it consistently with 1 pod, depending on the order I created the ingresses. I didn't try with multiple pods. But I think we are seeing the same issue... perhaps we could get some input from the ingress-nginx team. |
Hi @aledbf, I was wondering if you to take a look at this. The problem seems to be that if you have multiple ingresses with the same host and different annotations, the annotations are copied from whichever ingress is processed first. This change came in 0.23.0 with #3696 The indeterminate nature of this seems undesirable. I am happy to take a stab at a solution, but I'm not sure what the desired behavior is. Here is the current location of the problematic code Thankfully, it seems I can get around the issue and bring back determinate behavior, if I add another ingress for the host without the annotations, with a path of
cc @kd7lxl , hope this helps with your issue! |
Yes, thanks. We've been using this exact workaround. I alluded to it in my comment above but didn't share an example as good as yours. I also added some alerting so we can catch new instances of this bug quickly and contact the associated team. Here's the query. Values greater than one are bad. |
@kd7lxl I reread your comment, and you were perfectly clear -- if I'd taken the time to read closely. Alas, time seems to run shorter every day. Also, that is a great Prom query, thanks for sharing! |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-contributor-experience at kubernetes/community. |
@fejta-bot: 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. |
NGINX Ingress controller version: v0.34.1
We saw this when we tried to upgrade from v0.22.0 It appears in v0.34.1, but I was able to reproduce the issue starting in v0.23.0.
Kubernetes version (use
kubectl version
): 1.18.3 (also seen in 1.16.8)Environment:
uname -a
): Linux minikube 4.19.114 Basic structure #1 SMP Mon Jul 6 11:11:02 PDT 2020 x86_64 GNU/LinuxWhat happened:
When upgrading ingress-nginx and using an ingress with
nginx.ingress.kubernetes.io/auth-url
, we would see the default backend get an auth configuration that we did not expect. It added alocation = /_external-auth-Lw {
block and the following lines tolocation / {
:it seemed nondeterministic (sometimes it was there, sometime it wasn't), but I was able to reproduce it by adding the ingresses in a certain order.
What you expected to happen:
I expected the default backend to remain the same when I added an ingress.
How to reproduce it:
Install minikube/kind
Install the ingress controller
Install an application that will act as default backend (is just an echo app)
Create two ingresses
get rendered nginx template
delete ingresses and recreate in opposite order
get rendered nginx configs
diff nginx configs:
Anything else we need to know:
Happy to help reproduce. I have the above steps saved in a gist: https://gist.github.com/davidnortonjr-sps/d9f5c67dfff3d83a3b78bca6d3f8da2f
/kind bug
The text was updated successfully, but these errors were encountered: