-
Notifications
You must be signed in to change notification settings - Fork 8.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
Controller resolves default-backend pod IP as DNS name if Ingress leads to ExternalName service #12136
Comments
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-sigs/prow repository. |
The information you have provied is not clear.
|
/remove-kind bug |
I don't have LB in testing environment, I've added a NodePort just to make sure controller is up and running. Ingress-nginx services are not related to the problem. In fact, I've deleted every nginx svc beside admission (in ns ingress-nginx), issue persists. Because you don't have to have working frontend to reproduce it.
Ok, I've reinstalled ingress-nginx through helm quick start:
Not related, didn't do. We have a production environment with LBs where this issue does reproduce.
Sure. But removing
controller still tries to resolve pod IP. Note that I'm not even sending any requests into this ingress:
|
I can't understand your test |
The service created by the ingress-nginx controller is in a pending state
So the tests you conduct or the status you report is not valid. If you need more support on this, then kindly show a valid test related debug data, for someone to analyze. I will close this issue for now as we know that there are many users with service object of --type externalName. Once you have posted data with valid tests, then you can re-open this issue. /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:
If an ingress resource leads to service with type
ExternalName
, but also has annotationnginx.ingress.kubernetes.io/default-backend
with values set to a service with typeClusterIP
, ingress-nginx-controller tries to resolve pod IP of said ClusterIP service as a DNS name. I have attached manifests down in Others section.A lot of following errors are generated in
ingress-nginx-controller
logs.10.111.0.218
is IP of a pod for default-backend service:Seems that the ClusterIP service somehow matched with this condition https://github.com/kubernetes/ingress-nginx/blob/controller-v1.11.2/rootfs/etc/nginx/lua/tcp_udp_balancer.lua#L74-L79
What you expected to happen:
Ingress-nginx-controller
does not try to resolve IP addresses as DNS names.NGINX Ingress controller version v1.11.2
Kubernetes version: v1.27.16
Environment:
uname -a
): 5.15.0-122-generickubectl version
kubectl get nodes -o wide
helm ls -A | grep -i ingress
helm -n <ingresscontrollernamespace> get values <helmreleasename>
kubectl describe ingressclasses
kubectl -n <ingresscontrollernamespace> get all -A -o wide
kubectl -n <ingresscontrollernamespace> describe po <ingresscontrollerpodname>
kubectl -n <ingresscontrollernamespace> describe svc <ingresscontrollerservicename>
kubectl -n <appnamespace> get all,ing -o wide
kubectl -n <appnamespace> describe ing <ingressname>
If applicable, then, your complete and exact curl/grpcurl command (redacted if required) and the reponse to the curl/grpcurl command with the -v flag
Others:
kubectl describe ...
of any custom configmap(s) created and in useingress yaml:
externalName service:
ClusterIP service connected to pod that ingress-nginx tries to resolve as DNS:
the pod:
How to reproduce this issue:
dns_lookup(): failed to query the DNS server for 10.111.0.218
error.Anything else we need to know:
The text was updated successfully, but these errors were encountered: