2. Cilium架构基础：核心组件关系
Cilium 的架构由多个协同工作的组件构成，理解它们之间的依赖与数据流关系是进行网络策略配置和容量调优的前提。本章聚焦于 Cilium Agent、Cilium Operator、CNI 插件以及 eBPF 数据路径这四个核心要素，梳理它们在 Kubernetes 集群中的角色与交互方式。
2.1 组件全景与职责划分
下表从功能定位、运行位置和生命周期三个维度对比了 Cilium 的核心组件：
| 组件 | 运行位置 | 核心职责 | 生命周期 |
|---|---|---|---|
| Cilium Agent | 每个 Kubernetes 节点（DaemonSet） | 管理 eBPF 程序、同步网络策略、处理端点事件 | 与节点共存，重启影响本地数据路径 |
| Cilium Operator | 集群内任意节点（Deployment） | 协调集群级状态、处理 IPAM、更新 CiliumEndpoint | 高可用部署，故障由 Leader 选举接管 |
| CNI 插件 | 每个节点（二进制文件） | 响应 kubelet CNI 请求，调用 Agent 完成网络接入 | 每次 Pod 创建/删除时触发 |
| eBPF 数据路径 | 内核（由 Agent 加载） | 执行包转发、策略过滤、负载均衡 | 持续运行，随策略更新热替换 |
关键认知：Agent 是“数据面大脑”，Operator 是“控制面协调器”。Agent 故障会导致本地节点网络中断，而 Operator 短暂不可用不会影响已有数据路径，但会阻塞新 Pod 的 IP 分配和全局状态同步。
2.2 组件交互流程与数据路径
下图展示了从 Pod 创建到网络流量经过 eBPF 数据路径的完整组件协作关系：
2.3 组件协作的详细机制
2.3.1 Cilium Agent：数据面的核心引擎
Agent 是运行在每个节点上的 DaemonSet，它通过 Kubernetes Watch 机制监听 Pod、Service、Endpoint 和 NetworkPolicy 的变化。当检测到变更时，Agent 执行以下操作：
- 编译 eBPF 程序：将高层网络策略和端点信息编译为 eBPF 字节码。
- 加载到内核：通过
bpf()系统调用将程序附加到网络钩子（如 XDP、TC、cgroup）。 - 管理本地端点：维护
CiliumEndpoint资源，记录 Pod 的 IP、安全标识和策略映射。
调优关注点：Agent 的
--bpf-map-dynamic-size-ratio 参数控制 eBPF Map 的预分配比例。在 Pod 密度超过 100/节点的集群中，建议将该值从默认 0.0025 提升至 0.005，以减少 Map 扩容带来的性能抖动。
2.3.2 Cilium Operator：集群级状态协调器
Operator 以 Deployment 形式运行，通常部署 2 个副本并通过 Leader 选举保证高可用。它的核心职责包括：
- IPAM（IP 地址管理）：从集群 IP 池中分配 CIDR 段给新加入的节点。
- CiliumEndpoint 同步：当 Agent 创建或更新本地端点时，Operator 负责将变更同步到 Kubernetes API Server。
- 身份管理：维护安全身份（Security Identity）与标签的映射关系，确保跨节点策略一致性。
容量规划提示：Operator 的
--operator-pprof 和 --operator-metrics 端口在生产环境中应开启，用于监控 Leader 选举延迟和 API Server 请求速率。当集群规模超过 500 节点时，建议将 Operator 的 --nodes-interval 从默认 30s 调整为 60s，以降低 API Server 负载。
2.3.3 CNI 插件：Pod 网络接入的触发器
CNI 插件是一个轻量级二进制文件，由 kubelet 在 Pod 创建/删除时调用。它不直接处理网络流量，而是作为 Agent 的“前哨”：
- kubelet 调用 CNI 插件，传入 Pod 的 namespace、name 和网络命名空间。
- CNI 插件通过 Unix Socket 向本地 Agent 发送
AddNetwork或DelNetwork请求。 - Agent 根据请求创建或销毁虚拟网络设备（veth pair），并更新 eBPF Map。
# CNI 插件调用 Agent 的典型流程（日志示例）
time="2025-01-15T10:00:00Z" level=info msg="Received CNI AddNetwork request"
containerID="abc123" ifName="eth0" netNs="/proc/1234/ns/net"
time="2025-01-15T10:00:01Z" level=info msg="Endpoint created successfully"
endpointID=456 identity=789 ip="10.0.1.5"2.3.4 eBPF 数据路径：内核中的策略执行点
eBPF 数据路径是 Cilium 性能优势的核心。Agent 将编译后的 eBPF 程序挂载到内核的不同钩子点，形成完整的包处理流水线：
2.4 组件间的关键通信模式
理解组件间的通信模式对于容量调优至关重要。下表总结了主要通信链路及其对集群资源的影响：
| 通信链路 | 协议/接口 | 频率 | 资源消耗特征 |
|---|---|---|---|
| Agent → API Server | gRPC Watch | 持续（长连接） | 初始全量同步时带宽高，后续增量更新低 |
| Operator → API Server | gRPC Watch + List | 持续 + 周期性 | Leader 选举和 IPAM 分配时产生突发请求 |
| CNI 插件 → Agent | Unix Socket | Pod 创建/删除时 | 瞬时高并发（批量 Pod 启动时） |
| Agent → eBPF Map | bpf() syscall | 策略更新时 | Map 操作延迟受内核锁竞争影响 |
| 跨节点 Agent 间 | 直接路由/隧道 | 持续 | 数据面流量，受网络带宽和 MTU 限制 |
调优实践：在大型集群中（>200 节点），建议为 Agent 和 Operator 配置独立的
--k8s-client-burst 和 --k8s-client-qps 参数。Agent 的默认 QPS 为 20，在 Pod 频繁创建/删除的场景下可提升至 50；Operator 的默认 QPS 为 10，在 IPAM 分配密集时建议提升至 25。
2.5 组件关系总结
将上述关系归纳为三个层次，便于记忆和排障：
- 控制面层：Operator 与 API Server 交互，管理集群级状态（IPAM、身份、端点同步）。
- 节点代理层：Agent 监听 API Server 事件，通过 CNI 插件响应 Pod 生命周期，并将策略编译为 eBPF 程序。
- 内核数据面层：eBPF 程序在 XDP、TC、cgroup 等钩子点执行包处理，实现高性能网络策略和转发。