服务网格 34:发布 v2 后怎样定位慢依赖和错误身份并回滚
发布后出现 503、慢请求和错误身份,先回滚哪一层
把一次变更拆成三条可独立恢复的链:inventory-v2 新 Pod/Service 的工作负载变更、指向 v2 的请求路由变更、保护 orders → inventory 的身份与授权变更。在同一合成业务输入上只看客户端 503,不能知道错误从入口网关、Envoy 无端点、上游连接、授权拒绝还是库存应用产生;必须把客户端退出码、代理响应详情与应用端日志按同一请求 ID 对齐。
设正常 loadgen → frontend → orders → inventory-v1,orders 还要调用 external-stub;发布新增 inventory-v2 并只将带 x-canary: yes 的少量合成请求送到 v2,最后再扩大权重。预置两个故障:库存 v2 的一个依赖人为变慢,与来自非预期 ServiceAccount 的写请求。慢与拒绝是不同故障,分别采集请求 ID、代理 response flags/details、路由/endpoint 当前配置、授权策略及后端日志。可加“提交账本后延迟响应”的受控负例,确认客户端超时不等于副作用未发生,也不把回滚配置当作撤销已写入的账本。
每个阶段保存五种证据
| 阶段 | 资源与控制器 | 代理状态 | 请求/应用实证 | 回退门禁 |
|---|---|---|---|---|
| v1 基线 | Service、EndpointSlice、身份策略 | 正常 route/cluster/endpoint | 相同 SKU 的版本与外部 stub | 客户端与账本正常 |
| v2 小流量 | 版本标签、subset 或 HTTPRoute 附着 | 实际路由/活跃端点 | 带头命中 v2、无头仍按预期 | 不越过错误率与副作用门禁 |
| 慢依赖/错误身份 | 仅隔离故障开关及实验 ServiceAccount | 代理超时/授权拒绝位置 | 客户端退出码、应用是否收到及账本 | 失败断言非零且归因正确 |
| 回滚 | 恢复路由/工作负载/策略各自版本 | 目标配置已变更并生效 | 重新发唯一请求 ID、确认版本/拒绝恢复 | 长连接/重试/账本对照无回归 |
路由回退最快改变的是新的路由选择,已在途请求和旧连接还需单列观察;回退应用镜像涉及 Pod 就绪/端点变化;策略回退可能重新放行或误拒错误身份,需要同一负例重新执行。多层重试可能使 v2 背后仍收到重发,计数分母按逻辑请求/上游尝试/应用账本分别给出。若退到 v1 后账本已经有两条相同操作 ID,不能因为客户端后续读 200 就把状态写成“完全恢复”,应提出应用补偿/去重缺口。
仅针对合成服务的复跑
先从 examples/service-mesh/ 只读检查目标 context:
1 | |
有隔离集群及版本兼容配置后,才在固定的 frontend/orders/inventory-v1/v2/external-stub 镜像上部署业务并冻结输入。按无网格→sidecar 基线→v2 canary→慢依赖/错误身份→分别回滚流量、策略和部署的顺序,给每个阶段独立的合成请求 ID 和操作 ID。正常路径断言 v1/v2 版本正确、库存与外部依赖均有对应日志;失败路径断言错误身份被拒且账本不增加、慢依赖达到预期客户端结果、意外成功或重复写入使检查非零。每步留环境、代码/配置版本、完整命令/退出码、资源条件、控制面状态、代理当前配置与后端结果;不要仅上传官方示例输出。所有流量故障仅针对实验 context,不连接生产,不清理其他集群。
当前 examples/service-mesh/evidence/34/20261001T150042Z-2701357/ 的前置检查退出 127,原始错误 NOT_RUN: kubectl: command not found;没有进行 canary、错误身份/慢依赖注入或真实回滚,整项网格发布实验 NOT_RUN。run-01.sh 的进程账本只证明响应丢失会重复副作用;它不是本篇综合发布验收。
练习与参考解答
- v2 发布后出现 503,运营截图显示代理 xDS ACK,可认定策略成功下发且故障在应用吗?参考解答:不能。ACK 不是当前 route/endpoint 必定有效,也不证明请求通过;按同一请求 ID 核对对应代理 active route/cluster/endpoint、response flags/details、连接与身份记录及库存应用是否收到,再决定回滚哪个层次。
- 回滚 v2 权重为 0 后,新请求都命中 v1,但账本仍多出两条相同操作 ID。如何改验收结论?参考解答:路由选择已回退,业务副作用没有撤销,不能宣布完全恢复。比对客户端与后端 attempts 和 operation ID,停止重试/写入扩大,按应用幂等或补偿规则处理两条记录;以后再用正确/错误身份与长连接负例验证回滚不会旁路策略。
官方参考与系列导航
- Istio traffic shifting 与 诊断 proxy:配置到请求的分层验证。
- Kubernetes Deployment rollout:应用版本与 readiness 的回滚范围。
- Istio authorization:身份/授权作用范围,发布前后都要测拒绝路径。
