📚 课程目录第2章 Cilium架构基础

2. Cilium架构基础：Cilium数据平面与eBPF技术原理，以及其在Kubernetes中的角色

Cilium 并非传统的基于 iptables 或 IPVS 的 CNI 插件。其核心创新在于将 eBPF（extended Berkeley Packet Filter） 技术引入 Kubernetes 网络与安全层，从根本上改变了数据平面的处理方式。理解 Cilium 的架构，首先需要掌握 eBPF 如何工作，以及 Cilium 如何利用它构建出高性能、可观测且安全的数据平面。

2.1 eBPF 技术原理：内核中的可编程沙箱

eBPF 是一项允许用户在 Linux 内核中安全地运行沙箱化程序的技术，无需修改内核源代码或加载内核模块。它相当于在内核中提供了一个轻量级的虚拟机环境，使得网络、跟踪、安全等子系统可以被动态编程。

  关键概念： eBPF 程序通过 bpf() 系统调用加载到内核，经过验证器（Verifier）严格检查（确保无循环、无越界、终止性），然后由 JIT 编译器编译为本地机器码执行。这保证了安全性与高性能。

eBPF 程序被挂载到内核中的各种钩子点（Hook Points），例如网络数据包到达（XDP、TC）、系统调用入口/出口、函数跟踪点等。当事件触发时，eBPF 程序被原子性地执行，并可以通过 eBPF Maps 与用户空间或其它 eBPF 程序交换数据。

与 Cilium 的关系： Cilium 是 eBPF 在 Kubernetes 领域最成熟的应用之一。它利用 eBPF 替代了 kube-proxy 的 iptables 模式，并实现了网络策略、负载均衡、可观测性等功能，全部在内核态完成，避免了大量上下文切换和数据拷贝。

2.2 Cilium 数据平面架构

Cilium 的数据平面完全构建在 eBPF 之上，其核心组件包括 Cilium Agent（用户空间守护进程）和 eBPF 程序（内核空间执行）。Agent 负责与 Kubernetes API Server 交互，监听 Pod、Service、NetworkPolicy 等资源变化，然后将这些高层意图编译为 eBPF 程序并加载到内核。

下图展示了 Cilium 数据平面的核心组件及其在 Kubernetes 节点上的交互关系：

数据包处理流程简述：

网卡接收：数据包到达节点网卡。
XDP 钩子：在驱动层，eBPF 程序（XDP）可以最早决定丢弃、转发或重定向数据包，性能极高。
TC 钩子：数据包进入内核协议栈的 Traffic Control 层，Cilium 的 eBPF 程序在此执行网络策略检查、负载均衡（DNAT）、封装/解封装（VXLAN/Geneve）等操作。
eBPF Maps 查询：eBPF 程序通过查询 Maps 获取端点信息、策略规则、Service 后端列表等，实现无锁、高效的决策。

2.3 Cilium 在 Kubernetes 中的核心角色

Cilium 在 Kubernetes 集群中扮演了多重角色，远远超出了传统 CNI 插件的范畴。下表总结了其主要功能领域：

角色	功能描述	eBPF 实现优势
CNI 网络	为 Pod 分配 IP 地址，实现 Pod 间、Pod 与 Service 间的连通性。支持 Overlay（VXLAN/Geneve）和原生路由模式。	直接通过 eBPF 进行路由决策和封装，无需经过 iptables 或用户空间代理，延迟更低。
网络策略引擎	实现 Kubernetes NetworkPolicy，并支持 CiliumNetworkPolicy（L3-L7 策略），可基于 HTTP/gRPC 方法、Kafka 主题等应用层协议进行访问控制。	策略执行点位于内核 eBPF 程序中，每个数据包都经过策略检查，无需 iptables 规则遍历，性能线性扩展。
负载均衡器	完全替代 kube-proxy，为 ClusterIP、NodePort、ExternalIPs 等 Service 类型提供高性能负载均衡。	eBPF 实现 Maglev 或一致性哈希算法，连接跟踪（conntrack）也在 eBPF 中完成，避免 iptables 规则爆炸问题。
可观测性	通过 Hubble 组件提供集群网络流量的可视化、监控和故障排查能力。支持 L3/L4/L7 流日志、指标和分布式追踪。	eBPF 程序在内核态直接采集数据包元数据，开销极低，且能捕获所有流量，无需 sidecar 代理。
安全与身份	基于身份（Identity）而非 IP 地址进行安全隔离。每个 Pod 被分配一个安全身份，策略基于身份执行，适应动态 IP 场景。	eBPF Maps 存储身份与端点映射，策略查找是 O(1) 的 Map 查询，而非 iptables 的规则链遍历。

2.4 关键架构组件：Cilium Agent 与 Operator

除了数据平面的 eBPF 程序，Cilium 还包含两个重要的控制平面组件：

Cilium Agent (DaemonSet)：运行在每个 Kubernetes 节点上。负责：
- 与 Kubernetes API Server 通信，监听 Pod、Service、Endpoint、NetworkPolicy 等资源变化。
- 管理本地 eBPF 程序的编译、加载和更新。
- 维护本地 eBPF Maps（如端点映射、策略映射、Service 映射）。
- 提供本地 API 供 cilium CLI 和 Hubble 查询状态。
Cilium Operator (Deployment)：集群级别的控制器。负责：
- 处理集群范围的协调任务，如 IP 地址管理（IPAM）、多集群网络。
- 管理 CiliumEndpoint 和 CiliumIdentity 等自定义资源（CRD）的生命周期。
- 处理节点故障转移和状态清理。

架构注意事项： 在 Helm 部署 Cilium 时，需要正确配置 Agent 和 Operator 的副本数、资源限制以及 eBPF 相关的内核参数（如 kernel.bpf_stats_enabled）。错误的配置可能导致 Agent 无法加载 eBPF 程序，进而影响整个集群的网络连通性。

2.5 数据平面 vs. 控制平面：Helm 部署视角

从 Helm Chart 开发者的角度看，理解 Cilium 的数据平面与控制平面分离至关重要。Helm values 文件中的配置项直接影响这两个平面的行为：

平面	Helm 配置示例	影响范围
数据平面	`routingMode: "native"`、`ipam.mode: "kubernetes"`、`kubeProxyReplacement: "strict"`	决定数据包如何被转发、封装、负载均衡。直接影响网络性能与兼容性。
控制平面	`operator.replicas: 2`、`agent.healthPort: 9879`、`hubble.relay.enabled: true`	决定集群管理、可观测性数据采集、高可用性。影响运维复杂度和资源消耗。