容器服务 Dataplane V2 转发模式

一、原理

TKE Dataplane V2 基于 eBPF 实现了东西向的 Service（包括 ClusterIP 和 NodePort）和 NetworkPolicy。当数据包从 Pod 网卡发出或到达 TKE 节点时，内核中的 eBPF 程序会决定如何路由和处理数据包。

二、Service 实现

TKE Dataplane V2 采用 eBPF 替换了原有的 iptables 和 IPVS 转发模式。当 Service 创建、删除等变更时，节点上会更新相应的 eBPF 转发逻辑；后续报文转发时，会判断报文是否是 Service 相关 IP，并进行对应的转发处理。如下：

三、NetworkPolicy 实现

使用 eBPF 取代原有的 iptables，实现 Pod 的网络策略。不会在宿主机上产生大量的 iptables 规则，降低网络策略对性能的影响。

四、部署方式

Dataplane V2 基于 Cilium 实现了 ClusterIP 和 NodePort 类型的 Service，完全替代了 kube-proxy。为简化 Cilium 的管理，我们将 cilium-agent 容器融入了 TKE 网络插件 tke-eni-agent，将 cilium-operator 容器融入了 TKE 网络控制器 tke-eni-ipamd。如下：

五、相较于 kube-proxy IPVS 模式

·数据面：Dataplane V2 的转发性能比 IPVS 可以提高15%-20%。

注意：说明：

注意：以上所有指标使用以下命令进行测试：

注意：./wrk -t16 -c2400 -d20s -H "Connection: close" –latency http://clusterip:80/

·控制面：在 Service 变更频繁或后端变更频繁的场景下，kube-proxy IPVS 模式下的 kube-proxy 进程会长时间占用超过一个 CPU 核心，时长和受影响的 Service 成正比。例如，500个 Service 受影响时，需要持续大约25秒。而在 Dataplane V2 情况下，基本无明显感知。

六、相较于 kube-proxy iptables 模式

·当 Service 数量达到5000个时，控制面性能会急剧下降，甚至导致系统不可用。而 Dataplane V2 即使在 Service 规模超过1万时，性能基本不受影响。

·iptables 方案下，转发性能随着 Service 数量的增加而下降；Dataplane V2 的转发性能与 Service 数量基本无关联。

·iptables 方案在 Service 数量较大时，周期对账会占用一定的 CPU 资源。Dataplane V2 无需对账机制，可节省节点 CPU 资源。

七、安全方面

Dataplane V2 原生支持 NetworkPolicy，无需额外部署新的组件，有效节省了节点的内存和 CPU 资源。

八、可观测性增强

相比于 iptables/IPVS，eBPF 程序可以更方便地暴露 Service 访问和 NetworkPolicy 裁决信息，结合 Kubernetes 元数据，提升了网络的可观测性。在 Dataplane V2 集群中支持部署 Cilium Hubble，可以对容器网络流量进行可视化展示，实现网络架构和业务拓扑关系的可观测性。