bind() to 0.0.0.0:8443 failed (98: Address in use) on EKS Fargate #7913
Comments
|
@timblaktu: 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. |
k8s-ci-robot
added
needs-triage
|
Answered in more detail in a different ticket. The problem is that port 8443 is the default port for the webhook, so you either need to also change the webhook port, or use a different port than 8443. |
|
/remove-kind bug |
k8s-ci-robot
added
needs-kind
|
The issue is unrelated to Fargate, the same configuration would have failed due to the command-line args shown. Note two things trying to listen on port 8443: |
|
Agreed
Thanks,
; Long
…On Sat, 13 Nov, 2021, 9:21 PM TBBle, ***@***.***> wrote:
The issue is unrelated to Fargate, the same configuration would have
failed due to the command-line args shown. Note two things trying to listen
on port 8443:
Args:
/nginx-ingress-controller
--publish-service=$(POD_NAMESPACE)/nginx-ingress-ingress-nginx-controller
--election-id=ingress-controller-leader
--controller-class=k8s.io/ingress-nginx
--configmap=$(POD_NAMESPACE)/nginx-ingress-ingress-nginx-controller
--validating-webhook=:8443
--validating-webhook-certificate=/usr/local/certificates/cert
--validating-webhook-key=/usr/local/certificates/key
--http-port=8080
--https-port=8443
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#7913 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABGZVWVWHYMFWR2BBTFXPG3UL2CPHANCNFSM5H532TYA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Thanks so much @TBBle, @longwuyuan - and sorry for the distraction - clearly this was cockpit error on my part, not understanding the innards of the ingress-nginx application and not being able to inspect the running container sufficiently. I finally have installed ingress-nginx on eks-fargate with the following values: |
NGINX Ingress controller version (exec into the pod and run nginx-ingress-controller --version.):
NGINX Ingress controller
Release: v1.0.4
Build: 9b78b6c
Repository: https://github.com/kubernetes/ingress-nginx
nginx version: nginx/1.19.9
Kubernetes version (use
kubectl version):Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.2", GitCommit:"8b5a19147530eaac9476b0ab82980b4088bbc1b2", GitTreeState:"clean", BuildDate:"2021-09-15T21:38:50Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.2-eks-0389ca3", GitCommit:"8a4e27b9d88142bbdd21b997b532eb6d493df6d2", GitTreeState:"clean", BuildDate:"2021-07-31T01:34:46Z", GoVersion:"go1.16.5", Compiler:"gc", Platform:"linux/amd64"}
Environment:
AWS / EKS / Fargate
(it's unclear what environment you're referring to)
the host/client I'm running terraform/aws cli/kubectl from is Amazon Linux.
uname -a):(it's unclear what environment you're referring to)
the host/client I'm running terraform/aws cli/kubectl from is:
Linux ip-10-94-189-201.ec2.internal 4.14.248-189.473.amzn2.x86_64 #1 SMP Mon Sep 27 05:52:26 UTC 2021 x86_64 x86_64 x86_64 GNU/LinuxEKS Cluster was created using this fork/branch of the terraform aws/eks module, and the following provider versions:
kubectl versionkubectl get nodes -o widewhere
helm/nginx-values.yamlcontains:These port values and
allowPrivilegeEscalation: falsewere set to work around this bug.helm ls -A | grep -i ingresshelm -n <ingresscontrollernamepspace> get values <helmreleasename>kubectl describe ingressclasseskubectl -n <ingresscontrollernamespace> get all -A -o widekubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>Current state of ingress object, if applicable:
n/A
Others:
n/A
What happened:
The Helm-installed ingress-nginx controller pod on fresh new Fargate-only EKS cluster perpetually fails liveness and readiness probes on startup.
What you expected to happen:
I expect the Helm-installed ingress-nginx controller pod to eventually get into a Running state, and then be able to function as an Ingress Controller and Load Balancer..
The pod logs indicate the controller application failed to bind to 0.0.0.0 (INADDR_ANY) port 8443:
It is expected that the controller application would be trying this port 8443 because that was specified in the values passed to the helm chart on installation.
I have confirmed that the address/port in question is indeed already bound. I'm able to execute
netstatcommand inside the running container as userwww-datato confirm indeed 0:8443 is already bound, but because I haven't yet figured out how to get root access, the PID/name of the processes are not available to me:How to reproduce it:
Install ingress-nginx pod via helm chart with the above values into EKS cluster with Fargate profiles. After helm install, just watch pod state and logs.
Anything else we need to know:
There are separate, dedicated Fargate profiles for
kube-system/corednsandingress.The VPC I'm installing the EKS cluster into has 3 public and 3 private subnets, and all 6 are passed to all Fargate profiles.
/kind bug
The text was updated successfully, but these errors were encountered: