2. Cilium 架构概览：数据面、控制面与 Kubernetes 集成

在容量规划视角下，理解 Cilium 的架构分层是优化网络接口配置的前提。Cilium 的核心设计遵循“控制面-数据面”分离原则，并通过 eBPF 技术将网络策略、负载均衡与可观测性下沉到内核层执行。本章从数据面、控制面及与 Kubernetes 的集成关系三个维度展开，为后续接口配置优化建立架构基础。

2.1 数据面：eBPF 驱动的内核转发引擎

Cilium 的数据面完全基于 eBPF（extended Berkeley Packet Filter）实现，不依赖传统的 iptables 或 IPVS。eBPF 程序被挂载到网络协议栈的关键钩子点（如 XDP、TC、套接字），在数据包到达用户态之前完成转发、过滤与封装决策。

数据面核心组件

2.2 控制面：Agent 与 Operator 的分工

Cilium 的控制面由两个主要组件构成：Cilium Agent（DaemonSet，每节点运行）和 Cilium Operator（Deployment，集群级运行）。它们共同负责策略下发、端点管理、身份分配与集群协调。

2.2.1 Cilium Agent — 节点级控制引擎

• 端点管理： 监听 Kubernetes API，维护本地 Pod 与主机的端点映射，写入 eBPF map。
• 策略编译： 将 CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy 编译为 eBPF 指令集。
• 接口配置： 创建/删除 cilium_net、cilium_host、lxc_health 等虚拟接口，设置 MTU、MAC、路由。
• 健康探测： 通过 cilium-health 子进程定期检测节点与 Pod 连通性。

2.2.2 Cilium Operator — 集群级协调器

2.3 与 Kubernetes 的集成关系

Cilium 通过 CNI 接口与 kubelet 集成，并利用 CRD（Custom Resource Definition）扩展 Kubernetes 网络策略模型。集成链路直接影响接口配置的生效路径与性能开销。

集成流程（Pod 创建场景）

1. kubelet 调用 Cilium CNI 二进制（cilium-cni）。
2. CNI 插件 通过 gRPC 请求本地 Agent 分配 IP 与端点 ID。
3. Agent 创建 veth pair，一端放入 Pod 网络命名空间，另一端挂载到 cilium_net 桥接。
4. Agent 编译该 Pod 的安全策略，写入 eBPF map，设置 TC 钩子。
5. Operator 更新全局身份映射，通知其他节点更新策略。

2.4 架构视角的容量规划要点

基于上述架构分析，在 Cilium 网络接口配置优化前，需建立以下容量基线：

• eBPF map 内存： 每个端点约占用 2-4 KB map 内存，1000 端点节点需预留 4-8 MB；策略规则数每增加 1000 条，额外消耗 1-2 MB。
• Agent CPU 预算： 策略编译为 CPU 密集型操作，建议为 Agent 预留 0.5-1 核（高密度节点 2 核）。
• Operator 协调延迟： 节点数 > 300 时，Operator 与 etcd 之间的 watch 延迟可能超过 5s，需调整 --operator-pprof 与 etcd 心跳间隔。
• 接口 MTU 链： 从 Pod veth → cilium_net → 主机 eth0，每一跳 MTU 必须一致或递减，否则触发内核分片。