服务网格 06：路由规则怎样变成代理配置
声明“给 v2 一部分流量”以后，谁真正执行
前面已建立 frontend → orders → inventory-v1 / inventory-v2 的服务链，并在 第 03 篇拆开独立代理的 route、cluster 与 endpoint。sidecar 模式下，应用继续用原来的上游地址，配置却需要从 Kubernetes 资源变成 orders 旁的 Envoy 可执行的路由。Istiod 负责观察和生成配置，不是业务请求必经的转发节点。读者需要知道 Service 与 Envoy route 的不同，并能用请求 ID 定位实际库存实例。
这张图中上方为控制路径，下方为请求路径；两个箭头不能合并。“资源已提交”“代理已确认”“配置已存在”“本次请求匹配”是四种不同命题。
五步收集证据
- 声明：
VirtualService表达匹配/路由意图，DestinationRule可定义 v1/v2 subset；分别核对资源的 generation、host、port、规则所在作用域、子集标签。API 接受对象，只证明资源提交成功。错误 host 或不匹配的请求头即使语法合法，也可能让目标请求始终沿旧路径。 - 控制器处理：Istiod 观察配置与服务发现变化，按关联代理的范围构造 xDS 所需资源。哪些 namespace、工作负载和网关能看到规则，须按实际 Istio 版本及安装方式核对；不能从“某一个代理同步了”推广到所有代理。
- 下发：对本次 orders Pod 对应的代理看 xDS 资源版本及 ACK/NACK、拒绝原因。ACK 表达对相应响应的确认，不证明依赖资源已完成 warming、所有配置可用或测试请求按预期路由。
- 数据面：用代理当前配置快照核对 virtual host、route、cluster、endpoint 是否对应 v2，并检查 v2 后端是否实际存在。即使配置快照正确，仍不能证明流量通过了该代理。
- 执行：发同一 SKU、分别带/不带特定请求头的两个请求 ID，联合代理访问日志、v1/v2 应用日志、响应中的
inventory_version与副作用账本断言实际命中情况。旧连接复用和多个 orders Pod 都会影响观察范围，不能以一条 200 宣告所有实例收敛。
对于错写 subset 标签而导致无 v2 endpoint、或 route 的 host 与实际请求不匹配这两种情况，排查起点不同：先比较请求 Host 与当前 route，再查 cluster/endpoint，而不是直接调权重。下一篇将拆解 xDS 的更新依赖与拒绝，不把 ACK 当作万能“已生效”信号。
可复跑对照与当前缺口
先在隔离集群固定 Kubernetes/Istio 与镜像 digest，部署相同合成服务链并验证第 04 篇的 sidecar 捕获；先只让 v1 接收请求，再只让带 x-canary: yes 的请求命中 v2，最后把 subset 标签故意改错。分别保存上述五层、输入请求/退出码及后端账本；成功场景要在 v2 实际日志出现相同请求 ID，失败断言对错误命中返回非零。在 examples/service-mesh/ 的只读环境入口为：
1 | |
此命令只作 context/Service/EndpointSlice/Pod 前置检查，不是完整路由实验。本环境的 examples/service-mesh/evidence/02/20261001T130351Z-2539112/ 记录 kubectl 缺失、退出 127；第 03 篇独立 Envoy 二进制亦未下载完。因此 Kubernetes 资源提交、控制器处理、xDS 下发、代理当前配置和代理请求路径全部 NOT_RUN，不能报告 v2 命中比例；复跑缺口见 writing-plans/service-mesh/research/06.md。
练习与参考解答
- 看到代理同步状态正常，v2 日志却没有目标请求，应怎样定位？参考解答：锁定真实发请求的 orders Pod/代理，查该代理 route、cluster、endpoint 与实际请求 Host/头/端口是否匹配，再关联代理与两个库存后端的请求 ID。同步状态不等于该请求选择了 v2。
- 造一个“合法配置但仍落 v1”的反例。参考解答：v2 route 只匹配
x-canary: yes，实际发往inventory的请求却没带头；分别发送有头和无头的相同 SKU、不同 ID，并检查 route 快照与后端日志，才能证明是匹配条件而非配置完全没下发。未运行前不预填结果。
官方资料与系列导航
- Istio 流量治理、VirtualService 与 DestinationRule：声明入口；具体字段/默认值需在冻结版本核对。
- Istio proxy-config：检查当前代理配置，不代替请求日志。
- Envoy v1.37.0 xDS 协议：资源更新和 ACK/NACK 的语义。
系列导航：00 基线 → 01 治理位置 → 02 Service → 03 Envoy → 04 Sidecar → 05 启停 → 06 路由配置（本文）→ 07 xDS 更新、依赖与拒绝。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
服务网格 01：SDK、网关与服务网格分别处理什么
同一请求，四处可能设置超时 上一期 第 00 篇 让 loadgen → frontend → orders → inventory-v1 / external-stub 的只读调用先跑通。下一步不是立即把所有网络选项移到代理，而是回答：调用方 SDK、入口网关、工作负载代理、应用分别知道什么？假设 frontend 对 orders 超时重发、orders 也对 inventory 重发，最后客户端只看到一次失败，这些重发造成的写入次数不一定是一次。 先修是区分连接失败、HTTP 响应与业务结果；这里讨论的是职责，不预设已有 Istio 集群。本篇记录的副作用实验使用本机进程直接访问 inventory，没有运行网关或网格代理。 图中业务请求由客户端经入口网关抵达 frontend；frontend 的 SDK 发起下游调用，若有 sidecar 则相邻的代理可能处理这段流量；orders/inventory 应用仍需决定一次业务操作能否重复执行。Istiod 的控制路径不在图中的业务转发链里。 职责不按功能名称，而按可见信息划分 位置 通常能看到什么 适合做什么 不能...
2026-10-01
服务网格 04：Sidecar 怎样接管流量
注入了代理，应用为何不必改 orders 的地址 第 03 篇把 orders 的库存地址显式改成了 Envoy listener。sidecar 模式希望应用继续访问原有 Service 地址，由同 Pod 的代理接管特定出入站流量。这里的“接管”不是 Istiod 替应用转发请求，而是 Pod 生命周期中添加代理并建立网络重定向规则；应用、代理和真正的目标 Pod 都需要从实际运行状态里核对。 图的左半段是 orders 的出站请求，右半段是 inventory 的入站请求。两个代理均在各自 Pod 附近工作；控制面向代理提供配置但通常不在业务连接中间。读者需先理解 Pod 多容器共享网络命名空间、Service 地址与 Envoy listener/cluster 的区别。 从 Pod 创建到一条连接被代理处理 Pod 被创建时，已配置且适用的注入机制可能修改新 Pod 的定义，加入代理容器以及代理启动所需配置。只给现存 namespace 打标签不会凭空改写已经运行的 Pod；必须检查新 Pod的容器列表和注入状态。控制面安装、webhook 匹配、Pod/namesp...
2026-10-01
服务网格 33：无网格、Sidecar 和 Ambient 性能怎样公平比较
Ambient L4 比 Sidecar 更快，这个结论缺什么前提 先补功能等价。对 orders → inventory-v1/v2 的同一请求，无网格、sidecar、ambient L4、ambient 加 waypoint 可能承担不同的 mTLS、请求头路由、JWT/授权、重试、遥测和连接池任务。仅把四组在某台机器上打出 p99 排名，通常是在比较不同工作。前面的章节分别要求真实代理路由与策略证据；只有所有组满足同一业务与安全门禁的部分，才有可比较的延迟。无法使 ambient L4 执行 HTTP 头路由时，应把这项能力标 N/A，而不是令其绕过规则后参与“同功能”排名。 性能测量也不能修复语义差异：没有策略的低延迟不能替代受约束流量的可用性；应用完成一次报价与代理可能进行两次上游尝试也不能用同一个请求数作分母。报告至少分为四列：发起的逻辑请求数、代理上游尝试数、应用处理数、客户端成功数；记录请求 ID 映射。若启用错误身份拒绝，拒绝请求占到哪一种分母要事先说明。 锁定参数再看分位数 组别 提供的能力 对照前需要固定的差异 无网格 应用本身及可选的应用...
2026-10-01
服务网格 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...
2026-10-01
服务网格 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 当作事务一致性会把副作用风...
2026-10-01
服务网格 07：xDS 更新、依赖与拒绝
ACK 到了，为什么这条请求仍走旧路由 第 06 篇区分路由声明、Istiod 处理、代理状态和实际请求。现在要观察代理同控制面协商资源的过程：Envoy 对一次 xDS 响应确认（ACK），究竟确认了什么？路由（RDS）可能引用 cluster（CDS），cluster 可能引用端点集合（EDS）；更新不是把一份“最终 YAML”原子广播给所有代理。适合已经认识 listener、route、cluster、endpoint 的读者。 图里的 ACK/NACK 属于特定流和资源类型的控制反馈；图下方的请求沿代理活跃配置执行。两条时间线需要同一代理标识和时间戳连接，不能把 Istiod 画在普通业务请求的中途。 ACK/NACK、资源依赖分别约束什么 控制面可使用聚合发现服务 ADS 在一个 gRPC 流内交换多类发现资源。SotW（state of the world）响应提供相应订阅范围的一组当前资源；Delta xDS 按增量订阅和新增/移除表达变化，两者资源版本的含义和删除方式不能机械套用。具体使用哪种模式须读取实际代理/控制面的协商与日志，不因文档提供两种协议就断言当...