容器服务 Dataplane V2 介绍

TKE 推出新一代 Kubernetes 网络数据平面——Dataplane V2。与之前版本相比，Dataplane V2 具有以下优势：
解决了 kube-proxy 在 iptables 模式下大量 Service 情况下的控制面性能问题。
原生支持 NetworkPolicy，无需额外安装 NetworkPolicy 插件。
支持部署 Hubble，增强集群网络的可观测性。
原理
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，可以对容器网络流量进行可视化展示，实现网络架构和业务拓扑关系的可观测性。
﻿
﻿
﻿
﻿
Dataplane V2 介绍

本页目录：

原理

Service 实现

NetworkPolicy 实现

部署方式

方案优势

相较于 kube-proxy IPVS 模式

相较于 kube-proxy iptables 模式

安全方面

可观测性增强
