3、Cilium架构回顾：eBPF原理、Cilium Agent、Cilium Operator、Cilium CNI插件、Hubble可观测性
在生产窗口执行Cilium回滚操作前，必须深入理解Cilium的核心架构组件及其协作机制。本章将系统回顾eBPF原理、Cilium Agent、Cilium Operator、Cilium CNI插件以及Hubble可观测性模块，为后续的回滚验证奠定理论基础。
3.1 eBPF原理与Cilium的基石
eBPF（extended Berkeley Packet Filter）是Cilium实现高性能网络、安全与可观测性的核心技术。它允许用户在Linux内核中安全地运行沙箱化程序，无需修改内核源码或加载内核模块。
核心机制：eBPF程序通过验证器（Verifier）确保安全性，通过JIT编译器转换为原生机器码，以内核钩子（Kprobes、Tracepoints、XDP、TC等）方式挂载执行。
回滚关键点：eBPF程序在Cilium回滚时会被卸载并替换为旧版本的程序。验证eBPF程序是否正确卸载、新程序是否成功加载，是回滚验证的首要步骤。
3.2 Cilium Agent：节点级控制平面
Cilium Agent是运行在每个Kubernetes节点上的守护进程（DaemonSet），负责管理该节点上的所有eBPF程序、网络策略、服务负载均衡以及端点（Endpoint）状态。
| 组件 | 职责 | 回滚影响 |
|---|---|---|
| Endpoint Manager | 管理本地Pod的网络端点，维护端点标识与eBPF映射关系 | 回滚期间端点状态可能丢失，需重建 |
| Policy Repository | 存储并编译网络策略（NetworkPolicy / CiliumNetworkPolicy）为eBPF映射 | 策略重新编译，旧版本策略可能不兼容 |
| Service Manager | 实现Kubernetes Service的eBPF负载均衡（Maglev / Random） | 回滚后服务后端映射需重新同步 |
| Node Discovery | 通过KV存储（etcd）发现集群节点变化 | 回滚期间节点信息同步延迟 |
| Identity Allocator | 为安全策略分配安全标识（Security Identity） | 标识分配可能中断，影响策略生效 |
回滚风险提示：Cilium Agent的配置参数（如隧道模式、路由模式、MTU、BPF-FS路径等）在不同版本间可能存在不兼容变更。回滚前必须比对Agent配置文件的差异。
3.3 Cilium Operator：集群级协调器
Cilium Operator是集群级别的控制器，负责处理全局性任务，不直接参与数据平面操作。它通常以Deployment形式运行，副本数建议为2以实现高可用。
- 节点间隧道管理：在隧道模式下（VXLAN/Geneve），Operator负责分配隧道端点IP并同步节点路由。
- IP地址管理（IPAM）：管理PodCIDR分配，支持Kuberenetes HostScope、CRD-backed、ENI（AWS）、Azure等模式。
- 安全标识同步：协调跨节点的安全标识一致性，确保策略正确应用。
- CRD状态更新：更新CiliumNode、CiliumEndpoint、CiliumIdentity等自定义资源的状态。
3.4 Cilium CNI插件：Pod网络接入点
Cilium CNI插件是Kubelet在创建Pod时调用的二进制文件，负责将Pod接入Cilium网络。它通过标准CNI接口（ADD/DEL/CHECK）与Kubelet交互。
CNI调用流程：Kubelet → Cilium-CNI二进制 → 与本地Cilium Agent通信（通过gRPC）→ Agent配置网络命名空间、创建veth对、加载eBPF程序、分配IP与安全标识。
CNI插件的关键配置参数包括：
- chaining-mode：是否与其他CNI插件（如portmap、bandwidth）链式组合。
- enable-ipv4/enable-ipv6：控制IP协议栈启用。
- ipam：IP地址管理模式（kubernetes、crd、eni、azure等）。
- tunnel：隧道协议（vxlan、geneve、disabled）。
回滚验证要点：回滚后必须执行CNI的CHECK操作，验证现有Pod的网络连通性。如果CNI插件版本不匹配，可能导致新Pod无法创建或现有Pod网络中断。
3.5 Hubble可观测性：网络流量可视化
Hubble是Cilium的可观测性层，基于eBPF实现细粒度的网络流量监控、服务依赖关系映射以及安全策略审计。它由Hubble Server（运行在每个节点）和Hubble UI（集群级Web界面）组成。
| 组件 | 功能 | 回滚影响 |
|---|---|---|
| Hubble Server | 从Cilium Agent获取eBPF事件流，提供gRPC API供查询 | 回滚期间事件流可能中断，历史数据保留取决于存储后端 |
| Hubble Relay | 聚合多个节点的Hubble Server，提供集群级统一查询接口 | Relay版本需与Server版本兼容 |
| Hubble UI | 基于React的Web界面，展示服务拓扑、流量指标、策略审计日志 | UI版本独立，通常不受回滚影响 |
| Hubble Metrics | 暴露Prometheus指标（丢包率、延迟、TCP状态等） | 指标字段可能变更，监控告警规则需同步调整 |
3.6 组件依赖关系与回滚影响矩阵
下表总结了Cilium各组件在回滚操作中的依赖关系与潜在影响，帮助制定回滚验证清单。
| 组件 | 依赖组件 | 回滚顺序 | 验证指标 |
|---|---|---|---|
| Cilium Agent | eBPF内核版本、Cilium Operator | 先回滚Agent，再回滚Operator | Pod连通性、eBPF程序加载状态、端点数量 |
| Cilium Operator | Kubernetes API Server | Agent回滚完成后回滚 | CRD状态更新、IPAM分配、隧道同步 |
| Cilium CNI插件 | Cilium Agent（gRPC通信） | 与Agent同时回滚 | 新Pod创建成功率、CNI CHECK通过率 |
| Hubble Server | Cilium Agent（事件源） | Agent回滚后回滚 | 事件流连续性、gRPC API可用性 |
| Hubble Relay | Hubble Server | Server回滚后回滚 | 集群级查询响应、拓扑图正确性 |
回滚验证最佳实践：在生产窗口执行回滚前，先在预发环境按上述依赖顺序进行灰度回滚，并使用Hubble持续监控流量变化。回滚完成后，执行全量Pod的连通性测试和策略审计，确保无遗留问题。