Cilium 架构深度解析：核心组件与数据路径
Cilium 的架构设计围绕 eBPF 技术展开，将数据平面与控制平面解耦，同时提供强大的可观测性能力。理解其核心组件——Cilium Agent、Cilium Operator、CNI 插件、eBPF 数据路径以及 Hubble——是进行容量基线校准和准入策略评审的基础。
2.1 核心组件总览
下表总结了 Cilium 各组件的职责、部署形态及其在压测与运维中的关键作用：
| 组件 | 部署形态 | 核心职责 | 压测/运维关注点 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理 eBPF 程序、策略执行、IPAM、服务转发 | CPU/内存开销、eBPF map 大小、API 响应延迟 |
| Cilium Operator | Deployment（通常 1-2 副本） | 集群级协调：CIDR 分配、身份管理、故障恢复 | Leader 选举稳定性、API Server 请求频率 |
| CNI 插件 | 二进制文件（由 kubelet 调用） | Pod 网络接口创建与配置 | Pod 启动延迟、配置失败率 |
| eBPF 数据路径 | 内核内（由 Agent 加载） | 网络包处理、策略过滤、负载均衡 | PPS 吞吐、延迟分布、连接跟踪表容量 |
| Hubble | DaemonSet + Deployment | 流日志采集、网络可观测性、指标暴露 | 流日志速率、存储开销、gRPC 连接数 |
2.2 Cilium Agent：节点级控制平面
Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程，是 Cilium 最核心的控制组件。它通过 gRPC 与 kube-apiserver 通信，监听 Pod、Service、Endpoint、NetworkPolicy 等资源变化，并将这些事件转化为 eBPF 程序与 map 的更新。
压测关键指标： Agent 的
cilium-agent 进程内存占用与节点上管理的 Endpoint 数量呈正相关。在 5000 Pod/节点的规模下，Agent 内存消耗通常在 500MB-1.5GB 之间，具体取决于策略复杂度与连接跟踪规模。
2.3 Cilium Operator：集群级协调器
Operator 负责执行需要集群全局视角的操作，例如：
- CIDR 分配： 为每个节点分配 PodCIDR 范围。
- 身份管理： 维护安全身份（Security Identity）与标签的映射关系。
- 故障恢复： 在节点故障时清理残留的端点状态。
Operator 通常以 Deployment 形式运行，通过 Leader 选举保证高可用。在压测场景下，需要关注 Operator 对 API Server 的请求速率，避免成为控制平面的瓶颈。
2.4 CNI 插件：Pod 网络入口
当 kubelet 创建 Pod 时，会调用 Cilium CNI 二进制文件。CNI 插件负责：
- 为 Pod 创建 veth pair 设备。
- 将一端放入 Pod 网络命名空间，另一端接入主机。
- 调用 Cilium Agent 的 API 为 Pod 分配 IP 并加载初始 eBPF 程序。
性能基准： 在裸金属节点上，Cilium CNI 的 Pod 启动延迟通常在 5-15ms 之间。如果超过 50ms，需要排查 Agent 响应延迟或 API Server 负载。
2.5 eBPF 数据路径：内核内网络处理
Cilium 将网络处理逻辑下沉到 Linux 内核的 eBPF 钩子点，避免了传统 iptables 或 IPVS 的上下文切换与规则遍历开销。核心数据路径包括：
- XDP（eXpress Data Path）： 在网卡驱动层进行最早期的包处理，适用于 DDoS 防护和高性能转发。
- TC（Traffic Control）ingress/egress： 在协议栈入口/出口处执行策略过滤、封装/解封装、负载均衡。
- Socket-level BPF： 通过
BPF_PROG_TYPE_CGROUP_SKB实现 Pod 级别的策略隔离。
容量规划警告： eBPF map 的大小是有限的。连接跟踪表（CT map）默认大小可能只支持 65536 条并发连接。在压测前必须根据预期并发连接数调整
bpf-ct-global-tcp-max 等参数，否则会导致丢包。
2.6 Hubble：可观测性组件
Hubble 是 Cilium 原生的可观测性层，基于 eBPF 采集网络流数据，提供实时流量监控、策略审计和故障排查能力。其组件包括：
- Hubble Relay： 以 DaemonSet 形式运行在每个节点，从 Cilium Agent 获取流事件，并通过 gRPC 流式传输。
- Hubble Server： 集群级聚合层，提供统一的查询接口和指标暴露（Prometheus 格式）。
- Hubble UI： 基于 Web 的可视化界面，展示服务依赖图、流量拓扑和策略执行状态。
压测数据驱动： 在压测期间，Hubble 的流日志速率可能达到每秒数十万条。需要提前配置
hubble-flow-buffer-size 和 monitor-aggregation 参数，避免 Agent 因日志积压导致 OOM。
2.7 组件交互流程
一个典型的 Pod 网络创建与策略应用流程如下：
- kubelet 调用 Cilium CNI 插件 为 Pod 创建网络命名空间。
- CNI 插件通过 Unix Socket 向本地 Cilium Agent 请求 IP 分配与端点注册。
- Agent 从 Operator 管理的 IP 池中分配 IP，并加载初始 eBPF 程序到 Pod 的 cgroup 和 veth 设备。
- 当网络策略发生变化时，Agent 更新 eBPF map（如策略 map、连接跟踪 map），实现实时策略生效。
- Hubble Relay 从 Agent 的 eBPF 事件环形缓冲区读取流日志，上报给 Hubble Server。
准入策略评审要点： 在压测前，应通过 Hubble 的
hubble observe 命令验证策略是否按预期生效。例如：# 观察特定 Pod 的流量是否被策略丢弃
hubble observe --pod default/my-app --verdict DROPPED