实验：TPU、GKE Managed DRANET 与多集群推理网关

当您的工作负载在一个区域失败，但您仍需要访问服务时会发生什么？这是可用性和持续运行的常见情况。随着 Kubernetes 生态系统最近的功能增强，例如 动态资源分配 (DRA) 和 推理网关，我决定在 Google Cloud 上对这些功能进行实验，以测试一个简单的 AI 推理工作负载。

在本文中，我们将探讨此设置，您也可以直接跳转到本 codelab 的详细配置：构建多集群 GKE 推理网关，搭配 TPUs、Cloud Storage FUSE 和托管 DRANET。

构建组件

为构建此实验，使用以下产品、功能和工具：

• Google Kubernetes Engine（GKE）托管 DRANET：这是一个托管功能，允许您请求并共享 Pod 之间的资源。它支持 GPU 和 TPU。在此测试中，两个不同区域均使用了 TPU，并通过托管 DRANET 分配网络资源。

• **多集群 GKE 推理网关**：在多个 GKE 集群之间负载均衡您的 AI/ML 推理工作负载。该功能适用于故障转移场景，这正是我实验旨在测试的目标。支持此功能的是 多集群跨区域内部应用负载均衡器gke-l7-cross-regional-internal-managed-mc

• **Cloud Storage FUSE**：提供一种将数据、模型、检查点和日志直接存储在 Cloud Storage 中的方法。为了加快部署速度，下载了一个开源的 Gemma 模型存放在该存储中供检索。

• 虚拟私有云 (VPC)：作为基础的全球网络，提供内部负载均衡器和计算节点之间隔离且安全的通信。

• **GKE Fleets**：Fleets 将独立的区域集群统一管理在一个控制平面下。

• **TPU v6e**：Google 自定义的 AI 加速器，提供服务模型所需的高性能计算能力。所使用的 VM 家族类型为 ct6e-standard-4t，配置为 2x2 切片

设计模式示例

目标是在两个不同区域的 GKE 集群上部署一个 LLM 模型（Gemma 3）。每个集群将使用 4 个 TPU v6e 芯片。模型应存储在 Cloud Storage 中。工作负载由支持多集群的 GKE 推理网关提供服务。流量应路由至离用户最近的区域，若某一区域发生故障，则自动切换至另一区域。

组合实现

要为项目在两个区域获取 TPU 访问权限，您必须确保这两个区域拥有 必要的配额。

开始： 设置环境。

• 创建一个 标准 VPC，并配置防火墙规则和与预留资源在同一区域的子网。

• 创建一个 仅代理子网，该子网将用于与附加到 GKE 推理网关的内部区域应用负载均衡器配合使用。

• 设置防火墙规则，允许流量和健康检查。

• 在两个区域为网关预留静态内部 IP 地址。

• 配置一个 Cloud Storage FUSE 存储桶，并设置专用 IAM 服务账号。将其绑定到 Kubernetes 工作负载身份，以便您的 Pod 可以安全挂载存储桶并直接读取模型权重。

下一步： 创建标准 GKE 集群和节点池。

• 在您选择的区域部署两个独立的 GKE 集群。

• 在集群创建过程中启用网关 API (--gateway-api=standard) 和 Cloud Storage FUSE CSI 驱动程序 (--addons GcsFuseCsiDriver)。

• 为两个集群分别创建专用的 TPU v6e 节点池 (ct6e-standard-4t)。

• 通过设置标志 ---accelerator-network-profile=auto 和 --node-labels=cloud.google.com/gke-networking-dra-driver=true，在这些 TPU 节点池 上启用托管 DRANET。

下一步： 通过 Fleet 注册建立全局网络。

• 根据 舰队创建和注册设置指南，将两个 GKE 集群注册到统一的 GKE Fleet。

• 在您的舰队上启用多集群服务发现和多集群入口。

• 将您的主区域指定为配置中心，作为跨区域路由规则的控制平面。

下一步： 部署 AI 工作负载。

• 使用临时 Kubernetes 作业直接将 Gemma 3 (gemma-3-27b-it) 模型权重下载到您的 Cloud Storage 存储桶中。

• 定义一个 ResourceClaimTemplate，明确请求托管的 DRANET 设备类（deviceClassName: netdev.google.com），并将分配模式设置为 "All"。

• 在两个区域的 TPU 节点上部署您的推理服务器（例如 vLLM）。确保 Pod 规格使用节点选择器匹配 2x2 TPU 拓扑结构，请求恰好 4 个 TPU，并挂载 netdev 声明。这将确保您的 Pod 同时利用专用加速器网络和标准以太网。

下一步： 配置多集群推理网关。

• 安装必要的自定义资源定义（CRD），使 Kubernetes 能够处理如 InferenceObjective 等专用路由对象。

• 部署 AutoscalingMetric 以跟踪硬件利用率，例如 KV 缓存使用情况。

• 使用 Helm 将两个区域的独立 AI 部署组合成一个逻辑上的 InferencePool。

• 部署跨区域网关及其关联的 HTTPRoute，以管理全球传入流量。

• 对池应用健康检查和后端策略，确保负载均衡基于您自定义的硬件指标。

配置一个 InferenceObjective，指示网关将提示路由至可用性最高的区域，避免将请求发送至过载的 TPU。

测试故障转移

通过模拟主区域中断来验证高可用架构。一旦主部署被下线，网关会自动检测到故障并无缝地将所有后续用户请求重定向至活跃的次级集群，从而在不丢弃流量的情况下确保持续可用性。

下一步

深入体验动手实验和更多关于这些功能的信息，请参阅以下内容。

想提问、了解更多或分享想法？请在 Linkedin 上与我联系。

发布于

• 开发者与实践者
• 网络