Worker节点curl localhost/apple返回502 Bad Gateway问题排查
关于你的理解偏差
首先纠正一个小误区：你说Ingress Controller以DaemonSet部署在每个节点，localhost应该能正常解析，这部分前半段是对的——DaemonSet确实会在每个节点启动一个Ingress Controller Pod，但你遇到的502问题不是localhost访问Ingress Controller失败，而是Ingress Controller Pod本身无法连接到后端的上游服务（也就是日志里的http://172.17.0.8:5678/apple）。日志里的connect() failed (113: No route to host)已经明确指向了这个核心问题，和localhost解析Ingress Controller无关。
可能的问题根源（结合你的集群环境）
你的集群用了CentOS7、K8s 1.26、cri-dockerd和Calico CNI，大概率是以下几个方向出了问题：
Calico路由或网络策略阻塞
172.17.0.8是Docker默认网桥docker0的子网地址，但Calico作为K8s的CNI插件，正常情况下K8s Pod应该使用Calico分配的独立子网（一般不是172.17.x.x）。这说明后端服务Pod可能没走Calico网络，而是直接用了Docker默认网桥；或者Calico在worker节点的路由规则配置异常，导致Ingress Controller Pod无法访问这个后端地址。
你可以先进入worker节点的Ingress Controller Pod，执行ping 172.17.0.8或nc -zv 172.17.0.8 5678验证连通性。如果连不通，先检查Calico节点Pod状态：kubectl get pods -n kube-system -l k8s-app=calico-node，确保所有节点的Calico Pod都处于Running状态；再查worker节点的路由表ip route，看有没有到172.17.0.8所在子网的路由条目。CentOS7 firewalld拦截了Pod间通信
CentOS7默认开启firewalld，很可能worker节点的防火墙规则阻止了Ingress Controller Pod和后端Pod的通信。你可以临时关闭worker节点的firewalld（systemctl stop firewalld），再测试curl命令，如果恢复正常，那就是防火墙的问题。后续需要添加规则允许Calico子网和Docker网桥子网的通信，或者配置K8s集群所需的firewalld规则（比如开放VXLAN、BGP相关端口，以及Pod间IP通信）。后端服务Pod的网络配置异常
先查后端Pod的实际IP：kubectl get pods -o wide，看是不是172.17.0.8。如果是的话，说明这个Pod没有使用Calico CNI，而是用了Docker默认网络——这在K8s集群里是不正常的，K8s应该通过CNI统一管理Pod网络。你可以检查这个Pod的YAML配置，看有没有设置hostNetwork: true或者其他异常网络参数；也可以检查cri-dockerd的配置，确保它正确关联了Calico作为CNI插件。Ingress或Service配置问题
确认Ingress资源的后端Service是否正确指向了目标Pod，再查Service的Endpoints状态：kubectl get endpoints <your-service-name>。如果Endpoints里没有172.17.0.8:5678，那Ingress Controller可能拿到了错误的上游地址，但从日志看已经有这个地址了，所以这个可能性相对较低。
快速排查步骤
- 进入worker节点的Ingress Controller Pod：
kubectl exec -it <ingress-pod-name> -n <ingress-namespace> -- sh - 执行
wget -O - http://172.17.0.8:5678/apple，验证是否能获取到内容 - 如果不行，在worker节点上执行
ping 172.17.0.8，看节点层面能不能连通 - 查看Calico节点Pod的日志：
kubectl logs <calico-node-pod-name> -n kube-system，排查路由相关错误 - 检查worker节点的firewalld规则：
firewall-cmd --list-all，确认是否允许Pod子网的通信
内容的提问来源于stack exchange，提问作者curious_brain
