服务网格 28：Sidecar 迁移 Ambient 如何验证与回退

给 namespace 换标签，为什么不足以宣布迁移完成

第 04 篇描述随业务 Pod 部署的代理，第 26 篇将四层移到 ztunnel，第 27 篇讨论七层 waypoint。三者覆盖点不同：**标签声明意图，Pod 是否仍有 sidecar、流量经哪个代理及安全策略在哪里执行，必须分别取证。**对于已有 sidecar 的 Pod，仅改 namespace 标签不能让其就地消失；混合阶段须按冻结的 Istio 版本核验代理优先级、滚动重建和路由结果。

sidecar 基线经混合阶段进入 ambient L4 与 waypoint L7；遇到错误规则按反方向逐批回退

迁移不是换一个部署模式名称，而是给每个已有能力重新确定执行位置。以累计应用为例，orders → inventory 的身份与四层保护可以通过 ztunnel 重新验收；请求头灰度到 v2、对 POST /reserve 的方法级拒绝要核对 waypoint 的附着及七层策略。sidecar 的 VirtualService/DestinationRule subset 不能原样假定可作为 ambient 中 HTTPRoute 的版本后端；要按目标发布版支持范围，用实际可用的 v1/v2 Service 和 endpoint 验证。请求返回正确库存版本是必要证据，不是足够证据：仍可能绕过授权点。

先盘点能力，再转换策略

迁移前的观察	ambient 目标执行点	必须重跑的反例
sidecar 对等身份与传输保护	ztunnel L4 与 HBONE 相关连接段	错误 ServiceAccount、未入网格来源
以请求头分流 v1/v2	已绑定 waypoint 的 HTTPRoute	错误头、空后端、直达 Pod IP
方法/路径级写入拒绝	waypoint 附着的七层授权	`POST /reserve` 后查看账本是否仍新增
应用账本与重试	应用自己的去重与可追溯日志	响应丢失后重复操作 ID

表中 L4 身份和 L7 来源不可以替换着读：当请求经过 waypoint 时，目标 ztunnel 看到的对等身份可能是 waypoint；sidecar 来源与网格外来源是否走 waypoint 又取决于实际拓扑。若过早把目标端四层策略收紧为“只许 waypoint”，未迁移的合法 sidecar 调用可能被拒绝；若为避免误拒而把策略全放开，旁路却可能绕过七层拒绝。顺序应该是先确认每种来源的实际路径，再在隔离流量中验证强制约束。

逐批转换和回退的实验入口

只在 examples/service-mesh/ 先对具名隔离 context 运行无副作用检查：

1	`SM_CONTEXT=service-mesh-lab SM_NAMESPACE=service-mesh-lab bash scripts/check-02.sh`

具备相容的 Kubernetes/Istio/ztunnel 版本及镜像后，保存同一份验收输入：只读 sku=paper、带/不带 canary 头、预期和错误 ServiceAccount、POST /reserve 的唯一操作 ID；每次尝试生成单独 X-Request-ID。先跑 sidecar 基线，取 Pod 容器列表、代理活跃 route/cluster、证书公开元数据及账本。再部署 waypoint、绑定目标并先验证“创建未绑定时规则不生效”的负例；逐批调整入网并重建应用 Pod，从容器列表核对 sidecar 是否仍在，从 ztunnel/waypoint 记录核对真实路径。每批对比响应版本、拒绝位置及账本条数，差异超出预先门禁就返回非零并停止扩散。

回退同样要求真实请求验收：恢复前一版本的选择标签与策略、按批准的批次重建 Pod，检查 sidecar 确实回来、旧长连接处理方式符合预期，再重跑正反用例。只“kubectl 回写标签”不保证已有连接重选路径；只看到健康检查 200 也不能替代七层拒绝恢复。任何故障只对隔离合成服务注入，先保存快照再回滚，不清理其他环境。

本机前置检查证据 examples/service-mesh/evidence/28/20261001T144241Z-2675442/：退出 127，原始错误 NOT_RUN: kubectl: command not found；没有 sidecar/ambient 混合集群及策略版本。全套迁移、回退、旁路和新旧连接对照均 NOT_RUN；本机进程成功和文章中的矩阵是待执行的验收设计，不是已迁移结果。

练习与参考解答

入网标签已变更，如何证伪“所有工作负载已经无 sidecar”？参考解答：列出变更前后的真实 Pod 容器及创建时间、代理资源和 ztunnel/waypoint 请求日志；保留尚未重建的旧 Pod 作为反例，再分别测服务调用。标签不能替旧 Pod 卸载代理，也不说明请求已改走 ambient。
迁移后 canary v2 成功、正常 GET 200，但旁路 POST /reserve 也可写入，应判定迁移成功吗？参考解答：不能。安全门禁失败，账本显示预期拒绝点未生效；定位来源路径与 Service/Pod IP 附着，核对目标 ztunnel 对 waypoint 身份的四层限制，在隔离环境修正后重测合法请求与旁路负例，不通过就回退。