Kubernetes集群中同节点Pod间网络访问异常问题分析与解决

问题现象

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

1. MySQL Pod能够通过Service名称（apollo-db）访问自身服务
2. BusyBox Pod能够解析Service名称，但无法通过该名称访问MySQL服务
3. 直接使用Pod IP可以正常访问
4. 其他节点上的Pod能够正常访问该Service

环境信息

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

排查过程

1. 基础连通性测试

首先验证了基本的网络连通性：

• BusyBox Pod能够解析Service名称apollo-db为正确的ClusterIP（192.168.134.205）
• BusyBox Pod能够直接通过MySQL Pod IP（192.168.0.233）访问服务
• 节点本身能够通过Service IP和Pod IP访问MySQL服务

2. 网络抓包分析

在节点上使用tcpdump抓包发现了关键现象：

• BusyBox Pod发出的SYN包能够到达MySQL Pod
• MySQL Pod返回了SYN-ACK响应
• 但BusyBox Pod立即发送了RST（重置连接）包

这表明TCP连接已经建立，但被异常重置。

3. 内核模块检查

通过排查发现节点缺少关键的内核模块br_netfilter，该模块负责处理桥接网络的数据包过滤和NAT转换，是Kubernetes网络正常运行的基础组件。

4. 根本原因

问题的根本原因是：

1. 节点未加载br_netfilter内核模块
2. 导致节点上的Pod间通过Service通信时，数据包无法正确进行NAT转换
3. 虽然直接使用Pod IP可以绕过Service机制直接通信
4. 其他节点上的Pod通信走的是节点间路由，不受此影响

解决方案

执行以下命令加载缺失的内核模块：

modprobe br_netfilter

为确保节点重启后仍能正常工作，建议将模块加入自动加载列表：

echo "br_netfilter" >> /etc/modules-load.d/k8s.conf

预防措施

为避免类似问题再次发生，建议：

1. 在节点初始化时检查并加载所有必需的内核模块
2. 使用以下命令验证网络配置：

   lsmod | grep br_netfilter
   sysctl net.bridge.bridge-nf-call-iptables
   

3. 在Kubernetes节点准备清单中加入内核模块检查项
4. 定期进行集群健康检查，包括网络连通性测试

技术原理深入

Kubernetes网络模型中，同节点Pod间通过Service通信会经历以下流程：

1. 数据包从源Pod发出，目标为Service IP
2. kube-proxy通过iptables/ipvs将Service IP转换为具体Pod IP
3. 由于源和目标在同一节点，数据包需要通过Linux网桥转发
4. br_netfilter模块在此过程中负责：
   • 确保网桥流量经过iptables规则处理
   • 实现NAT转换
   • 维护连接跟踪状态

缺少该模块会导致NAT转换失败，虽然TCP三次握手能完成，但后续数据包无法正确路由，最终触发连接重置。

总结

Kubernetes集群网络问题往往与底层系统配置密切相关。本文通过一个典型案例，展示了同节点Pod间Service通信异常的完整排查过程，强调了基础组件检查的重要性。运维人员应当充分理解Kubernetes网络模型和Linux网络栈的交互原理，才能快速定位和解决此类问题。