【Cilium / eBPF】Gateway API / 南北向边界：与本系列东西向焦点的分工

本系列主线是东西向：Pod→Pod 经 identity、策略 map、Service BPF LB、可选加密的路径与失败模式。Cilium v1.20.0 发行说明把 Gateway API 推到 v1.6.1 量级，并带上 BackendTLSPolicy、更多 HTTPRoute 能力——那是南北向产品面。若把两者写成同一套排障口令，值班会在「Hubble Policy denied」与「Gateway 监听器/Envoy 路由」之间来回空转。

本文是第 15 篇：钉边界与分工，不是 Gateway API 教程，也不重写 Envoy Filter/xDS 内核。读完应能回答：何时问题仍在本系列五轴内，何时必须离开东西向坐标系。

本文是「Cilium / eBPF 数据面内核」系列第 15 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 14 篇 · 对照替代路径	Calico / kube-proxy / sidecar / Ambient
第 15 篇 · Gateway 边界	南北向 vs 东西向
第 16 篇 · 选型收束	排除树与开放问题

版本锚定：Cilium v1.20.0；嵌入 Envoy 与 Gateway API 随该发行说明（叙述量级：Envoy v1.37.x、Gateway API v1.6.1）。第三方升版须显式标注。

一、先画南北与东西，再谈开关

北 → 南：集群外客户端 → Gateway/Ingress/LB →（可选）L7 代理 → Service/Pod
东 ↔ 西：Pod →（identity/policy/service/encrypt）→ Pod

flowchart LR
  client["External client"]
  gw["Gateway / Ingress"]
  svc["Service / BPF LB"]
  pod["Pod endpoint"]
  client -->|"north-south L7/L4"| gw
  gw --> svc
  svc -->|"east-west datapath"| pod
  pod2["Pod A"] -->|"east-west"| pod3["Pod B"]

口令：包还在集群外进入监听器时，先问 Gateway/Envoy；包已成为 Pod 身份之间的东西向流时，先问本系列五轴。

二、Cilium Gateway API 在 v1.20 里是什么（机制级）

发行说明（v1.20.0）将 Cilium 的 Gateway API 支持推进到上游 v1.6.1 能力面，并包括例如：

• BackendTLSPolicy：网关到后端的 TLS 与证书校验。
  
• HTTPRoute 侧更多流量控制（如 CORS、额外重定向码等——以发行说明为准）。
  
• 与嵌入 Envoy 版本绑定的监听器/路由实现细节。

机制含义，而不是菜谱含义：

1. 南北向 L7 的数据面内核是用户态 Envoy（嵌入），不是「另一个 BPF map 里的 HTTP 路由器」。
   
2. 经 Gateway 进入集群后，后端方向仍可能再走 Cilium 的 Service/identity/加密路径——排障常要两跳坐标系。
   
3. Gateway 的身份在 Hubble 里常以保留 identity（文档示例中的 ingress / world 等）出现；观测时不要把入口代理身份与业务 Pod 身份混为一谈（第 8、12 篇）。

站内 Envoy 数据面系列 回答「Filter/xDS/上游池如何失败」；本系列回答「身份与 BPF 路径如何失败」。Gateway 开启时，一次用户请求可能串联两者。

三、与东西向焦点的接缝

3.1 仍然落在本系列五轴内的症状

3.2 必须离开本系列主线的症状

3.3 危险交叉区：组合回归

社区在特定组合上报告过：Gateway API + 云 CNI chaining + native routing + WireGuard node encryption 等条件下，跨节点南北向流量黑洞，且 Hubble 不见 drop（见公开 issue 讨论；v1.20 预发与补丁线有修复叙事）。教训不是「不要用 Gateway」，而是：

• 南北向问题不能假设总有 Policy denied 文案。
  
• 加密路径表（第 9、13 轴五）与 host routing 模式必须写进 Gateway 上线检查单。
  
• 复现与否证要固定 CNI 模式、KPR、加密、Gateway 四元组，禁止只改一维却宣称「Gateway 坏了」。

本系列把该交叉区标为已知工程间隙：完整矩阵测试留给平台验收，不在此伪造结果。

上线检查单（语义级）

启用 Cilium Gateway 前，至少用文字确认下列项（结果记入变更单；本篇不提供「复制即通过」的命令输出）：

1. 东西向基线已绿：第 13 篇轴一至四在无 Gateway 时已有 runbook。
   
2. 四元组写死：CNI chaining 与否、native/tunnel、KPR 开闭、加密模式（含是否 node-to-node）。
   
3. 身份可读：能用 Hubble 区分 world / ingress（或当前保留 identity）与后端 Pod identity。
   
4. 回程与健康检查：外部 LB → Gateway 监听端口与 hostNetwork/NodePort 无冲突；健康检查路径不依赖尚未附着的 HTTPRoute。
   
5. 回滚面：关掉 Gateway 开关或摘除 HTTPRoute 后，东西向五轴仍可独立值班——禁止「南北向与 CNI 绑死无法回滚」。

缺第 1 项时开 Gateway，等于在未知 BPF 方言上再叠 Envoy 方言。缺第 2 项时出黑洞，复盘只能猜。

四、本系列明确不写什么

写：南北向与东西向的责任面、观测身份差异、加密/KPR 组合风险、何时把工单移出本系列。

五、观测与值班：两套仪表盘

第 12 篇的最小仪表盘对东西向值班仍成立；启用 Cilium Gateway 的平台应追加南北向一类信号（监听器就绪、BackendTLS、嵌入 Envoy 指标），并在 runbook 写明升级时先重跑哪一类门禁。

一次请求的两跳证据包

对「外部客户超时」类工单，最小证据包建议拆成两段，避免混写：

只有北段没有南段，会把后端 CNP deny 误判成「网关坏了」。只有南段没有北段，会把证书/路由错误误判成「Cilium 丢包」。第 13 篇的「一次否证一轴」在跨平面时升级为「一次否证一段」。

站内 network/60 从产品与协议勾选谈网关；Envoy 16 从排除树谈要不要用户态 L7。本篇只补：在已经选了 Cilium 的集群里，Gateway 如何接到东西向坐标系而不污染它。

六、与选型终章的关系

第 16 篇排除树问的是「要不要 Cilium eBPF 东西向内核」。Gateway 是正交开关：

• 可以：Cilium CNI + 外部 Envoy Gateway / 其他 Ingress。
  
• 可以：Cilium CNI + Cilium Gateway。
  
• 可以：其他 CNI + Cilium 不负责 Gateway（视支持矩阵）。

「选了 Cilium」≠「必须用 Cilium Gateway」；「用了 Cilium Gateway」≠「可以不会东西向五轴」。ADR 应分两行写：东西向数据面与南北向入口实现。

与 Ingress 历史包袱

许多集群仍并存 Ingress 与 Gateway API。本系列不比较两者的注解生态或迁移菜谱，只要求值班地图标明：当前外部流量默认进哪一类对象。若默认仍是 Ingress，却把 Hubble 里的 ingress identity 一律解释成 Gateway——字段同名不等于实现同栈。升级到 Cilium Gateway 时，把旧 Ingress 控制器的排障口令从 runbook 删除或降级，避免两套南北向同时「好像都对」。

东西向五轴不因 Ingress/Gateway 切换而改写；改写的是北段证据包。平台若希望减少心智负担，应选定一个南北向实现作为默认，并把另一个标为遗留，而不是长期双默认。

七、谱系、争论与开放问题

谱系

南北向 L7 入口的学术/工程谱系走在用户态代理与 API 网关传统上（与 Envoy/Nginx/HAProxy 系列同源）；东西向身份策略走在 eBPF 可编程数据面传统上。Cilium 把两者放进同一项目，方便采购与统一发行，但没有消除两套内核假设。本篇的工作是防止「统一品牌」被误读成「统一排障坐标」。对值班而言，品牌统一最多缩短工单路由；真正缩短 MTTR 的是北段/南段证据包能不能在五分钟内填完，以及填完后能否指到唯一责任面。

争论：CNI 是否应内置 Gateway

A 侧：同一供应商减少胶水；身份从 world→ingress→Pod 可观测链路更短。
B 侧：扩大爆炸半径；南北向 L7 与东西向 BPF 的发布节奏耦合，组合缺陷更难隔离。
本系列不站队；要求平台在启用 Cilium Gateway 时显式接受「双坐标」编制，或明确把南北向外包给独立网关团队。若编制上只有「会点 HTTPRoute」的人、没有人会读第 13 篇，启用 Gateway 只会把东西向事故伪装成路由配置问题，平均定位时间上升而不是下降。

开放问题

1. 南北向与东西向排障坐标能否统一到单一证据包格式：例如强制包含「入口身份 + 后端身份 + 是否过加密路径」三字段。可检验：用同一 postmortem 模板跑两起真实事故。
   
2. BackendTLSPolicy 与透明加密叠层时的责任划分：网关到后端 TLS 与节点 WireGuard 同时开启时，延迟税与失败模式如何写入 SLO？需自测；正文不引用虚构百分比。
   
3. hostNetwork Gateway 与 NodePort 健康检查的责任面：在启用 hostNetwork 时，外部 LB 探测失败应先查监听器还是先查节点防火墙？需要可重复的分层否证顺序，避免南北向与主机网络策略互相甩锅。

参考资料

官方（A 级）

• Cilium v1.20.0 Release notes：Gateway API v1.6.1、BackendTLSPolicy、嵌入 Envoy 版本
• Cilium 文档：Gateway API / Service Mesh（以 docs.cilium.io/en/v1.20/ 现行路径为准）
• Kubernetes SIG Network：Gateway API 规范（版本随 CRD）

站内对照

• 第 6 篇 · kube-proxy 替代
• 第 9 篇 · 透明加密
• 第 10 篇 · L7 与 Mesh 边界
• 第 13 篇 · 排障坐标系
• Envoy 系列
• 网关选型 network/60

实验台账

• 无 Gateway 延迟对比；组合黑洞仅作风险边界引用，不冒充实测。
• 启用 Gateway 的验收应至少覆盖：同节点后端、跨节点后端、加密开/关各一组连通性，并保留北段与南段证据包各一份（可删减，须来自本环境）。

→ 上一篇：对照替代路径 · 系列目录 · 下一篇：选型收束