Cilium 架构核心组件解析
Cilium 基于 eBPF（extended Berkeley Packet Filter）技术构建，其架构由多个协同工作的组件组成。理解这些组件及其交互流程，是掌握 Cilium 网络策略与性能调优的基础。本章将深入解析 Cilium Agent、Cilium Operator、Cilium CLI 以及 Hubble 观测平台的核心职责与协作机制。
组件总览与职责划分
Cilium 的架构遵循“控制面-数据面-观测面”分离的设计原则。下表总结了各核心组件的定位与关键职责：
| 组件 | 部署形态 | 核心职责 | 关键能力 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 数据面策略执行、eBPF 程序管理 | 端点管理、网络策略下发、Service 负载均衡 |
| Cilium Operator | Deployment（通常 1-2 副本） | 集群级控制面协调 | 身份管理、IPAM、KVStore 同步、CRD 状态维护 |
| Cilium CLI | 客户端二进制 | 运维调试与策略验证 | 策略预览、连通性测试、eBPF 状态查询 |
| Hubble | DaemonSet + Deployment | 可观测性与安全监控 | 流量捕获、L3/L4/L7 可见性、策略审计 |
架构要点：Cilium Agent 是唯一直接操作 eBPF 的组件，Operator 负责集群级状态协调，Hubble 作为观测层独立运行，三者通过 gRPC 和 CRD 进行通信。
Cilium Agent：数据面的执行引擎
Cilium Agent 以 DaemonSet 方式运行在每个 Kubernetes 节点上，是 Cilium 数据面的核心。它负责将用户定义的网络策略和安全规则编译为 eBPF 程序，并挂载到网络设备上。
- 端点管理：Agent 通过监听 Kubernetes API Server 获取 Pod 变化，为每个 Pod 创建对应的 CiliumEndpoint 对象，并分配安全身份标识（Security Identity）。
- 策略编译：将 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy 转换为 eBPF map 中的键值对，实现 O(1) 复杂度的策略匹配。
- Service 处理：利用 eBPF 实现 kube-proxy 替代，支持 DSR（Direct Server Return）和 Maglev 一致性哈希，提升负载均衡性能。
- 健康检查：定期通过 eBPF 程序检测节点和端点的连通性，更新 ClusterMesh 状态。
Cilium Operator：集群控制面的协调者
Operator 负责处理全局性的控制面任务，减轻 Agent 的负担，避免每个 Agent 都去竞争 API Server 资源。
- 身份管理：为每个安全身份（Security Identity）分配全局唯一的数字 ID，并维护身份与标签的映射关系。
- IPAM（IP 地址管理）：根据集群配置（如 CRD-backed、ENI、Azure IPAM）分配 Pod CIDR，回收已释放的 IP。
- KVStore 同步：当使用 etcd 作为状态存储时，Operator 负责将集群状态写入 KVStore，供跨节点 Agent 同步。
- CRD 状态更新：监控 CiliumEndpoint、CiliumNode 等 CRD 的状态变化，触发相应的协调逻辑。
注意：在 Cilium 1.14+ 版本中，Operator 的职责进一步精简，部分功能（如端点垃圾回收）已迁移至 Agent 的 Leader Election 机制中。
Cilium CLI：运维与调试利器
Cilium CLI 是管理员最常用的命令行工具，它直接与 Cilium Agent 的本地 API 通信，提供实时状态查询和策略验证能力。
| 命令 | 功能说明 | 典型场景 |
|---|---|---|
cilium status |
查看 Agent 健康状态、KVStore 连接、eBPF 资源使用 | 快速诊断节点级问题 |
cilium endpoint list |
列出本节点所有端点及其安全身份、策略状态 | 验证 Pod 是否被正确纳管 |
cilium bpf policy get |
查看指定端口的 eBPF 策略 map 内容 | 调试策略是否按预期生效 |
cilium connectivity test |
执行端到端连通性测试，验证网络策略 | 集群部署后的冒烟测试 |
Hubble：可观测性与安全审计
Hubble 构建在 Cilium 的数据面之上，利用 eBPF 的观测能力提供细粒度的流量可视化和策略审计功能。
- Hubble Relay：作为集群内的 gRPC 代理，聚合所有 Hubble Agent 的数据，提供统一的查询接口。
- Hubble UI：基于 Relay 数据的 Web 界面，展示服务依赖图、流量拓扑和策略拒绝事件。
- Hubble CLI：提供
hubble observe命令，支持按 Pod、标签、IP、协议等维度过滤实时流量。 - 指标暴露：将 eBPF 捕获的流量指标（如每秒包数、延迟分布）以 Prometheus 格式暴露，便于集成到监控系统。
组件交互流程与数据流
下图展示了 Cilium 各组件之间的核心交互流程，从策略创建到 eBPF 程序生效的完整链路：
关键交互流程详解
以下步骤描述了从用户创建网络策略到 eBPF 程序生效的完整链路：
- 策略提交：用户通过
kubectl apply -f policy.yaml将 CiliumNetworkPolicy 提交到 Kubernetes API Server。 - CRD 存储：API Server 将策略存储为 CRD 对象，并触发 Watch 通知。
- Operator 协调：Cilium Operator 监听到策略变化，为涉及的端点分配或更新安全身份（Security Identity），并将身份信息写入 CiliumEndpoint 状态。
- Agent 拉取：每个节点上的 Cilium Agent 通过 Watch 机制或 Operator 的推送，获取本节点相关的策略和身份信息。
- eBPF 编译：Agent 将策略规则（L3/L4/L7）编译为 eBPF 指令，并更新 eBPF map（如
cilium_policy、cilium_ct）。 - 数据面生效：eBPF 程序挂载到网络设备（如
lxc、eth0），对进出流量执行策略匹配和转发。 - Hubble 捕获：Hubble Agent 通过读取 eBPF map 和 perf event 环形缓冲区，获取流量元数据（源/目的 IP、端口、Verdict）。
- 观测聚合：Hubble Relay 聚合集群内所有 Hubble Agent 的数据，通过 gRPC 暴露给 Hubble UI 或 CLI。
性能关键点：整个流程中，只有步骤 5（eBPF 编译）涉及 CPU 密集型操作，且仅在策略变更时触发。数据面的策略匹配完全在 eBPF 中完成，不经过用户态，因此延迟通常在微秒级。
组件通信方式总结
下表总结了各组件之间的通信协议与数据流向：
| 源组件 | 目标组件 | 通信协议 | 数据内容 |
|---|---|---|---|
| Cilium CLI | Cilium Agent | gRPC (Unix Socket) | 状态查询、策略调试、eBPF map 读取 |
| Cilium Agent | Kubernetes API Server | HTTPS (REST) | Watch Pod/Policy/Endpoint 变化 |
| Cilium Operator | Kubernetes API Server | HTTPS (REST) | CRD 状态更新、身份分配 |
| Cilium Agent | Cilium Operator | gRPC (可选) | 身份分配请求、IPAM 租约 |
| Hubble Agent | Cilium Agent | 共享内存 / eBPF map | 流量事件、策略 Verdict |
| Hubble Relay | Hubble Agent | gRPC (TCP) | 聚合后的流量流（Flow）数据 |
架构设计要点总结
- 去中心化数据面：每个节点上的 Agent 独立管理本地的 eBPF 程序，不依赖中心化控制器进行数据包处理，避免单点瓶颈。
- 控制面分层：Operator 处理全局状态（身份、IP），Agent 处理本地状态（端点、策略），降低 API Server 压力。
- 观测面解耦：Hubble 作为独立组件，即使 Hubble 集群故障，Cilium 的数据面转发和策略执行不受影响。
- eBPF 作为统一底座：无论是网络策略、负载均衡还是可观测性，都基于 eBPF 的 map 和程序实现，避免了多套内核模块的维护成本。