Istio 1.31 引入 agentgateway 智能体网关节点，并正式启动从 Google Cloud 向 AWS 的基础设施迁移

一句话结论

Istio 1.31 支持智能体流量代理并调整云服务托管平台，运维团队需在年底前完成镜像源迁移。

关键要点

• Istio 1.31 新增 `istio-agentgateway-waypoint` GatewayClass，可在网格中将 agentgateway 作为七层代理节点运行。
• 版本停止向 Google Cloud 提供镜像与 Helm Chart，旧仓库 10 月 13 日断供测试，12 月正式退役。
• 流量管理新增 `use-waypoint-canary` 标签与权重注解，可配置比例将新建连接导向金丝雀节点。
• 路由配置新增 `zoneAwareLbSetting` 字段，允许按可用区自动溢出，替代静态百分比策略。
• 新增 `fips-140-3` 合规策略值，要求组件以 Go 1.24 及以上版本编译以通过合规验证。

背景与事实

Istio 核心项目于 8 月 31 日发布了 1.31 版本，该版本兼容 Kubernetes 1.32 至 1.36 版本。此版本在功能层面重点扩展了数据平面对智能体应用的支持。新引入的 `istio-agentgateway-waypoint` 网关类允许管理员在 ambient（非侵入式）网格架构中部署 agentgateway。该组件是一个基于 Rust 语言编写的专用数据平面，最初由 Solo.io 开发并捐赠给 Linux 基金会。与传统的 HTTP 代理不同，agentgateway 针对智能体工作负载的通信模式进行了优化，能够直接解析和转发模型上下文协议（MCP）等新型协议，从而降低了处理大型语言模型交互时的复杂性。为了配合这一架构演进，Istio 修复了后端 ListenerSet 处理和 mTLS（双向 TLS）连接相关的兼容性缺陷，使代理节点间的安全通信更加稳定。

在流量控制机制上，该版本确立了针对代理节点自身的灰度发布能力。运维人员通过为服务或命名空间指定 `use-waypoint-canary` 标签，可以定义一套主节点与金丝雀节点并存的配置。随后，利用 `use-waypoint-canary-weight` 注解，系统能够按照预设的百分比将新建的网格内连接路由至新的金丝雀节点。需要注意的是，此机制仅作用于新建立的 TCP 连接，对于已经建立的长连接，流量拆分效果不会立即体现。由于该能力目前处于 Alpha（实验）阶段，系统维护者明确警告其标签结构、注解行为及底层实现可能在后续版本中发生变更，生产环境需做好兼容预案。

基础设施托管方面的调整同样是本次版本发布的重大内容。Istio 官方宣布停止向 Google Cloud 发布容器镜像和 Helm Chart 包。由 Solo.io 的 Keith Mattix 和 Microsoft 的 Steven Jin 撰写的官方博客解释了此次变动的原因：由于项目资金模式发生转变，Istio 基础设施正在整体从 Google Cloud Platform 迁移至 Amazon Web Services（AWS）。为了保障平滑过渡，官方设定了明确的时间表：10 月 13 日 15:00 至 18:00（UTC）将进行下一次计划内断供测试，届时旧端点将短暂停用；而最终的彻底退役测试安排在 12 月 8 日 15:00 至 12 月 9 日 15:00（UTC）。仍在使用 `gcr.io/istio-release` 或 Google 托管 Helm 仓库的团队，必须在此期间完成客户端配置的切换。此外，验证团队需要特别注意密钥更新，1.31.0 版本使用 `istio-key.pub`，而 1.31.1 及后续版本已更换为 `istio-key-v2.pub`。

针对大中型服务网格的性能与合规性需求，1.31 版本在底层负载均衡与安全策略上引入了深度优化。负载均衡方面，`DestinationRule` 和 `MeshConfig` 资源新增了 `zoneAwareLbSetting` 字段。该机制赋予 Envoy 代理自动感知能力，使其优先将请求路由至与下游代理同处的可用区端点，只有在本地计算资源耗尽时，才会将流量溢出至其他可用区。这一设计取代了旧的 `localityLbSetting`，用户不再需要手动维护静态的流量分配百分比，从而降低了大型跨区域集群的维护成本。出站流量处理也得到增强，新增的 `ALLOW_ANY_DYNAMIC_DNS` 模式允许代理在请求发出时直接解析 HTTP Host 标头中的主机名，消除了为每一个外部微服务或 API 逐一编写 `ServiceEntry` 资源的工作量。

安全合规方面，该版本为金融与政府等强监管行业提供了更严格的加密标准支持。环境变量 `COMPLIANCE_POLICY` 新增了 `fips-140-3` 取值，一旦启用，系统强制 TLS 版本不低于 1.2，并过滤出符合美国联邦信息处理标准（FIPS）的密码套件，仅允许 P-256 和 P-384 椭圆曲线。官方文档特别强调，仅仅修改运行时的策略参数是无效的，部署者必须确保 Istio 的 Go 语言组件使用 Go 1.24 或更高版本，且必须采用 `GOFIPS140=v1.0.0` 或更高版本的已验证构建二进制文件。在准入控制层面，`AuthorizationPolicy` 资源扩展了 `trustDomains` 与 `notTrustDomains` 字段，这使得网格策略能够根据通信对等端证书中提取的信任域进行匹配或排除，为多租户或跨信任边界的安全隔离提供了更细致的粒度。

影响分析

对于国内使用 Istio 构建微服务架构或云原生应用的大型企业，本次更新在运维策略和合规审计上带来了直接影响。首先，基础设施源头的迁移将打破长期依赖的自动化流水线。大量团队在 CI/CD 流程或 GitOps 工具中硬编码了 Google Cloud 的镜像仓库地址，若未在 10 月底前的窗口期内调整拉取策略与签名验证密钥，极可能在随后的版本升级中遭遇构建失败或部署阻断。因此，运维团队应立即评估内部镜像同步系统的改动，并建立针对 AWS 新源头的拉取镜像机制。其次，对于致力于企业级合规的机构，FIPS 140-3 标准的引入降低了安全审计的门槛，但提升了构建系统的复杂度。安全团队必须介入软件供应链环节，强制要求 CI 系统在编译代理组件时注入合规的编译参数。

此外，智能体应用架构的演进正在改变流量管理的边界。随着企业大模型应用与各类 AI 智能体（Agent）的落地，传统的基于 REST API 或 gRPC 的流量拓扑正在向携带复杂状态和新型协议（如 MCP）的方向演变。Istio 引入专为智能体优化的 Rust 数据平面，意味着未来的网格层将具备对 AI 语义化协议的细粒度观测与控制能力。架构师在设计新一代服务调用链时，应考虑预留 agentgateway 作为边缘与核心数据平面之间的专用节点，通过灰度机制实现平滑切换。然而，鉴于该机制尚处实验阶段，企业在生产环境应用此特性时，必须建立严格的监控指标体系，并对标签与注解可能发生的底层变动保持警惕，防止因社区代码迭代导致的配置意外失效。

适用边界

上述关于流量金丝雀拆分功能的分析，严格限定在代理节点（Waypoint）的替换与升级场景，并不适用于传统的边缘网关（Ingress/Edge Gateway）配置。由于该机制对新建连接有依赖性，对于长连接（如 WebSocket 流式通信、数据库持久连接）极密集的架构，流量比例变更无法实时生效，因此不适用于要求秒级流量熔断或瞬时业务回滚的极端敏感场景。同时，FIPS 140-3 合规策略的约束是全局且排他性的，它不适用于开发测试环境或允许使用非对称椭圆曲线（如 secp256k1）的特定区块链交互场景。最后，基于可用区的自动溢出负载均衡机制依赖于 Kubernetes 集群具备完整的拓扑认知能力，对于缺乏节点区域标签（`topology.kubernetes.io/zone`）的裸金属部署或极简容器云环境，该功能无法生效，相关配置将被忽略。

孤本观察

从社区治理与基础设施演进的视角来看，Istio 放弃长期托管方 Google 并转向 AWS，实质上反映了云原生项目在后开源时代对资金模式与工程自主权的重新考量。结合其对专用智能体协议代理的投入，可以看出该社区正在试图将网格的控制边界从传统的 L4/L7 网络流量，进一步下沉并延伸至 AI 时代的业务逻辑交互层。

来源：InfoQ 中文 AI