【Envoy Gateway】选型收束与开放问题：排除树、南北向叶关闭与系列边界

前 15 篇把 Envoy Gateway 南北向控制面拆到可观测与可排障的精度：附着与 status、Provider watch、XdsIR/InfraIR、xDS 与舰队、路由/TLS/L4/Policy、东西向接缝，并对照了 Cilium Gateway、Istio/GAMMA、Ingress。选型若再写成「各有优劣看场景」，等于把机制丢掉。

本文是终章：用机制排除树收束判断，回收 Cilium 16 与 Tetragon 16 指向的南北向叶，写明何时不该跑 Envoy Gateway，列出仍开放的问题，并以 ADR 可粘贴的语言关闭「南北向 Gateway 控制面内核」续作边界。不做跨方案延迟排行榜。本系列覆盖 CR→IR→xDS 内核；不承诺 Falco 全书，也不重写 Cilium Gateway。

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

篇目	核心内容
第 15 篇 · 东西向接缝	北段 / 南段证据包
第 16 篇 · 选型收束（终章）	排除树、开放问题、边界关闭

版本锚定：Envoy Gateway v1.9.0（源码 tag v1.9.0，2026-08-14）。Gateway API v1.6.1；数据面 Envoy v1.39.0。Cilium 系列钉 v1.20.0；Istio 系列钉 1.30.3；Tetragon v1.7.0。不以 gateway.envoyproxy.io/latest/ 冒充本 tag。

一、先排除，再选择（机制判据）

排除树每一叶必须回答一个可证伪的机制问题，而不是「看场景」。谱系上，这棵树接在 Ingress 失败（host+path 不够、注解不可移植）与 Gateway API GEP（角色导向、可移植核心、Policy Attachment）之后：今天选的不是「要不要网关」，而是哪一种翻译内核配得上编制。

flowchart TD
  portable{"Need portable Gateway API\nnot Ingress annotations?"}
  portable -->|"No"| ing{"Ingress annotations and\nexisting controller runbook enough?"}
  ing -->|"Yes"| ingress["Keep Ingress controller"]
  ing -->|"No"| l4a{"Is L4 Service LB enough?"}
  l4a -->|"Yes"| lbonly["L4 LB / NodePort / kube-proxy"]
  l4a -->|"No"| other["Out of this series scope"]
  portable -->|"Yes"| l4b{"Is L4 LB enough\nwithout L7 routes?"}
  l4b -->|"Yes"| lbonly
  l4b -->|"No"| cilgw{"Need Cilium-embedded gateway\nidentity hop plus KPR?"}
  cilgw -->|"Yes"| cil["Cilium Gateway\nsee cilium/15"]
  cilgw -->|"No"| egpol{"Need EG-specific policies\nSecurityPolicy BTP EEP?"}
  egpol -->|"No"| othergapi{"Another GAPI implementation\nIstio Contour NGF acceptable?"}
  othergapi -->|"Yes"| alt["Istio / Contour / NGF leaf"]
  othergapi -->|"No"| staff{"Can staff operate EG\nfive axes?"}
  egpol -->|"Yes"| staff
  staff -->|"No"| defer["Do not run Envoy Gateway yet"]
  staff -->|"Yes"| eg["Envoy Gateway v1.9.0"]

甜区：自管 Kubernetes，已决定用 Gateway API 做南北向默认，需要与 Envoy 数据面系列同一套 ACK/warming 方言，愿意运维 EG Policy 与 v1.9 版本门（TCP/UDP v1 CRD、mergeType 仅 xRoute、Lua 默认关），值班能用第 13 篇五轴说话，东西向 CNI（若为 Cilium）有独立五轴编制。

苦区：无人能区分 Accepted 与 Programmed；把 Ingress 注解逐条塞进 EnvoyPatchPolicy；无 v1.6 CRDs 却升级 EG 导致 L4 路由静默消失；把 Cilium Hubble 当成 EG 的 status；只用云 LB 四层转发却为「云原生套餐」打开整棵 IR 管线。

何时不该跑 Envoy Gateway（否证条件）

下列任一成立，排除树上 Envoy Gateway 叶判负（可写进 ADR）：

1. 编制撑不住五轴——不能用第 13 篇口令区分未附着、IR 空、xDS NACK、Envoy 旧快照、入口之后的 CNI deny。
   
2. 需求停在 Ingress 注解，且 runbook 已覆盖——可移植核心不是当前约束；换 Kind 不换动物园。
   
3. 只要 L4 LB——Gateway API 的 HTTPRoute 税没有对象。
   
4. 南北向绑定 Cilium 嵌入网关——要的是 eBPF 拦截 + 入口身份进 Hubble，不是独立 XdsIR。Cilium 15 已划界。
   
5. 把「装了 Envoy Gateway」当成配置已在数据面生效——未核 Programmed 与 Envoy ACK/warming 的间隙，未核 tracing 默认 0% 采样。

否证触发后应重跑排除树，而不是口头「入口已经 Gateway API 化」。沉没成本不是机制判据：发行版默认装上、POC 转正，都要把现状当假设再走一遍上表。迁出税要写进 ADR，但不能改写「编制读不懂 IR」这一事实。

Envoy 16 排除树在「需要动态 L7 + xDS」处指向网关/sidecar。本系列回收的是生产侧如何生成那棵资源树；数据面仍用 envoy 系列。两棵树不要合成一张延迟海报。

二、回收 Cilium 16 与 Tetragon 16 的南北向叶

Cilium 16 边界表把 Gateway 配置全书标为「本系列仅边界」，并挂到本系列 index（当时规划已锁定、正文未写）。Tetragon 16 同样写明南北向 Gateway 见本系列、本系列不抢运行时安全。两条指针在姊妹终章交付时是悬空的机制叶：读者知道「还有南北向那一层」，但不知道 Accepted 仍 404、IR 空、NACK 后 known-good、TCPRoute 静默跳过、与 Cilium 四元组如何分证据包。

本系列交付后，该叶的机制内容如下——三边终章不再悬空：

给读完三边的人一句分工口令：

• 「identity / policy map / Hubble deny」→ cilium/ 第 13 篇
  
• 「该不该上 eBPF 数据面」→ Cilium 16 排除树
  
• 「exec_id / TracingPolicy / Override」→ Tetragon 13
  
• 「该不该上 Tetragon」→ Tetragon 16
  
• 「Accepted / XdsIR / xds_nack_total」→ 本系列 13
  
• 「该不该上 Envoy Gateway」→ 本篇排除树
  
• 「Falco 规则怎么写」→ 上游 Falco 文档；本站不另开全书

Cilium 终章承诺的南北向续作指针、Tetragon 终章挂上的 Gateway 入口，到此关闭悬空状态。不是「永远不再写网关」，而是：同一句「去看 Envoy Gateway」不应再没有可核对篇章。 Cilium Gateway 作为嵌入实现，对照停在第 14 篇与 Cilium 15，不在本站另开第二套内核系列——这是显式选择，不是遗漏。

谱系：Ingress 失败、GEP 分叉、IR 这一跳

经典定义可以收成一条链，避免终章退回产品年表：

1. Ingress（Kubernetes 1.1 起）：host+path 映射。表达力失败后，差异化能力进不可移植 annotation（k8s-network/17）。
   
2. Gateway API GEP：角色导向、可移植核心、用 status 让对象自解释（GEP-1364 的 Accepted / Programmed / ResolvedRefs）、用 Policy Attachment 扩展而不改核心 spec（GEP-713）。GEP-713 自身是 Memorandum，并写明可发现性与 fanout status 仍是未解工程问题——扩展 CRD 分裂不是「厂商道德」，是该模式的已知代价。
   
3. 实现分叉：同一张 Gateway API，翻译内核可以是 EG 的 XdsIR、istiod 的 model、Cilium agent 的嵌入 Envoy 路径、Contour 的 xDS、NGF 的 nginx conf（第 14 篇）。
   
4. IR 这一跳：Envoy Gateway System Design 用 Infra IR 与 xDS IR 把外部资源与数据面解耦。正确性多一层中间表示，排障就多一跳——这是编译器式 IR 的老权衡，不是 v1.9 回归。对照 Istio 往往直接 CRD→xDS，少一跳 IR，值班少一个 dump 面，也少一个「status 绿但 IR 空」的命名空间。

东西向身份策略走 eBPF 可编程数据面（McCanne & Jacobson, USENIX Winter ’93；Höiland-Jørgensen et al., CoNEXT ’18 XDP），与南北向用户态代理（Envoy xDS 协议）不是同一条学术河。Cilium 把两者放进同一项目，方便采购；Cilium 15 的工作是防止品牌统一被读成坐标统一。本系列站在河的北岸：只保证 CR→IR→xDS 可落格。

争论（有文献/规范锚点）

可移植核心 vs 实现 Policy CRD。 A 侧：Gateway API 存在的理由就是换实现 YAML 仍工作。B 侧：GEP-713 承认许多行为放不进核心 spec，Policy Attachment 是目前找到的模式，但 Discoverability / fanout status 未消失。Envoy Gateway 的 SecurityPolicy 族是 B 侧工程化；v1.9.0 收紧 mergeType 只挂 xRoute，是用 admission 限制爆炸半径，不是回到纯核心。ADR 应写清：哪些意图必须停在可移植 HTTPRoute，哪些允许 EG Policy——混写等于自建注解动物园 2.0。

南北向是否应内嵌进 CNI。 A 侧：同一供应商、world→ingress→Pod 观测链更短（Cilium Gateway 文档的 eBPF+TPROXY 叙事）。B 侧：扩大爆炸半径，L7 发布节奏与 BPF 路径耦合（Cilium 15 已列组合黑洞为工程间隙）。本系列不站队；排除树把「需要嵌入」与「需要独立 EG」分成两叶。编制只有一队人时，选嵌入并不能少学一套轴，只会把两套轴写进同一张错误工单。

Programmed 能不能当「配置已生效」SLO。 GEP-1364 把「soon」留给实现。Envoy 的 ACK ≠ warming 完（envoy/09）。EG 的 status 在 Translator 里计算，早于 Worker 切快照。把条件绿写进 SLO，与把 Hubble 全绿写成「没有丢包」，是同一类口径错误。该项保持开放（第三节）。

三、系列级开放问题（可证伪）

关闭条件必须是测量或正式文档/源码变更，不是路线图幻灯片。下列四项在 v1.9.0 边界内保持开放。

3.1 status 条件是否足以当「配置已生效」SLO

问题：Accepted/Programmed/ResolvedRefs 全 True 且 observedGeneration 对齐时，能否在 SLO 里写成「数据面已按该世代服务」？还是必须叠加 Envoy ACK、warming 完成、以及（若启用）合成探测？
为何重要：第 02、13 篇与 GEP-1364 表明 Programmed 只保证「已送出」；官方 Configuration Issues 表明 Accepted 与 ResolvedRefs 可以分叉，客户端拿到 500 direct_response。把 status 当唯一 SLO，会把轴四故障算成控制面成功。
检验：固定一次 HTTPRoute 变更，对比条件翻转时刻、xDS ACK 时刻、合成请求打中新后端的时刻。
入口：GEP-1364；envoy xDS REST and gRPC protocol（warming）；EG Configuration Issues。
现状：机制已知；默认门禁数值因集群而异，本系列不编造秒数。

3.2 IR 与 xDS 的对账工具是否一等公民

问题：egctl x translate --to ir 与 --to xds、控制面 admin dump、Envoy /config_dump 能否在运维上对齐成同一完备性证明——「CR 世代 G 对应 IR 世代 I 对应 Envoy 快照 S」？
为何重要：IR 是 EG 相对 istiod 直译的那一跳。没有对账作业时，轴二只能靠推断。v1.9.0 的 EnvoyPatchPolicy 对旧 xDS 名失效，会让「translate 看起来对、运行时匹配空」成为常态事故。
检验：同一变更窗口对 IR dump 与 Envoy dump 做 Listener/Route 名对账；NACK 时核对 xds_nack_total 的 type URL。
关闭条件：上游把 IR↔︎xDS 对账做成一等诊断，或本集群写明「IR 仅开发、xDS dump 才是证据」的 ADR 并配作业。
现状：工具入口已有；完备性对账仍开放。

3.3 remote infrastructure provider 的责任面

问题：v1.9.0 新增 remote infra：Envoy Gateway 把 InfraIR 经 gRPC 交给外部 provider，由对方 reconcile 数据面。失败时 status 的 Programmed、Infra Manager 指标、xDS 连通，各自算谁的 SLO？
为何重要：控制面「已翻译 InfraIR」与「集群里有可调度的 Envoy Pod」被拆到两个进程。第 10 篇只钉机制边界，不写未核厂商适配。责任含糊时，轴一与轴四会互相甩锅。
检验：在试验环境把 remote provider 故意停掉，看 Gateway 条件、IR 是否仍更新、现有 Envoy 是否继续服务旧快照。
约束：官方要求 provider 幂等，并对 CreateOrUpdate 重试；这不是「失败可见性」保证。
现状：能力在 v1.9.0 Release Notes 与 Remote Infrastructure Provider 文档；责任面未标准化。

3.4 与 Cilium 四元组的联合 runbook

问题：故障时先填北段证据包还是先看 Hubble？CNI/KPR/加密/南北向实现 四元组如何在同一张工单里引用，而不把 EG 五轴与 Cilium 五轴写进同一段因果？
为何重要：第 15 篇只给口令与检查单语义；两边都可以「看起来像入口事故」。Cilium 16 的 Hubble 环满、静默黑洞、Gateway×加密双税仍开放——本系列不代为关闭。
检验：合成「EG direct_response 500 + 南段全绿」与「EG 200 + Hubble Policy denied」各一次，值班是否落到正确系列。
约束：不裁决「先装 Cilium 还是先装 EG」。Ambient 与 Cilium 双栈责任（Cilium 16 / istio-xds 16）同样保持开放，三边不要互相冒充关闭。

写给后续维护者：升 Envoy Gateway 小版本时，先核 TCP/UDP CRD 门、mergeType、SDS 名、xDS 消息上限是否进入该 tag，再更新本篇「能力/非能力」表，而不是重写排除树的问题顺序。 live 文档出现、tag 未包含的能力，保持「开放项」而不是悄悄写进甜区。

四、显式关闭：本系列边界

给读完本系列的人三条收束（ADR 友好）

1. 排除树进 ADR：写清卡在哪一叶机制判据；附否证条件（编制减员、退回 Ingress 注解、只要 L4、改走 Cilium Gateway、南北向并入 istiod）。示例句：
   「若平台不再维护 Envoy Gateway 五轴值班，或不需要可移植 Gateway API，则 Envoy Gateway 叶必须重跑排除树，禁止以『入口已云原生化』续跑。」
2. 若选了 Envoy Gateway：第 13 篇五轴进发布门禁；第 08/12 篇 CRD 与 Helm 所有权进升级检查单；第 09 篇 mergeType / Lua 默认关进变更评审；第 15 篇四元组进与 CNI 团队的联合上线；第 11 篇 xds_nack_total 与 tracing 默认 0% 进值班——缺一项降级为试验集群。
   
3. 若没选：用第 14 篇机制表做代际复盘；禁止无口径 RPS 截图重开「要不要 Envoy Gateway」争论。需要东西向判断时回 Cilium 终章；需要进程/syscall 时回 Tetragon 终章；需要产品勾选时回 k8s-network/18 与 network/60。

终章立场：Envoy Gateway 值得写 16 篇，是因为失败可命名——Accepted 与 Programmed 分叉、ResolvedRefs 假仍 500、RouteRulesOverlap 阴影、Translator 空 IR、NACK 后 known-good、未装 v1.6 CRDs 时 L4 静默跳过、出 hop 之后的 Cilium 四元组。选型若离开这些名字，讨论退回安装量与品牌口号。记住一个动作：先排除，再打开 EG Policy，再打开与 Cilium 的接缝——排除自带否证，Policy 自带实现锁定，接缝自带双坐标编制。

对平台团队的务实建议：先用第 13 篇在试验命名空间跑通一次真实或演练故障（至少覆盖「Accepted 仍无正确后端」与「NACK 后旧快照」），再决定是否把 Envoy Gateway 定为默认南北向。若演练里卡在「读不懂 IR 与 status 的差」，优先补第 02、04、05 篇门禁与编制，而不是先开 remote infra 与 EnvoyPatchPolicy。排除树的正确用法是缩短错误迁移，而不是证明某品牌永远正确。

若读者时间只够两篇：读 01 全景 建立缺口意识，再读本篇排除树；然后按自己的主轴跳进 04/08/13 之一。完整通读的收益是「症状能落格」；跳读的风险是把 Programmed=True 当成流量已切，或把 Hubble deny 写成 HTTPRoute 故障。

给维护者：补丁级更新应改版本钉与开放问题进展，而不是重写排除树的问题顺序。若 3.x 随新 tag 或测量关闭，在本篇追加「已关闭项」并链到复盘，避免后人把 remote infra 的责任面写回「尚未存在」。

回到系列开头的缺口：站内已有 Gateway API 产品教程、Envoy 消费侧、Cilium 东西向边界与 Tetragon 运行时安全，缺的是「南北向 CR 如何变成可归因的 IR 与 xDS」。若读完 16 篇仍只能复述功能清单，说明阅读停在目录；若能在故障里说出「这是轴二 IR 空」或「这是南段 identity deny」，机制文才算交货。

参考资料

规范 / 官方文档 / 源码（A）

• Envoy Gateway v1.9.0 全文 tag；System Design（XdsIR / InfraIR）；Gateway API Translator Design；Remote Infrastructure Provider；Release Notes
• Gateway API v1.6.1；GEP-1364 Status；GEP-713 Policy Attachment（Memorandum；可发现性/fanout 为已知问题）
• Envoy v1.39.0 xDS 协议（ACK / warming / 最终一致）
• Cilium v1.20.0 终章：选型收束
• Tetragon v1.7.0 终章：选型收束

论文 / 谱系

• McCanne, S. & Jacobson, V. (1993). The BSD Packet Filter. USENIX Winter ’93（可编程包过滤；东西向 eBPF 谱系）
• Höiland-Jørgensen, T. et al. (2018). The eXpress Data Path. CoNEXT ’18（内核可编程数据面；与用户态代理分叉）
• Gateway API GEP 总览：角色导向、可移植核心、Policy Attachment（规范锚点，非会议论文）
• Envoy xDS 协议规范：控制面/数据面配置面（与 istiod / EG 翻译内核共用）

站内对照

• 系列目录
• Cilium 16 · 南北向原指针
• Tetragon 16 · Gateway 原指针
• 第 13 篇 · 排障
• 第 14 篇 · 对照
• 第 15 篇 · 接缝
• Envoy 16
• istio-xds 16

实验台账

• 本篇无跨方案 benchmark；选型依据为机制排除。开放问题的关闭依赖测量或上游文档，不在此伪造时间线。

至此，系列在机制层闭合：从 Gateway API 附着与 status，到 IR、xDS、舰队、版本门、五轴、对照与东西向接缝，再到排除树。后续补丁级更新应改版本钉与开放问题进展，而不是重写「先排除再选」的顺序。

→ 上一篇：东西向接缝 · 系列目录