Kubernetes中同一节点Pod间网络访问故障排查与分析

问题现象

在Kubernetes集群环境中，用户遇到了一个典型的网络连通性问题：部署在同一节点上的两个Pod（MySQL和BusyBox）之间无法通过Service名称正常通信。具体表现为：

1. MySQL Pod能够通过Service名称"apollo-db"访问自身服务
2. BusyBox Pod能够解析"apollo-db"域名到正确的Service IP
3. 但BusyBox Pod无法通过Service IP或域名访问MySQL服务
4. 有趣的是，BusyBox Pod可以直接通过MySQL Pod IP访问服务

环境信息

• Kubernetes版本：1.31.1
• 容器运行时：containerd v1.7.23
• 网络插件：Flannel v0.25.7（使用VXLAN后端）
• 操作系统：Alibaba Cloud Linux 2.1903 LTS
• 节点分布：Master节点在AWS，Worker节点在阿里云，通过专线连接

初步排查

网络连通性测试

通过一系列网络测试，我们获得了以下关键信息：

1. DNS解析测试：BusyBox Pod能够正确解析"apollo-db"到Service IP（192.168.134.205）
2. 直接连接测试：
   • BusyBox Pod → MySQL Pod IP（192.168.0.233）：成功
   • BusyBox Pod → Service IP（192.168.134.205）：失败
3. 跨节点测试：另一个节点上的BusyBox Pod能够正常访问Service

数据包捕获分析

通过在节点上使用tcpdump抓包，我们观察到以下关键现象：

1. BusyBox Pod发出的SYN包能够到达MySQL Pod
2. MySQL Pod返回了SYN-ACK响应
3. 但BusyBox Pod立即发送了RST包终止连接

这表明TCP三次握手虽然开始但未能完成，问题可能出在连接跟踪或网络地址转换环节。

深入分析

内核模块缺失

经过进一步排查，发现问题的根本原因是节点缺少必要的内核模块"br_netfilter"。这个模块对于Kubernetes网络特别是Service的IPVS/iptables实现至关重要，它负责：

1. 桥接网络流量的过滤和监控
2. 实现连接跟踪（conntrack）功能
3. 支持网络地址转换（NAT）

模块缺失的影响

当br_netfilter模块未加载时，会导致：

1. Service的虚拟IP无法正确进行NAT转换
2. 连接跟踪表无法正确建立和维护连接状态
3. 跨节点通信可能正常（依赖Flannel的VXLAN封装）
4. 但同一节点内的Pod间通过Service通信会失败

解决方案

解决此问题的方法非常简单：

# 加载br_netfilter内核模块
sudo modprobe br_netfilter

# 确保模块开机自动加载
echo "br_netfilter" | sudo tee /etc/modules-load.d/br_netfilter.conf

预防措施

为避免类似问题，建议在Kubernetes节点准备阶段：

1. 检查并加载所有必需的内核模块：

   modprobe br_netfilter
   modprobe overlay
   modprobe nf_conntrack
   

2. 验证内核参数配置：

   sysctl -w net.bridge.bridge-nf-call-iptables=1
   sysctl -w net.ipv4.ip_forward=1
   

3. 在系统初始化脚本中确保这些配置持久化

总结

这个案例展示了Kubernetes网络问题排查的典型思路：从现象出发，通过分层测试逐步缩小问题范围，最终定位到系统层面的配置缺失。对于生产环境中的Kubernetes集群，节点的基础系统配置检查应该成为部署前的标准流程，特别是：

1. 内核模块完整性检查
2. 网络参数配置验证
3. 基础网络连通性测试
4. 跨节点和同节点通信的全面验证

通过系统化的准备和验证，可以避免大多数因环境配置不当导致的网络问题，确保集群的稳定运行。