Kubernetes网络排错实录：当Pod网络不通时，我是如何用Calicoctl一步步揪出真凶的

Kubernetes网络排错实战：Calico网络故障的深度诊断与解决

凌晨三点，告警铃声划破了运维中心的宁静——生产环境中两个关键业务Pod突然无法通信。作为值班SRE，我迅速连接到集群，开始了一场与时间的赛跑。这不是简单的ping超时问题，而是涉及Calico网络插件、BGP路由协议和Linux内核网络栈的复合型故障。下面将完整还原这次排错过程，并形成可复用的排查框架。

1. 故障现象与初步定位

业务团队报告服务A无法调用服务B，错误日志显示连接超时。通过kubectl exec进入Pod A执行ping测试，确认到Pod B的IP地址（10.244.3.21）确实不通。但有趣的是，Pod B却能正常访问其他服务。这种单向不通的现象暗示问题可能出在特定路径的网络配置上。

关键检查点：

• 确认两端Pod状态：kubectl get pod -o wide | grep -E "A|B"
• 检查基础网络连通性：kubectl exec Pod-A -- ping -c 3 10.244.3.21
• 验证Service是否正常：kubectl get svc | grep Service-B

注意：当出现单边不通时，应优先排查目标Pod所在节点的网络策略和路由表

2. Calico网络架构快速回顾

在深入排查前，有必要理解Calico的核心组件如何协同工作：

# 查看Calico组件状态 calicoctl node status

3. 系统性排查流程实施

3.1 BGP邻居状态检查

首先怀疑节点间BGP会话异常。执行以下命令查看BGP邻居关系：

calicoctl get bgpPeer -o wide

发现目标节点（worker-03）的状态为"Established"，但路由表却缺少关键条目。进一步检查具体路由宣告：

# 在worker-03上执行 birdcl show route all

输出显示10.244.3.0/24网段的路由确实缺失。这解释了为什么Pod A无法到达Pod B——数据包在worker-01节点被丢弃，因为下一跳不可达。

3.2 IPPool配置验证

接下来检查IP地址分配是否正常：

calicoctl get ippool -o yaml

重点关注以下参数：

• disabled: 是否禁用地址分配
• natOutgoing: 是否启用SNAT
• ipipMode: 隧道模式设置

发现两个Pod分属不同的IPPool，且其中一个Pool的natOutgoing被误设为false。这导致回程流量被安全组拦截。

3.3 Route Reflector诊断

我们的集群使用Route Reflector拓扑。检查RR配置：

calicoctl get node worker-rr -o yaml

关键字段routeReflectorClusterID必须全局唯一。发现近期扩容时新RR节点使用了重复的ClusterID，导致路由信息冲突。通过以下命令修复：

calicoctl patch node worker-rr-new -p '{"spec": {"bgp": {"routeReflectorClusterID": "244.0.1.1"}}}'

3.4 MTU不匹配问题

虽然BGP和IPPool问题已解决，但ping测试仍出现碎片化报错。检查MTU配置：

# 查看Pod内网卡MTU kubectl exec Pod-A -- ip link show eth0 # 查看宿主机隧道设备MTU ip link show tunl0

发现宿主机物理网卡MTU为9000，但Calico配置为1500。添加以下环境变量到calico-node DaemonSet：

- name: FELIX_IPINIPMTU value: "1440" # 9000 - 60(IP头) - 20(IPIP头)

4. 高级排查技巧

当常规手段无法定位问题时，这些方法往往能奏效：

Felix日志分析技巧：

# 跟踪实时日志 tail -f /var/log/calico/felix.log | grep -E "DROP|REJECT" # 查找特定Pod的流日志 grep "10.244.3.21" /var/log/calico/felix.log

数据包捕获方法：

# 在源节点捕获出向流量 tcpdump -i eth0 host 10.244.3.21 -w pod-a.pcap # 在目标节点捕获入向流量 tcpdump -i caliXXXX -w pod-b.pcap

性能调优参数：

# 调整BGP保持时间（默认90秒） calicoctl patch bgpconfiguration default -p '{"spec": {"nodeToNodeMeshEnabled": true, "asNumber": 64512, "serviceClusterIPs": [{"cidr": "10.96.0.0/12"}], "serviceExternalIPs": [{"cidr": "192.168.0.0/16"}], "listenPort": 179, "logSeverityScreen": "Info", "nodeMeshMaxRestartTime": "30s"}}'

5. 故障预防体系构建

基于此次教训，我们建立了三层防护体系：

1. 监控层：

   • BGP会话状态监控（Prometheus + calico-exporter）
   • 路由表差异告警（自定义Controller对比各节点路由）

2. 验证层：

   # 每日自动网络测试 kubectl create job --from=cronjob/network-checker test-$(date +%s)

3. 规范层：

   • IPPool变更必须经过双人复核
   • 新节点加入需通过拓扑验证脚本
   • 关键配置变更实施蓝绿部署

# 示例：网络健康检查CronJob apiVersion: batch/v1beta1 kind: CronJob metadata: name: network-checker spec: schedule: "0 3 * * *" jobTemplate: spec: template: spec: containers: - name: checker image: network-tester:1.2 command: ["/bin/sh", "-c"] args: - ping -c 3 ${TARGET_IP} || exit 1; env: - name: TARGET_IP value: "10.244.1.1" restartPolicy: OnFailure

6. 典型故障模式速查表

根据社区数据统计，Calico网络问题主要集中在以下几个领域：

这次排障经历让我深刻体会到，Calico网络问题往往不是单一因素导致，而是多个配置项共同作用的结果。掌握组件间的交互原理，建立系统化的排查思路，比记住具体命令更为重要。