OpenYurt 中跨节点服务访问的 IPVS 与 IPSec 兼容性问题分析

在 OpenYurt 边缘计算框架的实际部署中，我们发现了一个涉及网络协议栈底层交互的有趣现象：当使用 IPVS 模式的 kube-proxy 时，在云节点（cloud node）的宿主机网络命名空间中，无法通过 Cluster IP 访问边缘节点上的服务，但直接使用 Pod IP 却能正常访问。这个现象揭示了 Linux 内核中 IPVS、conntrack 和 XFRM 子系统之间微妙的交互问题。

问题现象与技术背景

在典型的 OpenYurt 部署环境中，包含云节点和多个边缘节点，节点间通过 Raven 组件建立的 IPSec 隧道实现跨物理区域的网络互通。当在云节点的宿主机网络命名空间中执行以下操作时：

1. 通过 Service 的 Cluster IP 访问（如 telnet 10.255.31.243 80）会失败
2. 直接使用 Pod IP 访问（如 telnet 10.233.68.67 80）却能成功

通过抓包分析发现，TCP 三次握手中的 SYN 包能够到达边缘节点的 Pod，SYN-ACK 也能返回云节点，但连接却无法完成建立。深入内核态观察发现，返回的 SYN-ACK 包在 XFRM（Linux 内核的 IPsec 框架）策略检查阶段被丢弃，导致 /proc/net/xfrm_stat 中的 XfrmInNoPols 计数器不断增长。

根本原因分析

问题的核心在于 Linux 内核网络协议栈中 IPVS、conntrack 和 XFRM 三个子系统的交互时序：

1. IPVS 的 DNAT 行为：IPVS 在 NAT 模式下会修改目标地址（Cluster IP → Pod IP），同时可能改变源端口
2. conntrack 状态跟踪：IPVS 的 DNAT 操作不会在 conntrack 中设置 DNAT 状态标志（0x20），只设置 SNAT 标志（0x10）
3. XFRM 策略检查：当 SYN-ACK 包返回时，nf_nat_decode_session 根据 conntrack 状态重建流信息。由于缺少 DNAT 标志，重建的流信息中源地址不正确，导致无法匹配预先配置的 XFRM 策略

相比之下，kube-proxy 的 iptables 模式能够正常工作，是因为 iptables 的 DNAT 会在 conntrack 中正确设置 DNAT 标志位，使得 XFRM 策略检查时能够获取正确的流信息。

解决方案与实践建议

针对这一问题，OpenYurt 社区提出了几种可行的解决方案：

1. 避免在宿主机网络访问 Cluster IP
   在 Pod 网络命名空间中访问服务可以绕过此问题，因为 Pod 内部不涉及 XFRM 策略检查

2. 使用 kube-proxy 的 iptables 模式
   虽然性能略低于 IPVS 模式，但能保证功能完整性

3. 扩展 Raven 的 XFRM 策略配置
   在 Gateway 节点上添加 Service 网段到本节点 Pod 网段的 XFRM 策略：

   ip xfrm policy add src <Service网段> dst <本地Pod网段> dir in ptype main tmpl proto esp mode tunnel
   

4. 网络架构调整建议
   对于复杂的边缘计算场景，可以考虑：

   • 云边主机网络通过 IPSec 打通（运维刚需）
   • 跨节点 Pod 通信仍走 CNI 插件的 overlay 网络（如 VXLAN over IPSec）
   • 这种分层设计既能保证兼容性，又能简化网络配置

技术启示与最佳实践

这个案例为我们提供了几个重要的技术启示：

1. 网络功能组合的隐式依赖
   IPVS 和 IPSec 都是成熟的技术，但在特定组合下仍可能产生意料之外的交互问题

2. 内核网络调试方法论
   通过结合 conntrack、xfrm_stat、dropwatch 等多个维度的观测数据，可以准确定位复杂的网络问题

3. 边缘计算网络设计原则
   在边缘场景中，网络设计应遵循"最小干预"原则，尽量保持与标准 Kubernetes 网络模型的兼容性

OpenYurt 作为边缘计算平台，通过灵活的架构设计既支持了复杂的网络场景，又保持了与原生 Kubernetes 的兼容性。对于使用者而言，理解这些底层机制有助于更合理地规划网络架构和排查问题。