1. Cilium 概述:项目背景、核心功能与 eBPF 关系

1.1 项目背景:从容器网络到云原生基础设施

Cilium 诞生于 2015 年,由 Thomas Graf 等内核网络专家创建,旨在解决传统容器网络方案(如 Calico、Flannel)在微服务架构下面临的性能瓶颈与安全粒度不足问题。其核心设计理念是:利用 eBPF 技术将网络、安全与可观测性能力下沉到 Linux 内核,绕过 iptables 和 overlay 隧道带来的性能损耗。

关键里程碑:
  • 2015 — Cilium v1.0 发布,基于 eBPF 实现 L3/L4 网络策略
  • 2017 — 加入 CNCF 孵化,引入 L7 HTTP/gRPC 感知能力
  • 2021 — 成为 CNCF 毕业项目,被 AWS、Google、Red Hat 等广泛采用
  • 2023 — Cilium 成为 Kubernetes 网络插件默认选项之一(如 EKS Anywhere、AKS)

Cilium 的定位已从“容器网络插件”演变为“云原生网络、安全与可观测性平台”,其核心依赖 eBPF 技术实现内核级数据面加速。

1.2 核心功能:网络、安全、可观测性三位一体

Cilium 的功能体系可划分为三个核心领域,下表展示了各领域的关键能力与实现机制:

功能领域 关键能力 实现机制(eBPF 挂钩) 典型场景
网络 Pod 到 Pod 通信、Service 负载均衡、多集群互联(Cluster Mesh) TC(Traffic Control)入口/出口、XDP(eXpress Data Path) K8s 集群内东西向流量、南北向 Ingress 加速
安全 L3/L4 网络策略、L7 HTTP/gRPC 感知策略、身份认证(基于 SPIFFE) cgroup 套接字、tracepoint、kprobe 零信任网络、微服务间最小权限控制
可观测性 Hubble 流量可视化、服务依赖图、DNS 监控、TCP 指标 perf_event 环形缓冲区、kprobe、tracepoint 故障排查、性能分析、安全审计
缓存命中故障排查视角: 网络功能中的 Service 负载均衡依赖 eBPF 维护的 conntrack 和 lb map 缓存。当缓存未命中时,数据包会回退到内核协议栈处理,导致延迟飙升。这正是本课程后续章节的核心排查对象。

1.3 Cilium 与 eBPF 的关系:内核可编程性的基石

eBPF(extended Berkeley Packet Filter)是 Linux 内核的一种沙箱化可编程技术,允许用户在不修改内核源码或加载内核模块的情况下,安全地注入自定义程序。Cilium 是 eBPF 在云原生领域最成功的应用之一,二者关系可概括为:

  • eBPF 提供执行环境: Cilium 将网络策略、负载均衡逻辑编译为 eBPF 字节码,通过 bpf() 系统调用加载到内核的特定挂钩点(如 TC、XDP、cgroup)。
  • Cilium 封装复杂性: 用户无需编写 eBPF 代码,通过 Kubernetes CRD(如 CiliumNetworkPolicy)声明式配置,Cilium 代理自动生成并管理 eBPF 程序的生命周期。
  • 缓存命中依赖 eBPF Map: Cilium 使用 eBPF Map(哈希表、数组)存储连接跟踪、端点信息、策略规则等运行时数据。缓存命中故障本质上是 eBPF Map 查找失败或过期。

下图展示了 Cilium 数据面中 eBPF 程序的加载与缓存交互流程:

Cilium 数据面:eBPF 程序与缓存交互流程 用户空间 Cilium Agent (DaemonSet) 内核空间 eBPF 验证器 + JIT 编译器 eBPF 程序 TC/XDP 入口 cgroup 套接字 eBPF Maps (缓存) conntrack map lb map / endpoint map 数据包 命中 → 快速转发 未命中 → 回退协议栈 说明: 缓存命中故障排查核心:检查 eBPF Map 中 conntrack 条目是否过期、lb map 后端是否一致、endpoint map 是否与 Pod IP 同步。

1.4 缓存命中故障的根源:eBPF Map 查找失败

在 Cilium 数据面中,每个数据包到达节点时,eBPF 程序会依次执行以下查找:

  1. Endpoint Map 查找: 根据目标 IP 判断是否为本地 Pod,若未命中则走 overlay 或路由。
  2. Conntrack Map 查找: 检查连接跟踪表,若未命中则创建新条目(可能因表满导致逐出)。
  3. LB Map 查找: 对于 Service 流量,查找后端映射表,若未命中则回退到 kube-proxy 或内核协议栈。
常见缓存未命中原因:
  • Map 容量不足: 默认 conntrack map 大小为 65536,高并发场景下易溢出。
  • 条目过期: 连接跟踪超时时间(如 TCP 默认 6 小时)与实际流量模式不匹配。
  • 端点变更: Pod 扩缩容后,endpoint map 未及时更新,导致旧 IP 查找失败。
  • 内核版本差异: 低版本内核(如 4.19)对 eBPF Map 操作有性能限制。

1.5 课程定位:从原理到实战的缓存命中排查

本课程后续章节将深入以下内容:

章节 核心内容 关联缓存问题
第 2-5 章 eBPF Map 原理与 Cilium 数据结构 理解 conntrack/lb map 的底层实现
第 6-10 章 缓存命中故障场景复现与诊断工具 使用 bpftool、cilium monitor 定位未命中
第 11-15 章 性能调优与内核参数配置 调整 map 大小、超时时间、GC 策略
第 16-20 章 生产环境案例与自动化排查脚本 大规模集群缓存命中率优化

通过本课程,你将掌握从 eBPF 原理到 Cilium 缓存命中故障排查的完整技能链,能够独立诊断和优化容器网络环境中的性能瓶颈。