Istio 1.31.0 已正式发布。这个版本的重点不只是新增几个 API，而是把生产环境里最容易出问题的几类操作做得更可控：Ambient 模式支持 waypoint 金丝雀流量分配，多集群稳定性得到改进，Envoy 可以进行可用区感知负载均衡，同时还补上了外部域名动态转发、FIPS 140-3 合规和更灵活的指标采集能力。
升级前需要注意两件事：Istio 1.31.0 官方支持 Kubernetes 1.32 至 1.36；从 Istio 1.31 开始，官方将逐步停止发布 GCP 托管的部分制品。Docker 镜像仍可从 Docker Hub 获取，Helm chart 和其他制品则迁移到了新的 Blob、GHCR 地址。生产环境不要继续依赖旧的 GCP 地址。
版本变化值得关注什么
1. Agentgateway 可以作为 waypoint
Istio 1.30 引入了实验性的 gateway-only 支持，1.31 进一步增加了 istio-agentgateway-waypoint GatewayClass，可以将 agentgateway 部署为 waypoint proxy。与此同时，ListenerSet 处理以及 agentgateway 后端的 mTLS 连接问题也得到修复。
这意味着采用 Ambient 模式时，团队可以把 waypoint 当作独立的流量治理边界，并逐步将特定服务或命名空间切换到新的代理实现。
2. Ambient waypoint 支持加权金丝雀
服务或命名空间现在可以同时引用 primary waypoint 和 canary waypoint：
istio.io/use-waypoint-canary指定服务使用的 canary waypoint。istio.io/use-waypoint-canary-namespace指定 canary waypoint 所在命名空间。istio.io/use-waypoint-canary-weight控制进入 canary waypoint 的流量比例。
这种方式不要求客户端修改配置，可以先把 5% 或 10% 的网格内连接送往 canary waypoint，再根据指标逐步扩大比例。需要注意，waypoint 配置本身仍应保持兼容，灰度期间要重点观察延迟、错误率、连接数和代理资源消耗。
3. 多集群 Ambient 稳定性提升
1.31 包含大量 Ambient 模式修复，尤其集中在多集群部署场景：凭据轮换不再容易造成过期 snapshot 或丢失 endpoint shard，多处内存泄漏和 goroutine 泄漏得到修复。CNI node agent 还修复了并发 map 写入 panic、文件描述符泄漏，以及 Pod 删除期间可能出现的死锁。
对使用多集群 Ambient 的团队来说，升级验证不能只覆盖单集群服务调用，还应包括凭据轮换、节点重启、Pod 删除和跨集群端点变化。
流量管理开始更贴近生产网络
可用区感知负载均衡
DestinationRule.TrafficPolicy.LoadBalancerSettings 和 MeshConfig 新增 zoneAwareLbSetting。启用后，Envoy 会优先把流量发送到与下游代理处于同一可用区的端点；只有本地容量不足时，才溢出到其他可用区。
这和已有的 localityLbSetting 不同：后者通常依赖静态 locality 权重，而 zone-aware 方案由 Envoy 根据可用容量自动处理区域级路由。跨地域故障转移顺序和基于标签的优先级层级仍可以叠加使用。
可以这样为某个服务配置一个最小示例，运行前请根据集群实际标签确认区域字段和 Istio API 版本：
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: payments
namespace: shop
spec:
host: payments.shop.svc.cluster.local
trafficPolicy:
loadBalancer:
zoneAwareLbSetting:
enabled: true
Mesh 级默认流量策略
新的 MeshConfig.defaultTrafficPolicy 可以为整个网格设置默认的 connectionPool 和 outlierDetection。如果某个 DestinationRule 显式设置了对应 block，就覆盖网格基线；没有设置的字段则继承 mesh 默认值，而不是直接回到 Istio 内置默认值。
这适合统一定义连接池上限和异常端点驱逐策略，但也会扩大配置的影响范围。上线前应盘点已有 DestinationRule，并在测试环境验证长连接、重试和故障摘除行为。
未知主机的动态 DNS 转发
在 outbound traffic policy 中使用 ALLOW_ANY_DYNAMIC_DNS 后，HTTP 请求的 Host 头可以在请求时交给 Envoy Dynamic Forward Proxy 解析，从而减少为每个外部域名创建 ServiceEntry 的需要。非 HTTP 流量仍使用 PassthroughCluster，上游 TLS origination 可以通过 meshConfig.outboundTrafficPolicy.tls 配置。
这个能力方便接入大量动态外部域名，但也会改变出口控制面：域名解析、DNS 可用性、审计和安全策略都需要重新评估。对必须显式登记外部依赖的环境，ServiceEntry 仍然更合适。
安全、网关与可观测性
Istio 1.31 新增 FIPS 140-3 合规策略。设置 COMPLIANCE_POLICY=fips-140-3 后，TLS 至少使用 1.2，并限制为符合 FIPS 的密码套件和 P-256/P-384 曲线；Go 组件需要使用 Go 1.24 以上并通过 GOFIPS140=v1.0.0 构建。启用前应确认镜像构建链路和底层加密库都满足组织的合规要求。
AuthorizationPolicy 的 Source 新增 trustDomains 和 notTrustDomains，可以根据对端证书推导出的 trust domain 允许或排除请求。Gateway API 的 AllowInsecureFallback 支持网关请求并尝试验证客户端证书；即使没有证书或验证失败，也可以允许连接，并通过 x-forwarded-client-cert 将信息交给后端自行判断。这个选项必须配合后端校验逻辑使用，否则容易把“可选客户端证书”误当成“已完成身份认证”。
此外，严格网关合并默认开启，PILOT_ENABLE_STRICT_GATEWAY_MERGING 可避免 Istio Gateway CRD 跨命名空间合并到由 Gateway API 管理的代理中。MCP 配置服务端点也要求经过验证的控制面身份，标准 sidecar、gateway 和 ztunnel 流量不受此项影响。
指标方面，Pod 可以使用 prometheus.istio.io/scrape-targets 声明多个应用指标端点，格式为逗号分隔的 port:path 列表；pilot-agent 会并发抓取并合并结果。还可以通过 ENVOY_SECURE_METRICS_PORT 和 ENVOY_SECURE_MERGED_METRICS_PORT 暴露受 mTLS 保护的抓取端口，并用 PILOT_AGENT_MERGE_ENVOY_STATS=false 关闭 Envoy stats 合并。
例如，以下 Pod 注解可用于声明两个应用指标端点，端口和路径需要替换为容器实际监听值：
apiVersion: v1
kind: Pod
metadata:
name: checkout
namespace: shop
annotations:
prometheus.istio.io/scrape-targets: "8080:/metrics,9090:/internal/metrics"
spec:
containers:
- name: checkout
image: example/checkout:1.0.0
ports:
- containerPort: 8080
- containerPort: 9090
升级时可以这样落地
先确认 Kubernetes 版本和当前 Istio 制品来源：
kubectl version
istioctl version
istioctl x precheck
确认预检通过后，在隔离环境生成新版本清单并审查差异。1.31 的 manifest generate -o 可以直接把生成结果写入文件：
istioctl manifest generate \
--set profile=ambient \
-o istio-1.31.0.yaml
kubectl diff -f istio-1.31.0.yaml
生产升级建议分阶段进行：先升级控制面，再观察 Pilot、ztunnel、网关和业务代理的资源与错误指标；多集群环境额外执行凭据轮换、节点重启、Pod 删除和跨集群访问测试。若使用 Helm 或自动化流水线，也要同步替换旧的 GCP 制品地址，并验证 Docker Hub、Blob 和 GHCR 的访问权限。
采用建议
Istio 1.31.0 最有价值的变化集中在渐进式发布和运行时治理：waypoint 金丝雀降低了 Ambient 配置变更的发布风险，zone-aware 负载均衡有助于降低跨可用区成本和延迟，mesh 级默认策略则减少了重复配置。
升级前可以按这份清单检查：
- Kubernetes 是否处于 1.32 至 1.36 支持范围内。
- 镜像、Helm chart 和安装脚本是否仍引用旧 GCP 地址。
- 是否依赖 Ambient 多集群，并准备了凭据轮换和节点级故障测试。
- 是否需要显式管理外部域名；若需要，谨慎启用动态 DNS 转发。
- 开启 FIPS 140-3 前，是否完成 Go、镜像和加密库的合规验证。
DestinationRule、Gateway、AuthorizationPolicy 和 Prometheus 抓取配置是否需要回归测试。
对于生产网格，不建议把所有新特性一次性打开。先完成版本和制品迁移，再选择 waypoint 灰度、区域感知负载均衡或安全策略中的一个场景验证，能更容易定位升级带来的行为变化。