-
Notifications
You must be signed in to change notification settings - Fork 1.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
linkerd-destination Failed to connect error=Connection refused (os error 111) #8943
Comments
I'd recommend upgrading to the latest stable 2.11.4. While I can't be sure, this does look like an issue that has already been fixed by linkerd/linkerd2-proxy#1670. If you continue to run into issues after upgrading we can work from there. |
Hi @kleimkuhler! Upgraded to 2.11.4. Still getting the issue (see below). Also, there are no controller.yaml and controller-rbac.yaml files in the 2.11.4 helm chart (comparing to v2.10.0). Are those separate?
Also, how can we fix the "the following nodes do not expose a podCIDR" issue? Thank you! |
@kleimkuhler v2.10.2 runs with no issues. |
@kleimkuhler |
@kleimkuhler We rolled back to v2.10.2. I haven't had a chance to do a deep dive. I was hoping someone from the linkerd team would have insights. @alan-kea |
This looks like a permissions issue with EKS. I had the same problem when trying to have the CP come up. |
@Tizull Could you please give more details on the permissions fix? |
@jesseadev i'm also having trouble with the "os error 111". In relation to your question: "Also, how can we fix the "the following nodes do not expose a podCIDR" issue?"
Thats how i got the green checkmark with "linkerd check". |
The fix that worked for me was to delete the "linkerd-destination-XXX" pod. |
@jesseadev sorry for the lack of updates on this issue. A reproduction would be helpful with narrowing down what's going on here; if you have manifests and a k8s environment that reproduces this easily I'd definitely be interested. Separately, the "the following nodes do not expose a podCIDR" warning was removed in favor or a less noisy check. You'll find this has changed on the most recent edges as well as the recently released It would be helpful to know if |
It would also be helpful to know if anyone on this thread has seen this result in control plane components failing to start properly. Or, does all the control plane Pods get up and running and While these logs can make it seem like there is a larger issue going on, if you're just seeing it at startup it very well could be that the DNS records have not been created yet for the other component Pods that are starting up. |
In my case all pods can start, are up and |
@h3nry-1 I'm a little confused by your comment; all Pods can start and In the case that this error is being returned at Pod startup, but eventually everything gets up and running, I'm thinking it could just be a race between other control plane Pods being created and therefore DNS entries don't exist yet. I'm not sure right now if there is any actual issue here if all the control plane Pods become healthy (without manual restarts) and |
@kleimkuhler Im sorry for my confusing comment but im still not quite sure why my errors occured or why they are gone. All pods can start up and 'kubectl get pod' shows 4/4 linkerd-destination, 2/2 linkerd-identity and 2/2 linkerd-proxy-injector pods. With 'kubectl logs linkerd-destination' the OS-Error 111 occured. After i manually deleted the linkerd-destination pod, the OS-Errors were gone from 'kubectl logs linkerd-destination'. I had some problems with reattaching my persistent Volumes in my K8s Cluster, maybe that was the problem in my case. I wish i could give you more insight in this regard. |
No problem h3nry-1. I'm going to close this out for now. I have some unanswered questions on here and it seems to me that this happens at startup but eventually the control plane components become healthy and If anyone on this issue does continue to see this problem and it leads to control plane components being stuck or the application not working correctly, I'd ask that you open a new issue with as much detail as you can provide. It feels better to start from a fresh issue on the latest stable rather than trying to piece together the comments on here. |
What is the issue?
linkerd-destination
Failed to connect error=Connection refused (os error 111) linkerd-proxy-injector [ 35.151685s] WARN ThreadId(01) outbound:server{orig_dst=10.100.0.1:443}:controller{addr=linkerd-dst-headless.linkerd.svc.cluster.local:8086}: linkerd_app_core::control: Failed to resolve control-plane component error=failed SRV and A record lookups: failed to resolve SRV record: no record found for name: linkerd-dst-headless.linkerd.svc.cluster.local. type: SRV class: IN; failed to resolve A record: no record found for name: linkerd-dst-headless.linkerd.svc.cluster.local. type: AAAA class: IN
How can it be reproduced?
Installing Linkerd on EKS (see versions below).
Logs, error output, etc
output of
linkerd check -o short
Environment
Possible solution
No response
Additional context
No response
Would you like to work on fixing this bug?
No response
The text was updated successfully, but these errors were encountered: