Istio 1.31 拥抱 AI 智能体：agentgateway 进网格，同时告别 Google Cloud

服务网格也要接 AI 智能体的活了。8 月 31 日发布的 Istio 1.31，允许团队用新的 GatewayClass 在 ambient 网格中把 agentgateway 作为七层 waypoint 代理运行。但同一版本里，还藏着一个不太起眼的动作：停止向 Google Cloud 发布容器镜像和 Helm Chart。

一分钟速览

• Istio 1.31 支持用 istio-agentgateway-waypoint GatewayClass，在 ambient 网格中运行 agentgateway 作为七层 waypoint
• agentgateway 是面向智能体流量的 Rust 数据平面，由 Solo.io 捐赠给 Linux 基金会
• 除普通 HTTP 外，它还能处理模型上下文协议等协议
• 同一版本停止向 Google Cloud 发布容器镜像和 Helm Chart
• 仍在使用 gcr.io/istio-release 等仓库的团队需要尽快迁移，相关服务将于 12 月退役

深度分析

为什么网格要懂”智能体协议”

agentgateway 的关键在于它理解的东西不一样。传统网关处理的是 HTTP 请求，而智能体之间的流量涉及模型上下文协议（MCP）这类新协议，还伴随着长连接、流式输出、工具调用等特征。Istio 1.31 把 agentgateway 作为七层 waypoint 接进 ambient 网格，等于给服务网格补上了一块面向 AI 流量的拼图。

这次集成建立在 1.30 中新增的实验性纯网关集成之上，1.31 还修复了 agentgateway 后端的 ListenerSet 处理和 mTLS 连接问题。1.31.1 又修掉了一个坑：仅被引用为金丝雀的 agentgateway waypoint 拿不到路由和策略，导致迁移过去的连接被拒绝。

金丝雀 waypoint：不打扰客户端也能灰度

流量迁移目前处于 Alpha 阶段：服务或命名空间可以通过 use-waypoint-canary 标签，在主 waypoint 之外指定一个金丝雀 waypoint，再用 use-waypoint-canary-weight 注解控制新连接中流向金丝雀的比例，无需修改客户端。需要注意的是，已经建立的连接不会迁移，所以长连接场景下流量拆分的效果会延迟显现。

告别 Google Cloud

托管平台的迁移是这次更”硬”的变化。据 Istio 博客，由于资金模式变化，项目今年正把全部基础设施从 Google Cloud Platform 迁移到 AWS。下一次计划内断供测试在 10 月 13 日进行，最终测试将从 12 月 8 日持续到 12 月 9 日。验证镜像签名的团队还要注意密钥轮换：1.31.0 用 istio-key.pub，1.31.1 及后续版本用 istio-key-v2.pub。

数据支撑

• 版本支持：Istio 1.31.0 支持 Kubernetes 1.32 至 1.36
• 发布时间线：1.31（8 月 31 日）、1.31.1（9 月 21 日）
• 迁移节点：10 月 13 日计划内断供测试，12 月旧服务退役

趋势洞察

服务网格正在从”管微服务”走向”管智能体”。当企业内部出现大量自主运行的 Agent，流量治理的对象就从固定服务变成了行为不确定的智能体，这对网关的理解能力提出了新要求。与此同时，Istio 离开 Google Cloud、转投 AWS，也说明即便是最成熟的开源基础设施项目，其可持续性依然取决于资金与治理结构——这对所有依赖开源基础设施的团队，都是个提醒。

对使用者意味着什么

对已经在跑 Istio 的团队来说，这次升级需要分成两件事看。技术侧是可选的新能力：如果业务里有智能体流量、需要处理 MCP 这类新协议，agentgateway waypoint 值得一试，但要记住相关流量迁移仍是 Alpha，标签和行为都可能变化。运维侧则是必须处理的迁移：仍在使用 gcr.io/istio-release、registry.istio.io 或 Google 托管 Helm 仓库的团队，需要在 12 月前完成切换，并同步更新镜像签名密钥。

结语

一手拥抱 AI 智能体，一手告别 Google Cloud。Istio 1.31 的两个动作，恰好概括了基础设施圈的当下：向前看，也向后清算。