2. Cilium基础架构：eBPF原理、Cilium Agent、Cilium Operator、Cilium CNI插件架构
Cilium 的核心竞争力在于将 eBPF（extended Berkeley Packet Filter）技术与 Kubernetes 容器编排深度结合，构建了一套高性能、可观测、安全可控的云原生网络基础设施。理解其基础架构，是掌握蓝绿发布流量监控与故障排查的前提。本章将拆解 eBPF 原理、Cilium Agent、Cilium Operator 及 CNI 插件四大核心组件。
2.1 eBPF 原理：Cilium 的底层引擎
eBPF 是一种在内核虚拟机中安全运行沙箱化程序的技术，允许用户在不修改内核源码或加载内核模块的情况下，动态扩展内核功能。Cilium 利用 eBPF 实现数据包转发、负载均衡、安全策略执行及可观测性数据采集。
核心机制： eBPF 程序通过
bpf() 系统调用加载到内核，由验证器确保安全性，然后通过即时编译（JIT）转换为原生机器码执行。Cilium 主要挂载以下 eBPF 钩子点：
- XDP（eXpress Data Path）： 在网卡驱动层处理数据包，实现高性能 DDoS 防护和转发。
- TC（Traffic Control）： 在协议栈 ingress/egress 处执行，用于策略实施和封装/解封装。
- cgroup： 在容器 cgroup 边界拦截系统调用，实现安全策略。
- Socket： 在 socket 层过滤或重定向连接，用于服务网格 Sidecar 无感注入。
下图展示了 eBPF 程序在 Linux 内核网络路径中的挂载位置与数据流关系：
2.2 Cilium Agent：节点级网络大脑
Cilium Agent 是一个运行在每个 Kubernetes 节点上的 DaemonSet 进程，负责管理该节点上所有容器的网络连通性、安全策略与可观测性。它是 Cilium 架构中最核心的执行单元。
| 功能模块 | 职责描述 | 与 eBPF 的关系 |
|---|---|---|
| 策略引擎 | 解析 Kubernetes NetworkPolicy 及 CiliumNetworkPolicy CRD，生成 BPF map 规则 | 将策略写入 BPF map，eBPF 程序运行时查询 map 决定放行/丢弃 |
| 端点管理器 | 维护节点上所有容器端点的 IP、标签、身份标识（Security Identity） | 将端点信息同步到 BPF map，供数据路径查找 |
| 服务负载均衡 | 实现 Kubernetes Service 的 ClusterIP/NodePort/LoadBalancer 转发 | 通过 eBPF 在 XDP/TC 层完成 DNAT/SNAT，绕过 iptables |
| 可观测性导出 | 采集网络流日志（Flow Log）、指标（Metrics）、HTTP/gRPC 七层信息 | eBPF 程序在数据路径上复制数据包元数据，通过 perf_event 或 ring buffer 上报 |
| 节点间隧道管理 | 管理 VXLAN/Geneve 隧道或直接路由，实现跨节点容器通信 | eBPF 程序在 TC 层执行封装/解封装 |
运维要点： 在蓝绿发布场景中，Cilium Agent 负责实时更新端点身份标识。当新版本 Pod 启动时，Agent 会为其分配新的 Security Identity，并更新 BPF map。旧版本 Pod 缩容后，Agent 清理对应 map 条目，确保流量不会路由到已终止的端点。
2.3 Cilium Operator：集群级控制协调器
Cilium Operator 是一个单实例 Deployment，负责处理集群范围的协调任务，不参与节点级数据路径转发。它通过监听 Kubernetes API 资源变化，驱动 Agent 执行全局操作。
- 身份分配： 为每个端点分配全局唯一的 Security Identity（基于标签组合），并确保身份在集群内一致。
- IPAM（IP 地址管理）： 管理 PodCIDR 分配，支持 CRD-backed、Kuberenetes HostScope、AWS ENI、Azure IPAM 等多种模式。
- CNP/CCNP 策略验证： 校验 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy 的语法与语义，避免无效策略下发到 Agent。
- KVStore 状态同步： 当使用 etcd 作为状态存储时，Operator 负责维护 KVStore 中的集群状态一致性。
- 故障恢复： 监控 Agent 健康状态，触发重新加载配置或重启异常 Agent。
注意： Operator 的可用性直接影响集群网络变更的响应速度。在蓝绿发布期间，如果 Operator 异常，新版本 Pod 可能无法及时获取 Security Identity，导致流量被策略拒绝。建议为 Operator 配置 PodDisruptionBudget 和反亲和性调度。
2.4 Cilium CNI 插件：容器网络接入点
Cilium CNI 插件是一个轻量级二进制文件，由 kubelet 在创建 Pod 时调用。它负责将容器接入 Cilium 管理的网络，并配置初始网络命名空间状态。
CNI 插件的执行流程如下：
- ADD 操作： kubelet 调用 Cilium CNI 二进制，传入容器 ID、网络命名空间路径、Pod 名称/命名空间等参数。
- 接口创建： 在容器网络命名空间中创建 veth pair，一端放入容器（eth0），另一端留在主机网络命名空间（lxcXXXX）。
- IP 分配： 通过本地 Unix Socket 向 Cilium Agent 请求 IP 地址，Agent 从 IPAM 池中分配。
- 端点注册： Agent 将新端点信息（IP、MAC、Pod 标签）注册到本地端点列表，并分配 Security Identity。
- eBPF 程序加载： Agent 为 veth 主机端加载 eBPF 程序，设置策略 map 和转发规则。
- 路由配置： 在容器内设置默认路由，指向 veth 主机端。
- DEL 操作： Pod 删除时，CNI 插件清理 veth 接口，Agent 释放 IP 并移除 BPF map 中的端点条目。
下图展示了 CNI 插件、Agent 与内核 eBPF 之间的协作关系：
2.5 组件关系总结
下表从职责范围、部署形态、数据路径参与度三个维度对比四大组件：
| 组件 | 职责范围 | 部署形态 | 参与数据路径 |
|---|---|---|---|
| eBPF 程序 | 数据包转发、策略执行、观测采集 | 内核态，由 Agent 加载 | 是（核心执行者） |
| Cilium Agent | 节点级策略管理、端点管理、隧道管理 | DaemonSet（每节点一个） | 否（控制面下发规则） |
| Cilium Operator | 集群级身份分配、IPAM、策略校验 | Deployment（单实例/多副本） | 否（纯控制面） |
| Cilium CNI 插件 | 容器网络接入、接口创建、IP 请求 | 二进制文件，由 kubelet 调用 | 否（仅 Pod 生命周期触发） |
蓝绿发布关联： 在蓝绿发布过程中，Cilium Agent 负责实时更新端点身份与策略 map，确保新旧版本 Pod 的流量隔离；Cilium Operator 保证全局身份一致性，避免跨节点策略冲突；CNI 插件确保新 Pod 快速接入网络；eBPF 程序在数据路径上执行精确的流量转发与监控，为自动化故障排查提供毫秒级流日志与指标。