GKE Dataplane V2


本页面简要介绍了 GKE Dataplane V2 的功能和工作原理。

在阅读本页面内容之前,请确保您熟悉 GKE 集群内的网络

GKE Dataplane V2 概览

GKE Dataplane V2 是专为 Kubernetes 网络而优化的数据平面。GKE Dataplane V2 可提供:

  • 一致的网络用户体验。
  • 可实时查看网络活动。
  • 更简单的架构,可更轻松管理集群并进行问题排查。

GKE Dataplane V2 在默认情况下为所有新 Autopilot 集群启用。

GKE Dataplane V2 的工作原理

GKE Dataplane V2 是使用 eBPF 实现的。当数据包到达 GKE 节点时,内核中安装的 eBPF 程序会决定如何路由和处理数据包。与使用 iptables 处理数据包不同,eBPF 程序可以在数据包中使用 Kubernetes 特有的元数据。这样一来,GKE Dataplane V2 便可以更高效地处理内核中的网络数据包,并向用户空间报告已添加注解的操作,以便进行日志记录。

下图显示了数据包使用 GKE Dataplane V2 通过节点的路径。

GKE 将 GKE Dataplane V2 控制器作为名为 anetdDaemonSet 部署到集群中的每个节点。anetd 解释了 Kubernetes 对象并在 eBPF 中编制了网络拓扑。anetd Pod 在 kube-system 命名空间中运行。

GKE Dataplane V2 和 NetworkPolicy

GKE Dataplane V2 是使用 Cilium 实现的。适用于 GKE 的旧版数据平面是使用 Calico 实现的。

这两种技术都用于管理 Kubernetes NetworkPolicy。Cilium 使用 eBPF,Calico 容器网络接口 (CNI) 使用 Linux 内核中的 iptables

GKE Dataplane V2 的优势

可伸缩性

GKE Dataplane V2 的可扩缩性特征与旧版数据平面不同。

对于 GKE Dataplane V2 不使用 kube-proxy 且不依赖于 iptables 进行服务路由的 GKE 版本,GKE 消除了一些与 iptables 相关的瓶颈,例如服务数量。

GKE Dataplane V2 依赖于 eBPF 映射,这些映射限制为所有服务 260,000 个端点。

安全

Kubernetes NetworkPolicy 始终在具有 GKE Dataplane V2 的集群中处于开启状态。您无需安装和管理第三方软件插件(如 Calico)即可实施网络政策。

运维

使用 GKE Dataplane V2 创建集群时,网络政策日志记录是内置的。在集群上配置日志记录 CRD,以查看 Pod 允许和拒绝连接的时间。

一致性

GKE Dataplane V2 可提供一致的网络体验。

如需了解详情,请参阅 GKE Dataplane V2 的可用性

GKE Dataplane V2 技术规范

GKE Dataplane V2 支持具有以下规范的集群:

规范 GKE VMware 上的 GDC(纯软件) 裸金属上的 GDC(纯软件)
每个集群的节点数 7,500 500 500
每个集群的 Pod 数 200,000 15000 27500
一个 Service 背后的 Pod 数量 10000 1000 1000
集群 IP Service 的数量 10000 1000 1000
每个集群的 LoadBalancer Service 数量 750 500 1000

GKE Dataplane V2 会维护 Service 映射,以跟踪哪些 Service 引用哪些 Pod 作为其后端。在所有 Service 中汇总的每个 Service 的 Pod 后端数量必须全部放入 Service 映射,其中最多可包含 260,000 个条目。如果超出此限制,您的集群可能无法按预期工作。

1.31 版中的节点限制提高到 7,500

从 Kubernetes 1.31 版开始,每个 GKE Dataplane V2 集群的节点限制已从 5,000 个提高到 7,500 个。之前对集群施加的条件(5000 个节点限制)仍然适用。

1.23 版中的节点限制提高到 5,000

从 Kubernetes 1.23 版开始,每个 GKE Dataplane V2 集群的节点限制已从 500 个提高到 5,000 个,并对集群施加了以下附加条件:

  • 使用 Private Service Connect 的专用集群或公共集群。如需检查您的集群是否使用 Private Service Connect,请参阅使用 Private Service Connect 的公共集群
  • 仅限区域级集群
  • 只有使用 GKE 1.23 版或更高版本创建的集群具有提高的 5,000 个节点限制。使用更早 GKE 版本创建的集群可能需要提升集群大小配额。 请与支持团队联系以寻求帮助。
  • 使用 Cilium CRD(CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy)的集群无法扩容到 5,000 个节点。

Google Distributed Cloud 中的 LoadBalancer Service

Google Distributed Cloud 支持的 LoadBalancer Service 数量取决于所使用的负载均衡器模式。使用捆绑式负载均衡模式 (Seesaw) 时,Google Distributed Cloud 支持 500 个 LoadBalancer Service;将集成式负载均衡模式与 F5 搭配使用时,则支持 250 个。如需了解详情,请参阅可伸缩性

限制

GKE Dataplane V2 存在以下限制:

  • GKE Dataplane V2 只能在创建新集群时启用。现有集群无法升级为使用 GKE Dataplane V2。
  • 在 1.20.12-gke.500 之前的 GKE 版本中,如果您启用具有 NodeLocal DNSCache 的 GKE Dataplane V2,则无法使用 dnsPolicy: ClusterFirstWithHostNet 配置 Pod,或者 Pod 会出现 DNS 解析错误
  • 从 GKE 1.21.5-gke.1300 版开始,GKE Dataplane V2 不支持 CiliumNetworkPolicy 或 CiliumClusterwideNetworkPolicy CRD API。 从 GKE 1.28.6-gke.1095000 和 1.29.1-gke.1016000 版开始,您可以在新集群或现有集群上启用 CiliumClusterwideNetworkPolicy
  • 不支持手动创建与 NodePort 类型的 Service 关联的内部直通网络负载均衡器。
  • 由于 GKE Dataplane V2 使用 eBPF 优化了 eBPF 内核数据包处理,因此如果您的工作负载的 Pod 流失率较高,则 Pod 性能可能会受到影响。GKE Dataplane V2 主要侧重于实现最佳 eBPF。
  • GKE Dataplane V2 上具有多个 (TCP/UDP) 端口的多集群 Service 存在一个已知问题。如需了解详情,请参阅具有多个端口的 MCS 服务
  • GKE Dataplane V2 使用 cilium 而不是 kube-proxy 来实现 Kubernetes Service。kube-proxy 由 Kubernetes 社区维护和开发,因此 Service 的新功能可能会先在 kube-proxy 中实现,然后才在 GKE Dataplane V2 使用的 cilium 中实现。首先在 kube-proxy 中实现的 Service 功能的一个示例是 KEP-1669:代理终止端点
  • 对于使用默认 SNAT 和 PUPI 范围运行 1.25 版或更低版本的 NodePort Service,您必须将 Pod 的 PUPI 范围添加到 ip-masq-agent ConfigMapnonMasqueradeCIDRs 中以避免连接问题。
  • 在某些情况下,GKE Dataplane V2 代理 Pod (anetd) 可能会消耗大量 CPU 资源,每个实例多达两到三个 vCPU。当节点上有大量 TCP 连接快速打开和关闭时,就会发生这种情况。为缓解此问题,我们建议为相关工作负载实现 HTTP 调用和连接池 keep-alive。
  • 运行控制平面 1.27 版或更低版本的 GKE Dataplane V2 集群不支持 Service .spec.internalTrafficPolicy 字段。服务的有效内部流量政策为 Cluster;任何节点上的后端都被视为 Service 解析的候选对象。如需详细了解该字段,请参阅服务内部流量政策

GKE Dataplane V2 和 kube-proxy

除了在使用 GKE 1.25 及更早版本的 Windows Server 节点池上以外,GKE Dataplane V2 不使用 kube-proxy

在不使用 GKE Dataplane V2 的情况下启用网络政策强制执行功能

如需了解如何在不使用 GKE Dataplane V2 的集群中启用网络政策强制执行功能,请参阅使用网络政策强制执行功能

后续步骤