2. Cilium 架构解析：核心组件与交互流程

Cilium 基于 eBPF（extended Berkeley Packet Filter）实现，其架构由多个协同工作的组件构成。理解这些组件的功能与交互，是排查容器网络缓存命中故障、进行性能调优的基础。本章将深入解析 Cilium Agent、Cilium Operator、Cilium CNI 插件以及 Hubble 观测组件。

2.1 核心组件总览

Cilium 的架构采用控制面与数据面分离的设计。数据面运行在 Linux 内核中，通过 eBPF 程序实现网络策略、负载均衡与可观测性；控制面则由运行在用户空间的守护进程和控制器组成。

2.2 Cilium Agent：节点级核心引擎

Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程，通过 DaemonSet 部署。它是整个 Cilium 数据面管理的核心，直接与 Linux 内核交互。

2.2.1 核心功能

• eBPF 程序生命周期管理：Agent 负责将编译好的 eBPF 程序加载到内核的特定挂载点（如 XDP、TC、cgroup、套接字），并管理其生命周期。
• 端点（Endpoint）管理：每个 Pod 在 Cilium 中被抽象为一个“端点”。Agent 维护端点的标识、标签、网络策略和状态。
• 网络策略同步：监听 Kubernetes API Server 中的 NetworkPolicy 资源，将其转换为 eBPF map 中的高效查找表，实现数据面的策略执行。
• 服务负载均衡：实现基于 eBPF 的 kube-proxy 替代方案，将 Service 流量直接转发到后端 Pod，避免 iptables 的性能瓶颈。
• 节点事件处理：监听节点、Pod、Service 的创建、更新和删除事件，动态调整 eBPF 程序和数据路径。

2.2.2 关键数据流

Kubernetes API Server
        │
        ▼
Cilium Agent (用户空间)
        │
        ├── 监听事件 (Watch)
        ├── 解析策略 (Policy Engine)
        ├── 生成 eBPF Map 条目
        └── 加载/更新 eBPF 程序
                │
                ▼
Linux 内核 (eBPF 运行时)
        │
        ├── XDP/TC 程序 (网络数据面)
        ├── cgroup 程序 (套接字层)
        └── eBPF Maps (策略/状态存储)

2.3 Cilium Operator：集群级协调器

Cilium Operator 是一个集群级的单实例控制器（通常以 Deployment 形式运行），负责处理全局性的协调任务，不直接参与数据面操作。

2.4 Cilium CNI 插件：Pod 网络入口

Cilium CNI 插件是一个轻量级的二进制文件，安装在每个节点的 CNI 配置目录中（通常为 /opt/cni/bin/）。当 kubelet 需要创建 Pod 网络时，会调用该插件。

2.4.1 工作流程

1. CNI ADD 调用：kubelet 通过 gRPC 或二进制调用 Cilium CNI 插件，传入 Pod 的命名空间、名称、网络命名空间等信息。
2. 接口创建：CNI 插件在宿主机上创建 veth pair，一端放入 Pod 的网络命名空间，另一端留在宿主机。
3. IP 分配：CNI 插件向 Cilium Agent 请求 IP 地址分配（通过本地 Unix Socket 通信）。
4. 端点注册：Agent 将新 Pod 注册为端点，分配 Security Identity，并加载对应的 eBPF 程序。
5. 路由配置：CNI 插件在 Pod 网络命名空间内配置默认路由和 IP 地址。
6. 返回结果：CNI 插件将接口信息、IP 地址、DNS 配置等返回给 kubelet。

2.5 Hubble：可观测性层

Hubble 是 Cilium 的可观测性组件，提供网络流量的实时监控、分析和可视化能力。它由三个主要部分组成：

• Hubble Agent（节点级）：运行在每个节点上，作为 Cilium Agent 的 sidecar 或内嵌模块，从 eBPF 数据路径采集流量事件。
• Hubble Relay（集群级）：聚合所有节点 Hubble Agent 的数据，提供统一的查询接口。
• Hubble UI / CLI：提供图形化界面和命令行工具，用于查看服务拓扑、流量日志和指标。

2.5.1 数据采集与缓存

Hubble 通过 eBPF 的 perf_event 环形缓冲区或 BPF map 从内核空间采集数据。这些数据包括：

// Hubble 采集的核心事件类型
- 网络流 (Flow)：五元组、方向、Verdict (ALLOW/DROP)
- DNS 请求/响应：域名、IP、返回码
- HTTP 请求/响应：方法、路径、状态码、延迟
- TCP 状态：SYN、FIN、RST、窗口大小
- 策略命中：匹配的策略 ID、动作

2.6 组件交互流程总结

以下是一个 Pod 创建并开始通信的完整交互流程，展示了各组件如何协同工作：

1. Pod 创建：kubelet 调用 Cilium CNI 插件。
2. CNI 请求：CNI 插件通过 Unix Socket 向本地 Cilium Agent 请求 IP 和端点注册。
3. Agent 处理：Agent 分配 IP，创建端点，加载初始 eBPF 程序。
4. 策略同步：Agent 从 API Server 获取 Pod 相关的 NetworkPolicy，更新 eBPF map。
5. Operator 协调：Operator 确保全局身份标识一致，处理 IPAM 池状态。
6. 数据通信：Pod 发送数据包，eBPF 程序在内核中执行策略检查、负载均衡和封装/解封装。
7. Hubble 采集：eBPF 程序将流量事件推送到 Hubble Agent，Hubble Relay 聚合后供 UI 查询。