2. Cilium架构解析：Cilium Agent、Operator、CNI插件、Hubble组件及数据路径详解
Cilium 的架构设计围绕 eBPF（extended Berkeley Packet Filter）技术展开，将数据平面与控制平面解耦，同时通过多个组件协同工作，实现高效的网络、安全与可观测性能力。理解这些组件的职责及其交互关系，是掌握 Cilium 网络策略与接口配置的基础。
2.1 核心组件总览
Cilium 部署在 Kubernetes 集群中时，主要包含以下四个核心组件：
| 组件 | 部署形态 | 核心职责 |
|---|---|---|
| Cilium Agent | DaemonSet（每个节点一个） | 管理 eBPF 程序、实现网络策略、服务负载均衡、与 CNI 交互 |
| Cilium Operator | Deployment（通常 1~2 副本） | 处理集群级协调任务，如 IPAM、身份管理、端点同步 |
| CNI Plugin | 二进制插件（由 kubelet 调用） | 将 Pod 接入 Cilium 网络，配置网络接口与路由 |
| Hubble | DaemonSet + Deployment | 提供网络流量的可观测性、服务依赖图与安全事件监控 |
架构要点： Cilium Agent 是数据平面的核心，运行在每个节点上，直接操作 eBPF 程序；Operator 是控制平面的协调器，负责全局状态管理；CNI 插件是 kubelet 与 Cilium 之间的桥梁；Hubble 则构建在 Agent 之上，提供流量可视化能力。
2.2 Cilium Agent：数据平面的执行者
Cilium Agent 是架构中最关键的组件，它通过 gRPC 与 kube-apiserver 通信，监听 Pod、Service、NetworkPolicy 等资源的变化，并将这些事件转化为 eBPF 程序更新。Agent 的主要功能包括：
- eBPF 程序管理： 编译、加载、附加和卸载 eBPF 程序到网络接口（如 eth0、lxc 等）。
- 网络策略执行： 将 Kubernetes NetworkPolicy 和 CiliumNetworkPolicy 翻译为 eBPF map 中的规则，实现 L3/L4/L7 层过滤。
- 服务负载均衡： 使用 eBPF 实现 kube-proxy 替代，支持 DSR（Direct Server Return）和 Maglev 一致性哈希。
- 端点管理： 维护本地节点的端点（Pod）列表，并为其分配安全身份（Security Identity）。
- 节点间通信： 通过隧道模式（VXLAN/Geneve）或直接路由模式，管理跨节点 Pod 通信的数据路径。
关键机制： Agent 使用 eBPF map 作为共享数据结构，允许内核态 eBPF 程序与用户态 Agent 高效交换信息。例如，策略规则存储在
cilium_policy map 中，连接跟踪信息存储在 cilium_ct4 map 中。
2.3 Cilium Operator：集群级协调器
Operator 负责处理那些不需要在每个节点上执行的任务，减轻 Agent 的负担。其核心职责包括：
- IPAM（IP 地址管理）： 从集群的 IP 池中为节点分配 PodCIDR，支持 CRD-backed、Kuberenetes HostScope、AWS ENI、Azure 等多种模式。
- 身份管理： 为每个端点分配全局唯一的 Security Identity，并维护 Identity 到标签的映射关系。
- 端点同步： 监控集群中所有端点的状态变化，确保 Agent 之间的身份信息一致。
- 资源清理： 清理已删除节点或 Pod 残留的 CiliumEndpoint 和 CiliumIdentity 资源。
高可用注意： Operator 通常以 Deployment 方式运行，建议设置
replicas: 2 并配置 Pod Anti-Affinity，避免单点故障影响 IPAM 和身份分配。
2.4 CNI 插件：Pod 接入网络的入口
当 kubelet 在节点上创建 Pod 时，会调用 CNI 插件（通常是 cilium-cni 二进制文件）。CNI 插件的执行流程如下：
- ADD 操作： kubelet 调用 CNI 插件，传入 Pod 的命名空间、名称、网络命名空间等信息。
- 接口创建： CNI 插件创建 veth pair，一端放入 Pod 的网络命名空间（通常命名为 eth0），另一端连接到主机的网络命名空间（通常命名为 lxcXXXX）。
- IP 分配： CNI 插件通过 Unix Socket 向本节点的 Cilium Agent 请求 IP 地址分配。
- 路由与策略配置： Agent 返回 IP 地址后，CNI 插件在 Pod 的网络命名空间中配置默认路由，并在主机侧配置路由规则。
- eBPF 附加： Agent 将 eBPF 程序附加到新创建的 veth 接口上，开始执行网络策略和负载均衡。
性能优势： Cilium 的 CNI 插件不依赖 iptables 或 bridge 转发，所有数据路径决策都在 eBPF 层面完成，延迟更低，吞吐量更高。
2.5 Hubble：可观测性层
Hubble 是 Cilium 的可观测性组件，它利用 eBPF 程序在内核态捕获网络事件，并通过用户态 Relay 组件提供 API 和 UI。Hubble 的架构包含两个部分：
- Hubble Agent（DaemonSet）： 运行在每个节点上，与 Cilium Agent 共享 eBPF map，收集流量日志、DNS 请求、TCP 状态变化等事件。
- Hubble Relay（Deployment）： 聚合所有 Hubble Agent 的数据，提供集群级别的 gRPC API，支持 Hubble UI 和
hubble observeCLI 查询。
Hubble 提供的关键能力包括：
| 能力 | 说明 |
|---|---|
| 流量日志 | 记录所有被策略允许或拒绝的网络流，包含源/目的 IP、端口、协议、Verdict |
| 服务依赖图 | 自动生成集群内服务间的通信拓扑，帮助理解微服务调用关系 |
| DNS 监控 | 捕获 Pod 发出的 DNS 查询与响应，支持基于 DNS 名称的网络策略 |
| HTTP 层可见性 | 在启用 L7 策略时，记录 HTTP 请求方法、路径、状态码等详细信息 |
2.6 数据路径详解
Cilium 的数据路径描述了数据包从 Pod 发出到目标 Pod 或外部服务的完整流程。根据网络模式的不同，数据路径略有差异。以下以直接路由模式为例，展示同一节点内和跨节点通信的数据路径。
数据路径核心原则： 所有数据包在进入或离开网络接口时，都会经过 eBPF 程序的处理。eBPF 程序在 XDP（eXpress Data Path）或 TC（Traffic Control）钩子点挂载，实现策略检查、负载均衡、封装/解封装等操作。
2.6.1 同一节点内 Pod 通信
- 源 Pod 发送： 数据包从 Pod 的 eth0 发出，通过 veth pair 到达主机侧的 lxc 接口。
- TC ingress 处理： 主机侧 lxc 接口的 TC ingress 钩子触发 eBPF 程序，执行源端点查找、策略检查（允许/拒绝）、连接跟踪更新。
- 路由决策： 内核路由表判断目标 IP 属于本地节点，将数据包转发到目标 Pod 对应的 lxc 接口。
- TC egress 处理： 目标 lxc 接口的 TC egress 钩子触发 eBPF 程序，执行目标端点查找、策略检查。
- 目标 Pod 接收： 数据包通过 veth pair 到达目标 Pod 的 eth0。
2.6.2 跨节点 Pod 通信
- 源 Pod 发送： 数据包从 Pod 的 eth0 发出，通过 veth pair 到达主机侧 lxc 接口。
- TC ingress 处理： 执行源端点查找、策略检查、连接跟踪更新。
- 路由决策： 内核路由表判断目标 IP 属于远程节点，将数据包转发到主机的物理网卡（eth0）。
- 物理网卡 egress： 物理网卡的 TC egress 钩子触发 eBPF 程序，执行封装（VXLAN/Geneve）或直接路由的源地址转换（SNAT for masquerade）。
- 网络传输： 数据包通过底层网络到达目标节点的物理网卡。
- 物理网卡 ingress： 目标节点物理网卡的 TC ingress 钩子触发 eBPF 程序，执行解封装（如果使用隧道模式）或路由查找。
- 转发到目标 Pod： 内核路由表将数据包转发到目标 Pod 的 lxc 接口，经过 TC egress 策略检查后到达 Pod。
2.7 组件交互流程总结
下图展示了 Cilium Agent、Operator、CNI 插件和 Hubble 之间的交互关系，以及它们与 Kubernetes API Server 的通信路径。
架构设计启示： Cilium 将数据平面（Agent + eBPF）与控制平面（Operator）分离，使得策略更新和端点管理不会影响数据转发性能。同时，Hubble 作为可观测性层，不参与数据路径决策，保证了监控对性能的零影响。