Cilium 架构基础:核心组件与数据路径

Cilium 的架构设计围绕 eBPF(extended Berkeley Packet Filter)技术展开,通过在内核层面动态注入程序,实现网络、可观测性与安全策略。理解其组件分工与数据路径是优化集群升级期间镜像拉取流量的前提。

2.1 核心组件:Agent、Operator、CNI

Cilium 采用去中心化的控制平面与轻量级数据平面相结合的设计。三个核心组件各司其职:

组件 部署形态 核心职责 对升级的影响
Cilium Agent DaemonSet(每个节点一个) 管理本地 eBPF 程序、端点(Pod)标识、网络策略执行、服务负载均衡 升级时需逐节点重启,期间该节点网络策略可能降级
Cilium Operator Deployment(通常 1~2 副本) 集群级协调:IPAM(IP 地址管理)、CiliumEndpoint 清理、节点间身份同步 升级期间需保持可用,否则新 Pod 可能无法分配 IP
Cilium CNI 二进制插件(由 kubelet 调用) 将 Pod 接入 Cilium 网络,配置网络接口与路由 Agent 升级时 CNI 配置需原子切换,避免 Pod 启动失败
关键设计原则: Agent 是唯一直接操作 eBPF 的程序;Operator 不参与数据路径,只负责控制面协调。这种分离使得数据路径升级可以逐个节点进行,而控制面保持全局一致。

2.2 eBPF 数据路径

Cilium 的数据路径完全构建在 eBPF 之上,绕过了传统的 iptables 和 netfilter 框架。数据包从 Pod 发出到对端接收,经过以下关键钩子点:

  1. TC(Traffic Control)Ingress/Egress:在 Pod 的 veth 对宿主端挂载 eBPF 程序,执行策略检查与封装/解封装。
  2. XDP(eXpress Data Path):在网卡驱动层直接处理入站数据包,适用于 DDoS 防护和高性能转发。
  3. Socket BPF(cgroup/sockops):在 socket 层拦截连接建立,实现服务网格 Sidecar 无感通信。

以下示意图展示了 Cilium 在节点内的 eBPF 数据路径:

Cilium eBPF 数据路径(节点内) Pod A (eth0) veth (宿主机端) TC BPF Ingress 网络策略引擎 封装 / 路由决策 eth0 (物理) 数据路径说明 1. Pod A 发出数据包 → veth 对 → 宿主机端 TC Ingress 2. TC BPF 程序执行网络策略匹配(身份、标签、端口) 3. 通过策略后,进行 VXLAN/Geneve 封装或直接路由 → 物理网卡发出
升级优化点: 在集群升级期间,镜像拉取流量通常走节点出口。Cilium 的 eBPF 策略引擎可以在 TC 层直接对镜像仓库 CIDR 设置白名单策略,避免因策略误判导致拉取超时。同时,XDP 路径可用于丢弃非镜像仓库的恶意流量,降低控制面压力。

2.3 Cilium 与 kube-proxy 的关系

Cilium 可以完全替代 kube-proxy 的服务负载均衡功能,这是通过 eBPF 在 socket 层和 TC 层实现的。两者在实现方式和性能上存在显著差异:

对比维度 kube-proxy (iptables/IPVS) Cilium (eBPF)
数据路径 Netfilter 钩子(用户态 ↔ 内核态切换) eBPF 直接在内核态执行,无上下文切换
Service 更新性能 全量 iptables 规则重写(万条 Service 时秒级延迟) 增量 eBPF map 更新(毫秒级)
外部流量策略 需额外配置 externalTrafficPolicy 原生支持 DSR(Direct Server Return)
升级兼容性 kube-proxy 升级需重启,期间 Service 可能中断 Cilium Agent 滚动升级时,eBPF map 保持,连接不中断
升级注意事项: 如果集群同时运行 kube-proxy 和 Cilium(kubeProxyReplacement=disabled),Cilium 只处理网络策略,Service 负载均衡仍由 kube-proxy 负责。此时升级 kube-proxy 会影响所有 Service 流量,包括镜像仓库的 DNS 解析和连接。建议在升级前将 Cilium 的 kubeProxyReplacement 设置为 "true",完全接管 Service 逻辑,减少组件依赖。

2.4 组件协作流程(升级场景)

在集群升级过程中,Cilium 组件按以下顺序协作,确保网络策略持续生效:

  1. Operator 保持运行:持续响应新 Pod 的 IP 分配请求,维护 CiliumEndpoint 资源。
  2. Agent 逐节点升级:新版本 Agent 启动后,从 Operator 获取全局身份映射,重建本地 eBPF 程序。
  3. CNI 配置原子切换:通过 ConfigMap 更新 CNI 配置,kubelet 在创建新 Pod 时自动使用新版本插件。
  4. eBPF map 热迁移:Agent 升级期间,已有连接的 eBPF map 条目由内核保持,连接不中断。

以下示意图展示升级期间组件间的控制流与数据流:

升级期间 Cilium 组件协作 Cilium Operator Kubernetes API Cilium Agent (旧) Cilium Agent (新) eBPF Maps (连接状态保持) 升级流程 1. Operator 持续监听 API,分配 IP,不受 Agent 升级影响 2. 旧 Agent 收到终止信号,将 eBPF map 引用计数交给内核 3. 新 Agent 启动,从 Operator 同步身份,附加到已有 eBPF map 4. 已有连接通过内核保持的 map 条目继续转发,零中断
对镜像拉取的启示: 在 Agent 滚动升级期间,如果镜像仓库流量经过 Cilium 管理的 Service,eBPF map 的热迁移机制确保已有 TCP 连接不中断。但新建连接(如新 Pod 拉取镜像)需要等待新 Agent 完成身份同步。建议在升级前预热镜像缓存,减少升级窗口内的新拉取请求。