GKE Dataplane V2与Cilium的Pod到ClusterIP流量差异及负载均衡位置咨询

现象对比 #

Cilium的流量行为 #

启用kube-proxy替换时，从Pod的LXC接口抓包可见，流量目标IP直接解析为服务后端Pod的IP，ClusterIP不会出现在数据包中：

tcpdump -i lxcb6c0fc3970bd -n
...
IP 10.233.69.20.37886 > 10.233.66.81.6379

其中10.233.69.20是源Pod，10.233.66.81是服务的后端Pod。

GKE Dataplane V2的流量行为 #

相同场景下，从Pod的GKE接口抓包时，流量目标IP仍是服务的ClusterIP，而非后端Pod：

tcpdump -i gke631754ef122 -n
...
IP 10.80.2.23.35122 > 34.118.232.190.6379

34.118.232.190是服务的ClusterIP，后端Pod实际IP为10.80.5.15。

差异原因解释 #

尽管GKE Dataplane V2（DPv2）基于Cilium构建，但Google针对GKE架构做了定制化调整，核心差异在于服务负载均衡的实现时机与位置：

• Cilium在kube-proxy替换模式下采用客户端侧负载均衡：当Pod发起ClusterIP请求时，Cilium的eBPF程序会在源Pod网络栈出口处直接将ClusterIP替换为后端Pod的IP，属于客户端侧的地址转换，因此在Pod接口抓包看不到ClusterIP。
• GKE DPv2则将负载均衡逻辑移至节点网络层面：地址转换操作被推迟到节点的网络处理流程中执行，而非在Pod内部完成，所以Pod接口发出的流量仍以ClusterIP为目标。

DPv2的服务负载均衡位置 #

DPv2的负载均衡操作发生在节点的eBPF网络管道中，且处于Pod接口之后、节点对外网络接口之前的阶段：

1. 流量从Pod的gke接口发出，目标为ClusterIP；
2. 流量进入节点网络命名空间后，经过Cilium定制的eBPF程序处理，此时才完成ClusterIP到后端Pod IP的替换与负载均衡选路；
3. 转换后的流量直接转发至同节点目标Pod，或通过节点间隧道发送至跨节点的目标Pod。

这种设计是为了适配GKE与GCP VPC的深度集成架构，同时保留Cilium eBPF的高性能特性，仅调整了流量转换的时机与位置。

内容的提问来源于stack exchange，提问作者Patrik Polakovic