Kube-Router中Pod出口流量SNAT问题的分析与解决

问题背景

在使用Kube-Router构建Kubernetes网络环境时，一个常见的需求是让Pod能够直接与集群外部通信，而不经过源地址转换(SNAT)。然而在实际部署中，用户发现即使没有显式配置，Pod的出口流量仍然被自动进行了SNAT转换，导致外部系统无法看到Pod的真实IP地址。

环境配置分析

该案例中的环境具有以下特点：

1. 使用k3s部署的Kubernetes集群
2. 禁用了k3s内置的Traefik、local-storage等服务
3. 采用双栈网络配置(IPv4和IPv6)
4. 使用kube-router替代kube-proxy和flannel
5. 配置了BGP路由通告

问题现象

当Pod尝试与集群外部通信时，出站流量会被自动进行SNAT转换，源IP被替换为节点IP。这种现象同时出现在IPv4和IPv6流量上。

根本原因

通过深入排查，发现问题源于kube-router的一个默认行为：当启用Pod出口功能时(--enable-pod-egress，默认为true)，kube-router会自动添加一条iptables规则：

-A POSTROUTING -m set --match-set kube-router-pod-subnets src -m set ! --match-set kube-router-pod-subnets dst -m set ! --match-set kube-router-node-ips dst -j MASQUERADE --random-fully

这条规则的意思是：对于源地址属于Pod子网，目标地址不属于Pod子网也不属于节点IP的流量，执行MASQUERADE操作。

解决方案

要解决这个问题，有两种方法：

1. 禁用Pod出口功能：在kube-router的启动参数中添加--enable-pod-egress=false，这将阻止kube-router创建上述SNAT规则。

2. 手动管理路由和防火墙：如果确实需要保持Pod出口功能，则需要确保：

   • 外部网络能够路由到Pod IP
   • 网关设备允许非NAT的流量通过
   • 对于IPv4，可能需要额外配置网关设备的SNAT规则

实施效果

采用第一种方案后：

• IPv6通信完全正常，无需额外配置
• IPv4需要在网关设备(pfSense)上手动调整SNAT策略，因为pfSense默认只对直连网络进行MASQUERADE

经验总结

1. kube-router的--enable-pod-egress参数对网络行为有重要影响，需要根据实际需求明确配置
2. 在双栈环境中，IPv6和IPv4的NAT行为可能有差异，需要分别验证
3. 网关设备的默认策略可能影响集群网络行为，部署时需要全面考虑

扩展思考

对于需要精细控制Pod网络行为的场景，建议：

1. 明确规划IP地址分配方案
2. 详细记录各网络组件的默认行为
3. 建立完整的网络连通性测试方案
4. 考虑使用NetworkPolicy进行更细粒度的访问控制

通过这个案例，我们可以更深入地理解Kubernetes网络组件之间的交互关系，以及如何根据实际需求调整网络策略。