服务网格 27：Waypoint 创建之后流量就经过它吗

Gateway 对象存在，不等于七层策略已覆盖调用

第 26 篇在节点 ztunnel 上讨论身份、加密和四层流量；现在要让 orders 带 x-canary: yes 的 HTTP 请求去 inventory-v2，并拒绝未经允许的 POST /reserve，必须进一步核对 waypoint 的七层能力。控制面创建 waypoint、目标 Service 选择使用 waypoint、实际请求进入该代理，以及后端按规则应答，是四个不同事实。仅凭一个 Gateway Ready 或一次 200，不能断言数据面真正经 waypoint。

无绑定、已绑定和绕过三条路径：只有实际进入 waypoint 的请求才验证其 L7 路由与授权

Waypoint 是 ambient 模式下按范围共享的 Envoy 七层代理，而不是每个工作负载 Pod 内的 sidecar。面向 Service 的请求可通过附着选择使用它；目标 Service 的匹配、HTTPRoute 的 Service parentRefs 和七层授权的目标引用均需对应同一个实际流量对象。istio.io/use-waypoint 等绑定方式、waypoint Gateway 的监听能力、跨 namespace 限制与支持范围必须在固定 Istio/Gateway API 版本核对，不能把存在 waypoint 自动当成目标流量已转向。相反，直达 Pod IP、sidecar 来源、网格外客户端或网关来源是否经过 waypoint，均按来源模式与目标附着方式分别验证，不能根据一条 Service 路径外推。

授权点与旁路为什么要一起画

在图中，正常路径是 orders → 源 ztunnel → waypoint (L7) → 目标 ztunnel → inventory，与不走 waypoint 的四层路径作对照。七层 HTTP 方法、路径与请求头在 waypoint 判断；接收端 ztunnel 仍可作适用的四层身份判断，但它看到的对等身份在经 waypoint 的段上可能是 waypoint，不是最初的 orders。把原来绑定在 sidecar 工作负载上的策略原封不动转移，容易造成该拒绝的请求绕过七层检查，或该放行的来源被误拒。强制必须通过 waypoint 时，还须在接收端配置适用的四层限制并测试旁路确实被拒绝，而不能只写一条 HTTPRoute。

inventory 的只读 /quote 和合成写接口 /reserve 提供不同副作用判据：正常组读报价应返回期望的 inventory_version；配置七层拒绝后，写接口不应新增账本行。若仅观察客户端拒绝而未查库存账本，可能遗漏“拒绝发生前写入”；若只是把 POST /reserve 改造成应用本身 400，则也不能算 waypoint 授权已经通过。还需让请求带同一个逻辑操作标识和独立的 attempt ID，避免代理重试遮蔽错误实例。

三态与绕过对照

在 examples/service-mesh/ 先运行只读 context 前置检查：

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

隔离集群具备已冻结版本、ztunnel 与可用 Gateway API 实现后，依次对比：①未创建 waypoint 的 Service 调用基线；②已创建 waypoint 但尚未为库存目标绑定；③显式绑定后，检查绑定状态、控制面解析与 waypoint 当前 listener/route，发同一 SKU 的带头/不带头请求，比较 v1/v2 后端版本。每组保存资源快照、来源 Pod 身份、请求 ID、代理实际访问日志与应用账本，而非只截图 Gateway Ready。负例是在目标已绑定的前提下对受控 POST /reserve 配置拒绝；再从直达 Pod IP 和一个未适配的来源分别试探，记录是绕过、明确拒绝还是网络失败。策略希望拒绝却成功或账本增加时，断言必须非零并判 L7 验收失败。

本机 examples/service-mesh/evidence/27/20261001T143950Z-2672655/ 的检查退出 127，原始错误 NOT_RUN: kubectl: command not found。缺 Istio/ztunnel/waypoint/集群及实际绑定条件，上述路由、授权和绕过对照均 NOT_RUN；本机 run-01.sh 的副作用账本仅可作为应用行为基线，不能冒充 waypoint 拦截。

练习与参考解答

Gateway Ready，库存读请求也返回了 v2，可宣称 waypoint 的 header 规则生效吗？参考解答：不能。v2 可能由别的路由或直接连接命中。保存目标绑定条件、waypoint 当前路由、代理同一请求 ID 的访问记录及后端日志，再用移除绑定或改 header 的反例对照；“已创建”不等于“已经过”。
只针对 inventory Service 绑定 waypoint，客户端改为访问库存 Pod IP，原七层拒绝规则一定还能保护 POST /reserve 吗？参考解答：不一定。直达工作负载的附着方式须单独配置与验证。以同样操作 ID 记录路径和账本，若旁路成功就将安全断言置为非零；需要强制经过 waypoint 时，再加接收端四层保护并复测合法/绕过两条路径，不能单凭 L7 Route 保障。