**发布时间:** 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全文翻译 -->