2. Cilium 架构基础：核心组件与数据面关系
Cilium 的架构围绕 eBPF 技术构建，由四个核心组件协同工作：Cilium Agent、eBPF 数据面、Cilium Operator 和 Hubble。理解它们之间的职责划分与通信关系，是进行网络参数调优和准入控制的前提。
2.1 组件职责与功能矩阵
下表从部署位置、核心功能、与 eBPF 的关系三个维度，对比四个组件的差异：
| 组件 | 部署位置 | 核心功能 | 与 eBPF 的关系 |
|---|---|---|---|
| Cilium Agent | 每个 Kubernetes 节点（DaemonSet） | 管理 eBPF 程序生命周期、同步 Kubernetes 资源、处理网络策略 | 直接编译、加载、更新 eBPF 程序到内核 |
| eBPF 数据面 | Linux 内核（节点内） | 执行包转发、负载均衡、网络策略过滤、可观测性钩子 | 自身即 eBPF 程序集合 |
| Cilium Operator | 集群级（Deployment） | 处理集群范围任务：IPAM、Service 同步、节点间协调 | 不直接操作 eBPF，通过 Agent 间接触发 |
| Hubble | 每个节点 + 集群级（DaemonSet + Deployment） | 流日志采集、服务依赖图、网络可观测性 | 读取 eBPF map 中的事件数据，不修改数据面 |
2.2 组件关系图：控制面与数据面交互
下图展示了 Cilium 各组件的部署拓扑与通信路径。控制面组件（Agent、Operator、Hubble Server）通过 gRPC 或 Kubernetes API 交互，而数据面完全运行在内核 eBPF 中。
关键理解：Agent 是控制面的“执行者”，Operator 是“协调者”，eBPF 数据面是“执行引擎”，Hubble 是“观察者”。调优时，Agent 参数影响 eBPF 程序加载行为，Operator 参数影响集群级资源分配，而 Hubble 参数影响可观测性开销。
2.3 组件间通信协议与数据流
四个组件之间的通信并非全互联，而是遵循清晰的层级关系：
- Cilium Agent ↔ eBPF 数据面：通过
bpf()系统调用和 BPF 文件系统（通常挂载在/sys/fs/bpf）进行双向交互。Agent 将编译后的 eBPF 字节码加载到内核，并通过更新 eBPF Map 来下发策略和端点信息。 - Cilium Agent ↔ Cilium Operator：通过 Kubernetes API 和 gRPC 通信。Operator 监听集群事件（如 Node 加入/离开），然后通过 CRD 状态或直接调用 Agent API 触发 Agent 更新本地数据面。
- Hubble Relay ↔ eBPF 数据面：Hubble Relay 通过
perf_event环形缓冲区或 eBPF Map 从内核读取包事件和流统计信息，不上行修改数据面。 - Hubble Relay ↔ Hubble Server：节点级 Hubble Relay 将流日志通过 gRPC 流式传输到集群级 Hubble Server，后者提供聚合查询 API。
2.4 蓝绿发布场景下的组件角色
在蓝绿发布过程中，各组件的职责会动态变化：
| 阶段 | Cilium Agent | eBPF 数据面 | Cilium Operator | Hubble |
|---|---|---|---|---|
| 准备阶段 | 为新版本 Pod 预分配 IP，加载初始网络策略 | 建立新版本 Pod 的转发路径和策略规则 | 分配 IP 池，同步新 Service 端点 | 开始采集新版本流日志基线 |
| 切换阶段 | 更新 eBPF Map 中的端点标签，切换 Service 后端权重 | 执行流量迁移（权重调整或直接重定向） | 协调跨节点端点一致性 | 实时对比蓝绿版本流量指标 |
| 回滚阶段 | 恢复旧版本端点权重，清理新版本策略残留 | 撤销新版本的转发规则，恢复旧版本路径 | 回收未使用的 IP 资源 | 验证回滚后流量是否恢复正常 |
调优注意：蓝绿切换时，Agent 更新 eBPF Map 的延迟直接影响切换速度。如果
bpf-map-dynamic-size-ratio 或 map-count 参数设置过小，可能导致 Map 空间不足，阻塞策略更新。建议在蓝绿发布前通过 Hubble 监控 Map 使用率。
2.5 组件依赖关系总结
从部署和运维视角，组件间的依赖关系可以归纳为以下层级：
- 基础设施层：Linux 内核支持 eBPF（要求内核版本 ≥ 4.19，推荐 5.10+）。
- 节点代理层：Cilium Agent 是唯一直接与内核 eBPF 交互的组件，必须首先启动。
- 集群协调层：Cilium Operator 依赖 Agent 上报的节点状态，但 Agent 不依赖 Operator 即可运行基础转发功能。
- 可观测性层：Hubble Relay 依赖 Agent 初始化的 eBPF 程序（需要开启监控钩子），Hubble Server 依赖 Relay 上报数据。
这种分层设计使得 Cilium 在蓝绿发布中具备高可用性：即使 Operator 或 Hubble 短暂不可用，Agent 和 eBPF 数据面仍能维持已有网络策略和转发规则，不会影响业务流量。