服务网格 35：什么时候采用，退出时怎样证明能力仍在
要不要上网格，不能只比较代理的 p99 决策输入是需要哪些跨服务能力和统一治理、谁来承担证书/策略/升级/排障、现有 SDK/网关/网络策略能覆盖哪些边界，以及切换后产生的业务风险。第 33 篇的四种模式甚至没有天然等价的功能集合，不能仅用单个延迟数字选择产品。对于累计 frontend → orders 调用链（orders 先调用 inventory，成功后再调用 external-stub），先把请求头灰度、工作负载身份、入口出口约束、授权拒绝、超时重试、日志和回滚列成验收条目，另把 POST /reserve 的去重留给应用。网格可以执行跨进程策略，不能替代订单事务。 场景 A：多个平台团队要对 Service 间身份与 HTTP 路由作一致治理，应用语言多、证书轮换由平台承担；网格可能减少应用重复实现，但要付控制面/数据面容量、版本偏差、策略作用域及故障排查成本。场景 B：少量同语言服务、只需 SDK 的超时与明确的入口限制，可能先用应用 SDK、网关和网络策略达到需求，不为不需要的 HTTP 授权引入共享 waypoint。两者都只是条件分支：当前没有网格真实实验和...
服务网格 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 当前配置、授权策略及后端日志。可加“提交账本后延迟响应”的受控负例，确认客户端...
服务网格 33：无网格、Sidecar 和 Ambient 性能怎样公平比较
Ambient L4 比 Sidecar 更快，这个结论缺什么前提 先补功能等价。对 orders → inventory-v1/v2 的同一请求，无网格、sidecar、ambient L4、ambient 加 waypoint 可能承担不同的 mTLS、请求头路由、JWT/授权、重试、遥测和连接池任务。仅把四组在某台机器上打出 p99 排名，通常是在比较不同工作。前面的章节分别要求真实代理路由与策略证据；只有所有组满足同一业务与安全门禁的部分，才有可比较的延迟。无法使 ambient L4 执行 HTTP 头路由时，应把这项能力标 N/A，而不是令其绕过规则后参与“同功能”排名。 性能测量也不能修复语义差异：没有策略的低延迟不能替代受约束流量的可用性；应用完成一次报价与代理可能进行两次上游尝试也不能用同一个请求数作分母。报告至少分为四列：发起的逻辑请求数、代理上游尝试数、应用处理数、客户端成功数；记录请求 ID 映射。若启用错误身份拒绝，拒绝请求占到哪一种分母要事先说明。 锁定参数再看分位数 组别 提供的能力 对照前需要固定的差异 无网格 应用本身及可选的应用...
服务网格 32：多集群调用怎样跨网络发现与恢复
同名 Service 能跨集群访问，是否就算完成多集群 不能。真正的两集群须分别证明服务发现看到了远端 endpoints、东西向网络能穿越边界、工作负载身份在预期信任关系下通过、故障切换确实由可用的远端实例处理，以及业务数据是否有独立同步/去重方案。第 31 篇的两个 namespace 即使互访，也不是两个 Kubernetes 控制平面与两个故障域。本篇先以 sidecar 双 primary、双网络为待测拓扑；不能把得到的 sidecar 结果直接外推 ambient 多集群。 令 A 集群运行 frontend → orders 和 inventory-v1，B 集群运行相同 Service 名的 inventory-v2，两边各用固定请求 ID 返回真实版本。每侧的 Istiod 不是数据面业务转发节点；请求跨网络时要核对其实际经过的东西向网关、接收端代理及目标 Pod。控制面知道某个远端 IP，不代表路由必然经过正确网关或 TLS 身份被接受。若两套集群各自创建了合成库存账本，即使远端请求成功，账本数据依然不会自动同步；把跨集群 200 当作事务一致性会把副作用风...
服务网格 31：多租户需要隔离哪些控制面与数据面边界
一个 namespace 一个租户，隔离就足够了吗 不够。租户 A 与 B 在同一隔离实验集群内分别运行累计 frontend → orders → inventory 服务，可以复用同一合成 SKU、请求 ID 前缀和库存账本，但四类边界仍需分开证明：谁能提交规则（Kubernetes RBAC）、规则可见及附着到谁（Istio/Gateway API 作用域）、业务请求能否越权（数据面认证授权），以及共享控制面/waypoint/ztunnel 被租户 A 占满时租户 B 的可用性。前面认证与授权章节讨论的执行点不能由“两个 namespace”替代，HTTPRoute 的同 namespace 生产者规则还可能作用于所有调用该 Service 的来源。 Namespace 给资源命名空间，不自动为所有业务流量隔离网络，不自动防止错误的全局策略，也不为共享 waypoint 建立硬性的按租户容量限额。RBAC 能禁止 A 修改 B 的资源，却无法据此推出 A 对 B Service 的 HTTP 请求一定会被拒绝；相反，数据面策略即使拒绝了 A，也不能阻止 A 以被授予的 ...
服务网格 30：控制面和数据面升级怎样验证回退
回退 revision 标签，是否就回到原版本 不是。第 29 篇把已有代理、新工作负载和控制面分开；升级时也要区分“哪个版本生成配置、哪个版本代理正在运行、共享的 CRD 与现有长连接在哪里”。Istio sidecar 可通过 revision 将新控制面接到受控工作负载，再通过滚动重建切换注入版本；已经运行的 Pod 不会仅因为 namespace 的 revision 标签修改就自动换代理。回退标签也不自动恢复此前升级过的 CRD schema 或新版本写入的资源语义。 本篇不提供通用的“跨多少个版本都能混跑”承诺：先选实际仍受支持的 Istio 两个发布版本、Kubernetes 版本及升级路径，查官方版本偏差/兼容表；保存控制面和数据面镜像 digest、网格配置、CRD 修改前后快照。控制面连通、xDS 对新资源 ACK、代理健康只是中间层；最终以带请求 ID 的 orders → inventory-v1/v2 请求和库存应用账本为准。升级事件与坏版本的回滚都须按时间线判断，不能引用别的集群截图作为本实验结果。 Sidecar 与 ambient 的批次不同 S...
服务网格 29：控制面不可用后哪些调用还能继续
关掉 Istiod，业务请求会立即中断吗 不能从“控制面不可用”直接推出一个统一结论。第 06 篇的链路是规则提交、Istiod 等控制器处理、xDS 下发、代理当前配置、业务请求经过代理、应用返回；Istiod 不处于普通 orders → inventory 请求的数据面转发路径上。已有连接和已安装资源的代理可能继续转发，新代理能否取得 listener/cluster/endpoint、新版本 Pod 是否被发现、证书到期后能否续期是不同问题，不能用某个时刻的 HTTP 200 概括整个故障窗口。 旧 TCP 连接继续传输依赖其当前对端和连接状态；新 TCP 连接若代理仍拥有可用目标配置，未必立即失败。若库存扩容为 v2 或替换 v1 Pod，原有 endpoint 不一定仍有效；代理收到哪些变化、是否对新的 Pod 完成身份/证书初始化，必须读状态和实际请求。xDS ACK 说明控制面/代理曾就某个资源版本交互，不保证该资源此刻仍是全部必要配置，不保证请求成功；反过来短暂失去 Istiod 也不能证明现有业务连接必然断开。 按时间与资源划分故障域 测试对象 故障前...
服务网格 28：Sidecar 迁移 Ambient 如何验证与回退
给 namespace 换标签，为什么不足以宣布迁移完成 第 04 篇描述随业务 Pod 部署的代理，第 26 篇将四层移到 ztunnel，第 27 篇讨论七层 waypoint。三者覆盖点不同：**标签声明意图，Pod 是否仍有 sidecar、流量经哪个代理及安全策略在哪里执行，必须分别取证。**对于已有 sidecar 的 Pod，仅改 namespace 标签不能让其就地消失；混合阶段须按冻结的 Istio 版本核验代理优先级、滚动重建和路由结果。 迁移不是换一个部署模式名称，而是给每个已有能力重新确定执行位置。以累计应用为例，orders → inventory 的身份与四层保护可以通过 ztunnel 重新验收；请求头灰度到 v2、对 POST /reserve 的方法级拒绝要核对 waypoint 的附着及七层策略。sidecar 的 VirtualService/DestinationRule subset 不能原样假定可作为 ambient 中 HTTPRoute 的版本后端；要按目标发布版支持范围，用实际可用的 v1/v2 Service 和 endpoi...
服务网格 27：Waypoint 创建之后流量就经过它吗
Gateway 对象存在，不等于七层策略已覆盖调用 第 26 篇在节点 ztunnel 上讨论身份、加密和四层流量；现在要让 orders 带 x-canary: yes 的 HTTP 请求去 inventory-v2，并拒绝未经允许的 POST /reserve，必须进一步核对 waypoint 的七层能力。控制面创建 waypoint、目标 Service 选择使用 waypoint、实际请求进入该代理，以及后端按规则应答，是四个不同事实。仅凭一个 Gateway Ready 或一次 200，不能断言数据面真正经 waypoint。 Waypoint 是 ambient 模式下按范围共享的 Envoy 七层代理，而不是每个工作负载 Pod 内的 sidecar。面向 Service 的请求可通过附着选择使用它；目标 Service 的匹配、HTTPRoute 的 Service parentRefs 和七层授权的目标引用均需对应同一个实际流量对象。istio.io/use-waypoint 等绑定方式、waypoint Gateway 的监听能力、跨 namespace 限...
服务网格 26：Ambient 数据面如何转发请求
没有业务 Pod 内的 sidecar，谁在传输层接管 先保留第 04 篇的调用基线：orders → inventory-v1/v2 仍是 Pod 间业务请求，Istiod 下发信息而不转发普通业务流量。Ambient 把原来随每个应用 Pod 部署的代理职责拆开：Istio CNI 处理加入 ambient 的流量接管，节点上的 ztunnel 为工作负载提供传输安全与四层授权；需要 HTTP 路由、方法或路径策略时，另由 waypoint 执行七层处理。本篇只验第一层，不能拿到库存 HTTP 200 就宣称七层规则已生效。 图是跨节点情形的待验证路径模型：orders 发出的 TCP 流被转向源节点 ztunnel，经 HBONE 到目标节点 ztunnel，再送达库存应用。HBONE 使用 HTTP/2 CONNECT 封装并以 mTLS 保护所承载的 TCP 流；HTTP/2 是隧道协议，不表示库存应用的 HTTP/1.1 已变成 HTTP/2，也不能从图中推导请求头参与了负载均衡。同节点通信的路径是否同样形成跨 ztunnel 隧道须按实际版本和流量证据核对，不能把...
