GKE Dataplane V2

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

在阅读本页内容之前，您应先了解 GKE 集群中的网络。

GKE Dataplane V2 概览

GKE Dataplane V2 是专为 Kubernetes 网络优化的 GKE 和 GKE 集群数据平面。GKE Dataplane V2 可提供：

  • GKE 和所有 GKE 集群环境中的网络体验一致。如需了解支持 GKE Dataplane V2 的环境，请参阅 GKE Dataplane V2 的可用性。
  • 可实时查看网络活动。
  • 更简单的架构，可更轻松管理集群并进行问题排查。

GKE Dataplane V2 为 1.22.7-gke.1500 及更高版本、1.23.4-gke.1500 及更高版本以及 1.24 及更高版本中的所有新 Autopilot 集群启用。

GKE Dataplane V2 的工作原理

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

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

GKE 将 GKE Dataplane V2 控制器作为名为 anetd 的 DaemonSet 部署到集群中的每个节点。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 映射，该映射目前限制为所有服务 64,000 个端点。

安全

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

运维

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

一致性

GKE Dataplane V2 可在 GKE 和其他 GKE 集群环境上提供相同的功能。如需了解详情，请参阅 GKE Dataplane V2 的可用性。

GKE Dataplane V2 技术规范

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

指定 GKE GKE on VMware Google Distributed Cloud Virtual for Bare Metal
每个集群的节点数 5000* 500 500
每个集群的 Pod 数 5 万 15000 27500
每个集群的 LoadBalancer 服务数 750 500† 1000

GKE Dataplane V2 维护一个服务映射，以跟踪哪些服务将哪些 Pod 称为后端。在所有服务中汇总的每项服务的 Pod 后端数量必须全部适合服务映射，其中可以包含多达 64000 个条目。如果超出此限制，您的集群可能无法按预期工作。

* 从 Kubernetes 1.23 版开始，每个 Dataplane v2 集群限额已从 500 个节点提高到 5000 个节点，并对集群施行了以下附加条件：

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

† GKE on VMware 支持的 LoadBalancer 服务数量取决于所使用的负载均衡器模式。在使用捆绑式负载均衡模式 (Seesaw) 时，GKE on VMware 支持 500 个 LoadBalancer 服务，并在将集成负载均衡模式与 F5 结合使用时支持 250 个 LoadBalancer 服务。如需了解详情，请参阅可扩缩性。

限制

GKE、GKE on VMware 以及其他所有环境存在以下限制：

  • GKE Dataplane V2 只能在创建新集群时启用。现有集群无法升级为使用 GKE Dataplane V2。
  • 如果您启用具有 NodeLocal DNSCache 的 GKE Dataplane V2，则无法使用 dnsPolicy: ClusterFirstWithHostNet 配置 Pod，或者 Pod 会遇到 DNS 解析错误。从 1.20.12-gke.500（稳定版）开始解除了此限制。
  • 从 GKE 1.21.5-gke.1300 版开始，GKE Dataplane V2 不支持 CiliumNetworkPolicy 或 CiliumClusterwideNetworkPolicy CRD API。
  • 不支持手动创建与 NodePort 类型的 Service 关联的内部直通网络负载均衡器。
  • 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：代理终止端点。
  • 对于在具有运行 1.25 版或更早版本的 GKE Dataplane V2、默认 SNAT 和 PUPI 范围的集群上创建的 NodePort Service，需要将 Pod 的 PUPI 范围添加到 nonMasqueradeCIDRs (ip-masq-agent ConfigMap) 中，以避免连接问题。
  • 在某些情况下，GKE Dataplane V2 代理 Pod (anetd) 可能会消耗大量 CPU 资源，每个实例多达两到三个 vCPU。当节点上有大量 TCP 连接打开和关闭时，就会发生这种情况。为缓解此问题，我们建议为相关工作负载实现 HTTP 调用和连接池 keep-alive。

GKE Dataplane V2 和 kube-proxy

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

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

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

后续步骤