MicroK8s跨节点Pod网络访问异常排查与解决方案

问题背景

在使用MicroK8s部署服务时，用户在不同操作系统环境中遇到了网络访问差异问题。具体表现为：在Ubuntu 22.04系统上部署的服务能够正常通过Ingress和Pod IP访问，而在Red Hat Enterprise Linux 9.5系统上，虽然通过Service可以访问Pod，但直接通过Pod IP访问时却返回502错误。

现象分析

通过对比两个环境的网络配置，发现以下关键点：

1. 网络拓扑结构一致：两个集群中的Ingress、Service和Pod之间的映射关系完全相同

   • Ingress指向Service的80端口
   • Service指向Pod的8080端口
   • 通过Service访问都能正常工作

2. 直接Pod访问差异：

   • Ubuntu环境：curl http://<pod-ip>:8080/healthz返回200
   • RHEL环境：相同命令返回502

3. 网络组件差异：

   • Calico日志在RHEL环境中异常增多（1000+行 vs Ubuntu的20行）

根本原因

经过深入排查，发现问题根源在于RHEL系统的安全防护配置。与Ubuntu不同，RHEL默认启用了更严格的网络访问规则，这些规则阻止了直接对Pod IP的访问请求，但允许通过Service的Cluster IP进行访问。

解决方案

针对此问题，有以下几种解决方法：

1. 临时解决方案：完全禁用安全防护（适用于测试环境）

   sudo systemctl stop firewalld
   sudo systemctl disable firewalld
   

2. 推荐解决方案：配置安全规则允许Pod网络通信（生产环境适用）

   sudo firewall-cmd --permanent --zone=trusted --add-source=10.1.0.0/16
   sudo firewall-cmd --permanent --zone=trusted --add-source=10.152.183.0/24
   sudo firewall-cmd --reload
   

3. 替代方案：调整MicroK8s网络插件配置

   microk8s disable calico
   microk8s enable flannel
   

最佳实践建议

1. 在生产环境中，建议采用第二种方案，既保证安全性又确保网络连通性
2. 跨平台部署时，应提前检查各系统的网络配置差异
3. 对于关键业务系统，建议在部署前进行网络连通性测试
4. 考虑使用NetworkPolicy来细化Pod间的访问控制，而非依赖主机安全防护

总结

MicroK8s作为轻量级Kubernetes发行版，在不同Linux发行版上的网络行为可能因系统配置差异而有所不同。特别是在RHEL/CentOS系列系统上，默认的安全策略往往会导致Pod网络访问问题。通过合理配置安全规则或选择合适的CNI插件，可以确保集群网络正常工作。这也提醒我们在混合环境部署时，需要特别关注底层系统的网络配置差异。