服务网格 12：Gateway API 如何描述网格内路由

HTTPRoute 没有 Gateway，也能作用于 Service 吗

前提是实现支持 Gateway API 的网格路由能力（GAMMA），不是“集群安装了 HTTPRoute CRD”就自动生效。第 06 篇的五层证据仍适用：提交 HTTPRoute、检查控制器接受与关联状态、查代理当前 route/cluster、观察真实请求经过哪条代理路径、核对库存服务的版本和请求 ID。控制面不处于普通 orders → inventory 请求的转发链上。

生产者和消费者 HTTPRoute 分别附着于 inventory Service，但命名空间决定作用的调用者

与入口流量附着到 Gateway 不同，网格中的 HTTPRoute 通过 parentRefs 指向 Kubernetes Service，例如 inventory 的端口 80。parentRefs 回答“哪条 Service 流量可受此规则影响”，backendRefs 回答“命中后转发到哪个目标”；前者不是后端 Pod 列表，后者也不表示调用者身份。通过目标应用日志的同一请求 ID 才能核对后端版本，不能只看对象 Accepted=True。

放在哪个命名空间，改变了谁受影响

Gateway API 网格概览将与目标 Service 同命名空间的 Route 称为生产者 Route：它由 Service 提供方定义，对访问该 Service 的客户端生效。位于其他命名空间的 Route 是消费者 Route，只作用于该 Route 所在命名空间的客户端。图中 service-mesh-lab 内的规则拟约束所有对库存服务的调用；mesh-clients 内的规则只针对该命名空间发往库存服务的调用。先确认具体实现支持这两类 Route，别把“跨命名空间能创建 Route”误读成“所有来源都经过它”。

orders (service-mesh-lab) ──> inventory Service ──> inventory-v1/v2
orders (mesh-clients)      ──> inventory Service ──> inventory-v1/v2
         来源作用域 ───────────> Route parentRef 决定附着对象
         请求匹配 ─────────────> Route rule/backendRef 决定目标

例如将 header x-canary: yes 的请求路由到 inventory-v2：先确保 v2 Service、端口和后端实例存在，再提交指向 inventory Service 的 Route；同时保留没有该 header 的 v1 基线。同一 Service 同一命名空间内的多条 Route 会依 Route 合并与优先级规则处理，不能假定“后一条 YAML 自动覆盖前一条”。ReferenceGrant 涉及跨命名空间后端引用时还需单独审查；不要把消费方 Route 的跨命名空间 parentRefs 与跨命名空间 backendRefs 混为一谈。

隔离环境中的正反例如何判断

先在 examples/service-mesh/ 做只读前置检查，命令是单行，检查脚本拒绝非指定 context 与非实验 namespace：

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

通过后才在隔离集群部署同一累计应用，并核对实现的 Gateway API 支持矩阵、HTTPRoute CRD 和 controller 版本；分别用生产者 Route 和消费者 Route 发带头/不带头请求，保存来源命名空间、请求 ID、Route status.parents、代理路由快照、库存服务实际响应与副作用账本。负例：把 parentRef 指到不存在的实验 Service，或把受控请求换到消费者 Route 不覆盖的来源 namespace；要求“规则没有按预期作用”时断言非零，而不是以提交成功判实验通过。向实际数据面放行与拒绝均需客户端及后端证据；不能把两个 namespace 当成真实路由实验本身。

当前宿主没有 kubectl/集群；前置检查原始错误与退出码 127 在 examples/service-mesh/evidence/02/20261001T130351Z-2539112/。没有选定 Gateway API controller/版本，也没有此 Route 的真实配置和请求，故整项实验 NOT_RUN，上述流程是待验收步骤，不是实测结果。移植到 Istio 时还须逐条确认 GAMMA 支持的匹配、过滤器、超时能力，不把 VirtualService 的功能与 HTTPRoute 无条件等同。

练习与参考解答

HTTPRoute 状态显示 Accepted=True，但 v2 没有任何请求，能认定负载均衡有错吗？参考解答：不能。先检查来源是否在作用范围、请求 header 是否匹配、backendRefs 服务/端口与 endpoints 是否有效，再看代理当前路由和同一请求 ID 的库存日志。Accepted 不能证明请求实际经过该规则。
保留规则内容不变，把生产者 Route 移到 mesh-clients 命名空间；哪些请求应重新核验？参考解答：此时它是消费者 Route，重点对比该来源和其他来源（如 service-mesh-lab）访问同一 Service 的结果；如仍有生产者 Route，应检查两者优先级与合并行为。控制器对这一组合是否支持要看选定版本，不可先填预期状态码。