【Cilium / eBPF】选型收束：排除树、开放问题与系列边界关闭
内容提要
本文为Cilium/eBPF数据面系列终章，提出以机制排除树替代“看场景”选型。核心是先判断是否需要identity中心L3/L4、L7策略、KPR等，再决定是否采用Cilium。明确何时不应使用（如编制不足、仅需简单连通），强调沉没成本非判据，并列出开放问题与ADR建议，收束系列。
延伸解读
排除树：从“看场景”到可证伪判据
本文提出用机制排除树替代“各有优劣看场景”的选型方式。每个决策点都是可证伪的机制问题，例如是否需要 identity 中心的 L3/L4、是否接受 KPR 的路径矩阵等。这种结构化方法让选型不再依赖主观偏好，而是基于具体技术条件和运维能力，便于团队达成共识并写入 ADR。
沉没成本不是选型依据
许多集群已默认安装 Cilium，但本文强调“已经装了”不应成为继续使用的理由。正确做法是将现状作为假设重新跑排除树，若判负则制定迁出或缩面计划，如关闭 KPR、加密或 Gateway。迁出税应写入 ADR，但不能因此掩盖编制撑不住五轴等事实。
开放问题：可证伪的改进方向
系列列出五个开放问题，如 Hubble 环满时 DROPPED 是否欠采样、identity 窗口能否纳入 SLO、静默黑洞的可观测性等。这些问题均要求通过测量或文档变更来关闭，而非依赖路线图承诺。这为后续维护者提供了明确的验证路径，避免重复开题。
ADR 友好收束：先排除，再开 KPR
文章给出可直接用于 ADR 的示例句，强调若平台无法维护 identity/Hubble 五轴值班，或 Service 必须由 kube-proxy 唯一拥有，则必须重跑排除树。同时建议先用第 13 篇在试验环境演练故障，再决定是否将 Cilium 设为默认 CNI，以缩短错误迁移。
Q&A
Cilium/eBPF选型时，如何用机制排除树做决策？
机制排除树通过一系列可证伪的机制问题来决策，而不是依赖“看场景”。核心问题包括：是否需要内核态、以identity为中心的L3/L4？是否需要丰富的每请求L7策略？是否只需要经典Service LB（iptables/IPVS）？是否需要BGP/路由型CNI？编制上能否支撑identity/map/Hubble五轴？能否接受唯一Service所有权（KPR）？透明加密威胁模型与路径表是否写清？根据回答，决定是否采用Cilium，或选择kube-proxy、Calico、sidecar、Ambient等其他方案。
哪些情况下不应该使用Cilium？
以下情况不应使用Cilium：不需要identity中心的L3/L4，只需连通和简单防火墙；编制撑不住五轴与map压力；主需求是每服务L7且已有sidecar经济学；Service所有权无法唯一（禁止半开KPR）；把Cilium当“点一下就有网格”且无人读观测排障文档；南北向组合（Gateway×加密×chaining）无验收仍要全开。
已经装了Cilium但不符合排除树条件，应该怎么办？
沉没成本不是机制判据。正确做法是把现状当作假设重跑排除树，若判负，制定迁出或缩面计划（关KPR、关加密、关Gateway、甚至换CNI），而不是用“重装成本高”伪造判正。迁出税要写进ADR，但不能改写“编制撑不住五轴”这一事实。若判正，则把第12-13篇补成门禁，使“已安装”变成“可运营”。
Cilium系列中提到的五个关键问题是什么？
五个关键问题：1. 东西向失败落在哪一层？→ 五轴 + map/hook。2. Identity相对IP消除了什么、窗口如何表现？→ 第2、7、13篇轴三。3. KPR后Service走哪条BPF路径？→ 第5-6篇。4. Hubble/metrics何时全绿仍丢包？→ 第8、12-13篇。5. 何时选Cilium？→ 排除树。
Cilium选型时，如何避免常见的错误？
常见错误包括：无人懂identity窗口却开默认拒绝；半开KPR；用未标定延迟海报打倒Calico；把“装了Cilium”当成已上网格；启用Gateway+node encryption+chaining却无组合验收。避免方法是遵循排除树，确保机制判据满足，并落实观测与排障门禁。
Cilium系列中提到的开放问题有哪些？
开放问题包括：1. Hubble环满时DROPPED是否系统性欠采样；2. identity窗口的发布门禁能否纳入SLO；3. 静默黑洞的可观测完备性；4. Ambient+Cilium双栈责任界面；5. Gateway与透明加密双税。这些问题需要测量或正式文档变更才能关闭。
读完Cilium系列后，如何将结论落地到ADR？
将排除树进ADR，写清卡在哪一叶机制判据，附否证条件（如编制减员、改走sidecar主路径、强制双轨kube-proxy、关闭加密威胁模型等）。示例句：“若平台不再维护identity/Hubble五轴值班，或Service必须由kube-proxy唯一拥有且禁止KPR，则Cilium eBPF叶必须重跑排除树，禁止以历史惯性续跑。”
Cilium与Envoy/HAProxy在选型上的分工是什么？
分工口令：ACK/warming/Filter失败→envoy/；Runtime/stick-table/seamless reload→haproxy/；identity/map/KPR/Hubble deny→本系列；该不该上eBPF数据面→排除树。Envoy/HAProxy终章承诺的eBPF续作指针，到此关闭悬空状态。
