【Cilium / eBPF】L7 与 Mesh 边界：节点 Envoy、sidecar 与 Ambient

「Cilium 也能做 Service Mesh」常被听成「可以删掉 Istio」。机制上更准确的说法是：L3/L4 与 identity 留在 BPF；需要 HTTP 路径、方法、头匹配等 L7 语义时，Cilium 把流重定向到节点上的 Envoy（或等价代理路径）。 这与 sidecar 全量拦截、与 Istio Ambient 的 ztunnel/waypoint 分工都不同。本篇只划边界；Ambient 实现留给 istio-xds / 上游文档，不在此重写。

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

篇目	核心内容
第 7 篇 · 策略编译	proxy_port 出口
第 9 篇 · 加密	透明加密
第 10 篇 · L7 Mesh 边界	可选 Envoy；vs sidecar / Ambient
第 11 篇 · ClusterMesh	多集群边界

版本锚定：Cilium v1.20.0（发行说明含嵌入 Envoy v1.37.x 量级；第三方升版须显式标注）。Gateway API / 南北向见第 15 篇。无集群不伪造 Envoy admin 输出。

一、为什么 L7 不能「全放进 BPF」

eBPF 验证器限制（指令数、有界循环、无稳定「完整 HTTP/1.1 状态机」库）决定了：生产级路径匹配、头操作、gRPC 状态映射等，仍以用户态代理为务实落点。站内 ebpf/ 讲 VM 约束；envoy/ 讲 Filter 链。Cilium 的选择是：

• 纯 L3/L4：TC/XDP/cgroup 路径上 map 判定，不经 Envoy；
• 含 L7 的策略 / 可见性：policy 条目带 proxy port，BPF REDIRECT 到节点代理，由 Envoy 做 L7 后再转发或拒绝。

这不是暂时妥协口号，而是 verifier 与工程复杂度的稳定分界——与 k8s-network/13 开放问题「多少 L7 能进 BPF」同源。

flowchart TD
  pkt["Pod traffic"] --> l4{"L7 rule?"}
  l4 -->|"no"| bpf["BPF ALLOW/DENY"]
  l4 -->|"yes"| redir["BPF redirect\nproxy_port"]
  redir --> envoy["Per-node Envoy"]
  envoy --> l7{"L7 allow?"}
  l7 -->|"yes"| dst["Destination Pod"]
  l7 -->|"no"| drop["Deny / error response"]

二、Cilium 的 per-node Envoy 模型

2.1 与 sidecar 的拓扑差

Cilium 路径上，只有 命中 L7 规则（或 L7 可见性） 的流才进 Envoy；其余 L3/L4 流保持 in-kernel。这是相对「默认一切进 sidecar」的路径税差——前提是你没有把网格功能全开成 L7。

2.2 编译与数据面衔接

第 7 篇已述：L7 规则写入 policy map 的不是单纯 ALLOW，而是重定向元数据。失败面分裂：

1. BPF 未正确 redirect → 流可能被 L4 误放或误杀；
2. Envoy 配置未跟上 → 超时、连接拒绝；
3. Envoy L7 拒绝 → Hubble 见 L7 verdict / HTTP 状态，L3 drop 计数未必动。

节点 Envoy 成为 共享故障域：单节点代理过载影响该节点所有 L7 强制工作负载，而 sidecar 过载通常限制在单 Pod。这是「省内存」换来的相关故障模式。

2.3 能力边界（机制陈述）

Cilium Service Mesh / L7 策略覆盖的是官方文档列出的协议与规则面（HTTP 等；以 v1.20 文档为准）。它不自动等于：

• 全功能 Istio 流量管理（金丝雀、复杂 VirtualService 图）；
• 多集群网格控制面（那是 ClusterMesh + 各产品自己的多集群方案交叉）；
• 应用身份（SPIFFE）体系的全集。

把「能写 HTTP path 规则」夸成「网格可迁移完毕」会在第一张金丝雀工单上破裂。

三、相对 sidecar：何时 BPF+节点 Envoy 不够

适合偏向 Cilium L7 的信号：

• 策略以 身份 + L3/L4 为主，L7 是少量路径级闸门；
• 希望避免 sidecar 注入与每 Pod 内存；
• 已选 Cilium 作 CNI，想减少第二数据面。

仍应留在 sidecar（或等价 per-workload 代理）的信号：

• 需要 每工作负载独立 的证书生命周期、WASM/Filter 定制、与网格控制面深度绑定的路由；
• 节点代理共享故障域不可接受；
• 团队运行手册建立在 Istio/Linkerd 工具链上，迁移成本高于节点内存。

与 kube-proxy replacement 叠加时：socket-LB 可能与 sidecar 的流量改写冲突；官方 KPR 文档提示在服务网格场景使用 socketLB.hostNamespaceOnly 一类约束，避免双改写。这是 集成边界，不是边角注释。

四、相对 Istio Ambient：只划边界，不重写

Ambient 将 L4 安全/遥测放到节点 ztunnel，L7 按需Waypoint。与 Cilium 的「BPF L4 + 可选节点 Envoy」在 形状上相似（都想去掉默认 sidecar），但：

本系列立场：不在此证明谁更快；排除树见第 14–16 篇与 envoy/16、haproxy/14。读者若已为 Ambient 付学习税，不必因「Cilium 也能 L7」强行双栈——双网格控制面是最贵的失败模式之一。

五、失败模式与观测

排障顺序：先确认规则是否 L7 → Hubble verdict 是否 REDIRECTED → 再看 Envoy 指标；不要从「ping 通」推导 HTTP 策略已生效。

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

谱系：应用层代理（早期 L7 LB）→ 服务网格 sidecar 普及（统一 mTLS 与策略）→ sidecar 税引发 sidecarless / ambient / 节点代理 回流 → Cilium 用 eBPF 收回 L3/L4，L7 仍交 Envoy。Envoy 自身谱系见站内 envoy 系列；eBPF 与用户态代理的分工是系统界长期争论，不是厂商月度话题。

争论：

1. 节点代理 vs sidecar 故障域：资源效率 vs blast radius。
2. L7 策略放 CNI 还是放网格控制面：平台网络队 vs 服务网格队的所有权；组织边界常比技术边界硬。
3. 「eBPF mesh」营销：L3/L4 内核路径真实；L7 仍用户态——宣传若抹掉这层，属叙事作弊。

开放问题：

1. 哪些 L7 语义可以在未来内核辅助下安全 offload，而不把 verifier 复杂度推给每集群定制程序？
2. CNI 内嵌网格与 Ambient 双栈时，身份与策略的权威源如何唯一？（第 14、16 篇）

七、所有权、渐进开启与「假网格」

平台团队常被要求「先开 Cilium Mesh 试试」。可检验的渐进顺序是：

1. 只开 CNI + NetworkPolicy（L3/L4），确认 Identity 与 Hubble 归因可用；
2. 对 单个命名空间 增加一条窄 L7 规则，观察是否出现 REDIRECTED 与节点 Envoy CPU；
3. 再评估是否引入完整流量管理对象；若已有 Istio，停止在 Cilium 侧重做平行金丝雀。

假网格指：声明了 Mesh，但绝大多数规则仍是 L3/L4，却按「全功能网格」向业务承诺超时注入、按头路由、全链路 mTLS 产品体验。承诺与机制不对齐时，业务会在 Cilium 与 Istio 之间来回提工单，最终两套都半开。所有权建议写进平台宪章：L3/L4 与 CNI 身份归网络平面；复杂 L7 流量管理归网格平面（若存在）；重叠 API 只允许一个权威。

资源账也要分开算：节点 Envoy 的内存摊销在节点上，sidecar 摊销在 Pod 上。密集 L7 强制时，节点模型可能把税集中到少数「热节点」；调度器若不通报代理热点，会出现「只有某几台机器上的服务变慢」。这是边界问题，不是调大 CPU request 能单独解决的。

与第 6 篇 KPR、第 9 篇加密同时开启时，集成矩阵应在预发验证：socket-LB 开关、是否 hostNamespaceOnly、L7 流是否同节点短路、跨节点是否二次封装。缺一张矩阵就上生产，等于把组合爆炸留给值班。

7.1 可见性与强制的不同税

仅开启 L7 可见性（解析 HTTP 供 Hubble 展示）与开启 L7 强制（按 path 拒绝）都可能把流送进 Envoy，但失败后果不同：可见性挂了，业务仍通、只是观测缺字段；强制挂了，业务直接失败。把「先开可见性观察一周」写成变更步骤，可以降低第一次 L7 强制的爆破半径。

DNS 代理 / toFQDN 与 L7 HTTP 规则常被同一团队配置，却落在不同子系统：前者影响 IP 集合如何进入策略，后者影响已建立（或新建）连接的应用层判定。排障时问清「失败的是解析还是 HTTP」，再决定看 DNS 路径还是 Envoy 访问日志。

对标站内代理系列排除树：若核心诉求是复杂 L7 路由与多团队 VirtualHost，权威应在 Envoy/Istio；若核心诉求是身份 NetworkPolicy 与 kube-proxy 税，权威在 Cilium。本篇边界存在的意义，就是阻止用一种产品叙事吞掉另一种产品的责任面。

也可以用反例自检：若关闭所有 L7 规则后故障消失，问题在 Envoy 路径；若关闭 L7 后仍在，问题在 L3/L4、Service 或加密。不要在未做这一刀之前同时重启 agent、sidecar 与业务——变量过多时，任何「修好了」都不可复现。同理，评估 Cilium Mesh 是否足够，应拿 真实 L7 规则集合 对照能力表，而不是拿市场幻灯片对照。

节点 Envoy 的版本随 Cilium 发行绑定（v1.20 叙述为 Envoy v1.37.x 量级）。自行替换节点代理二进制绕过发行通道，会失去支持边界，也不再能用本系列的版本锚点推理行为。

从阅读路径看：本篇接在加密之后、ClusterMesh 之前，是因为 L7 边界常在单集群内就被问到，而多集群网格会把边界问题再放大一层。若你的目标只是「删掉 kube-proxy + 身份策略」，可以读完第 6–7 篇后跳过本篇；若有人主张「用 Cilium 替换全部 Istio」，本篇是必读的冷水。

Gateway API 南北向 L7（第 15 篇）与东西向 L7 策略不是同一条控制链：前者面向入口资源模型，后者面向 CNP/网格策略。混称「我们开了 L7」而不说是哪一条链，会导致排障找错组件。东西向 L7 与南北向 Gateway 同时出问题时应拆开时间线，不要默认是「Envoy 全坏了」。机制分界清楚，故障域才分得清。

八、本篇边界

不写：Ambient ztunnel 源码、Istio VirtualService 教程、Cilium Gateway 全章（第 15 篇）、Envoy Filter 开发。
下一篇钉 ClusterMesh：多集群身份与服务发现提供什么、明确不保证什么。

一句话收束：Cilium 的 Mesh 能力是「BPF 上的 L3/L4 + 按需节点 Envoy」；与 sidecar/Ambient 是替代关系上的部分重叠，不是超集——重叠区双开通常只叠加故障域。 把边界写进架构评审清单，比事后争论「谁该管 L7」便宜得多。下一篇进入多集群身份与服务发现边界。

参考资料

官方文档（A）

• Cilium v1.20 — Service Mesh / L7 policy 相关章节（docs.cilium.io/en/v1.20/ 下 network/servicemesh 与 security/policy/layer7）
• Cilium v1.20 — kube-proxy free 中与 socket-LB / 网格共存的说明
• Istio — Ambient 模式概述（对照用，不引入实现细节断言）

论文 / 工程对照（A/B）

• 可编程数据面限界：CoNEXT 2018 XDP；与用户态代理分工见站内 envoy 选型章
• Envoy 代理模型：站内 envoy/

站内

• 第 7 篇 · 策略编译
• envoy/16 · 选型收束
• istio-xds 索引
• k8s-network/13 · 无 sidecar 叙事

→ 上一篇：透明加密 · 系列目录 · 下一篇：ClusterMesh