【Cilium / eBPF】选型收束：排除树、开放问题与系列边界关闭

前 15 篇把 Cilium 东西向数据面拆到可观测与可排障的精度，并对照了 Calico、kube-proxy、sidecar、Ambient，划清了 Gateway 南北向边界。选型若再写成「各有优劣看场景」，等于把机制丢掉。

本文是终章：用机制排除树收束判断，回收 Envoy 16 / HAProxy 14 指向的 eBPF 叶，写明何时不该跑 Cilium，列出仍开放的问题，并以 ADR 可粘贴的语言关闭「K8s eBPF 数据面内核」续作边界。不做跨方案延迟排行榜。

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

篇目	核心内容
第 15 篇 · Gateway 边界	南北向与东西向分工
第 16 篇 · 选型收束（终章）	排除树、开放问题、边界关闭

版本锚定：Cilium v1.20.0（docs.cilium.io/en/v1.20/；源码 tag v1.20.0）。嵌入 Envoy / Gateway API 随该发行说明。Tetragon 安全事件全书、完整 Ambient 实现重写本系列不承诺。

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

排除树每一叶必须回答一个可证伪的机制问题，而不是「看场景」。

flowchart TD
  l3{"Need identity-centric\nL3/L4 in kernel?"}
  l3 -->|"No"| l7{"Need rich per-request\nL7 policy?"}
  l7 -->|"No"| svc{"Only classic Service LB\non iptables/IPVS?"}
  svc -->|"Yes"| kproxy["kube-proxy +\nCNI for connectivity"]
  svc -->|"No"| cal{"Need routed CNI\nBGP-class model?"}
  cal -->|"Yes"| calico["Calico-class"]
  cal -->|"No"| other["Other CNI / out of scope"]
  l7 -->|"Yes"| iso{"Per-pod proxy isolation\nrequired?"}
  iso -->|"Yes"| side["Envoy sidecar"]
  iso -->|"No"| amb["Ambient / node proxy\n(+ CNI underneath)"]
  l3 -->|"Yes"| staff{"Can staff identity,\nmaps, Hubble axes?"}
  staff -->|"No"| defer["Do not run Cilium yet"]
  staff -->|"Yes"| kpr{"Accept KPR path matrix\nand single Service owner?"}
  kpr -->|"No"| split["Cilium without KPR\nor defer KPR"]
  kpr -->|"Yes"| enc{"Threat model needs\ntransparent encrypt?"}
  enc -->|"Optional later"| cil["Cilium eBPF datapath"]
  enc -->|"Yes, with path table"| cil

甜区：私有化/裸金属或自管 K8s，需要 identity NetworkPolicy +（可选）KPR 统一数据面，有 Hubble/五轴值班语言，L7 仅少数服务按需，能执行加密路径表与升级版本钉。

苦区：无人懂 identity 窗口却开默认拒绝；半开 KPR；用未标定延迟海报打倒 Calico；把「装了 Cilium」当成已上网格；启用 Gateway+node encryption+chaining 却无组合验收。

二、回收代理系列的 eBPF 叶

Envoy 16 排除树在「仅 L3/L4」处指向 eBPF；HAProxy 14 同样把「只要 L3/L4 转发与身份」指向 eBPF/IPVS。本系列交付后，该叶的机制内容如下——两边终章不再悬空：

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

• 「ACK/warming/Filter 失败」→ envoy/
  
• 「Runtime/stick-table/seamless reload」→ haproxy/
  
• 「identity/map/KPR/Hubble deny」→ 本系列 13
  
• 「该不该上 eBPF 数据面」→ 本篇排除树
  
• 「该不该上 RADOS/Rook」等 → 各存储系列；不要串台

Envoy/HAProxy 终章承诺的 eBPF 续作指针，到此关闭悬空状态。不是「永远不再写网络」，而是：同一句「去看 eBPF」不应再没有可核对篇章。

三、系列阅读路径回收

五个关键问题到终章仍然够用：

1. 东西向失败落在哪一层？→ 五轴 + map/hook。
   
2. Identity 相对 IP 消除了什么、窗口如何表现？→ 第 2、7、13 轴三。
   
3. KPR 后 Service 走哪条 BPF 路径？→ 第 5–6 篇。
   
4. Hubble/metrics 何时全绿仍丢包？→ 第 8、12–13 篇。
   
5. 何时选 Cilium？→ 本篇排除树。

写给后续维护者：升 Cilium 小版本或改 KPR/加密/Gateway 四元组时，先重跑第 13 篇与组合验收，再更新本篇排除树假设。

四、何时不该跑 Cilium（数据面否证）

下列任一成立，排除树上 Cilium 叶判负（可写进 ADR 否证条件）：

1. 不需要 identity 中心的 L3/L4——只要连通与简单防火墙。
   
2. 编制撑不住五轴与 map 压力——先托管或简化。
   
3. 主需求是每服务 L7 且已有 sidecar 经济学——先 Envoy 叶，CNI 可另选。
   
4. Service 所有权无法唯一——禁止半开 KPR。
   
5. 把 Cilium 当「点一下就有网格」且无人读第 12–13 篇——观测与排障缺位等于无生产资格。
   
6. 南北向组合（Gateway×加密×chaining）无验收仍要全开——先缩面。

否证触发后应重跑排除树，而不是口头「我们一直用 Cilium」。

与「已经装了」沉没成本

许多集群在排除树问句回答「否」之前就已经装上 Cilium（发行版默认、厂商镜像、或历史 POC 转正）。沉没成本不是机制判据。正确动作是：把现状当作假设重跑排除树——若判负，制定迁出或缩面计划（关 KPR、关加密、关 Gateway、甚至换 CNI），而不是用「重装成本高」伪造判正。迁出税要写进 ADR，但迁出税不能改写「编制撑不住五轴」这一事实。

若判正，则把第 12–13 篇补成门禁，使「已安装」变成「可运营」。POC 转正最常见的失败是：功能演示用 Hubble UI 截图，生产却没有 map pressure 告警与五轴 runbook。

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

5.1 Hubble 环满与真实丢包归因

问题：flow 环高占用时，DROPPED 是否系统性欠采样，导致轴一分诊失败？
检验：第 12 篇开放问题；固定可数 deny，对比 observe 与 datapath 计数。
关闭条件：测量或上游保证采样完备性的文档变更。

5.2 identity 窗口的发布门禁

问题：标签变更下 deny 窗口 P99 能否纳入 SLO？
检验：第 13 轴三；policy_implementation_delay + 合成探测。
现状：机制已知；默认门禁数值因集群而异，本系列不编造。

5.3 静默黑洞的可观测完备性

问题：无 Hubble drop 的南北向/加密组合失败，能否强制留下 reason？
检验：第 15 篇交叉区；固定四元组复现。
入口：上游 troubleshooting 与发行说明修复叙事。

5.4 Ambient + Cilium 双栈责任界面

问题：故障时先查共享 L4 代理还是 Hubble？
检验：第 14 篇开放问题；需要可执行分层 runbook。
约束：本系列不裁决产品胜负。

5.5 Gateway 与透明加密双税

问题：BackendTLS + WireGuard 同开时的 CPU/延迟税能否成为 ADR 数字？
约束：必须自测；正文不引用虚构百分比。
入口：第 15 篇开放问题。

关闭条件必须是测量或正式文档变更，不是路线图幻灯片。

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

1. 排除树进 ADR：写清卡在哪一叶机制判据；附否证条件（编制减员、改走 sidecar 主路径、强制双轨 kube-proxy、关闭加密威胁模型等）。示例句：
   「若平台不再维护 identity/Hubble 五轴值班，或 Service 必须由 kube-proxy 唯一拥有且禁止 KPR，则 Cilium eBPF 叶必须重跑排除树，禁止以历史惯性续跑。」
2. 若选了 Cilium：第 13 篇五轴进发布门禁；第 6 篇 Service 所有权进网络变更单；第 9/15 篇组合四元组进上线检查；第 12 篇三类仪表盘进值班——缺一项降级为试验集群。
   
3. 若没选：用第 14 篇机制表做代际复盘；禁止无口径延迟截图重开「要不要 Cilium」争论。需要代理内核判断时回 Envoy/HAProxy 终章；需要产品勾选时回 k8s-network/13。

终章立场：Cilium 数据面值得写 16 篇，是因为失败可命名——identity、policy map、service map、CT、Hubble verdict、加密路径、KPR 所有权。选型若离开这些名字，讨论退回安装量与品牌口号。记住一个动作：先排除，再开 KPR，再开加密与 Gateway——排除自带否证，KPR 自带路径矩阵，加密与 Gateway 自带组合验收。

对平台团队的务实建议：先用第 13 篇在试验命名空间跑通一次真实或演练故障（至少覆盖 policy deny 与 Service 空后端），再决定是否把 Cilium 定为默认 CNI。若演练里卡在「读不懂 identity」，优先补第 2、7、12 篇门禁与编制，而不是先开 ClusterMesh 与 Gateway。排除树的正确用法是缩短错误迁移，而不是证明某品牌永远正确。

若读者时间只够两篇：读 01 全景 建立缺口意识，再读本篇排除树；然后按自己的主轴跳进 06/07/13 之一。完整通读的收益是「症状能落格」；跳读的风险是把 Hubble UI 当成根因库，或把 KPR 当成零失败保证。

七、与姊妹终章对齐的纪律

读完三边后，不应再问「代理系列为啥不讲 CNP」——那是分工，不是遗漏。

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

给维护者：补丁级更新应改版本钉与开放问题进展，而不是重写排除树的问题顺序。若开放问题被测量关闭，在本篇追加一小节「已关闭项」并链到复盘或实验记录，避免后人重复开题。

回到系列开头的缺口：站内已有 Cilium 产品篇与 eBPF VM 系列，缺的是「东西向失败如何落格到 identity/map/KPR」。若读完 16 篇仍只能复述功能清单，说明阅读停在目录；若能在故障里说出「这是轴三身份窗口」或「这是 Service 所有权双轨」，机制文才算交货。

参考资料

规范 / 官方文档（A）

• Cilium v1.20.0 Concepts / Operations / Observability / Transparent Encryption / Gateway API
• 源码 tag v1.20.0：bpf/、pkg/datapath/、pkg/identity/、pkg/maps/
• Kubernetes：NetworkPolicy、Service、EndpointSlice、Gateway API

站内对照

• 系列目录
• Envoy 16 选型收束
• HAProxy 14 选型收束
• k8s-network/12 Calico
• k8s-network/13 Cilium
• eBPF 内核实现
• 第 13 篇 · 排障
• 第 14 篇 · 对照
• 第 15 篇 · Gateway 边界

论文谱系

• McCanne, S. & Jacobson, V. (1993). The BSD Packet Filter. USENIX Winter ’93
• Höiland-Jørgensen, T. et al. (2018). The eXpress Data Path. CoNEXT ’18

实验台账

• 本篇无跨方案 benchmark；选型依据为机制排除。

至此，系列在机制层闭合：从 identity 与包路径，到观测、五轴、对照与南北向边界，再到排除树。后续补丁级更新应改版本钉与开放问题进展，而不是重写「先排除再选」的顺序。

→ 上一篇：Gateway 边界 · 系列目录