-
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 Nginx Ingress Controller fails to start on EKS Node #9230
Comments
@PhilipBehrenberg: 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. |
/remove-kind bug |
The default install has the exact same issue. By default install I assume you mean the one that is to just run the following command:
I have a bunch of other pods running without any issue. They are able to communicate with each other, even across separate nodes in different AZ. The DNS is also working as expected. |
Then please post the error messages and other logs. Thanks. |
All of my logs and everything are in the original post. Running the default install failed in the exact same way, same error everything. |
/assign @strongjz |
I have the same issue. For me, it starts failing on |
In case this is helpful to someone else. I was having this exact issue with DOKS. In my case the reason was using This was causing the health checks to fail due to a missing node address. Specifically, the value of
Simply turning it off with
|
This is 2 years old and lots of users are currently using the controller on EKS without this failure. In any case the version of the controller reported is not supported anymore and AWS now requires the install of the AWS LoadBalancer Controller along with AWS specific annotations set during the install. This issue is adding to the open issues count without a action item so I will close it for now. Please use the latest release of the controller as documented in the Deployment docs and ensure to open required ports and match the standard OS config as required by K8S. Then post all the info asked in the issue description by editing out th eold info and pasting the new test info.Then reopen the issue if you are still tracking this. Else it can remain closed. It will help us reduce the count of real issues being tracked with action items. thnaks /close |
@longwuyuan: 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-sigs/prow repository. |
What happened:
Ingress Controller pods error on startup and enter CrashLoopBackOff. This system is running on EKS on customized versions of the official AWS EKS nodes.
Ingress Controller Pod Logs
What you expected to happen:
The ingress controller pods should start up and enable incoming connections from the NLB that was created by the inrgess-nginx.
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
Kubernetes version (use
kubectl version
):Environment:
uname -a
): Linux 5.4.209-116.367.amzn2.x86_64 Basic structure #1 SMP Wed Aug 31 00:09:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linuxstig-build-linux-high
ingress-nginx ingress-nginx 1 2022-10-27 23:40:51.1602531 +0000 UTC deployed ingress-nginx-4.3.0 1.4.0
Ingress Controller Values File
Describe IngresClass
Describe All
Describe Svc
How to reproduce this issue:
This is only happening in 1 of 3 environments that, as far as I can tell are the same. The environment itself is somehow causing this issue. This happens with every helm install I've done in this environment.
Additional Information:
The chart is successfully creating all of the NLB pieces, the only piece that's failing is the IC pods.
The permissions on the
/etc/resolv.conf
are different in this pod then they are in the pod in the other environements this has worked correctly in:The text was updated successfully, but these errors were encountered: