Istio 1.30.3：集中修复 Ambient、XDS 推送与证书轮换问题

2026-07-16 33 预计阅读时间: 1 分钟
来源: istio.io AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

Istio 1.30.3 是一次以稳定性为核心的补丁发布。它没有引入大规模功能变更，而是集中处理 1.30.2 到 1.30.3 之间发现的控制面扩展性、Ambient 模式、证书轮换、多集群同步和优雅退出问题。对于使用 Waypoint、GitOps 或远程集群的团队，这次升级的价值尤其明确。

XDS 推送不再轻易拖高控制面负载

Istio 1.30 曾出现一个影响 GitOps 集群的问题：即使 VirtualService 只发生元数据变化，例如 Helm 注解、Argo CD 标签或 kubectl.kubernetes.io/last-applied-configuration 更新，也可能触发面向所有代理的 XDS 推送。

在拥有大量 VirtualService 的集群里，持续同步工具会频繁更新元数据。这类更新本来没有改变流量规则，却可能增加 Istiod CPU 消耗和配置推送延迟。1.30.3 恢复了更严格的判断：只有 spec 或 istio.io 相关标签、注解发生变化时，才触发相应推送。

Ambient 模式也获得了更细粒度的地址更新机制。工作负载或服务地址变化产生的 XDS 推送，现在只发送给受影响的 Waypoint，而不是广播给所有 Waypoint 和代理。这项优化直接减少了大规模 Ambient 网格中的无效计算和网络传输。

如果升级后怀疑新机制影响了配置传播，可以临时关闭作用域推送，用它进行故障隔离：

kubectl -n istio-system set env deployment/istiod \
  AMBIENT_SCOPED_ADDRESS_PUSHES=false

kubectl -n istio-system rollout status deployment/istiod

这会扩大推送范围，因此更适合作为诊断手段，而不是长期配置。恢复默认行为时执行：

kubectl -n istio-system set env deployment/istiod \
  AMBIENT_SCOPED_ADDRESS_PUSHES-

如果使用 revision 安装或自定义了 Istiod Deployment 名称，需要将命令中的 deployment/istiod 替换为实际名称。

证书、多集群与非 Kubernetes 工作负载更可靠

这次发布修复了几个容易演变成长时间故障的问题。

挂载为文件的 Kubernetes Secret 在第二次及后续轮换时，pilot-agent 可能漏掉证书重新加载。1.30.3 修复后，连续证书轮换不再依赖 Pod 重启才能稳定生效。

多集群场景中，Istiod 过去可能无法及时加载更新后的远程集群 Secret，例如轮换访问令牌后，必须重启 Istiod 才能恢复。更严重时，新集群注册表会在同步过程中死锁，使远程集群的服务注册信息持续陈旧。该问题也在本版本中修复。

非 Kubernetes 工作负载还有一个升级边界需要特别处理：新版本可以把 HBONE 能力传播到自动注册的 WorkloadEntry，但升级前已经注册的资源不会自动改变。它们仍可能继续走明文连接，直到重新注册，或者显式添加隧道标签。

可以先找出自动注册的 WorkloadEntry，再根据实际接入方式逐个确认：

kubectl get workloadentry -A \
  -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TUNNEL:.metadata.labels.networking\.istio\.io/tunnel'

确认工作负载支持并应当使用 HBONE 后，可以这样补标签：

kubectl -n app-ns label workloadentry vm-api-01 \
  networking.istio.io/tunnel=http --overwrite

运行前需要替换命名空间和资源名。不要批量给尚未验证兼容性的虚拟机或裸机工作负载打标签，否则可能直接改变它们的数据路径。

Waypoint 与 Ambient 数据路径修复

1.30.3 修正了多项 Waypoint 行为：

  • 引用其他命名空间 Waypoint 的 Service，现在会包含其所在范围应生效的命名空间级 Telemetry 配置。
  • 网格级 defaultHttpRetryPolicy 会正确应用于连接到 Waypoint 的本地服务入站路由。
  • 应用命名空间中的 WasmPlugin 通过 targetRefs 指向 Service 时，不再因为 LDS 与 ECDS 的跨命名空间判断不一致而导致 Waypoint 启动后反复崩溃。
  • 目的服务配置 L7 AuthorizationPolicy 时，跨网络流量通过东西向网关不再被错误生成的 deny-all RBAC 过滤器拦截。
  • Ambient CNI 节点代理修复了 Pod 删除事件与 ztunnel 重连并发时可能阻塞 ZDS 服务器的死锁。
  • Istiod 会清理失败 Pod IP 对应的 needResync 条目，避免这些记录持续累积造成内存泄漏。

优雅退出也得到修复。过去，Ambient ingress gateway 和 Waypoint 中的 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 可能永远无法触发，因为 pilot-agent 把 Envoy 的 HBONE 内部监听器连接也算作活跃业务连接。代理只能一直等到 terminationGracePeriodSeconds 到期。1.30.3 会排除这些内部连接，使零活跃连接退出机制能够按预期工作。

升级后可以这样观察 Waypoint 的重启、就绪和退出状态：

kubectl get pods -A -l gateway.networking.k8s.io/gateway-name -o wide

kubectl get events -A \
  --sort-by='.lastTimestamp' | tail -n 50

kubectl -n app-ns logs deployment/app-waypoint \
  -c istio-proxy --since=10m

第三条命令中的命名空间和 Deployment 名称需要按集群实际资源调整。

自定义 CNI 未就绪污点

Istio 1.30.3 允许通过 PILOT_NODE_UNTAINT_CONTROLLERS_TAINT_NAME 为 Pilot 的节点去污点控制器指定自定义污点名。默认值仍是 cni.istio.io/not-ready。

如果平台团队已经使用自定义污点标记 CNI 尚未准备好的节点，可以这样实践：

kubectl -n istio-system set env deployment/istiod \
  PILOT_NODE_UNTAINT_CONTROLLERS_TAINT_NAME=mesh.example.com/cni-not-ready

kubectl -n istio-system rollout status deployment/istiod
kubectl get nodes -o custom-columns='NAME:.metadata.name,TAINTS:.spec.taints'

这里的环境变量值必须和节点上的实际污点 key 一致。配置错误可能导致污点无法移除，进而让依赖该污点策略的工作负载长期无法调度。

升级时应重点验证什么

这虽然是补丁版本，但涉及证书、服务发现、XDS 和 Ambient 数据路径，仍应采用分阶段升级。

  1. 记录升级前 Istiod CPU、内存、XDS 推送耗时和代理同步状态，特别关注大量使用 Argo CD 或 Helm 管理 VirtualService 的集群。
  2. 在测试环境连续轮换至少两次文件挂载证书，确认代理加载的是最新证书，而不是只验证第一次轮换。
  3. 多集群环境应轮换一份远程集群凭据，并确认服务注册信息更新，不再依赖重启 Istiod。
  4. 检查历史自动注册的 WorkloadEntry，决定重新注册还是补充 networking.istio.io/tunnel=http 标签。
  5. 对 Waypoint 执行滚动终止测试，确认连接清空后能及时退出，同时验证重试、Telemetry、WasmPlugin 和跨网络授权策略。
  6. 升级后持续观察 Istiod 日志与资源曲线。只有在定位 Ambient 地址推送异常时，才考虑临时设置 AMBIENT_SCOPED_ADDRESS_PUSHES=false。

Istio 1.30.3 的主要收益不是新增 API，而是减少那些只有在持续同步、高频轮换或大规模 Ambient 部署中才会暴露的故障。已经运行 1.30.x 的集群通常值得优先评估该补丁，但 HBONE 标签、远程集群凭据和自定义污点都带有明确的运维边界，不能仅凭一次控制面滚动升级就认为迁移已经完成。

# AI # Go # Istio # Kubernetes # LLM # Service Mesh # 云原生 # 后端

相关推荐