minikube访问nginx-thrift/media-frontend提示192.168.49.2拒绝连接

• social-network命名空间下nginx-thrift、media-frontend对应的Pod均显示正常运行状态
• 执行命令minikube -n social-network service --all查询命名空间下所有服务地址，可返回nginx-thrift、media-frontend、jaegar-out三个服务的访问URL
• 实际访问验证结果：jaegar-out服务可正常打开Jaeger UI，但访问nginx-thrift、media-frontend的URL时，浏览器提示192.168.49.2 refused to connect连接被拒绝错误

1. 校验Service端口与容器实际监听端口是否匹配 #

这是最高发的诱因：jaeger服务端口配置正确所以访问正常，剩下两个服务如果Service定义里填的targetPort和容器内进程实际监听的端口不一致，kube-proxy会把请求转发到根本没有服务监听的端口，直接触发连接拒绝。

• 排查操作：
  先查询两个服务的端口配置：

  kubectl get svc -n social-network nginx-thrift media-frontend -o yaml | grep -A 10 ports
  

  再查询对应Pod内容器实际监听的端口，把命令里的占位符替换成实际Pod名即可：

  kubectl exec -n social-network <nginx-thrift对应Pod名> -- netstat -tulpn
  kubectl exec -n social-network <media-frontend对应Pod名> -- netstat -tulpn
  

• 修复方案：如果两边端口不匹配，修改Service的targetPort字段，和容器实际监听端口保持一致，重新apply配置即可。

2. 检查服务进程的监听地址配置 #

如果容器内的Nginx、前端服务进程只绑定了127.0.0.1本地回环地址，Pod外部的请求（包括Service转发的流量）是无法访问到进程的，同样会返回连接拒绝。

• 排查方法：看上述netstat命令返回的监听地址列，如果对应服务端口绑定的是127.0.0.1就属于该问题。
• 修复方案：修改两个服务的配置文件，把监听地址从127.0.0.1调整为0.0.0.0，重新加载配置或者重启Pod即可生效。

3. 验证Minikube服务隧道是否正常 #

Minikube在使用虚拟机驱动（Windows/macOS环境默认）时，如果没有启动tunnel，NodePort类型的服务很容易出现端口不通的问题；如果jaeger刚好是LoadBalancer类型被tunnel正常覆盖，就会出现只有jaeger能访问的现象。

• 排查操作：新开一个独立终端窗口执行minikube tunnel，保持该进程持续运行不退出，再重新访问两个异常服务的URL，验证是否能正常连通。
• 修复方案：日常访问Minikube集群内的LoadBalancer、NodePort服务时，保持minikube tunnel进程后台运行即可。

4. 校验Pod内服务进程是否真的正常运行 #

部分场景下服务进程崩溃退出后，如果存活探针配置不合理，Pod状态会误显示为Running，但实际已经没有进程在监听对应端口。

• 排查操作：分别查看两个服务Pod的近期日志，排查是否有启动报错、进程崩溃记录：

  kubectl logs -n social-network <nginx-thrift对应Pod名> --tail=100
  kubectl logs -n social-network <media-frontend对应Pod名> --tail=100
  

• 修复方案：根据日志输出的报错信息修复问题，常见的报错包括配置文件语法错误、依赖服务连接失败、文件权限不足等，修复后重启Pod，验证端口正常监听即可。

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