从一次线上网络排查实战，逆向拆解K8s Service与Pod通信的完整路径（含tcpdump抓包分析）

那天凌晨3点，监控系统突然报警：核心业务服务的成功率跌至85%。登录Dashboard后发现，某个Deployment下的Pod虽然显示"Running"，但通过Service访问时出现间歇性超时。作为值班SRE，我必须在15分钟内定位问题——这不仅仅是一次故障修复，更是理解Kubernetes网络底层原理的绝佳机会。

1. 故障现象与初步诊断

当接到"Service无法访问后端Pod"的报警时，首先需要确认故障范围。通过以下命令快速验证基础连通性：

# 验证Service端点是否正常
kubectl get endpoints my-service -o wide

输出显示Endpoint列表非空，但部分IP存在连接超时。此时立即想到三个排查方向：

1. Pod内部状态 ：应用是否真实健康？
2. 网络中间层 ：kube-proxy规则是否正确？
3. 底层网络 ：节点间路由是否畅通？

使用 tcpdump 在目标Pod所在节点抓包，发现一个关键现象：

# 在Pod所在节点抓取eth0流量
tcpdump -i eth0 host <pod_ip> -vv

抓包结果显示SYN包能到达Pod网卡，但未见到ACK响应。这排除了CNI插件和节点间网络的问题，将焦点收缩到Pod内部。

关键提示：当Service访问异常时，首先通过 kubectl describe svc 确认Endpoint状态，再逐层向下排查，避免在错误方向上浪费时间。

2. 深入kube-proxy的流量转发机制

Kubernetes的Service本质上是kube-proxy维护的虚拟IP。通过分析iptables规则，可以还原流量转发路径：

# 查看kube-proxy生成的iptables规则链
iptables-save | grep my-service

典型输出示例：

-A KUBE-SERVICES -d 10.96.1.2/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-XXXXXX
-A KUBE-SVC-XXXXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-YYYYYY 
-A KUBE-SVC-XXXXXX -j KUBE-SEP-ZZZZZZ

每条规则的关键含义：

规则链	作用	典型跳转目标
KUBE-SERVICES	入口规则匹配	指向对应Service链
KUBE-SVC-XXXXXX	负载均衡逻辑	通过probability实现随机分发
KUBE-SEP-YYYYYY	终结点规则	执行DNAT转换到Pod IP

当发现某条SEP规则流量异常时，使用 conntrack 工具跟踪连接状态：

conntrack -L -d <pod_ip> | grep UNREPLIED

3. Pod网络命名空间深度排查

进入问题Pod的网络命名空间进行诊断：

# 获取目标容器的PID
docker inspect --format '{{.State.Pid}}' <container_id>

# 进入网络命名空间
nsenter -t <pid> -n bash

# 检查本地端口监听
netstat -tulnp

发现应用进程虽然存在，但监听端口与Service配置的targetPort不匹配。这解释了为何SYN包得不到响应——根本原因是Deployment更新后未同步Service定义。

4. 全链路数据包追踪实验

通过构造测试流量，完整还原数据包路径：

1. 客户端发起请求 ：

   curl http://<service_ip>:80
   

2. 在Service节点抓包 ：

   tcpdump -i any host <service_ip> or host <pod_ip> -w service_node.pcap
   

3. 在Pod节点抓包 ：

   tcpdump -i cni0 host <pod_ip> -w pod_node.pcap
   

对比两个抓包文件的时间戳和序列号，可以清晰看到：

• 客户端 → Service IP：原始请求
• Service节点执行DNAT后 → Pod IP：转换后流量
• Pod响应 → 客户端：经过SNAT的返回路径

5. 典型故障模式与解决方案

根据实际运维经验，Service与Pod通信问题通常集中在以下几类：

故障类型	诊断方法	解决方案
Endpoint缺失	kubectl describe svc	检查Label Selector匹配
网络策略拦截	kubectl get networkpolicy	调整Ingress规则
kube-proxy异常	journalctl -u kube-proxy	重启kube-proxy组件
容器端口未监听	nsenter 进入命名空间检查	修正容器端口配置
节点负载过高	top 查看CPU软中断	优化节点资源分配

对于本文的案例，最终发现是滚动更新时旧版本Pod未正常终止，导致Service将流量路由到已停止响应的Pod。通过调整 terminationGracePeriodSeconds 和增加Readiness探针解决了问题。

6. 高级诊断工具链推荐

除基本命令外，以下工具能显著提升排查效率：

• kubectl-debug ：直接向Pod注入诊断容器
• cilium connectivity test ：网络连通性自动化测试
• kubectl-trace ：在集群节点执行BPF程序
• Weave Scope ：可视化网络拓扑

例如使用cilium进行连通性测试：

cilium connectivity test --namespace my-app

这些工具的组合使用，能将平均故障修复时间(MTTR)降低60%以上。