-
Notifications
You must be signed in to change notification settings - Fork 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
Upgrade to version 2.4.0 with "-disable-ipv6=true" cannot reach upstream. #3138
Comments
Thanks for reporting this @jppitout - we are investigating. |
Hi @jppitout, I am trying to reproduce the issue. Would you mind sharing your deployment config files and the generated NGINX conf file, please? |
Sure, see below: |
Hi @jppitout Thank you for your info. I was able to reproduce the issue. The command line argument works for virtual server and transport server as expected, but not for ingress resources at the moment. We will publish a fix soon. |
We merged a fix to the main branch and pushed a new image to Docker Hub. Please try to deploy again with the |
@jppitout can you please give us the full pod log along with deployment yaml? As I can see earlier your pod was starting but issue was in ingress. |
My apologies it is in fact working. There was indeed a change made to the deployment manifest for another test being performed. I can confirm this bug fix is working and the ingress controller is working as expected! |
Describe the bug
We've upgraded our nginx-ingress controller from version 2.1.2 to 2.4.0 and included the
-disable-ipv6=true
arg in our deployment manifest. TKGi clusters don't allow IPv6. (see also #2970)The nginx-ingress pods start but cannot reach any upstream pods. Connections fail with 404s.
We've set debugging to
-v=3
and configured log-format to:Which produces these logs:
On the pods themselves we're still seeing ipv6 listeners configured (along with IPv4 listeners):
To Reproduce
Steps to reproduce the behavior:
-disable-ipv6=true
argumentExpected behavior
kubernetes-ingress is able to communicate with upstream pods/services.
Environment
Additional context
See also #2970
The text was updated successfully, but these errors were encountered: