Kubernetes集群Ingress突发502错误求助（含failed_to_pick_backend日志）

这种运行稳定2-3周后突然爆发Ingress 502的情况确实挺蹊跷，我之前处理过几例类似的问题，结合你提到的failed_to_pick_backend报错，给你几个针对性的排查方向：

• 优先检查后端Service的端点状态
  failed_to_pick_backend最直接的原因是Ingress匹配到路由规则后，找不到可用的后端Pod端点。你可以先执行：

  kubectl get endpoints <你的服务名称> -n <对应命名空间>
  

  看看输出里的ADDRESSES字段是不是包含所有正常运行的Pod IP。有时候Pod状态显示Running，但就绪探针（readinessProbe）临时失败（比如应用内部GC卡顿、数据库连接池耗尽），会导致Pod被从Service的端点列表中剔除，Ingress自然找不到后端。同时可以去Ingress Controller的Pod日志里搜索具体的服务名称，确认是哪个Service出了问题。

• 排查Ingress Controller的资源瓶颈
  运行几周后很容易出现内存泄漏或连接数耗尽的情况，尤其是Nginx Ingress这类基于反向代理的控制器。你可以用以下命令查看资源占用：

  kubectl top pods -n <Ingress控制器所在命名空间>
  

  如果内存占用持续走高，可能是日志未配置轮转、或者某些自定义annotation导致的内存泄漏。另外检查TCP连接数：

  kubectl exec -n <Ingress命名空间> <Ingress Pod名称> -- netstat -an | grep ESTABLISHED | wc -l
  

  如果连接数远超预期（比如上万甚至十几万），可以调整Ingress Controller的worker-processes参数，或者缩短proxy-connect-timeout、proxy-read-timeout这类超时配置，避免连接堆积。

• 验证Ingress Controller与后端Pod的连通性
  即使端点存在，也可能因为网络策略、主机防火墙或者CNI插件的问题导致Ingress Controller无法访问Pod。你可以进入Ingress Controller的Pod，直接telnet后端Pod的端口测试：

  kubectl exec -it -n <Ingress命名空间> <Ingress Pod名称> -- telnet <Pod IP> <服务端口>
  

  如果不通，检查集群内的NetworkPolicy有没有新增规则，或者主机节点的iptables/ipvs配置是否异常。另外也要确认CNI插件（比如Calico、Flannel）的Pod状态是否正常，有没有网络波动。

• 排查隐性的配置变更
  你说集群和Pod没有手动更新，但要注意几个隐性变更的可能：

  • Ingress Controller是否使用了latest镜像？可能后台自动拉取了新版本，导致配置兼容问题；
  • 有没有其他团队或自动化工具修改了Ingress资源的annotation？比如误加了nginx.ingress.kubernetes.io/whitelist-source-range这类限制规则；
  • CoreDNS的缓存是否异常？可以在Ingress Pod里ping一下Service名称，看能不能正常解析到ClusterIP。

如果是Nginx Ingress Controller的话，还可以查看它生成的Nginx配置文件，确认路由规则和后端映射是否正确：

kubectl exec -n <Ingress命名空间> <Ingress Pod名称> -- cat /etc/nginx/nginx.conf | grep -A 10 <你的域名>

希望这些方向能帮你定位到问题！

内容的提问来源于stack exchange，提问作者Amidii