Cilium网络缓存与连接跟踪故障诊断 - 第1节
1.1 Cilium 是什么
Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的云原生网络、安全与可观测性开源项目。它被设计为 Kubernetes 的 CNI（Container Network Interface）插件，但能力远超传统 CNI：Cilium 利用 eBPF 在内核态动态注入程序，实现网络转发、负载均衡、网络策略、流量加密、可观测性等功能，而无需修改内核代码或容器应用。
Cilium 的核心定位是：“内核级云原生数据平面”。它通过 eBPF 将网络、安全和可观测性逻辑直接运行在 Linux 内核中，从而获得接近原生内核的性能和极低的延迟。
关键特性速览：
- 高性能网络：基于 eBPF 的转发路径，绕过 iptables 和 conntrack 的性能瓶颈。
- 身份安全：基于 Kubernetes 标签（而非 IP 地址）定义网络策略，支持 L3/L4/L7 策略。
- 可观测性：通过 Hubble 组件提供集群级别的流量可视化、指标和事件监控。
- 多集群网络：支持 Cluster Mesh，实现跨集群 Pod IP 直连。
- 透明加密：支持 WireGuard 或 IPsec 加密节点间流量。
1.2 eBPF 核心原理
eBPF 是 Cilium 的技术基石。理解 eBPF 是理解 Cilium 性能优势的前提。eBPF 允许用户在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。
1.2.1 eBPF 工作流程
- 编写与编译：开发者使用 C 语言编写 eBPF 程序，通过 LLVM/Clang 编译为 eBPF 字节码。
- 验证：用户态程序（如 Cilium Agent）通过
bpf()系统调用将字节码加载到内核。内核的 eBPF 验证器会检查程序是否安全终止、无循环、无越界访问。 - JIT 编译与附加：通过 JIT（Just-In-Time）编译器将字节码转换为本地机器指令，并附加到指定的内核事件钩子（如网络包接收、系统调用、函数入口/出口）。
- 执行与数据交互：当内核事件触发时，eBPF 程序自动执行。程序可以通过 eBPF Maps（键值存储）与用户态程序交换数据，或直接修改包内容、决定转发行为。
性能关键点：eBPF 程序运行在内核态，避免了传统网络方案中用户态与内核态之间的上下文切换和数据拷贝。这是 Cilium 能实现微秒级延迟的核心原因。
1.2.2 eBPF 与传统网络方案对比
| 维度 | 传统 iptables / netfilter | eBPF / Cilium |
|---|---|---|
| 数据路径 | 线性遍历规则链，规则越多延迟越高 | 哈希查找 + 直接跳转，O(1) 复杂度 |
| 连接跟踪 | 全局 conntrack 表，锁竞争严重 | Per-CPU 或 Per-Pod 的 eBPF Map，无锁或细粒度锁 |
| 策略执行 | 依赖 iptables 规则，更新需重建整条链 | 动态更新 eBPF Map，原子替换，无中断 |
| 可编程性 | 仅支持预定义动作（ACCEPT/DROP/SNAT） | 支持任意内核态逻辑（封装、加密、负载均衡、观测） |
| 性能开销 | 高（尤其在大规模集群中） | 极低（接近原生内核转发） |
1.3 Cilium 在云原生网络中的定位与优势
在云原生生态中，Cilium 定位为“下一代容器网络与安全基础设施”。它填补了传统 CNI（如 Flannel、Calico）在性能、安全粒度和可观测性上的不足。
1.3.1 定位：从 CNI 到统一数据平面
- 替代传统 CNI：提供 Pod 网络连通性（IPAM、路由、Overlay）。
- 替代 kube-proxy：通过 eBPF 实现 Service 负载均衡，性能远优于 iptables 模式。
- 替代网络策略引擎：原生支持 Kubernetes NetworkPolicy，并扩展至 L7 策略（HTTP/gRPC/Kafka）。
- 替代独立可观测性工具：Hubble 提供基于 eBPF 的零侵扰流量监控。
1.3.2 核心优势
| 优势 | 说明 |
|---|---|
| 极致性能 | eBPF 数据路径绕过 iptables，延迟降低 50%-80%，吞吐提升 2-5 倍。 |
| 安全身份 | 基于 Kubernetes 标签（而非 IP）定义策略，Pod 重启或迁移后策略自动生效。 |
| 深度可观测 | Hubble 提供 L3/L4/L7 流量日志、指标和 Service Map，无需 sidecar 代理。 |
| 动态更新 | eBPF 程序可原子替换，策略和路由更新无需重启 Pod 或重建连接。 |
| 多集群原生 | Cluster Mesh 实现跨集群 Pod IP 直连，无需网关或代理。 |
注意：Cilium 的优势高度依赖内核版本。建议生产环境使用 Linux 内核 5.10+，以获取完整的 eBPF 特性（如 BPF_PROG_TYPE_SK_LOOKUP、BPF_MAP_TYPE_RINGBUF）。低版本内核可能回退到 iptables 模式，性能优势将大幅减弱。
1.4 Cilium 架构总览
下图展示了 Cilium 的核心组件及其在 Kubernetes 节点上的部署关系。理解这个架构是后续排查缓存命中故障的基础。
1.5 缓存命中故障排查的切入点
在 Cilium 环境中，“缓存命中”通常指 eBPF Maps 中的连接跟踪条目、端点信息或策略规则的查找结果。当缓存未命中时，数据包可能被错误地丢弃、转发到错误路径或触发不必要的策略重新评估，导致连接中断、延迟飙升或吞吐下降。
常见缓存相关故障场景：
- 连接跟踪表溢出：eBPF Map
cilium_ct4/cilium_ct6满，导致新连接被丢弃。 - 端点信息过期：Pod 迁移后，eBPF Map 中的端点 IP 未及时更新，导致路由错误。
- 策略缓存不一致：策略更新后，eBPF 程序仍使用旧策略 Map，导致流量误放行或误拦截。
- Service 后端缓存失效：后端 Pod 变更后，负载均衡 Map 未同步，导致请求被转发到已终止的 Pod。