Kube-Hetzner项目中NGINX Ingress连接被拒绝问题分析与解决方案

问题背景

在使用Kube-Hetzner项目部署Kubernetes集群时，用户遇到了NGINX Ingress控制器无法连接到后端服务的问题。具体表现为访问应用域名时返回502 Bad Gateway错误，NGINX日志显示"connect() failed (111: Connection refused)"。

错误现象分析

从日志中可以清晰地看到以下关键信息：

1. 客户端请求被正确路由到了app.abcdefg.com
2. Ingress控制器尝试将请求代理到http://10.42.5.5:3000/
3. 连接被目标Pod拒绝(Connection refused)

配置检查

用户提供的配置显示：

1. Service配置正确，将80端口映射到Pod的3000端口
2. Ingress配置正确，将主机名app.abcdefg.com路由到Service的80端口
3. TLS证书配置正常，使用了cert-manager进行管理

根本原因

经过深入分析，发现问题实际上出在应用容器本身：

1. 应用Pod虽然运行在3000端口，但容器可能没有正确监听该端口
2. 或者防火墙规则阻止了对3000端口的访问
3. 也可能是应用启动时绑定到了127.0.0.1而非0.0.0.0

解决方案

1. 验证容器端口：

   • 使用kubectl exec进入Pod，检查应用是否真正监听在3000端口
   • 使用netstat -tuln或ss -tuln命令查看监听端口

2. 检查应用绑定地址：

   • 确保应用绑定到0.0.0.0而非127.0.0.1
   • 修改应用配置，使其接受外部连接

3. 验证容器网络策略：

   • 检查是否有NetworkPolicy阻止了Ingress控制器到Pod的连接
   • 确保命名空间中没有限制流量的策略

4. 临时测试方法：

   • 创建临时busybox Pod测试是否能从集群内部访问服务
   • 使用curl直接访问Service ClusterIP验证连通性

经验总结

1. 在Kubernetes环境中，502错误通常表示Ingress控制器与后端Pod之间的连接问题
2. 完整的连接路径需要检查：
   • Ingress配置 → Service → Endpoints → Pod端口 → 容器实际监听
3. 建议采用自下而上的排查方法：
   • 先确认容器内应用运行正常
   • 再验证Service到Pod的连通性
   • 最后检查Ingress配置

最佳实践建议

1. 在部署前使用kubectl port-forward测试应用是否可访问
2. 为应用添加就绪探针，确保完全启动后再接收流量
3. 在容器中暴露健康检查端点，便于诊断
4. 使用kubectl describe service和kubectl get endpoints验证服务发现

通过这种系统化的排查方法，可以快速定位和解决Kubernetes环境中的网络连接问题，确保应用的高可用性。