Cilium 基础回顾：eBPF 技术原理、Cilium 架构组件与 Kubernetes 集成
在深入服务目录平台的流水线集成与准入控制之前，必须牢固掌握 Cilium 的核心技术基础。本章将系统回顾 eBPF 技术原理、Cilium 的架构组件（Agent、Operator、CNI）以及它与 Kubernetes 的集成方式，为后续章节的实战操作奠定坚实的理论基础。
2.1 eBPF 技术原理
eBPF（extended Berkeley Packet Filter）是一项革命性的 Linux 内核技术，允许用户在不修改内核源代码或加载内核模块的情况下，安全、高效地在内核中运行沙箱化程序。Cilium 正是基于 eBPF 构建其网络、安全与可观测性能力。
bpf() 系统调用加载到内核，经过验证器（Verifier）严格检查（确保无循环、无越界、终止性），然后由 JIT 编译器转换为原生机器码执行。程序挂载到内核事件（如网络数据包、系统调用、函数入口/出口）上，实现动态插桩。
| 特性 | 传统内核模块 | eBPF 程序 |
|---|---|---|
| 安全性 | 无运行时检查，崩溃可能导致内核 panic | 验证器强制安全，拒绝危险程序 |
| 可移植性 | 需针对特定内核版本编译 | 一次编译，到处运行（CO-RE） |
| 性能 | 函数调用开销，上下文切换 | JIT 编译，接近原生内核性能 |
| 编程模型 | C 语言，直接操作内核数据结构 | 受限 C / Rust，通过 BPF 辅助函数与 Maps 交互 |
| 更新方式 | 需卸载/加载模块，可能中断服务 | 原子替换，无中断更新 |
eBPF 程序通过 Maps 与用户空间交互。Maps 是键值存储结构，用于共享状态、统计信息和配置数据。Cilium 大量使用 Maps 来存储端点信息、策略规则和连接跟踪状态。
2.2 Cilium 架构组件
Cilium 采用微服务架构，由多个协同工作的组件构成。在生产环境中，这些组件以 DaemonSet、Deployment 等形式运行在 Kubernetes 集群中。
2.2.1 Cilium Agent
运行方式： DaemonSet，每个节点一个 Pod。
- 核心职责： 管理节点上的 eBPF 程序，处理网络数据路径、安全策略执行与负载均衡。
- 关键功能：
- 通过
cilium-agent进程与 kube-apiserver 通信，监听 Pod、Service、NetworkPolicy 等资源变化。 - 生成并加载 eBPF 程序到网络接口（如
cilium_host、lxc等）。 - 维护本地 eBPF Maps（端点映射、策略映射、连接跟踪表）。
- 处理 NodePort、ExternalTrafficPolicy 等 Kubernetes 网络特性。
- 通过
2.2.2 Cilium Operator
运行方式： Deployment，通常 1 个副本（高可用可多副本）。
- 核心职责： 处理集群级别的控制面任务，减轻 Agent 负担。
- 关键功能：
- 为节点分配 PodCIDR 范围（当使用 CRD-backed IPAM 时）。
- 管理 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy 的 CRD 状态。
- 处理 Service 的负载均衡器 IP 分配（如 MetalLB 集成）。
- 执行身份（Identity）的全局垃圾回收。
2.2.3 Cilium CNI 插件
运行方式： 二进制文件，由 kubelet 在 Pod 创建时调用。
- 核心职责： 实现 Kubernetes CNI 接口规范，完成 Pod 网络接口的创建与配置。
- 工作流程：
- kubelet 调用
cilium-cni二进制（ADD命令）。 - CNI 插件通过 Unix Socket 与节点上的 Cilium Agent 通信。
- Agent 创建 veth 对，一端放入 Pod 网络命名空间，另一端挂载到 Cilium 数据路径。
- Agent 为 Pod 分配 IP 地址与安全身份（Security Identity）。
- Agent 加载对应的 eBPF 程序，实现网络连通性与策略隔离。
- kubelet 调用
2.3 Cilium 与 Kubernetes 的集成方式
Cilium 通过多种机制深度集成到 Kubernetes 生态中，使其不仅是一个 CNI 插件，更是一个完整的云原生网络、安全与可观测性平台。
2.3.1 作为 CNI 插件
Cilium 实现了标准的 CNI 规范，kubelet 在创建 Pod 时调用 cilium-cni 二进制。这是最基础的集成方式，确保每个 Pod 获得网络连通性。
- IPAM 模式： 支持 Cluster Pool（默认）、Kuberenetes HostScope、CRD-backed、ENI（AWS）、Azure IPAM 等。
- 数据封装： 支持 VXLAN、Geneve 隧道模式以及直接路由模式（Direct Routing）。
2.3.2 通过 CRD 扩展 Kubernetes API
Cilium 定义了大量自定义资源定义（CRD），将网络策略、服务映射、身份标识等概念以 Kubernetes 原生方式管理。
| CRD 名称 | 用途 | 作用范围 |
|---|---|---|
CiliumNetworkPolicy |
增强版网络策略，支持 L3-L7 规则、HTTP/gRPC 过滤 | 命名空间级 |
CiliumClusterwideNetworkPolicy |
集群全局网络策略，适用于跨命名空间场景 | 集群级 |
CiliumEndpoint |
记录每个 Pod 的身份、IP、策略状态 | 命名空间级 |
CiliumIdentity |
安全身份标识，基于标签派生，用于策略匹配 | 集群级 |
CiliumNode |
节点配置，包含 IPAM 分配、隧道端点信息 | 集群级 |
2.3.3 服务网格与 Ingress 集成
Cilium 内置了基于 eBPF 的服务网格能力，无需 Sidecar 代理即可实现 L7 流量管理。
- Cilium Service Mesh： 通过 Envoy 代理（集成在 Agent 中）或纯 eBPF 实现 L7 策略与可观测性。
- Cilium Ingress Controller： 直接使用 eBPF 处理 Ingress 流量，性能优于传统反向代理。
- Gateway API 支持： 实现 Kubernetes Gateway API 规范，提供更丰富的流量路由能力。
2.3.4 可观测性集成
Cilium 通过 Hubble 组件提供深度网络可观测性，数据直接来自 eBPF 程序。
- Hubble Relay： 聚合集群中所有 Hubble 实例的数据，提供全局视图。
- Hubble UI： 可视化服务依赖图与流量流向。
- Metrics 集成： 暴露 Prometheus 指标，可与 Grafana 等监控系统对接。