Cilium 架构核心：Agent、Operator、CNI、eBPF 数据路径与 Hubble 可观测性
Cilium 的架构围绕 eBPF 技术构建，由多个协同工作的组件组成。理解这些核心组件及其交互关系，是设计基于 Cilium 的蓝绿发布与灾备方案的基础。本章将深入剖析 Cilium Agent、Cilium Operator、Cilium CNI、eBPF 数据路径以及 Hubble 可观测性模块。
2.1 核心组件总览
Cilium 的架构采用控制面与数据面分离的设计。数据面由运行在每个节点上的 Cilium Agent 和 eBPF 程序 组成，负责处理实际的数据包转发与策略执行。控制面由 Cilium Operator 和 KV Store（可选） 组成，负责管理集群级别的状态与资源协调。
| 组件 | 职责 | 部署形态 |
|---|---|---|
| Cilium Agent | 管理 eBPF 程序、同步节点状态、处理 API 请求 | DaemonSet（每个节点一个） |
| Cilium Operator | 处理集群级任务（如 IPAM、多集群互联） | Deployment（通常 1-2 个副本） |
| Cilium CNI | 实现 Kubernetes CNI 接口，为 Pod 分配网络 | 二进制插件（由 kubelet 调用） |
| eBPF 数据路径 | 内核中执行网络过滤、转发、负载均衡 | 内核态程序（由 Agent 加载） |
| Hubble | 提供网络可观测性与安全监控 | DaemonSet + Deployment |
架构要点： Cilium Agent 是唯一与内核 eBPF 子系统交互的组件。Operator 不直接操作 eBPF，而是负责协调 Agent 无法独立完成的全局任务，例如 IP 地址池管理（IPAM）和集群网格（Cluster Mesh）的端点同步。
2.2 Cilium Agent：数据面的核心引擎
Cilium Agent 以 DaemonSet 形式运行在每个 Kubernetes 节点上。它是整个架构中最关键的组件，负责以下核心任务：
- eBPF 程序生命周期管理： 编译、加载、附加和卸载各类 eBPF 程序（如 XDP、TC、cgroup/sockops）。
- 端点管理： 监听 Kubernetes API Server，维护本地节点上所有 Pod 的 Endpoint 信息，并将其写入 eBPF Map。
- 策略执行： 将 CiliumNetworkPolicy 转换为 eBPF Map 中的查找表，实现 L3/L4/L7 网络策略。
- 服务负载均衡： 通过 eBPF 实现 kube-proxy 替代，支持 Maglev 一致性哈希和 DSR（Direct Server Return）。
- 节点状态同步： 通过 KV Store（etcd）或直接与 Kubernetes API Server 通信，交换节点路由和健康信息。
蓝绿发布关联： 在蓝绿发布场景中，Cilium Agent 负责实时更新 eBPF Map 中的服务后端列表。当流量从蓝色版本切换到绿色版本时，Agent 通过更新 Service Backend Map 实现秒级生效，无需重启任何 Pod 或 kube-proxy。
2.3 Cilium Operator：集群级协调者
Cilium Operator 是一个 Deployment，通常运行 1-2 个副本以保证高可用。它不参与数据面转发，而是处理以下集群级逻辑：
- IPAM（IP 地址管理）： 管理集群 CIDR 的分配与回收，支持 CRD-backed、Kuberenetes HostScope、AWS ENI、Azure IPAM 等多种模式。
- 多集群互联（Cluster Mesh）： 同步不同集群的 Service 和 Endpoint 信息，实现跨集群 Pod IP 可达。
- 身份管理（Identity）： 为每个安全策略标签组合分配全局唯一的数字身份 ID，并同步给所有 Agent。
- CiliumEndpoint 垃圾回收： 清理已删除 Pod 残留的 CiliumEndpoint 资源。
2.4 Cilium CNI：Pod 网络接入点
Cilium CNI 是一个轻量级二进制插件，由 kubelet 在创建 Pod 时调用。其工作流程如下：
- ADD 操作： kubelet 调用 Cilium CNI 二进制，传入 Pod 的 namespace、name 和 sandbox ID。
- IP 分配： CNI 插件通过 Unix Socket 向本地 Cilium Agent 请求 IP 地址。
- 接口创建： Agent 创建 veth pair，一端放入 Pod 网络命名空间，另一端挂载到主机。
- eBPF 附加： Agent 为新的 veth 接口附加 eBPF 程序（TC ingress/egress），并更新本地 Endpoint Map。
- 返回结果： CNI 插件将 IP、MAC、路由等信息返回给 kubelet，完成网络接入。
2.5 eBPF 数据路径：高性能内核转发
Cilium 的数据路径完全基于 eBPF，绕过了传统的 iptables 和 netfilter 框架。其核心数据流如下：
eBPF 数据路径的关键优势在于：
- 无锁并发： eBPF Map 使用 RCU（Read-Copy-Update）机制，读操作无需加锁。
- 直接路由： 通过 eBPF 实现节点间 Pod 直接路由，无需隧道封装（Overlay 模式可选）。
- 套接字级加速： 使用 cgroup/sockops 和 cgroup/connect4 程序，在套接字创建阶段直接重定向流量，绕过完整的网络栈。
2.6 Hubble：基于 eBPF 的可观测性
Hubble 是 Cilium 的可观测性层，利用 eBPF 程序在内核态捕获网络事件，以极低的开销提供细粒度的流量监控和安全审计能力。
Hubble 的核心能力包括：
- 实时流量监控： 展示集群内所有 Pod 之间的网络连接，包括 TCP 握手、DNS 查询、HTTP 请求等。
- 安全策略审计： 记录被 CiliumNetworkPolicy 允许或拒绝的数据包，提供策略命中计数和丢弃原因。
- 服务依赖图谱： 自动生成服务间的通信拓扑，帮助识别蓝绿发布期间流量是否按预期路由。
- 指标导出： 支持 Prometheus 格式的指标暴露，包括每秒数据包数、丢弃率、延迟分布等。
灾备 RPO 验证关联： 在蓝绿发布灾备演练中，Hubble 是验证 RPO（恢复点目标）的关键工具。通过 Hubble 的流量回放和连接日志，可以精确判断在切换窗口内是否有数据包丢失或重复，从而量化实际 RPO 是否满足业务要求。
2.7 组件交互流程总结
以下表格总结了在 Pod 创建和流量转发场景下，各核心组件的交互顺序：
| 步骤 | 触发者 | 执行组件 | 动作 |
|---|---|---|---|
| 1 | kubelet | Cilium CNI | 调用 ADD 请求创建 Pod 网络 |
| 2 | Cilium CNI | Cilium Agent | 分配 IP、创建 veth、附加 eBPF 程序 |
| 3 | Cilium Agent | eBPF Map | 写入 Endpoint 和 Identity 信息 |
| 4 | Pod 发送数据 | TC egress eBPF | 查找 Service Map，执行负载均衡 |
| 5 | 目标节点 | TC ingress eBPF | 查找 Policy Map，执行策略检查 |
| 6 | eBPF 程序 | Hubble eBPF | 捕获事件元数据，发送到用户态 |
| 7 | Hubble Agent | Hubble Relay | 聚合事件，提供 gRPC 查询接口 |