[解决方案] GKE 网络接口十年：从核心连接到人工智能骨干网

**发布时间:** 2025-09-18 **厂商:** GCP **类型:** BLOG **原始链接:** https://cloud.google.com/blog/products/networking/gke-network-interface-from-kubenet-to-ebpfcilium-to-dranet --- <!-- AI_TASK_START: AI标题翻译 --> [解决方案] GKE 网络接口十年：从核心连接到人工智能骨干网 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 解决方案分析 ## 解决方案概述 该文档详细阐述了 **Google Kubernetes Engine (GKE)** 在过去十年间网络接口的演进历程，展示了其如何从满足核心连接需求发展为支撑大规模 **AI/ML 工作负载** 的网络骨干。解决方案的核心是不断迭代的 **容器网络接口 (CNI)** 实现，旨在为 Pod 提供高性能、安全且灵活的网络。演进路径清晰地体现了技术趋势：从基础的 `kubenet`，到与云平台深度集成的 **VPC 原生网络**，再到利用 **eBPF** 技术的 **GKE Dataplane V2**，并最终展望通过 **动态资源分配 (DRA)** 和 **Kubernetes 网络驱动 (KNDs)** 满足下一代 AI 应用的极致网络需求。该方案解决了在日益复杂的应用场景下，如何高效管理 IP 地址、提升网络性能、增强安全性和可观测性，并为特定工作负载（如 AI 训练）提供专用网络能力的核心问题。 ## 实施步骤 GKE 网络能力的演进遵循了清晰的技术迭代路径，每个阶段都为解决前一阶段的挑战并引入新的能力： 1. **奠基阶段 (2015-2017): `kubenet` 与基于路由的集群** - **技术原理:** 采用基础的 `kubenet` CNI 插件，在每个节点上创建网桥，并为 Pod 分配节点独有的 CIDR 地址段。节点间的路由依赖 Google Cloud VPC 路由规则（基于 Andromeda 网络虚拟化引擎）进行 Pod IP 范围的通告。 - **目的:** 解决容器间的基础通信问题，快速启动和运行集群。 2. **云原生集成阶段 (2018-2019): 拥抱 VPC 原生网络** - **技术原理:** 引入 **VPC 原生集群** 模式，利用 VPC 的 **别名 IP (Alias IP)** 功能，使 Pod IP 地址直接从 VPC 的子网中分配。这使得 Pod 成为 VPC 网络中的“一等公民”。 - **目的:** 解决 `kubenet` 模式下的 IP 管理复杂性和性能瓶颈，实现 GKE 与底层云网络的深度集成，并为使用 VPC 防火墙等原生能力奠定基础。此阶段也引入了 Calico 以支持网络策略。 3. **eBPF 革命阶段 (2020-至今): 推出 GKE Dataplane V2** - **技术原理:** 基于开源项目 **Cilium**，利用 **eBPF (扩展伯克利包过滤器)** 技术重构数据平面。eBPF 允许在内核空间动态执行程序，从而绕过传统的 `kube-proxy` `iptables` 规则，实现对网络包的高效处理。 - **目的:** 大幅提升网络性能和可扩展性，内置网络策略执行能力，增强网络可观测性，并为多网络、IPv6 等高级功能提供支持。Dataplane V2 已成为 GKE Autopilot 的默认选项和 GKE Standard 的推荐选项。 4. **面向 AI 的未来阶段 (2025+): 超越 CNI，探索 DRA 与 KNDs** - **技术原理:** 引入 Kubernetes 的 **动态资源分配 (DRA)** 框架，并结合 **Kubernetes 网络驱动 (KNDs)**，允许 Pod 像请求 GPU 一样动态请求和消费特定的网络资源。 - **目的:** 为 AI/ML 等需要极致吞吐量和超低延迟的工作负载提供更精细、更高效的网络资源管理能力。 ## 方案客户价值 - **简化的网络管理与集成** - 通过 VPC 原生网络，Pod IP 直接由 VPC 管理，使其可被 VPC 内其他资源直接路由，简化了 IP 地址规划和网络运维。 - **极致的性能与可扩展性** - GKE Dataplane V2 利用 eBPF 技术绕过传统内核网络路径，为服务路由和网络策略执行提供极高的数据包处理效率，显著降低延迟。 - 方案已验证可支持高达 _65,000 个节点_ 的超大规模集群，专为 AI/ML 训练和推理等苛刻工作负载优化，满足其对超高吞吐量（TB 级）和超低延迟的需求。 - **内置的增强安全性与可观测性** - Pod 作为 VPC 原生资源，可直接应用 VPC 防火墙规则进行精细化访问控制。 - Dataplane V2 内置了高效的网络策略执行引擎，无需再部署 Calico 等第三方组件。同时，基于 eBPF 的能力为网络策略日志等功能提供了深度的数据平面可观测性。 - **丰富的高级网络功能支持** - Dataplane V2 解锁了一系列高级功能，包括： - **IPv6 与双栈支持:** 满足现代化网络架构的需求。 - **多网络 (Multi-networking):** 允许 Pod 连接到多个不同的 VPC 网络，适用于网络功能虚拟化 (CNF) 和流量隔离场景。 - **服务流量导向 (Service steering):** 可将特定流量引导至虚拟防火墙等服务链进行处理。 - **Pod 持久化 IP:** 确保有状态应用或网络功能在重启后仍能保持相同的 IP 地址。 ## 涉及的相关产品 - **Google Kubernetes Engine (GKE):** 核心的托管式 Kubernetes 服务平台。 - **Google Cloud VPC:** GKE 集群所依赖的底层虚拟私有云网络，提供路由、防火墙和别名 IP 等核心能力。 - **GKE Dataplane V2:** GKE 推荐的基于 eBPF 和 Cilium 的高性能数据平面。 - **AI/ML 加速器:** 解决方案支持最新的硬件，如 **A4 实例 (NVIDIA GB200 GPU)** 和 **Trillium/Ironwood TPU**，确保网络能够匹配其计算能力。 - **Cilium:** GKE Dataplane V2 所基于的业界领先的开源 eBPF 网络项目。 ## 技术评估 - **技术先进性:** GKE 的网络演进路径清晰地展示了其对前沿技术的采纳和引领。从基础 CNI 到深度云集成，再到全面拥抱 `eBPF` 这一革命性内核技术，始终保持在行业前列。对 **DRA** 和 **KNDs** 的前瞻性探索，进一步巩固了其在满足未来 AI 工作负载网络需求方面的领先地位。 - **方案优势:** - **深度集成:** 与 GCP VPC 网络的无缝集成是其核心优势，提供了统一的管理平面、一致的安全模型和简化的操作体验。 - **卓越性能:** GKE Dataplane V2 提供的基于 `eBPF` 的数据平面，在性能、延迟和可扩展性方面均表现出色，是 AI/ML 等极端工作负载的理想选择。 - **功能完备且托管化:** Dataplane V2 将网络策略、高级网络功能和可观测性融为一体，作为一个 Google 托管组件，极大地降低了用户的运维复杂度和成本。 - **大规模验证:** 成功支持 65,000 节点的集群规模，证明了其架构在超大规模环境下的健壮性和可靠性。 - **可能的限制:** - 早期方案（如 `kubenet`）在 IP 管理和扩展性方面存在明显局限，但已被后续方案有效解决。 - 许多高级网络功能强依赖于 **GKE Dataplane V2**，这意味着用户在创建集群时需要做出正确的技术选型，否则后续可能无法使用这些功能。 ## 其他信息 - **社区贡献与开源:** Google 积极投入开源社区，并贡献了 **DRANET 项目** ([github.com/google/dranet](https://github.com/google/dranet)) 作为 Kubernetes 网络驱动 (KND) 的一个参考实现。这表明 Google 致力于与社区合作，共同定义和推动下一代 Kubernetes 网络标准的发展。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # GKE 网络接口十年演进：从核心连接到 AI 骨干网络 **原始链接:** [https://cloud.google.com/blog/products/networking/gke-network-interface-from-kubenet-to-ebpfcilium-to-dranet](https://cloud.google.com/blog/products/networking/gke-network-interface-from-kubenet-to-ebpfcilium-to-dranet) **发布时间:** 2025-09-18 **厂商:** GCP **类型:** BLOG --- 网络 # GKE 网络接口十年演进：从核心连接到 AI 骨干网络 2025 年 9 月 18 日 ##### Shrikant Kelkar 产品经理 ##### Vinay Bannai GKE 网络，高级主任软件工程师 ##### 试试 Gemini 2.5 我们最智能的模型现已在 Vertex AI 上提供 [立即试用](https://console.cloud.google.com/vertex-ai/studio/freeform) 不知不觉，Kubernetes 首次启航至今已逾十年，它从根本上改变了我们构建、部署和管理应用的方式。Google Cloud 凭借 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine) (GKE) 站在 Kubernetes 革命的前沿，为您的容器化工作负载提供了一个强大、可扩展且技术领先的平台。从那时起，Kubernetes 已成为 AI/ML 等工作负载的首选平台。 Kubernetes 的核心在于在应用程序之间共享机器资源，而 Pod 网络对于工作负载和服务之间使用 [容器网络接口](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (Container Network Interface, CNI) 进行连接至关重要。 在我们庆祝 GKE 十周年之际，让我们一同回顾我们是如何构建网络接口，为您提供高性能、安全且灵活的 Pod 网络，以及我们又是如何演进网络模型，通过 [Kubernetes 网络驱动程序](https://arxiv.org/pdf/2506.23628) (Kubernetes Network Driver) 来支持 AI 工作负载的。 让我们回顾历史，看看我们是如何一步步走到今天的。 ### **2015-2017 年：使用 kubenet 奠定 CNI 基础** 在 Kubernetes 的早期，我们需要在容器之间建立可靠的通信。对于 GKE，我们采用了一种扁平化的 IP 寻址模型，以便 Pod 和节点可以自由地与 [虚拟私有云](https://cloud.google.com/vpc?e=48754805&hl=en) (Virtual Private Cloud, VPC) 中的其他资源通信，而无需经过隧道和网关。在这些初创时期，GKE 早期的网络模型通常使用 [kubenet](https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview) 这一基础网络插件。Kubenet 通过在每个节点上创建一个网桥，并从专用于该节点的 [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) 范围为 Pod 分配 IP 地址，为集群的启动和运行提供了一种直接的方式。虽然 Google Cloud 的网络负责处理节点间的路由，但 Kubenet 负责将 Pod 连接到节点的网络，并实现节点内基本的 Pod 间通信。 在此期间，我们还引入了 [基于路由的集群](https://cloud.google.com/kubernetes-engine/docs/how-to/routes-based-cluster) (route-based clusters)，它基于 Google Cloud 路由，是 [Andromeda](https://research.google/pubs/andromeda-performance-isolation-and-velocity-at-scale-in-cloud-network-virtualization/) 引擎的一部分，该引擎为所有云网络提供支持。Andromeda 中的路由功能在使用 VPC 路由规则进行集群网络内的 IP 地址分配和路由方面发挥了关键作用。这需要在节点之间广播 Pod IP 范围。 然而，随着 Kubernetes 的采用呈爆炸式增长，应用程序的规模和复杂性不断增加，我们在管理 IP 地址和实现跨 VPC 不同部分 Pod 之间的高性能直接通信方面面临挑战。这促使我们开发一种与底层云网络更深度集成的网络解决方案。 ### **2018-2019 年：拥抱 VPC 原生网络** 为了满足这些不断变化的需求并与 Google Cloud 强大的网络功能集成，我们为 GKE 引入了 **VPC 原生网络** (VPC-native networking)。这标志着 CNI 在 GKE 中的运作方式实现了重大飞跃，其中别名 IP 范围 (alias IP ranges) (即节点中 Pod 使用的 IP 范围) 成为该解决方案的基石。VPC 原生网络成为默认和推荐的方法，帮助将 GKE 集群的规模扩大到 15000 个节点。通过 [VPC 原生集群](https://cloud.google.com/blog/products/gcp/introducing-vpc-native-clusters-for-google-kubernetes-engine?e=48754805) (VPC-native clusters)，GKE CNI 插件可确保 Pod 直接从您的 VPC 网络接收 IP 地址——它们成为您网络上的一等公民。 这一转变为我们带来了诸多好处： - **简化的 IP 管理：** GKE CNI 插件与 GKE 协同工作，直接从 VPC 分配 Pod IP，使其可直接路由，并更易于与您的其他云资源一起管理。 - **通过 VPC 集成增强安全性：** 由于 Pod IP 是 VPC 原生的，您可以将 VPC 防火墙规则直接应用于 Pod。 - **提升性能和可扩展性：** GKE CNI 插件促进了 VPC 内的直接路由，减少了开销并提高了 Pod 流量的网络吞吐量。 - **为高级 CNI 功能奠定基础：** VPC 原生网络为后续更复杂的 CNI 功能奠定了基础。 我们将 GKE 实现的 CNI 与 VPC 原生网络称为 GKE 标准网络与数据平面 v1 (dataplane v1, DPv1)。在此期间，我们还宣布了 [通过 Calico 对网络策略 (network policies) 提供正式版支持](https://cloud.google.com/blog/products/gcp/kubernetes-engine-network-policy-is-now-generally-available?e=48754805) 。网络策略允许您为集群内的流量以及 Pod 与外部世界之间的流量指定规则。 ### **2020 年至今：eBPF 革命** GKE CNI 策略的下一次重大演进伴随着 [扩展伯克利数据包过滤器](https://ebpf.io/) (extended Berkeley Packet Filter) 或 eBPF 的强大功能而来，它允许您在特权上下文中运行沙盒程序。eBPF 使得动态编程 Linux 内核变得安全，为在 CNI 层面实现网络、安全和可观测性开辟了新的可能性，而无需重新编译内核。 认识到这一潜力，Google Cloud 采纳了 [Cilium](https://cilium.io/) ，一个基于 eBPF 的领先开源 CNI 项目，并创建了 [GKE Dataplane V2](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2) (DPv2)。GKE Dataplane V2 于 2021 年 5 月达到正式可用 (GA)，代表了 GKE CNI 功能的一次重大飞跃： - **增强的性能和可扩展性：** 通过利用 eBPF，CNI 可以绕过传统的内核网络路径 (如 kube-proxy 基于 iptables 的服务路由)，实现对服务和网络策略的高效数据包处理。 - **内置网络策略执行：** GKE Dataplane V2 开箱即用地提供了 Kubernetes 网络策略执行功能，这意味着当使用 DPv2 时，您无需仅仅为了策略执行而安装或管理像 Calico 这样的独立 CNI。 - **增强的数据平面层可观测性：** eBPF 能够直接从内核深入洞察网络流。GKE Dataplane V2 为 [网络策略日志记录](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2#:~:text=When%20you%20create%20a%20cluster,and%20denied%20by%20your%20Pods) (network policy logging) 等功能提供了基础，从而提供了对 CNI 级别决策的可见性。 - **数据平面中的集成安全性：** eBPF 在 CNI 的数据平面内直接、高效且具有上下文感知地执行网络策略。 - **简化的运维：** 作为 Google 管理的 CNI 组件，GKE Dataplane V2 简化了客户工作负载的运维。 - **高级网络能力：** Dataplane V2 解锁了一系列强大的功能，这些功能在 Data Plane V1 中是不可用或更难实现的。这些包括： - [**IPv6 和双栈支持**](https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips#:~:text=Dual%2Dstack%20networking%20is%20only,or%20nodes%20are%20not%20supported.) **:** (IPv6 and dual-stack support) 使 Pod 和服务能够同时使用 IPv4 和 IPv6 地址。 - [**多网络**](https://cloud.google.com/kubernetes-engine/docs/how-to/setup-multinetwork-support-for-pods) **:** (Multi-networking) 允许 Pod 拥有多个网络接口，连接到不同的 VPC 网络或专用网络附件，这对于云原生网络功能 (cloud native network functions, CNFs) 和流量隔离等用例至关重要。 - [**服务导向**](https://cloud.google.com/kubernetes-engine/docs/concepts/about-gke-service-steering?hl=en) **:** (Service steering) 通过将特定流量引导通过集群内的一系列服务功能 (如虚拟防火墙或检查点) 来提供对流量的精细控制。 - [**Pod 的持久化 IP 地址**](https://cloud.google.com/kubernetes-engine/docs/how-to/setup-persistent-ip-addresses-on-gke-pods) **:** (Persistent IP addresses for pods) 结合 Gateway API，GKE Dataplane V2 允许 Pod 在重启或重新调度后保留相同的 IP 地址，这对于某些有状态应用或网络功能至关重要。 GKE Dataplane V2 现在是 GKE Autopilot 模式下新集群的默认 CNI，也是我们为 GKE Standard 集群推荐的选择，这突显了我们致力于提供由 eBPF 驱动的尖端网络接口的承诺。 ### **2024 年：为 AI 训练和推理扩展新高度** 2024 年，我们在 GKE 的可扩展性方面取得了里程碑式的成就，宣布 GKE 支持高达 [65,000 个节点](https://cloud.google.com/blog/products/containers-kubernetes/gke-65k-nodes-and-counting?e=48754805) 的集群。这一令人难以置信的壮举，相较于之前的限制有了显著的提升，很大程度上得益于 **GKE Dataplane V2** 强大且高度优化的架构。为如此大规模的集群提供动力，特别是对于要求苛刻的 AI/ML 训练和推理工作负载，需要一个不仅性能卓越，而且在规模上极其高效的数据平面。支撑这些 65,000 节点集群的 GKE Dataplane V2 版本专门针对极端规模和大规模 AI/ML 应用的独特性能特征进行了增强——这证明了 CNI 能够突破云原生计算的可能性边界。 对于 AI/ML 工作负载，GKE Dataplane v2 还支持不断增长的带宽需求，例如在我们最近发布的 [A4 实例](https://cloud.google.com/blog/products/compute/new-a4x-vms-powered-by-nvidia-gb200-gpus?e=48754805) 中。GKE Dataplane v2 还支持各种计算和 AI/ML 加速器，如最新的 [GB200](https://cloud.google.com/blog/products/compute/new-a4x-vms-powered-by-nvidia-gb200-gpus?e=48754805) GPU 以及 [Ironwood](https://blog.google/products/google-cloud/ironwood-tpu-age-of-inference/) 、[Trillium](https://cloud.google.com/blog/products/compute/introducing-trillium-6th-gen-tpus?e=48754805) TPU。 **对于当今的 AI/ML 工作负载，网络扮演着关键角色：** AI 和机器学习工作负载正在推动计算和网络的边界，为 GKE 网络接口带来了独特的挑战： - **极高的吞吐量：** 训练大型模型需要处理海量数据集，这要求由 GKE 网络接口调度的网络达到 Tb 级别。 - **超低延迟：** 分布式训练依赖于处理单元之间近乎瞬时的通信。 - **多网卡能力：** 为 [Pod 提供多个网络接口](https://cloud.google.com/kubernetes-engine/docs/concepts/about-multinetwork-support-for-pods) ，由 GKE Dataplane V2 的多网络功能管理，可以显著提升带宽并实现网络分段。 ### **2025 年 - 超越 CNI：应对下一代 Pod 网络挑战** **网络领域的动态资源分配 (DRA)** 一项有前途的 Kubernetes 创新是 [动态资源分配](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (dynamic resource allocation, DRA)。DRA 的引入旨在为工作负载提供一种更灵活、可扩展的方式来请求和使用 CPU 及内存之外的资源，它有望显著影响 CNI 管理和暴露网络资源的方式。虽然最初专注于 GPU 等资源，但其框架设计具有更广泛的适用性。 在 GKE 中，DRA (从 GKE 1.32.1-gke.1489001+ 版本开始提供预览版) 为更高效、更定制化的网络资源管理开辟了可能性，帮助要求苛刻的应用程序使用 Kubernetes 网络驱动程序 (Kubernetes Network Drivers, KNDs) 获得所需的网络性能。 **KNDs** 使用 **DRA** 在节点级别暴露网络资源，这些资源可以被所有 **Pod** (或所有容器) 引用。这对于 AI/ML 工作负载尤其重要，因为它们通常需要非常特定的网络能力。 ### **展望未来：塑造未来的创新** 旅程并未就此结束。随着加速工作负载的日益普及推动了 GKE 上的新架构，对 Kubernetes 网络的需求将持续增长。Kubernetes 网络驱动程序的一个参考实现是 DRANET 项目。我们期待与社区继续讨论并为 [DRANET 项目](https://github.com/google/dranet) 做出贡献。我们致力于与社区合作，提供以客户为中心的创新解决方案，以应对这些新挑战。 发布于 - [网络](https://cloud.google.com/blog/products/networking) - [容器与 Kubernetes](https://cloud.google.com/blog/products/containers-kubernetes) - [GKE](https://cloud.google.com/blog/products/kubernetes-engine) <!-- AI_TASK_END: AI全文翻译 -->