本文对比Linkerd 2.20与Istio xDS、Ambient及Cilium L4的机制差异，聚焦控制面协议、数据面引擎与排障坐标。Linkerd采用专用gRPC API与per-Pod代理，适合接受专用API的团队；Istio xDS适合存量CRD或多客户端场景；Ambient在xDS内去sidecar；Cilium适合仅需L3/L4。不比较性能，仅提供机制选型依据。

> 本文是写作规划，不是可发布正文。拆解对象：Cilium 在 Kubernetes 上的 eBPF 数据面内核——以 Cilium v1.20.0（2026-07；docs.cilium.io/en/v1.20/ / stable）为主线，把一次东西向包从 endpoint / identity，经 BPF 挂载点与…

本文对比Envoy Gateway与Cilium、Istio、Ingress注解等替代方案，聚焦翻译内核与排障坐标差异，而非性能。核心观点：各实现虽支持Gateway API，但控制面机制不同，如Cilium嵌入Envoy、Istio用istiod、Contour独立翻译器。选型需考虑团队隔离与观测链需求，避免硬套统一排障方法。

本文讨论Envoy Gateway与Cilium东西向数据面的排障接缝。请求离开网关后，失败可能落在Cilium的identity策略、Service BPF或加密路径。需区分北段（Gateway状态、Envoy日志）与南段（Hubble、identity），禁止交叉解释。固定CNI模式、KPR、加密、Gateway四元组，避免误判。工单改派需明确字段，不伪造证据。

本文对比了Tetragon与Falco、auditd、Cilium CNP/Hubble、seccomp四种安全方案的机制差异，聚焦于过滤位置与能否内联阻断。Falco在用户态解析参数存在TOCTOU竞态风险；auditd仅记录不阻断；CNP处理包路径而非进程；seccomp仅按syscall号过滤。Tetragon在内核hook匹配并支持Override，但仍有竞态窗口。选型需权衡机制与运维成本。

本文介绍Tetragon v1.7.0的eBPF运行时安全机制，聚焦进程血缘、Sensor/Hook、策略加载、过滤分层和强制执行五轴坐标系，并阐述exec_id、execve_map等关键概念。文章旨在补齐Cilium数据面与可观测性之间的安全内核层，提供排障指南，并规划16篇系列文章路线，强调可核对锚点与失败模式分析。

本文介绍Cilium eBPF数据面深度拆解系列，定位补足产品与内核实现间的缺口。核心提出五条排障坐标系：Identity、BPF挂载、Map状态、包路径、策略观测，并确立三条不变量：以Identity为策略键、map为权威状态、L3/L4尽量留在hook。文章规划16篇路线，聚焦可归因的失败模式，而非性能排名，为后续深入分析奠定框架。

本文介绍Cilium v1.20中Endpoint与Identity机制：Endpoint是节点上共享IP的网络实体，Identity是由安全相关标签导出的集群范围数字键，用于策略匹配。标签变更会触发身份重解析，产生init拒绝、新身份拒绝、旧身份放行三类短暂窗口。排障时应区分窗口类型，而非简单归咎于策略错误或系统不稳定。

本文介绍Cilium v1.20的BPF挂载机制，核心是XDP、TC、socket等hook在数据路径上的分工：XDP负责早过滤，TC处理策略与转发，socket加速同节点连接。程序经Go loader加载替换，与map世代耦合，能力不足时回退iptables。排障需确认程序是否实际挂载，而非仅看Pod状态。

本文介绍Cilium v1.20的BPF Map状态轴，涵盖Policy、Service、CT/NAT等核心表职责、默认上限及满表故障表象。强调排障先定位具体表，注意动态容量调整与NAT/CT约束，并指出升级世代切换和容量规划纪律的重要性。

本文介绍Cilium eBPF数据面东西向（Pod到Pod及经Service）的包路径停顿点。核心包括：同节点直连路径、经ClusterIP的LB/CT查找、跨节点overlay/加密、socket加速不替代策略、netfilter旁路是主路径目标但存在回退共存。排障需先查策略/身份，再查Service/CT，并区分东西向与南北向入口hook差异。

Cilium KPR使用BPF map替代kube-proxy的iptables/IPVS，实现O(1)查找与原子更新。ClusterIP采用socket-LB，NodePort支持SNAT/DSR/Hybrid模式，Maglev用于南北向一致性哈希。排障需区分socket与per-packet平面，注意map容量、externalTrafficPolicy及混部冲突。

本文介绍Cilium策略编译机制：从声明式策略经解析、选择器蒸馏为数字Identity，最终生成per-endpoint BPF策略map。重点分析default-deny按方向切入的时序窗口、Identity分配与传播延迟、ClusterMesh同步滞后等故障场景，并讨论L7代理重定向、实体规则及排障归因方法。

本文讨论Cilium/Hubble可观测性：Hubble flow提供连接级事件与verdict，metrics提供聚合计数，二者口径不同。全绿面板不代表无丢包，可能丢在未观测平面。排障应先定观测点，区分FORWARDED/DROPPED/REDIRECTED，注意采样、高基数、Relay延迟等盲区，结合Cilium agent与主机指标综合判断。

Cilium透明加密通过WireGuard或IPsec实现，与身份发现耦合，存在明文传播窗口。严格模式将明文窗口转为失败，但增加脆弱性。加密带来CPU、MTU和排障成本，不替代策略或TLS。选择需基于威胁模型，注意节点覆盖、密钥轮换和升级兼容性。

Cilium的L7服务网格能力基于BPF处理L3/L4，按需将流量重定向至节点Envoy处理L7语义，与sidecar和Istio Ambient模式不同。它适合以身份和L3/L4策略为主、L7规则较少的场景，但节点Envoy是共享故障域，且不覆盖完整Istio流量管理功能。开启时应渐进验证，避免“假网格”承诺。

ClusterMesh 提供跨集群 Pod 连通、身份感知策略及服务发现，但非强一致或高可用保证。其依赖相同配置、无冲突 CIDR 及同步状态，存在身份容量限制与同步滞后风险。运维需关注集群 ID 固定、地址规划及同步状态，避免误将网络连通视为应用 HA。

本文介绍Cilium v1.20.0可观测性排障方法，强调先选观测层（status、Hubble、metrics、bpftool），再读字段语义。区分控制面健康与数据面丢包，指出status全绿不等于策略放行，Hubble环满非丢包。建议用cilium-dbg解读BPF map，避免bpftool误读，并给出业务症状到观测层的映射及常见误判。

本文介绍Cilium v1.20网络排障的五轴坐标系：通用丢包、策略拒绝、身份漂移、服务黑洞和加密失败。每轴按症状、排查顺序和禁忌操作展开，强调先分型再行动，避免盲目重启或改策略。通过Hubble、BPF map和状态检查定位根因，并保留最小证据包用于复盘。