minikube环境下Pod访问Service连接超时问题原理咨询

核心根因 #

两个故障案例的本质都是 Pod内没有进程监听Service配置的targetPort端口，Service转发的流量到Pod后没有进程响应，所以返回连接超时。你测试用的Nginx Pod能正常访问，就是因为Nginx镜像默认启动后会自动监听80端口，符合Service转发要求。

分场景具体原因 #

• strongswan应用故障：你的Deployment配置中用command和args覆盖了镜像的默认启动逻辑，实际容器内只运行了while true; do sleep 30; done;死循环，没有启动strongswan业务进程，自然没有进程监听80端口，流量到Pod后直接无响应。
• godart应用故障：你的Dockerfile基于systemd基础镜像构建，只安装了godart的rpm包，没有配置godart服务的systemd自启规则，容器启动后systemd不会自动拉起godart进程，9020端口无进程监听，访问自然超时。

Node.js脚本临时修复的原理 #

你运行的Node.js脚本主动在Pod内监听了对应Service的targetPort端口（godart案例中为9020，修改监听端口为80也可修复strongswan的问题），此时Service转发过来的流量有进程接收响应，所以curl访问就恢复正常了，本质是补了「端口无进程监听」的缺失环节。

后续同类问题排查建议 #

• 先进入故障Pod执行ss -tulnp命令，确认Service配置的targetPort端口是否有进程监听
• 检查Deployment的command/args配置是否覆盖了镜像默认的业务启动逻辑
• 基于systemd的业务镜像，必须手动配置业务服务的自启规则，确保systemd启动后能自动拉起业务进程

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