【Envoy Gateway】HTTPRoute / GRPCRoute：匹配进入 RDS，阴影要靠 RouteRulesOverlap
内容提要
本文介绍Envoy Gateway v1.9.0中HTTPRoute与GRPCRoute的路由机制。核心要点：hostname匹配优先于规则，未命中返回404；多条Route按具体度、时间戳等优先级排序，Envoy按RDS顺序首条匹配；GRPCRoute用service/method匹配，无后端返回UNIMPLEMENTED；v1.9新增RouteRulesOverlap警告，仅针对完全相同匹配条件，不改变Accepted状态。排障时需区分404、500、ResolvedRefs失败及Overlap警告。
延伸解读
Accepted 不等于在吃流量
本文强调，一条 HTTPRoute 即使 Accepted=True，也可能因为同 listener 上存在更具体或更老的规则而被 Envoy 的 RDS 顺序阴影。这是规范行为，不是控制器故障。排障时不能只看 Accepted 状态，要检查实际匹配顺序，尤其是当多条 Route 的匹配条件部分重叠时。
RouteRulesOverlap 的边界
v1.9 新增的 RouteRulesOverlap 警告只针对完全相同（identical）的匹配条件，不覆盖部分重叠（如 / 前缀阴影 /api）。它只是警告，不改变 Accepted 状态。因此，即使没有 Overlap 警告，仍可能因更宽规则排在前面而看不到流量。发现 Overlap 后应修改匹配条件或删除被阴影的 Route，而非重装控制器。
GRPCRoute 与 HTTPRoute 的关键差异
GRPCRoute 使用 service/method 匹配，无后端时返回 UNIMPLEMENTED（而非 HTTP 500）。它不得与 HTTPRoute 合并，且 v1.9 允许通过 extensionRef 引用 HTTPRouteFilter 实现 rewrite 等扩展。排障时需区分 404（hostname 未命中）、500（无后端）、ResolvedRefs 失败（如 ExternalName）及 Overlap 警告，不能一概而论。
Q&A
Envoy Gateway 中，当请求的 hostname 没有匹配到任何 HTTPRoute 时，客户端会收到什么响应？
客户端会收到 404 响应。这是匹配失败，不是 5xx，也不是控制器未 Accepted。
在 Envoy Gateway 中，多条 HTTPRoute 匹配同一请求时，如何决定哪条规则生效？
Envoy Gateway 遵循 Gateway API 的优先级规则：先比较 hostname 的具体度（非通配符字符数），再比较 path、header 等匹配的具体度，然后比较 creationTimestamp（更老优先），最后按 namespace/name 字典序。Envoy 按 RDS 顺序取第一条匹配的规则。
GRPCRoute 与 HTTPRoute 在匹配机制上有什么主要区别？
GRPCRoute 使用 service 和 method 字段进行匹配，而 HTTPRoute 使用 URI path。默认匹配时，HTTPRoute 未写 matches 则匹配所有 HTTP 请求，GRPCRoute 未写 matches 则匹配所有 gRPC 请求。当没有后端且无直接响应 filter 时，HTTPRoute 返回 HTTP 500，GRPCRoute 返回 gRPC UNIMPLEMENTED。
Envoy Gateway v1.9.0 中 RouteRulesOverlap 警告的作用是什么？
RouteRulesOverlap 是 v1.9.0 新增的 warning status condition，用于标记同一 listener 上两条 route 的匹配条件完全相同的情况，以帮助发现被静默阴影的规则。它不会将 Accepted 设为 False，只发出警告。
当 HTTPRoute 没有指定 backendRefs 且没有直接响应的 filter 时，Envoy Gateway 会返回什么？
根据 Gateway API 规范，HTTPRoute 未指定 backendRefs 且没有直接响应的 filter 时，应返回 HTTP 500 错误。
在 Envoy Gateway 中，如何实现金丝雀发布？
金丝雀发布可以通过在同一 HTTPRoute 的 rule 中使用 weighted backendRefs 实现，或者通过更具体的 header match（如 env: canary）将流量导向 canary Service。不建议复制整份 HTTPRoute 来抢同一组 match，因为可能导致 RouteRulesOverlap 警告。
Envoy Gateway 中，ExternalName Service 作为 route backend 会有什么问题？
v1.9 修复了 ExternalName Service 作为 backend 的问题：之前会生成空地址 cluster，导致 IR 校验失败并卡住整份 snapshot；现在会显式设置 ResolvedRefs: False。集群外 FQDN 应改用 EG Backend。
HTTPRoute 和 GRPCRoute 能否在同一个 hostname 上共存？
Gateway API v1.6.0 发行说明将规范从必须拒绝改为可选拒绝，即实现可以拒绝，也可以让二者并存。Envoy Gateway v1.9 的 GRPCRoute 文档仍写“实现可以强制唯一”，但实际行为以集群中的 Accepted 条件为准。
