Cilium Helm仓库镜像加速与缓存部署 - 第2节

2.1 Cilium 架构概述

Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的云原生网络、安全与可观测性解决方案。其核心设计理念是将网络策略、负载均衡与可观测性逻辑下沉到 Linux 内核中执行，从而绕过传统 iptables 或用户态代理的性能瓶颈。

2.1.1 核心组件与分层架构

Cilium 采用控制面与数据面分离的架构，各组件职责清晰，协同完成网络策略、服务转发与监控数据的采集。

组件部署位置核心职责
Cilium Agent每个节点一个 DaemonSet管理 eBPF 程序加载、策略下发、端点管理、与 Kubernetes API Server 交互
Cilium Operator集群级 Deployment处理集群范围任务：IPAM、Service 同步、网络策略聚合、多集群互联
Cilium CNI 插件节点本地二进制实现 CNI ADD/DEL 接口，为 Pod 分配 IP 并挂载网络命名空间
HubbleAgent 内嵌 + 独立 Relay提供网络流量的可观测性、服务依赖图、安全事件告警
KVStore（可选）外部 etcd 或内置 CRD存储集群状态，用于大规模集群的节点间同步
架构要点： Cilium Agent 是数据面的核心管理者，它通过 gRPC 与 Cilium Operator 通信，并通过 BPF 系统调用将网络程序注入内核。Hubble 作为可观测性层，独立于数据转发路径，避免对性能产生影响。

2.1.2 Cilium 数据面工作流

当 Pod 发起对外访问时，Cilium 的数据面处理路径如下：

  1. 网络命名空间挂载：Cilium CNI 插件为 Pod 创建 veth 对，一端放入 Pod 命名空间，另一端挂载到主机。
  2. BPF 程序附着：Cilium Agent 在主机端的 veth 接口上附着 TC（Traffic Control）或 XDP（eXpress Data Path）类型的 BPF 程序。
  3. 策略匹配：BPF 程序在内核态直接查询 BPF Map（如策略映射、端点映射），决定允许或丢弃数据包。
  4. 服务转发：若目标为 ClusterIP 服务，BPF 程序执行 DNAT 和反向 SNAT，将数据包直接转发到后端 Pod，无需经过 iptables 或 kube-proxy。
  5. 可观测性采集：Hubble 通过 Perf Event Ring Buffer 从内核接收数据包事件，生成流日志与指标。
性能优势： 整个数据路径完全在内核态完成，避免了用户态与内核态之间的上下文切换，延迟降低 40%-60%，吞吐量提升 2-3 倍（对比 iptables 模式）。
Cilium 架构组件与数据流 Cilium 架构组件与数据流 控制面 Kubernetes API Server Cilium Operator KVStore (etcd/CRD) 数据面（每个节点） Cilium Agent eBPF 程序 (TC/XDP) Hubble (可观测性) 策略下发 Pod (veth 对) BPF Map (策略/端点) Perf Event Ring Buffer

2.2 eBPF 核心原理

eBPF 是一项革命性的 Linux 内核技术，允许用户在无需修改内核源码或加载内核模块的情况下，安全高效地在内核中运行沙箱化程序。Cilium 正是基于 eBPF 实现了网络、安全与可观测性的全面内核态化。

2.2.1 eBPF 程序生命周期

一个 eBPF 程序从编写到挂载执行，经历以下关键阶段：

阶段操作说明
编写C 语言编写，使用 LLVM Clang 编译生成 eBPF 字节码（.o 文件），包含 BPF 指令集
验证内核 BPF 验证器（Verifier）检查确保程序无循环、无越界、无死锁，保证安全性
JIT 编译即时编译为本地机器码将字节码转换为 x86/ARM 指令，提升执行效率
加载通过 bpf() 系统调用加载到内核附着到指定钩子点（Hook Point），如网络接口、系统调用、跟踪点
执行事件触发时自动运行数据包到达、系统调用发生时，内核直接执行 eBPF 程序
卸载程序不再需要时从内核移除释放 BPF Map 和程序资源，避免内存泄漏
关键约束： eBPF 程序不允许包含循环（除非有界且验证器可证明终止），栈大小限制为 512 字节，且不能直接调用内核函数（只能通过 BPF Helper 函数）。这些约束保证了程序的安全性与可终止性。

2.2.2 eBPF 在 Cilium 中的关键应用

Cilium 利用 eBPF 实现了以下核心网络功能：

  • 网络数据包处理：在 TC（Traffic Control）或 XDP 钩子点附着 BPF 程序，实现数据包的过滤、转发、封装/解封装。
  • 服务负载均衡：通过 BPF Map 存储 Service 与 Endpoint 的映射关系，在内核态完成 DNAT/SNAT，替代 kube-proxy 的 iptables 模式。
  • 网络策略执行：基于身份（Identity）的安全策略，BPF 程序在数据包路径上直接匹配策略规则，拒绝非法流量。
  • 可观测性数据采集：通过 BPF Perf Event 或 BPF Ring Buffer 将数据包元数据（源/目的 IP、端口、协议、标签）推送到用户态 Hubble。
  • 带宽管理与限速：利用 BPF 的 EDT（Earliest Departure Time）算法实现 Pod 级别的带宽限制，避免网络拥塞。
性能对比： 在同等硬件条件下，Cilium（eBPF 模式）处理 64 字节小包时，PPS（每秒数据包数）可达 iptables 模式的 3-5 倍，CPU 占用降低 60% 以上。这使得 Cilium 成为高吞吐、低延迟场景的首选 CNI 方案。
eBPF 程序生命周期与内核交互 eBPF 程序生命周期与内核交互 用户态 编写 (C + LLVM) 编译 (字节码) 加载 (bpf 系统调用) 卸载 (资源释放) 内核态 BPF 验证器 (Verifier) JIT 编译 (本地机器码) 钩子点执行 (TC/XDP) bpf() 系统调用 BPF Map：存储策略、端点、服务映射、统计信息

2.3 Cilium 与 kube-proxy 的关系

kube-proxy 是 Kubernetes 中负责 Service 负载均衡的传统组件，支持 userspace、iptables 和 IPVS 三种模式。Cilium 提供了完全替代 kube-proxy 的能力，通过 eBPF 实现更高效的服务转发。

2.3.1 功能对比

维度kube-proxy (iptables 模式)Cilium (eBPF 模式)
数据路径用户态 iptables 规则遍历，O(n) 复杂度内核态 BPF Map 查找，O(1) 复杂度
延迟高（规则越多延迟越大）低（恒定延迟，与规则数量无关）
CPU 开销高（每个数据包触发 iptables 遍历）低（内核态直接处理，无上下文切换）
可扩展性差（数千条规则后性能急剧下降）优（支持数万条规则，性能稳定）
网络策略不支持（需额外 NetworkPolicy 控制器）原生支持（基于身份的策略，内核态执行）
可观测性无原生支持（需额外工具）内置 Hubble，提供流日志、指标、服务依赖图
部署复杂度简单（Kubernetes 默认安装）中等（需替换 kube-proxy，配置 eBPF 环境）

2.3.2 替换 kube-proxy 的配置方式

在 Cilium 中启用 kube-proxy 替代功能，只需在 Helm 安装时设置以下参数：

helm install cilium cilium/cilium --version 1.16.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443

启用后，Cilium 会通过 eBPF 直接处理以下 Service 类型：

  • ClusterIP：集群内部服务发现与负载均衡，BPF 程序直接 DNAT 到后端 Pod。
  • NodePort：节点端口访问，BPF 程序在主机接口上处理入站流量并转发。
  • LoadBalancer：云厂商 LB 后端，Cilium 通过 BPF 实现 DSR（Direct Server Return）模式，减少二次封装开销。
  • ExternalName：DNS 映射，Cilium 通过 BPF Map 直接返回 CNAME 记录。
生产建议： 在替换 kube-proxy 前，请确保节点内核版本 ≥ 5.10（推荐 5.15+），并开启 BPF 相关内核选项（CONFIG_BPF、CONFIG_BPF_SYSCALL、CONFIG_NET_CLS_BPF 等）。可通过 cilium status 命令验证 kube-proxy 替代是否生效。

2.3.3 混合模式与回退策略

在某些场景下（如内核版本过低、不支持 eBPF 的虚拟化环境），Cilium 支持与 kube-proxy 共存：

  • 完全替代：kubeProxyReplacement=true，Cilium 接管所有 Service 逻辑，kube-proxy 可被移除。
  • 部分替代：kubeProxyReplacement=probe，Cilium 自动检测内核能力，仅替代支持的 Service 类型，其余回退到 kube-proxy。
  • 禁用替代：kubeProxyReplacement=false，Cilium 仅负责网络策略与 CNI，Service 转发仍由 kube-proxy 处理。
注意： 在混合模式下，Cilium 和 kube-proxy 可能对同一 Service 规则产生冲突。建议在测试环境中充分验证后再投入生产。推荐始终使用完全替代模式以获得最佳性能与一致性。

通过本章的学习，你已经掌握了 Cilium 的架构组成、eBPF 的核心原理以及 Cilium 与 kube-proxy 的关系。这些知识是后续配置 Helm Chart 仓库镜像加速的基础，因为镜像加速涉及网络策略、服务路由与数据面性能优化，而这些正是 Cilium 与 eBPF 的核心优势所在。

← 上一章 📖 返回目录 下一章 →