MicroK8s跨系统网络问题排查：安全策略对Pod直连访问的影响分析

问题现象

在部署MicroK8s集群时，用户发现一个有趣的现象：在Ubuntu 22.04系统上部署的服务运行正常，但在Red Hat Enterprise Linux 9.5系统上却出现了网络访问异常。具体表现为：

1. 通过Service访问Pod时工作正常（返回200状态码）
2. 直接通过Pod IP地址访问时却出现502错误（Bad Gateway）
3. 两种环境下（Ubuntu和RHEL）的Kubernetes资源配置完全一致
4. 网络拓扑结构检查显示Ingress→Service→Pod的链路配置正确

深入分析

网络拓扑对比

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

1. Ubuntu环境：

   • Ingress指向Service（10.152.183.39:80）
   • Service指向Pod（10.1.48.129:8080）
   • 两种访问方式（通过Service或直接Pod IP）均正常工作

2. RHEL环境：

   • Ingress指向Service（10.152.183.222:80）
   • Service指向Pod（10.1.102.147:8080）
   • 通过Service访问正常，但直接Pod IP访问失败

关键差异点排查

1. 网络插件日志差异：

   • Ubuntu上的Calico组件日志约20行
   • RHEL上的Calico组件日志超过1000行
   • 这表明RHEL环境下网络组件可能存在异常通信

2. 系统环境差异：

   • 操作系统：Ubuntu 22.04 vs RHEL 9.5
   • 默认安全策略配置不同
   • 内核网络模块可能有差异

根本原因

经过深入排查，发现问题根源在于RHEL系统的安全策略配置。RHEL默认启用了严格的安全规则，这导致：

1. Service到Pod的通信被允许（Kubernetes管理的网络规则）
2. 但直接从外部（包括集群内其他Pod）访问Pod IP的流量被安全策略拦截
3. 这种不对称的访问控制导致了502错误

解决方案

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

推荐方案：调整安全策略规则

# 允许Kubernetes Pod网络通信
sudo firewall-cmd --permanent --zone=trusted --add-source=10.1.0.0/16
sudo firewall-cmd --reload

备选方案：完全禁用安全策略（不推荐生产环境）

# 临时禁用
sudo systemctl stop firewalld

# 永久禁用
sudo systemctl disable firewalld

最佳实践建议

1. 生产环境：应保持安全策略开启，仅添加必要的规则
2. 跨平台部署：特别注意不同Linux发行版的默认安全策略差异
3. 网络检查：定期检查Calico等网络组件的日志是否有异常
4. 访问测试：部署后应测试多种访问路径（Service、Pod IP、Ingress等）

技术原理延伸

Kubernetes网络模型中，Pod间的通信本应直接进行。但在实际部署中，主机安全策略可能干扰这种通信：

1. Service访问：通过kube-proxy创建的iptables/ipvs规则，通常会被安全策略放行
2. Pod直连：依赖底层网络插件（如Calico）和主机网络栈的配合
3. RHEL特殊性：相比Ubuntu，RHEL默认有更严格的安全策略

理解这些底层机制有助于快速定位类似网络问题。