📚 课程目录第2章 Cilium架构回顾

2. Cilium 架构回顾：核心组件与数据路径

在深入验证租户隔离蓝图的通信机制之前，有必要系统回顾 Cilium 的整体架构。Cilium 并非传统意义上的 CNI 插件，而是一个基于 eBPF 的云原生网络、安全与可观测性平台。其核心组件包括 Cilium Agent、Cilium Operator、eBPF 数据路径以及 Hubble 可观测性组件。理解这些组件的职责与交互，是后续升级验证的基础。

2.1 核心组件总览

下表列出了 Cilium 部署在 Kubernetes 集群中的主要组件及其职责，这些组件通常以 DaemonSet 和 Deployment 的形式运行。

组件名称	部署类型	核心职责	与租户隔离的关系
Cilium Agent	DaemonSet	管理 eBPF 程序、节点本地网络策略、服务转发、健康检查	直接执行租户网络策略与隔离规则
Cilium Operator	Deployment	集群级协调、IPAM、身份管理、CRD 同步	管理租户身份标识与全局策略分发
eBPF 数据路径	内核态	网络包处理、策略执行、负载均衡、隧道封装	租户流量隔离的底层执行层
Hubble	DaemonSet + Deployment	流量可观测性、服务依赖图、安全事件监控	验证租户隔离策略是否生效的可视化工具

2.2 Cilium Agent：节点级策略执行引擎

Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程，是 Cilium 最核心的组件。它通过 gRPC 与 kube-apiserver 通信，监听 Pod、Service、NetworkPolicy 以及 Cilium 自定义资源（如 CiliumNetworkPolicy、CiliumEndpoint）的变化。

eBPF 程序管理：Agent 负责将用户意图（如网络策略）编译为 eBPF 字节码，并通过 bpffs 挂载到内核的钩子点（如 XDP、TC、cgroup）。
端点管理：维护本地节点上所有 Pod 的 CiliumEndpoint 对象，记录其 IP、身份标签和安全策略。
服务转发：实现基于 eBPF 的 kube-proxy 替代，提供高效的 Service 负载均衡。
健康检查：通过 eBPF 实现节点和 Pod 的连通性探测，支持 ClusterMesh 跨集群场景。

  关键点：在租户隔离场景中，Cilium Agent 是策略执行的最后一公里。每个节点上的 Agent 独立运行 eBPF 程序，确保跨节点租户流量被正确隔离。

2.3 Cilium Operator：集群级协调器

Cilium Operator 是一个集群级组件，通常以 Deployment 形式运行（建议副本数为 2 以实现高可用）。它不直接参与数据路径处理，而是负责集群范围的协调任务。

身份管理（Identity Management）：为每个具有唯一安全标签组合的 Pod 分配一个 16 位的数字身份 ID。租户隔离正是基于这些身份 ID 在 eBPF Map 中进行匹配。
IPAM（IP Address Management）：管理 Pod CIDR 分配，支持 CRD-backed、Kuberenetes HostScope、AWS ENI、Azure IPAM 等多种模式。
CRD 同步：确保 CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy 等 CRD 在集群内一致分发。
故障恢复：监控 Agent 健康状态，在 Agent 故障时触发身份回收或 IP 释放。

升级影响：Operator 的升级通常不会中断数据路径，但身份 ID 的重新分配可能导致短暂策略不一致。在升级验证中，需要关注 Operator 升级后身份映射的收敛时间。

2.4 eBPF 数据路径：高性能内核转发

eBPF 数据路径是 Cilium 区别于传统 CNI（如 Calico、Flannel）的核心优势。Cilium 利用 eBPF 在内核中动态注入程序，实现网络包的处理，无需修改内核代码或加载内核模块。

下图展示了 Cilium 在节点上的 eBPF 数据路径架构，包括关键的钩子点和数据流。

eBPF 数据路径的关键特性包括：

XDP（eXpress Data Path）：在网卡驱动层处理数据包，实现 DDoS 防护和早期过滤，性能极高。
TC（Traffic Control）Ingress/Egress：在协议栈入口和出口处执行策略，支持 L3/L4 甚至 L7 过滤。
cgroup/socket 钩子：在 socket 层拦截系统调用，实现进程级网络隔离和 sockmap 加速。
eBPF Maps：内核态与用户态共享的数据结构，存储策略规则、端点信息、路由表等，是数据路径的“内存数据库”。

升级风险：eBPF 程序与内核版本紧密耦合。Cilium 升级时，Agent 会重新加载 eBPF 程序，若新程序与旧内核不兼容，可能导致数据路径中断。升级前必须验证内核版本与 Cilium 版本的兼容性矩阵。

2.5 Hubble：可观测性与安全验证

Hubble 是 Cilium 的可观测性层，基于 eBPF 实现无侵入的流量监控。在租户隔离验证中，Hubble 是判断策略是否生效的关键工具。

Hubble 由两部分组成：

Hubble Agent（DaemonSet）：运行在每个节点上，从 Cilium Agent 获取 eBPF 事件，并提供本地 gRPC 服务。
Hubble Relay（Deployment）：集群级聚合层，将所有 Agent 的数据合并，提供全局视图。

下图展示了 Hubble 的组件架构及其与 Cilium Agent 的关系。

Hubble 在租户隔离验证中的典型用途：

流量可视化：使用 hubble observe 命令实时查看 Pod 间的通信，确认租户 A 的 Pod 无法访问租户 B 的 Pod。
策略审计：通过 Hubble UI 查看服务依赖图，识别被策略丢弃的流量（DROPPED 事件）。
性能分析：监控 eBPF 数据路径的延迟和丢包率，评估升级对网络性能的影响。

验证命令示例：

# 查看租户 A 的 Pod 发出的所有流量
hubble observe --from-pod tenant-a/app-1 -n tenant-a

# 查看被策略丢弃的流量
hubble observe --verdict DROPPED -n tenant-a

2.6 组件交互流程总结

在正常运行时，Cilium 各组件的交互流程如下：

策略定义：用户创建 CiliumNetworkPolicy CRD，定义租户隔离规则。
Operator 协调：Cilium Operator 监听到 CRD 变更，更新全局身份映射，并将策略分发到所有节点。
Agent 编译与注入：每个节点上的 Cilium Agent 将策略编译为 eBPF 程序，通过 bpftool 加载到内核钩子点，并更新 eBPF Map。
数据路径执行：当 Pod 发送数据包时，eBPF 程序在内核中匹配源/目的身份 ID，执行允许或丢弃动作。
Hubble 采集：Hubble Agent 从 eBPF 事件中捕获流量元数据，聚合后通过 Hubble Relay 供用户查询。