【Envoy Gateway】对照替代路径：Cilium Gateway、Istio、Ingress 与其他实现

前 13 篇把南北向失败落格到 status、IR、xDS、Envoy 数据面与入口之后的东西向。接下来的问题不是「Envoy Gateway 功能全不全」，而是：相对 Cilium 嵌入式网关、istiod 翻译、Ingress 注解模型，差在哪一层翻译内核、值班要讲哪套坐标——不是谁的 RPS 海报更大。

本文不做延迟排行榜。跨方案延迟比较需要固定网卡、内核、路由规则规模、TLS 与策略是否同开；单个数字比较是口径欺骗。产品勾选见 k8s-network/17 Ingress、k8s-network/18 Gateway API（角色教程钉 Gateway API v1.2 / EG v1.2，不得当成 v1.9.0 字段全集）；数据面排除树见 Envoy 16。对照结论钉各实现官方文档的机制陈述，不写未核过的「生产就绪」口号。

本文是「Envoy Gateway / Gateway API」系列第 14 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 13 篇 · 排障坐标系	五轴归因
第 14 篇 · 对照替代路径	翻译内核 × 排障坐标
第 15 篇 · 东西向接缝	北段 / 南段证据包

版本锚定：Envoy Gateway v1.9.0；Gateway API v1.6.1；Envoy v1.39.0。Cilium v1.20.0（docs.cilium.io/en/v1.20/）。Istio 系列钉 1.30.3（外链 istio-xds）。Contour 对照读 1.28 Gateway API 文档；NGINX Gateway Fabric 对照读官方 Gateway architecture（查阅时站点标 2.6.7）。第三方升版须显式标注。

一、Cilium Gateway：嵌入 Envoy，接缝在东西向

Cilium v1.20.0 文档 Gateway API Support 写明：支持 Gateway API v1.6.1 资源面（含 HTTPRoute / GRPCRoute / TLSRoute / BackendTLSPolicy / ReferenceGrant，以及可选 TCPRoute / UDPRoute / ListenerSet），并提供 CiliumGatewayClassConfig 作 GatewayClass.parametersRef。前置条件不是「再装一个独立网关控制器」那么轻：官方要求 kube-proxy replacement（kubeProxyReplacement=true）以及 L7 proxy（l7Proxy=true，默认开）。

机制差，而不是菜谱差：

1. L7 数据面仍是用户态 Envoy（Cilium 发行的裁剪发行版），不是「另一个 BPF map 里的 HTTP 路由器」。流量到 Service 端口后，eBPF 拦截并经内核 TPROXY 转到节点上的 Envoy。
   
2. 控制面不是 EG 那条 CR→XdsIR→xDS Translator 管线。Cilium agent / operator 把 Gateway API 编进自己的 Envoy 配置路径（含 CiliumEnvoyConfig 一类内部对象）；排障坐标先碰到 Hubble identity 与 BPF 路径，再碰到嵌入 Envoy。
   
3. 入口之后立刻接东西向四元组。Cilium 15 已经警告：品牌统一不等于坐标统一。启用 Cilium Gateway 等于强制值班同时会南北向 L7 与东西向 eBPF。

站内完整边界在 Cilium 15 · Gateway 边界。本篇只收一句选型判据：若南北向必须与 identity / Hubble / KPR 同一条观测链，Cilium Gateway 是「嵌入」而不是「再买一个独立控制面」；若南北向团队与 CNI 团队要隔离爆炸半径，独立 Envoy Gateway 才对得上第 13 篇五轴。

Cilium 文档还写：Ingress 与 Gateway API 都可以暴露为 LoadBalancer / NodePort，或 host 网络。hostNetwork 与 NodePort 健康检查的责任面仍是 Cilium 15 的开放问题，不在本系列用想象中的端口表关闭。

不做的事：不写 Cilium Gateway 的 HTTPRoute 金丝雀菜谱；不伪造 Hubble flow；不把「eBPF 更快」写成对照结论。

二、Istio：istiod 翻译与 GAMMA

Istio 官方 Kubernetes Gateway API（钉 1.30 文档树）把差异写成机制，而不是「谁更新潮」：

• Istio 自有 Gateway 配置的是已部署的网关 Deployment/Service；Gateway API 的 Gateway 既配置也（默认）部署数据面。
  
• VirtualService 把多协议塞进一个对象；Gateway API 按协议拆 HTTPRoute / TCPRoute 等。
  
• Gateway API 尚未覆盖 Istio 功能全集；缺口靠扩展与并行 CRD 补。

翻译内核是 istiod：无论输入是 VirtualService/DestinationRule，还是 Gateway API HTTPRoute，最终仍编进同一套 RDS/CDS/EDS，走 xDS 推送/ACK/warming。站内 istio-xds 写的是这条生产侧推送图；istio-xds 16 排除树问的是「mesh CRD 还是可移植 Gateway API」以及何时该跳出 xDS 去做 eBPF L4。

GAMMA（Gateway API for Mesh Management and Administration）把同一套 Route 接到东西向：parentRef 指向 Service 而不是 Gateway。Gateway API 项目文档写明该模型自 v1.1.0 起在 Standard Channel。Istio 1.30 文档在 Mesh Traffic 节给出 Service parentRef 示例。这对 Envoy Gateway 是另一条输入：EG v1.9 Concepts 把 Route 的 References 写成 Gateway——南北向入口；GAMMA 是 mesh 翻译，本系列不抢。混用时的冲突判定，istio-xds 16 标为双轨开放问题。

查阅 Istio 1.30 该页的 CRD 安装示例仍写 gateway-api/config/crd?ref=v1.5.1。这只说明该教程片段的安装钉，不能据此断言 Istio 1.30.3 运行时只支持到 v1.5.1，也不能把它写成与本系列 Gateway API v1.6.1 同一捆。升版对照要读 Istio 自己的兼容说明，不在本篇合并版本矩阵。

选型判据：

• 继续 istiod + 存量 VS/DR：单一网格闭环、需要 Istio 尚未进入 Gateway API 的字段。
  
• 南北向用 Gateway API、网格仍用 VS/DR：两套输入进同一 istiod，排障要先问「哪条 CRD 是权威源」。
  
• 南北向交给 Envoy Gateway、网格留给 Istio 或 GAMMA：控制面分裂；第 13 篇五轴只管 EG 这一侧。

不做的事：不重写 istiod watch→model→ADS；不把 Ambient ztunnel 与 EG 数据面舰队写成同构（ztunnel 仍是 xDS 客户端，见 istio-xds）。

三、Ingress 注解模型

Ingress 的核心 spec 是 host + path → Service。表达力不够的部分，历史路径是控制器私有 annotation：rewrite、金丝雀、超时、TLS 细节、连接池。站内 k8s-network/17 已把「最小公约数 + 注解动物园」写成 Ingress 注定被替代的机制原因。

对照 Envoy Gateway，差在三处不变量：

Ingress 仍可能是正确叶：现有注解 runbook 已覆盖、没有跨实现移植需求、编制上不想付 Gateway API + Policy CRD 的学习税。那不是「落后」，是排除树上的否证。假迁移是把 nginx ingress 注解逐条翻译成看起来像 HTTPRoute 的 YAML，却在 EnvoyPatchPolicy 里重建同一座动物园——可移植核心被放弃，只换了资源 Kind。

Gateway API 自己的 Policy Attachment（GEP-713）承认：用独立 Policy 对象改行为，会带来可发现性与 fanout status 问题。Envoy Gateway 的 SecurityPolicy / BackendTrafficPolicy 等正是这条分叉。对照 Ingress 注解时不要假装 EG Policy「完全标准化」——标准化的是附着模式，字段仍是实现扩展。v1.9.0 把 mergeType 限制在 xRoute，是在用 admission 收窄分叉，不是消灭分叉。

四、Contour 与 NGINX Gateway Fabric：实现对照叶

这两条路径只用来钉「同一张 Gateway API，翻译内核可以完全不同」。不写成第二套内核，不做第三名评选。

Contour（文档 1.28）

Contour 官方 Gateway API 写明：在 HTTPProxy / Ingress 之外实现 Gateway API，目标是 core 与 extended 特性。关键机制：

• 一个 Gateway 对应一套 Contour + Envoy（1:1 控制面与数据面）。
  
• 数据面仍是 Envoy + xDS（与 EG 同族），但控制面是 Contour 的翻译器，不是 EG 的 XdsIR/InfraIR。
  
• 供给分静态（人工对齐 Gateway 与 Contour 配置）与动态（Gateway provisioner 按 Gateway 拉起实例）。
  
• 仍可在 Gateway API 模式下混用 HTTPProxy/Ingress，并用 Contour 私有 listener protocol projectcontour.io/https 承接 TLS——迁移叶，不是纯净 GAPI 叶。

排障坐标因此是 Contour 日志 + Envoy admin，而不是 egctl 与 EG 的 xds_nack_total。同跑 Envoy 不等于同跑第 13 篇口令。

NGINX Gateway Fabric（官方架构文）

NGINX Gateway Fabric 官方 Gateway architecture 把控制面写成 controller-runtime 控制器：watch Gateway API，翻译成 NGINX 配置，经 gRPC 送给数据面 Pod 内的 NGINX Agent；Agent 写文件并信号 master reload。每个 Gateway 对应一份独立 NGINX 数据面 Deployment/Service。

这与 Envoy Gateway 的分歧不在「是否 Gateway API」，而在：

• 配置真相：NGINX 配置文件 + reload（Plus 可用 API 动态改 upstream），不是 LDS/RDS/CDS/EDS/SDS 资源树。
  
• 失败方言：reload 失败、Agent gRPC 中断、控制面挂了数据面仍用上一份缓存配置（官方 resilience 节）。EG 对应的是 xDS NACK + known-good 快照——同构的「旧配置继续服务」，不同构的协议。
  
• 不必解释 Envoy warming / ACK；必须解释 NGINX reload 窗口。站内 Nginx 数据面系列管后者；本系列不重写。

不做的事：不比较 Contour 与 NGF 的性能；不把 NGF 的 F5 telemetry 写成选型加分。

五、机制差表

对照只回答一个问题：输入 API、翻译内核、数据面各是什么；值班失败时先喊哪套坐标。

flowchart LR
  subgraph input["Input API"]
    gapi["Gateway API"]
    ing["Ingress plus annotations"]
    mesh["Istio CRD plus GAMMA"]
  end
  subgraph kernel["Translation kernel"]
    eg["EG Translator XdsIR InfraIR"]
    cil["Cilium agent plus CEC"]
    istiod["istiod model"]
    contour["Contour translator"]
    ngf["NGF to nginx conf"]
  end
  subgraph dp["Dataplane"]
    envoy["Envoy xDS"]
    nginx["NGINX plus agent"]
    ebpf["eBPF intercept plus Envoy"]
  end
  gapi --> eg
  gapi --> cil
  gapi --> istiod
  gapi --> contour
  gapi --> ngf
  ing --> contour
  mesh --> istiod
  eg --> envoy
  contour --> envoy
  istiod --> envoy
  cil --> ebpf
  ngf --> nginx

表后必须读的一句：前三行里「都说自己实现了 Gateway API」只对齐了输入面的一个子集；IR 是否存在、xDS 是否经过 go-control-plane、eBPF 是否先把包拽进节点代理，决定了第 13 篇口令能不能复用。不能复用就换系列，不要硬套 Accepted 故事。

经典假对立

• 「选了 Cilium 就必须用 Cilium Gateway」——Cilium 16 已把东西向与南北向写成 ADR 两行。EG + Cilium CNI 是合法组合，接缝见第 15 篇。
  
• 「选了 Istio 就不必 Gateway API」——Istio 官方意图是让 Gateway API 成为未来默认流量 API；存量 VS/DR 仍是平行输入。
  
• 「Envoy Gateway 与 Contour 都推 Envoy，所以排障相同」——翻译内核与 status 计算路径不同；EG 的 XdsIR 与 xds_nack_total 不是 Contour 方言。
  
• 「Ingress 已死」——规范方向是 Gateway API（SIG-Network 推荐入口），但编制与存量注解仍可能让 Ingress 叶判正。排除树在第 16 篇。

参考资料

规范 / 官方文档（A）

• Envoy Gateway v1.9.0 Concepts、System Design、Gateway API Translator Design、Gateway API Support
• Cilium v1.20.0 Gateway API Support（docs.cilium.io/en/v1.20/）：v1.6.1 资源面、KPR 前置、eBPF + Envoy
• Istio 1.30 Kubernetes Gateway API：自动部署 Gateway、与 VS 差异、Service parentRef（mesh）
• Gateway API GAMMA / mesh overview；GEP-713 Policy Attachment
• Contour 1.28 Gateway API：Gateway 1:1 Contour+Envoy、provisioner
• NGINX Gateway Fabric Gateway architecture：GAPI → NGINX conf → Agent gRPC（查阅时站点标 2.6.7）
• Kubernetes Ingress：k8s-network/17 所据上游 spec

站内对照

• Cilium 15 · Gateway 边界
• Istio-xds 16 · 选型与开放问题
• Istio 控制面系列
• Ingress
• Gateway API 角色教程
• Envoy 16 · 数据面排除树
• 网关产品对照 network/60

实验台账

• 无跨方案 benchmark；不引用第三方 POC 的 RPS/CPU 表。

→ 上一篇：排障坐标系 · 系列目录 · 下一篇：东西向接缝