链路概览
集群内一次访问要穿过五道关：DNS 把域名解析成 ClusterIP，报文到达这个虚拟 IP，所在节点的 kube-proxy 规则把它改写成一个具体后端 Pod 的地址，内核 conntrack 记录会话以便后续同连接复用，最后 Pod 内的进程在监听端口上接收。适用平台是 Kubernetes。把这五步记住，排查「服务不通」就能按层收敛，而不是在几十个对象之间乱翻。
基本信息
| 涉及对象 | Service、EndpointSlice、kube-proxy 规则、conntrack、Pod 内监听进程 |
|---|---|
| 适用平台 | Kubernetes，ClusterIP 由节点侧转发实现 |
| DNS 记录 | <service>.<namespace>.svc.cluster.local |
| 重要区别 | 容器内访问 Service 与节点或外部访问是不同路径 |
典型使用场景
- 服务整体不可用：按层排查，先判断是解析、转发、后端还是监听问题
- 容器内通、外部不通：说明差异在入口控制器或节点网络，不在 Service 本身
- 刚做完 NetworkPolicy 变更：策略在选择器变更后会立即生效，容易被忽略
- Pod 直连正常、走 Service 不通：问题集中在虚拟 IP 与转发规则
- 复盘故障：用这条链路给非网络同事解释影响范围
按层排查的命令对应
按层排查的命令对应
kubectl exec -it web-x -- nslookup web.prod.svc.cluster.local # 1 DNS 能否解析
kubectl get svc web -n prod -o wide # 2 Service 端口与选择器
kubectl get endpoints web -n prod # 3 后端是否存在
kubectl get pod -l app=web -n prod # 4 后端是否就绪
kubectl exec -it web-x -- netstat -tlnp # 5 容器内是否在监听
kubectl get networkpolicy -n prod # 6 策略是否拦截断开在哪一层
| 表现 | 断点层 | 下一步 |
|---|---|---|
| 域名解析失败，IP 直连正常 | DNS 层 | 查 CoreDNS 与 resolv.conf |
| ClusterIP ping 不通但 TCP 能连 | 正常现象 | 虚拟 IP 只处理转发，不响应 ICMP |
| 端口连不上但端点存在 | 转发或后端监听 | 核对 targetPort 与容器监听端口 |
| 偶发失败且并发高 | conntrack 或后端容量 | 查会话表与资源水位 |
| 策略变更后全断 | NetworkPolicy | 核对策略的选择器与端口 |
层次化排查能把「服务不通」快速收敛到 DNS、转发、后端、应用监听四类问题之一，比反复重启组件有效得多。
ClusterIP 是虚拟地址，ping 不通属正常现象，判断连通性要使用 TCP 层工具（curl、nc、telnet）。