服务访问不通的两种形态
服务访问不通有两种表现，指向完全不同的层次：连接被拒绝通常是目标端口没有进程监听或服务没有可用端点；连接超时则多为链路被策略或路由拦截。先分清属于哪一种，后续排查才有方向，否则会在错误的层次上浪费时间。
基本信息
| 连接被拒绝 | 目标端口无监听，或服务没有可用端点 |
|---|---|
| 连接超时 | 链路被网络策略、安全组或路由黑洞拦截 |
| 跨命名空间 | 确认服务名写法与策略双向放行 |
| 验证工具 | 临时排查容器里的 nc 与 dig 双验证 |
| DNS 先行 | 解析失败与网络不通的报错相似，先分清 |
| 方向性 | 单向放行不等于双向可达 |
现象与层次
| 现象 | 所在层次 | 下一步 |
|---|---|---|
| 连接被拒绝 | 服务或端点 | 查端点与容器是否在监听 |
| 连接超时 | 网络策略或路由 | 查策略、安全组与网段路由 |
| 解析失败 | DNS | 查解析链路与搜索域 |
| 间歇失败 | 负载或连接数 | 看后端健康与连接池配置 |
| 只有部分 Pod 失败 | 节点或策略差异 | 对比失败与正常 Pod 的节点 |
排查命令
排查命令
kubectl run tmp --rm -it --image=nicolaka/netshoot -- sh # 起临时排查容器
# 容器内依次执行：
dig +short db.dev.svc.cluster.local # 先确认解析
nc -vz db.dev 3306 # 再确认端口可达
curl -m 5 -sS http://web.dev/ # 最后确认应用响应
kubectl get endpoints db -n dev # 端点是否为空
kubectl get networkpolicy -n dev # 是否有策略拦截典型使用场景
- 新服务上线后调用方报超时，需要判断是解析、策略还是后端问题
- 跨命名空间调用失败，服务名写法与策略都可能有问题
- 部分 Pod 能通、部分不通，怀疑节点或策略不一致
- 业务告警前的连通性验证，避免把问题带到业务层
网络策略通常是命名空间级默认放行：只加一条允许规则不会拒绝其他流量，要默认拒绝必须显式声明拒绝全部的策略。
端点为空时同样表现为连接被拒绝或超时：先用端点状态确认后端是否真的注册上了，这一步最容易被跳过。
连接被拒绝多数不是防火墙问题，而是没有后端在监听端口；方向搞反会一直在网络层绕圈。