AWS EKS中LoadBalancer Service运行正常但无法响应请求排查

从你的描述来看，核心矛盾点是**kubectl port-forward能正常访问，但集群内其他Pod和外部ELB无法访问**，结合你用gunicorn部署Django的场景，先从以下几个关键方向排查：

1. 检查gunicorn的绑定地址（最可能的根因） #

gunicorn默认会绑定127.0.0.1，这个地址只能容器内部访问，即使你暴露了9000端口，集群内其他Pod或ELB也无法连接到服务。

• 先进入运行中的Pod，查看gunicorn的启动命令：

  kubectl exec -it <你的Pod名称> -- ps aux | grep gunicorn
  

• 如果输出里是类似gunicorn --bind 9000 ...或者没指定--bind参数，那就是绑定了127.0.0.1，必须修改启动命令为：

  gunicorn --bind 0.0.0.0:9000 你的Django项目.wsgi:application
  

• 你可以通过修改Dockerfile的CMD/ENTRYPOINT，或者在Deployment的容器配置里添加command参数来调整这个设置。

2. 验证容器内端口监听状态 #

确认gunicorn确实在监听容器的所有网络接口（0.0.0.0）：

kubectl exec -it <你的Pod名称> -- netstat -tulpn
# 如果容器没装netstat，用ss命令替代
kubectl exec -it <你的Pod名称> -- ss -tulpn

输出里应该能看到0.0.0.0:9000的监听记录，如果是127.0.0.1:9000，那就是绑定范围的问题，必须改成0.0.0.0。

3. 确认Service与Pod的关联状态 #

虽然你提到集群内能获取到服务地址，但还是快速验证下Service是否正确关联到Pod：

kubectl describe service api

在输出的Endpoints部分，应该能看到你的Pod IP和9000端口（比如10.xx.xx.xx:9000）。如果这里是空的，说明Service的selector和Pod标签不匹配，但从你的配置看app:api和type:web是匹配的，大概率不是这个问题，但可以快速排除。

4. ELB健康检查的后续验证 #

当gunicorn绑定正确后，ELB的健康检查应该会自动恢复正常——因为此时ELB能访问到Pod的9000端口。如果还是有问题，可以检查：

• 确认Deployment的containerPort和Service的targetPort都是9000（你的配置里是对的）
• 如果Django根路径/不返回200状态码，可能需要给ELB配置自定义健康检查路径（比如添加一个/health的健康检查视图）

总结 #

最可能的原因就是gunicorn没有绑定到0.0.0.0，导致只有容器内部能访问服务。修改启动命令后重新部署，集群内访问和ELB健康检查应该都会恢复正常。

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