避坑指南：K8s Pod网络通信那些‘诡异’的故障，我是如何一步步排查的

原创于 2026-06-14 15:15:28 发布 · 346 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#Kubernetes #Pod #网络通信 #故障排查

ios开发专栏收录该内容

49 篇文章

订阅专栏

避坑指南：K8s Pod网络通信那些‘诡异’的故障，我是如何一步步排查的

凌晨三点，告警铃声刺破寂静——生产环境中的订单服务突然无法调用支付模块。Kubernetes集群监控显示所有Pod状态正常，但跨节点通信的延迟曲线却呈现断崖式下跌。作为经历过数十次网络故障的老兵，我清楚这类"一切正常但就是不通"的问题往往隐藏着最棘手的陷阱。本文将还原从现象捕捉到根因定位的全过程，并整理成可复用的排查框架。

1. 现象分析与初步定位

故障发生时，首先需要明确 异常现象的精确边界 。通过kubectl describe endpoints确认支付服务的Pod IP列表与实际运行一致，但telnet测试显示只有同节点Pod能连通目标端口。这种"部分可达"的特征立刻排除了CNI插件完全失效的可能性。

关键排查命令：

# 检查Service与Endpoint映射
kubectl get svc payment-service -o wide
kubectl get ep payment-service

# 跨节点连通性测试（在业务Pod内执行）
nc -zv <目标PodIP> 8080
traceroute <目标PodIP>

通过 三维度隔离测试 快速缩小范围：

同节点Pod间通信 → 正常
跨节点Pod间通信 → 失败
节点间主机网络通信 → 正常

注意：测试时务必区分集群内Overlay网络和底层主机网络，避免误判

2. 网络栈逐层排查法

2.1 CNI插件层检查

首先确认Flannel的配置是否存在子网冲突。检查各节点的flanneld日志发现大量"failed to allocate subnet"警告：

journalctl -u flanneld | grep -i subnet

对比节点分配的子网段与kube-controller-manager的--cluster-cidr参数，发现存在重叠。这是由于有节点手动配置了静态IP导致地址池混乱。

2.2 节点路由表审计

异常节点的路由表缺少其他节点的Pod网段路由项：

# 正常节点路由表示例
ip route show | grep flannel
10.244.1.0/24 via 10.156.2.34 dev flannel.1 onlink

# 故障节点缺失关键路由

通过tcpdump抓包发现，跨节点ARP请求无法收到响应：

tcpdump -i flannel.1 -nn 'arp or icmp'

2.3 防火墙规则验证

突然想起最近安全团队更新了主机防火墙策略。检查iptables规则发现DROP了VXLAN端口：

iptables -L -n -v | grep 8472
Chain INPUT (policy DROP 3 packets, 252 bytes)
 pkts bytes target     prot opt in     out     source   destination
   0     0 DROP       udp  --  *      *       0.0.0.0/0 0.0.0.0/0 udp dpt:8472

3. 深度诊断工具链

3.1 网络策略追溯

虽然问题看似解决，但进一步检查发现部分命名空间的NetworkPolicy存在冲突：

# 冲突策略示例
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: db-isolation
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: payment

通过 策略模拟工具 验证规则生效情况：

kubectl-network-policy-visualizer --namespace production

3.2 eBPF深度观测

使用BCC工具集观测内核态网络行为：

# 跟踪丢包位置
trace 'kretprobe:ip_rcv { if (args->retval == NET_RX_DROP) { @[comm] = count(); } }'

# 检查conntrack状态
bpftrace -e 'kprobe:__nf_conntrack_hash_insert { printf("%s\n", kstack()); }'

4. 根治方案与防御体系

4.1 即时修复步骤

临时放行VXLAN端口：

iptables -I INPUT -p udp --dport 8472 -j ACCEPT

重建Flannel网络接口：

systemctl restart flanneld
ip link delete flannel.1

4.2 长效防御机制

建立 网络健康度检查清单 ：

检查项	检测命令	预期结果
CNI插件状态	journalctl -u flanneld -n 50	无ERROR日志
节点路由完整性	ip route show \| grep flannel	包含所有节点Pod网段
VXLAN隧道连通性	nc -zv <对端节点IP> 8472	端口开放
NetworkPolicy冲突	kubectl get networkpolicy -A	无重复selector

4.3 监控增强方案

部署以下Prometheus监控指标：

- job_name: 'flannel_health'
  metrics_path: '/metrics'
  static_configs:
    - targets: ['localhost:9323']
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: 'flannel-exporter:9113'

在集群扩容或安全策略变更后，这套排查框架已经帮我们避免了7次类似故障。记住：网络问题就像冰山，表面现象只是实际问题的十分之一。