K3s-Ansible项目中的Pod间网络通信故障排查与解决方案

在Kubernetes集群部署过程中，Pod间网络通信是最基础也是最重要的功能之一。本文针对使用techno-tim/k3s-ansible项目部署K3s集群时遇到的Pod间网络不通问题，深入分析原因并提供解决方案。

问题现象分析

在基于RedHat/CentOS系统的K3s集群部署中，用户经常遇到以下典型症状：

• 使用MetalLB或Kube-Vip作为负载均衡方案时，Pod之间无法建立网络连接
• 跨节点Pod通信完全失败
• 服务发现机制工作异常

根本原因

经过技术分析，发现问题主要源于RedHat系列发行版默认启用的firewalld服务。该防火墙服务会默认拦截节点间的Pod网络流量，导致以下关键影响：

1. CNI插件（如Flannel、Calico等）无法正常建立Overlay网络隧道
2. 节点间的Pod流量被错误过滤
3. 服务发现所需的DNS查询被阻断

解决方案

临时解决方案

对于需要快速恢复业务的情况，可以在所有节点执行：

sudo systemctl stop firewalld

此命令会立即停止防火墙服务，允许Pod间通信恢复正常。

永久解决方案

推荐采用以下两种方案之一：

方案一：完全禁用firewalld（适合测试环境）

sudo systemctl disable --now firewalld

方案二：精细配置防火墙规则（适合生产环境）

1. 允许CNI插件所需端口（以Flannel为例）：

sudo firewall-cmd --permanent --add-port=8472/udp

2. 允许Kubernetes API Server端口：

sudo firewall-cmd --permanent --add-port=6443/tcp

3. 允许节点间通信：

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="<集群节点CIDR>" accept'

4. 重载防火墙规则：

sudo firewall-cmd --reload

最佳实践建议

1. 对于生产环境，建议采用方案二的精细化配置，既保证安全性又确保网络连通性
2. 在Ansible playbook中增加防火墙规则配置步骤，实现自动化部署
3. 定期检查防火墙规则是否被意外修改
4. 对于关键业务集群，建议实施网络策略(NetworkPolicy)进行额外保护

技术原理补充

K3s默认使用Flannel作为CNI插件时，会建立VXLAN或UDP封装的Overlay网络。这些封装包需要特定的防火墙规则允许通过，否则节点间无法建立网络隧道，导致Pod间通信失败。理解这一底层原理有助于更好地排查类似网络问题。

通过以上解决方案，可以确保基于techno-tim/k3s-ansible项目部署的K3s集群中Pod网络功能正常工作，为上层应用提供稳定的网络基础。