【Envoy Gateway】对照替代路径：Cilium Gateway、Istio、Ingress 与其他实现
内容提要
本文对比Envoy Gateway与Cilium、Istio、Ingress注解等替代方案，聚焦翻译内核与排障坐标差异，而非性能。核心观点：各实现虽支持Gateway API，但控制面机制不同，如Cilium嵌入Envoy、Istio用istiod、Contour独立翻译器。选型需考虑团队隔离与观测链需求，避免硬套统一排障方法。
延伸解读
翻译内核差异决定排障坐标
文章强调，虽然各实现都支持 Gateway API，但翻译内核不同：Envoy Gateway 使用 XdsIR/InfraIR，Cilium 嵌入 Envoy 配置，Istio 通过 istiod，Contour 独立翻译器，NGINX Gateway Fabric 生成 NGINX 配置。这意味着排障时不能复用同一套方法，需根据实现选择对应的日志、状态和指标。
Ingress 注解模型的局限与适用场景
Ingress 依赖控制器私有注解，可移植性差，且失败可见性不足。但文章指出，若现有注解 runbook 已覆盖需求且无跨实现移植需求，Ingress 仍是合理选择。假迁移（将注解逐条翻译成 HTTPRoute 并用 EnvoyPatchPolicy 重建动物园）反而放弃可移植核心，应避免。
选型需考虑团队隔离与观测链
文章提出选型判据：若南北向需与 Cilium 的 identity/Hubble/KPR 同链，Cilium Gateway 是嵌入方案；若需隔离爆炸半径，独立 Envoy Gateway 更合适。Istio 场景需明确权威源（VS/DR 或 Gateway API），而控制面分裂时需注意排障坐标的切换。
Q&A
Envoy Gateway 与 Cilium Gateway 在控制面和数据面上有什么主要区别？
Envoy Gateway 使用独立的控制面，通过 Provider → Translator → XdsIR/InfraIR → xDS Translator 管线生成 Envoy 配置，数据面是托管的 Envoy 舰队。Cilium Gateway 则嵌入 Envoy，控制面由 Cilium agent/operator 管理，数据面是 eBPF 拦截加节点上的 Envoy，排障时需先关注 Hubble identity 和 BPF 路径。
Istio 的 istiod 在翻译 Gateway API 时有什么特点？
Istio 使用 istiod 作为翻译内核，无论输入是 VirtualService/DestinationRule 还是 Gateway API 的 HTTPRoute，最终都会编译进同一套 RDS/CDS/EDS，并通过 xDS 推送。此外，Istio 支持 GAMMA 模型，允许 Route 的 parentRef 指向 Service 以用于网格流量。
Ingress 注解模型与 Gateway API 相比有哪些不足？
Ingress 注解模型的可移植性差，换控制器后注解失效；角色分离不清晰，基础设施与应用共享同一对象；失败可见性低，注解错误往往没有标准条件。Gateway API 通过分层资源和 Policy Attachment 解决了这些问题，并提供 Accepted/Programmed/ResolvedRefs 等标准状态。
Contour 和 NGINX Gateway Fabric 在实现 Gateway API 时有什么不同？
Contour 使用自己的翻译器，一个 Gateway 对应一套 Contour + Envoy，数据面是 Envoy + xDS，但控制面不是 EG 的 XdsIR。NGINX Gateway Fabric 则通过 controller-runtime 控制器将 Gateway API 翻译成 NGINX 配置，经 gRPC 发送给数据面 Pod 内的 Agent，Agent 写文件并触发 reload。
在选型时，什么情况下应该选择 Cilium Gateway 而不是独立的 Envoy Gateway？
如果南北向流量必须与 identity、Hubble、KPR 等 CNI 功能在同一条观测链上，且团队希望统一管理，可以选择 Cilium Gateway。但如果南北向团队与 CNI 团队需要隔离爆炸半径，则独立的 Envoy Gateway 更合适。
Envoy Gateway 的 Policy Attachment 与 Ingress 注解相比有什么优势？
Envoy Gateway 的 Policy Attachment（如 SecurityPolicy、BackendTrafficPolicy）遵循 GEP-713 标准，附着模式标准化，但字段仍是实现扩展。相比 Ingress 注解，它提供了更好的可发现性和标准状态，但并非完全标准化。
文章中提到哪些常见的关于 Gateway API 实现的误解？
常见误解包括：选了 Cilium 就必须用 Cilium Gateway（实际上 EG + Cilium CNI 是合法组合）；选了 Istio 就不必用 Gateway API（Istio 官方意图是让 Gateway API 成为未来默认）；Envoy Gateway 与 Contour 都推 Envoy 所以排障相同（翻译内核和 status 计算路径不同）；Ingress 已死（规范方向是 Gateway API，但存量场景仍可能适用）。
