Istio 1.29.6 是一个以稳健性为核心的补丁版本。它没有引入需要重新设计流量模型的新能力，而是集中修复 Ambient 模式、非 Kubernetes 工作负载、Istiod 内存管理以及跨网络授权路径中的几个关键问题。对于正在使用 waypoint、ztunnel、east-west gateway 或自动注册 WorkloadEntry 的集群，这些修复值得尽快评估。
五项修复分别影响什么
Ambient 网关现在可以按活动连接数退出
启用 EXIT_ON_ZERO_ACTIVE_CONNECTIONS 后，代理应在活动连接归零时结束排空并退出。但在 Ambient ingress gateway 和 waypoint 上，pilot-agent 过去会把 Envoy HBONE 内部监听器中的进程内连接也算进去，例如 connect_originate、connect_terminate 和 main_internal。
这些内部连接不会像普通业务连接那样消失，因此计数始终无法归零。结果是 Pod 即使已经没有真实客户端流量，仍要一直等到 terminationGracePeriodSeconds 到期。
1.29.6 修正了这项统计。它直接改善滚动升级、缩容和节点维护时的退出速度，也减少了旧 Pod 长时间停留在 Terminating 状态的概率。
自动注册的非 Kubernetes 工作负载可以正确声明 HBONE
虚拟机等非 Kubernetes 工作负载通过自动注册生成 WorkloadEntry 时，之前没有把已声明的 HBONE 能力传播到资源上。控制面因此可能继续通过明文连接访问这些工作负载。
升级不会自动修复已经注册的资源。现有工作负载需要重新注册，或者在对应的 WorkloadEntry 上添加下面的标签：
metadata:
labels:
networking.istio.io/tunnel: http
这里的 http 表示使用 Istio 的 HBONE 隧道能力，并不是把业务协议简单改成普通 HTTP。添加标签前，应确认目标工作负载及其接入链路确实支持 HBONE，否则可能造成流量中断。
Ambient CNI 节点代理不再因竞态永久阻塞 ZDS
Ambient CNI node agent 中存在一个并发死锁：Pod 删除事件如果恰好与 ztunnel 建立或重新建立连接同时发生，ZDS 服务器可能被永久阻塞。
这类问题往往表现为节点上的新 Pod 无法及时进入 Ambient 数据平面、删除后的状态没有清理，或者必须重启节点代理才能恢复。1.29.6 修复了该竞态，对 ztunnel 重连较频繁或 Pod 变动密集的集群尤其重要。
Istiod 不再积累失败 Pod IP 的同步记录
Istiod 会通过 needResync 跟踪需要重新同步的条目。此前，关联失败 Pod IP 的条目没有被清理，长期运行后可能形成内存泄漏。
这项修复更偏向控制面的长期稳定性。升级后仍应继续观察 Istiod 的常驻内存，而不要把升级瞬间的下降当作唯一验证标准；旧进程只有在被替换后才会释放已经占用的内存。
L7 授权策略不再误伤跨网络流量
当目标服务配置了七层 AuthorizationPolicy 时，经 east-west gateway 转发的跨网络流量可能被一个错误生成的 deny-all RBAC 过滤器拦截。1.29.6 移除了这条非预期的阻断路径。
这项修复需要重点回归多网络场景，因为同一服务在集群内直连成功，并不能证明经 east-west gateway 的路径也正常。测试时应同时覆盖允许请求和应被拒绝的请求，避免只验证“请求通了”却遗漏授权策略失效的风险。
升级前可以这样盘点风险
下面的命令可以直接运行。请把 istio-system 替换为实际控制面命名空间；如果使用 revision 安装，还要分别检查每个 revision。
# 确认当前客户端和控制面版本
istioctl version
# 执行升级前兼容性检查
istioctl x precheck
# 查看 Istio 相关 Pod 及所在节点
kubectl get pods -A -o wide | grep -E 'istiod|ztunnel|istio-cni|eastwest|waypoint'
# 查找启用了 HBONE 标签的 WorkloadEntry
kubectl get workloadentry.networking.istio.io -A \
-l networking.istio.io/tunnel=http
# 列出全部 WorkloadEntry，供人工核对自动注册资源
kubectl get workloadentry.networking.istio.io -A \
-o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TUNNEL:.metadata.labels.networking\.istio\.io/tunnel,ADDRESS:.spec.address'
# 检查 Istiod 当前资源占用，需要集群已安装 metrics-server
kubectl top pod -n istio-system -l app=istiod
对于确认支持 HBONE、但升级前已自动注册且缺少标签的资源，可以这样修补。运行前替换命名空间和资源名称：
NAMESPACE='workload-namespace'
WORKLOAD_ENTRY='vm-workload-name'
kubectl label workloadentry.networking.istio.io \
-n "$NAMESPACE" "$WORKLOAD_ENTRY" \
networking.istio.io/tunnel=http --overwrite
kubectl get workloadentry.networking.istio.io \
-n "$NAMESPACE" "$WORKLOAD_ENTRY" \
-o jsonpath='{.metadata.labels.networking\.istio\.io/tunnel}{"\n"}'
不要对全部 WorkloadEntry 执行无差别批量打标。应先确认资源是否由目标工作负载自动注册、工作负载代理是否支持 HBONE，以及网络策略和防火墙是否允许对应链路。
把验证放在真实流量路径上
补丁版本也应采用分批升级。可以先更新一个非关键 revision 或测试集群，再观察以下行为：
# 检查数据平面与控制面的同步状态
istioctl proxy-status
# 观察控制面重启后的状态和资源趋势
kubectl rollout status deployment/istiod -n istio-system --timeout=5m
kubectl get pods -n istio-system -l app=istiod -o wide
# 查看 Ambient 组件最近的错误；标签可能因安装方式而异
kubectl logs -n istio-system -l app=ztunnel --since=30m --prefix
kubectl logs -n istio-system -l k8s-app=istio-cni-node --since=30m --prefix
连接排空问题可以通过一次受控的 waypoint 或 ingress gateway 滚动重启来验证：先保持少量长连接，再停止客户端，确认旧 Pod 在真实活动连接归零后退出，而不是等待完整的终止宽限期。
跨网络场景则应准备两个请求：一个匹配 L7 授权规则并应返回成功，另一个不匹配规则并应被拒绝。这样既能确认错误的 deny-all 已消失，也能确认原有授权边界仍然存在。
升级决策清单
使用 Ambient 模式、多网络 east-west gateway 或自动注册虚拟机工作负载的环境，应提高该补丁的优先级。仅运行传统 sidecar、没有跨网络流量的集群受到的直接影响较小，但 Istiod 内存泄漏修复仍然具有运维价值。
上线前建议确认以下事项：
- 已运行
istioctl x precheck，并处理与当前安装方式相关的告警。 - 已识别所有自动注册的
WorkloadEntry，明确哪些资源需要重新注册或添加 HBONE 标签。 - 已记录 Istiod 升级前的内存基线，准备在替换旧 Pod 后持续对比。
- 已为 waypoint、ztunnel 重连和 Pod 删除并发场景准备节点级验证。
- 已覆盖 east-west gateway 上的授权允许与拒绝用例。
- 已确认网关终止宽限期足以完成真实长连接排空，同时不会掩盖异常退出。
Istio 1.29.6 的价值不在功能数量，而在于修复几个只有在退出、重连、跨网络和长期运行时才会暴露的问题。升级验证也应围绕这些边界展开，而不能只检查 Pod 是否全部进入 Running。