Cilium 基础回顾：架构、eBPF 原理与 Kubernetes 集成
Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）技术的云原生网络、安全与可观测性项目。在灾备与蓝绿发布场景中，Cilium 的策略迁移能力是保障网络连通性与隔离性的关键。本节将系统回顾 Cilium 的核心架构、eBPF 技术原理及其与 Kubernetes 的集成方式，为后续策略迁移与灾备验证打下基础。
2.1 Cilium 整体架构
Cilium 采用控制面与数据面分离的架构。控制面负责策略管理与 API 交互，数据面通过 eBPF 程序在内核中执行网络转发与安全过滤。
- Cilium Agent：运行在每个 Kubernetes 节点上的守护进程，负责与 kube-apiserver 通信，生成并加载 eBPF 程序。
- Cilium Operator：处理集群级别的任务，如 IP 地址管理（IPAM）、多集群服务网格等。
- Cilium CLI / Hubble：CLI 用于手动管理策略；Hubble 提供可观测性能力，实时监控网络流量与策略命中情况。
- eBPF 程序：动态加载到内核的沙箱程序，实现网络数据包处理、负载均衡、安全策略执行等功能。
2.2 eBPF 技术原理
eBPF 是一种在内核中安全运行沙箱程序的技术，允许用户在不修改内核源码或加载内核模块的情况下，动态扩展内核功能。Cilium 利用 eBPF 实现高性能网络数据面与安全策略执行。
| 特性 | 传统方式（iptables / 内核模块） | eBPF 方式 |
|---|---|---|
| 性能 | 线性规则匹配，高延迟 | JIT 编译，内核内直接执行，低延迟 |
| 灵活性 | 需修改内核或加载模块，风险高 | 动态加载，安全沙箱，无重启 |
| 可编程性 | 固定规则语法，扩展困难 | C 语言编写，支持复杂逻辑 |
| 可观测性 | 日志与计数器有限 | 内核级追踪，丰富指标导出 |
| 安全隔离 | 模块可导致内核崩溃 | 验证器检查，禁止危险操作 |
bpf() 系统调用加载到内核，经过验证器（Verifier）检查后，由 JIT 编译器转换为原生机器码。Cilium 主要使用 XDP（eXpress Data Path）和 TC（Traffic Control）钩子点，分别处理网络驱动层和协议栈层的包。
2.3 Cilium 与 Kubernetes 的集成方式
Cilium 作为 CNI（Container Network Interface）插件与 Kubernetes 深度集成，提供 Pod 网络、Service 负载均衡、网络策略（NetworkPolicy）以及更高级的 CiliumNetworkPolicy 功能。
2.3.1 CNI 集成
Cilium 通过 CNI 规范为每个 Pod 分配 IP 地址并配置网络接口。当 kubelet 创建 Pod 时，Cilium CNI 插件负责调用 Cilium Agent 完成网络配置。
# Cilium CNI 配置示例（/etc/cni/net.d/05-cilium.conf）
{
"cniVersion": "0.3.1",
"name": "cilium",
"type": "cilium-cni",
"enable-debug": false
}2.3.2 策略集成
Cilium 完全兼容 Kubernetes 原生 NetworkPolicy，同时扩展了 CiliumNetworkPolicy（CNP）和 CiliumClusterwideNetworkPolicy（CCNP），支持 L7 协议过滤、DNS 策略、身份认证等高级功能。
| 策略类型 | 作用范围 | 支持 L7 | 典型场景 |
|---|---|---|---|
| Kubernetes NetworkPolicy | 命名空间内 | 否 | 基础 Pod 间隔离 |
| CiliumNetworkPolicy (CNP) | 命名空间内 | 是 | HTTP/gRPC 过滤、Kafka 策略 |
| CiliumClusterwideNetworkPolicy (CCNP) | 集群全局 | 是 | 多租户隔离、全局白名单 |
2.3.3 Service 与负载均衡
Cilium 使用 eBPF 实现高性能的 Service 转发，替代传统的 kube-proxy 模式。它支持 ClusterIP、NodePort、LoadBalancer 以及 ExternalTrafficPolicy 等所有 Kubernetes Service 类型。
2.3.4 身份与安全标识
Cilium 为每个 Pod 分配基于标签的 安全身份（Security Identity），而非依赖 IP 地址。这使得策略在 Pod 迁移、滚动更新时依然有效，是灾备场景下策略迁移的核心基础。
# 查看 Pod 的安全身份
$ kubectl exec -n kube-system ds/cilium -- cilium identity list
ID LABELS
1 k8s:app=frontend
2 k8s:app=backend
3 k8s:app=database