-
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
Ingress controller created AFTER basic auth enabled results in 503 #1890
Comments
I have managed to track this down, and feel it is a bug. If i deleted all pods and brought them back up, none of them worked, and I was seeing this in the logs:
So i tried deleting and recreating the secret, but to no avail. I noticed in the generated nginx config:
but it is 100% there. The next thing i did was take the basic auth annotations out of my ingress, and this worked fine, requests started going through. So i added the annotations back in, and it started working fine (the secret was read fine). This is consistent and reproducible after a scale. Any pods created after the ingress was created have this issue and the only way to fix it is to disable and re-enable auth on the ingress definition. I hope these steps help you to debug the issue. I am using |
PS. This is a particularly big problem as when pods are re-scheduled, this error resurfaces. So I am unable to handle maintenance, cluster updates, or horizontal pod autoscaling. |
This is further exacerbated by pod failing a liveness check, then coming back up and returning 503 until i disable, then re-enable basic auth on the ingress definition:
Same thing:
|
@Stono in case of any problems with security annotations (like not finding the secrets) we return error 503 in the configured ingress to avoid allowing unrestricted access to the resource. |
@aledbf yes i am aware, but if you read through my post you see that the secret IS there, it has been there for over a day. Whenever a pod is restarted it fails to pickup this secret unless i disable and re-enable auth on the ingress |
@Stono please run |
|
And here is the behaviour:
If I delete the pod, and wait for it to recreate I see this in the logs:
And the site 503s:
If i edit the ingress to remove basic auth:
It works:
If i re-enable auth:
Auth works as expected:
Therefore this problem is when the pod is create after the ingress is configured to use basic auth |
Also confirmed this exists with I am running Kubernetes 1.8.5 on GKE |
@Stono please test Edit: and post the logs |
That worked! Here are the logs anyway:
|
@aledbf seeing this issue again with nginx ingress 0.17.1 - could it be that this bug is back again? |
For me the issue was - I've created the basic-auth key in the 'default' namespace, and my service was in another namespace, so it couldn't fetch the basic-auth key. |
Also make sure that the htpasswd auth file is actually named
|
Thank you very much!!!!!!!!!!!!!!!!!!!! :) |
Most Important thing :( |
Hi,
I have a strange problem where if i scale the ingress controller:
I get:
but requests going to the scaled pod 503:
requests that go to the other pod are fine:
The text was updated successfully, but these errors were encountered: