【Envoy Gateway】选型收束与开放问题：排除树、南北向叶关闭与系列边界
内容提要
本文是Envoy Gateway系列终章，通过机制排除树收束选型判断，明确何时不应运行Envoy Gateway，并回收Cilium与Tetragon系列指向的南北向内容。文章列出排除树判据、否证条件、四个开放问题（如status是否足以当SLO），并给出ADR友好的收束建议，强调先排除再选择，避免品牌口号式讨论。
延伸解读
排除树的价值：先证伪再选择
本文提出的排除树不是简单的功能对比，而是一套可证伪的机制判据。它要求每个决策点回答具体问题，如是否需要可移植的Gateway API、是否只需L4负载均衡等。这种方法的优势在于，它迫使团队基于实际需求而非品牌偏好做决策，并明确列出了否证条件，如无法运维五轴或需求仅停留在Ingress注解。这有助于避免“看场景”式的模糊结论，让选型过程更严谨、可审计。
开放问题：status不能当SLO
文章指出，即使Gateway API的status条件（如Accepted、Programmed）全部为True，也不能直接视为配置已生效的SLO。因为Envoy的ACK不等于warming完成，status在Translator中计算，早于Worker切换快照。若将status作为唯一SLO，可能将数据面故障误判为控制面成功。建议结合Envoy ACK、warming完成及合成探测，并保持该问题开放，等待测量或上游文档变更。
系列边界：避免重复造轮子
本文明确关闭了系列边界，指出Cilium Gateway配置全书、Falco规则库等不属于本系列范围，并回收了Cilium和Tetragon系列中指向南北向的悬空指针。这种显式边界有助于读者理解各系列的分工，避免重复内容。同时，文章强调不承诺未实测的跨方案延迟榜，保持严谨性。
Q&A
Envoy Gateway 选型排除树的核心判断依据是什么？
排除树的核心是回答一系列可证伪的机制问题，而不是笼统地“看场景”。例如：是否需要可移植的 Gateway API？是否只需要 L4 负载均衡？是否需要 Cilium 嵌入网关？是否需要 EG 特有策略？团队能否运维五轴（status、IR、xDS、Envoy、东西向）？根据每个问题的“是/否”走向不同分支，最终决定是否选择 Envoy Gateway。
在哪些情况下不应该运行 Envoy Gateway？
以下任一情况成立，就不应运行 Envoy Gateway：1. 团队无法运维五轴（无法区分未附着、IR 空、xDS NACK、Envoy 旧快照、CNI deny）；2. 需求仅停留在 Ingress 注解且现有 runbook 已覆盖；3. 只需要 L4 负载均衡，不需要 L7 路由；4. 南北向必须绑定 Cilium 嵌入网关（需要 eBPF 拦截和 Hubble 身份）；5. 把“安装了 Envoy Gateway”误认为配置已生效，未验证 Programmed 状态和 Envoy ACK/warming。
Envoy Gateway 的 status 条件（Accepted/Programmed）能否作为配置生效的 SLO？
不能直接作为唯一 SLO。因为 Programmed 只保证配置已“送出”，不代表数据面已按该世代服务；Accepted 和 ResolvedRefs 可能分叉，客户端可能收到 500 direct_response。需要叠加 Envoy ACK、warming 完成以及合成探测来确认实际生效。
Envoy Gateway 与 Cilium Gateway 在南北向集成上有什么区别？
Envoy Gateway 是独立的控制面，通过 CR→IR→xDS 生成配置，适合需要可移植 Gateway API 和独立运维的场景；Cilium Gateway 是嵌入 Cilium 的网关实现，利用 eBPF 和 TPROXY，适合需要与 Cilium 身份观测链紧密集成的场景。选择时需根据是否需要 Cilium 嵌入、是否接受 KPR 前置等机制判据决定。
Envoy Gateway 的 IR（中间表示）在排障中扮演什么角色？
IR 是 Envoy Gateway 将 CR 翻译为 xDS 的中间层，包括 InfraIR 和 XdsIR。它增加了排障的一跳，但也提供了更清晰的中间表示，便于定位问题。例如，可以通过 egctl x translate 查看 IR，但需要与 Envoy 的 config_dump 对账才能确认配置是否真正生效。
Envoy Gateway 系列中提到的“五轴”具体指什么？
五轴指排障时需要关注的五个方面：status（Gateway API 状态）、IR（中间表示）、xDS（数据面配置）、Envoy（数据面实际状态）、东西向（与 CNI 的接缝）。团队需要能区分这五个层面的问题，才能有效运维 Envoy Gateway。
Envoy Gateway 的 remote infrastructure provider 是什么？
remote infrastructure provider 是 v1.9.0 新增的功能，允许 Envoy Gateway 将 InfraIR 通过 gRPC 交给外部 provider，由对方负责 reconcile 数据面。这引入了责任划分问题：控制面“已翻译 InfraIR”与“集群里有可调度的 Envoy Pod”被拆到两个进程，失败时 status、Infra Manager 指标、xDS 连通各自算谁的 SLO 尚未标准化。
Envoy Gateway 与 Istio 在控制面翻译内核上有什么主要差异？
Envoy Gateway 使用 XdsIR/InfraIR 作为中间表示，将 CR 翻译为 xDS；Istio 通常直接 CRD→xDS，少一跳 IR。因此 Envoy Gateway 排障时多一个 dump 面，但也多一个“status 绿但 IR 空”的命名空间；Istio 则更直接，但可能缺少中间层的可观测性。
