📚 课程目录第2章 Cilium架构深度解析

2. Cilium 架构深度解析：Cilium Agent、Cilium Operator、Hubble 组件、CNI 插件与数据路径

Cilium 并非一个单一二进制，而是一组协同工作的组件集合。理解每个组件的职责、生命周期以及它们如何通过数据路径串联，是进行网络策略编写和性能调优的基础。本章将拆解 Cilium 的控制面与数据面核心组件，并深入其基于 eBPF 的数据路径。

2.1 核心组件总览

Cilium 架构主要分为控制面组件和数据面组件。控制面负责策略管理、身份认证和集群状态同步；数据面则负责实际的数据包转发和策略执行。

组件	类型	部署方式	核心职责
Cilium Agent	DaemonSet	每个节点一个	管理 eBPF 程序、同步节点状态、执行网络策略、与 API Server 交互
Cilium Operator	Deployment	集群级（通常 1-2 副本）	处理集群级任务：IPAM、多集群服务、CNI 配置管理
Hubble	DaemonSet + Deployment	每个节点 + 集群级 UI	可观测性：流量抓取、服务依赖图、安全事件告警
CNI Plugin	二进制插件	节点本地	实现 Kubernetes CNI 接口，调用 Cilium Agent 完成 Pod 网络接入
Cilium CLI	客户端工具	用户终端	调试、状态检查、策略验证

关键认知： Cilium Agent 是唯一直接操作 eBPF 的组件，所有数据路径的修改都通过它完成。Operator 和 Hubble 是辅助性的控制面组件，它们的故障不会立即导致数据面中断，但会影响集群扩展性和可观测性。

2.2 Cilium Agent：数据面的核心引擎

Cilium Agent 以 DaemonSet 形式运行在每个 Kubernetes 节点上。它是整个架构中最繁忙的组件，负责将用户意图（网络策略、服务定义）转化为内核中的 eBPF 程序。

2.2.1 Agent 内部模块

Endpoint Manager：管理节点上所有 Pod（称为 Endpoint）的生命周期，包括 IP 分配、身份标签同步。
Policy Repository：存储并解析 CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy，生成策略决策的 BPF Map。
Datapath Regenerator：当 Endpoint 或策略发生变化时，触发 eBPF 程序的重新编译和加载。
K8s Watcher：监听 Kubernetes API Server 的 Pod、Service、Node、Policy 事件。
KVStore Sync：在集群规模较大时，通过 etcd 或 Consul 同步全局身份标识（Identity）。

2.2.2 Agent 启动流程

节点启动，kubelet 调用 Cilium CNI 插件。
CNI 插件通过 Unix Socket 请求 Cilium Agent 为 Pod 分配网络资源。
Agent 为 Pod 创建 Endpoint，分配 IP 和 Security Identity。
Agent 编译并加载针对该 Endpoint 的 eBPF 程序到网络设备（如 cilium_host、lxc*）。
Agent 将 Endpoint 信息写入 BPF Map，供数据路径查找。

# 查看节点上 Cilium Agent 管理的 Endpoint
cilium endpoint list
ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])   IPv6   IPv4           STATUS
           ENFORCEMENT        ENFORCEMENT
12345      Enabled            Enabled           1678       k8s:app=frontend              ...    10.0.1.5       ready

2.3 Cilium Operator：集群级协调者

Operator 负责那些不适合在每个 Agent 上独立执行的任务。它通过 Kubernetes 的控制器模式工作，确保集群状态符合预期。

功能模块	说明	性能影响
IPAM (IP Address Management)	管理 PodCIDR 分配，支持 CRD-backed、Kuberenetes HostScope、AWS ENI、Azure 等模式	高：IP 池耗尽会影响 Pod 调度
CNI Chaining	管理 Cilium 与其他 CNI 插件（如 Calico、Flannel）的链式部署配置	中：配置错误导致网络不通
Cluster Mesh	处理跨集群服务发现和网络策略同步	中：跨集群延迟和配置一致性
Node Init	新节点加入集群时，初始化 Cilium Agent 所需的系统配置（如内核参数）	低：仅在节点加入时触发

运维注意： 在大型集群（>500 节点）中，Operator 的 IPAM 控制器可能成为瓶颈。建议为 Operator 分配独立的资源配额，并启用 IPAM 的预分配缓存功能。

2.4 Hubble：可观测性的眼睛

Hubble 是 Cilium 的可观测性层，它利用 eBPF 在内核中直接捕获网络事件，无需修改应用代码或重启 Pod。

2.4.1 Hubble 组件架构

Hubble Agent (DaemonSet)：运行在每个节点上，从 Cilium Agent 的 BPF Map 中读取流量事件，并通过 gRPC 暴露。
Hubble Relay (Deployment)：集群级聚合层，将所有节点的 Hubble Agent 连接起来，提供全局查询接口。
Hubble UI (Deployment)：基于 Web 的可视化界面，展示服务依赖图、TCP 流、DNS 请求等。
hubble CLI：命令行工具，用于实时观察流量和事件。

2.4.2 Hubble 核心能力

能力	描述	典型命令/操作
流量监控	查看 Pod 之间、Pod 与外部之间的 L3/L4/L7 流量	`hubble observe --pod default/frontend`
服务依赖图	自动生成服务间的通信拓扑	Hubble UI 中查看
DNS 监控	捕获并记录所有 DNS 查询和响应	`hubble observe --type l7 --protocol dns`
HTTP 监控	记录 HTTP 请求方法、路径、状态码、延迟	`hubble observe --type l7 --protocol http`
安全事件	记录被网络策略丢弃的数据包、DNS 劫持等	`hubble observe --verdict DROPPED`

# 实时观察 default 命名空间下所有被策略丢弃的流量
hubble observe --namespace default --verdict DROPPED
TIMESTAMP             SOURCE                   DESTINATION              TYPE     VERDICT   SUMMARY
2025-03-15T10:30:01   pod/frontend-abc-123     pod/backend-xyz-456      L3/L4    DROPPED   TCP 10.0.1.5:80 -> 10.0.2.7:8080

2.5 CNI 插件：Kubernetes 网络接入点

Cilium 的 CNI 插件是一个轻量级二进制文件，通常位于 /opt/cni/bin/cilium-cni。它不执行复杂的网络逻辑，而是作为 kubelet 和 Cilium Agent 之间的桥梁。

2.5.1 CNI 调用流程

kubelet 需要创建 Pod，调用 CNI 插件的 ADD 命令。
CNI 插件解析标准输入（stdin）中的 CNI 配置，提取 Pod 名称、命名空间、网络附件等信息。
CNI 插件通过 Unix Socket（/var/run/cilium/cilium.sock）向 Cilium Agent 发送 gRPC 请求。
Cilium Agent 执行实际的网络配置（创建 veth pair、分配 IP、加载 eBPF 程序）。
CNI 插件将 Agent 返回的接口信息（MAC、IP、路由）返回给 kubelet。

# 查看节点上的 CNI 配置
cat /etc/cni/net.d/05-cilium.conf
{
  "cniVersion": "0.3.1",
  "name": "cilium",
  "type": "cilium-cni",
  "enable-debug": false
}

2.6 数据路径深度解析：eBPF 如何工作

Cilium 的数据路径完全基于 eBPF（extended Berkeley Packet Filter）实现。eBPF 允许在内核中安全地运行沙箱程序，无需修改内核源码或加载内核模块。

2.6.1 数据路径核心 Hook 点

XDP (eXpress Data Path)：在网卡驱动层处理数据包，性能最高，适合 DDoS 防护和负载均衡。
TC (Traffic Control) Ingress/Egress：在协议栈入口/出口处理，是 Cilium 默认的数据路径。
cgroup/skb：在 cgroup 层级处理，用于 socket 级别的策略控制。
Kprobes/Uprobes：动态跟踪内核/用户函数，用于 Hubble 的可观测性。

2.6.2 数据包转发流程（以 Pod 到 Pod 为例）

源 Pod 发送数据包：数据包从 Pod 的 veth 端进入主机网络栈。
TC Ingress Hook：Cilium 的 eBPF 程序在 cilium_host 或 lxc+ 接口的 TC Ingress 点被触发。
策略查找：eBPF 程序从 BPF Map 中查找源 Endpoint 的身份标识（Security Identity）。
路由决策：根据目标 IP 查找路由表，判断目标 Pod 是否在同一节点。
封装/转发：如果目标在同一节点，直接通过 veth pair 转发；如果跨节点，则通过 VXLAN/Geneve 隧道或直接路由转发。
目标节点处理：目标节点的 TC Ingress 程序再次执行策略检查，确认源身份允许访问后，将数据包交付给目标 Pod。

性能关键点： 整个数据路径完全在内核态完成，无需上下文切换到用户态。Cilium 通过 BPF Map 实现策略查找的 O(1) 时间复杂度，这是其性能优于 iptables 模式（O(n)）的根本原因。

2.7 组件交互与数据路径架构图

下图展示了 Cilium 各组件之间的交互关系以及数据包在数据路径中的流转过程。

2.8 关键性能指标与调优方向

理解架构后，我们需要关注影响性能的关键指标。下表列出了 Cilium 数据路径的核心性能指标及其调优方向。

指标	描述	典型值	调优方向
PPS (Packets Per Second)	每秒处理的数据包数量	XDP 模式可达 10M+ PPS	启用 XDP、调整 Ring Buffer 大小
Latency (P99)	数据包从源到目标的延迟	同节点 < 10μs，跨节点 < 100μs	使用直接路由替代隧道、优化 MTU
Connection Tracking	并发连接数	默认 65536，可调至 1M+	调整 `bpf-ct-global-max` 参数
Policy Enforcement	策略匹配延迟	O(1) 查找，通常 < 1μs	减少 BPF Map 大小、避免复杂 L7 规则
Hubble 事件采样率	可观测性数据采集频率	默认 100%	降低采样率（如 10%）以减少 CPU 开销

调优黄金法则： 在 GitOps 流水线中集成性能测试，每次策略变更后自动运行 cilium connectivity test 和 hubble observe 对比基线，确保性能回归在可接受范围内。

2.9 本章小结

Cilium Agent 是数据面的核心，负责 eBPF 程序的生命周期管理。
Cilium Operator 处理集群级任务，如 IPAM 和 Cluster Mesh。
Hubble 提供基于 eBPF 的可观测性，是调试和性能分析的利器。
CNI 插件 作为轻量级桥梁，将 kubelet 请求转发给 Agent。
数据路径 完全在内核态通过 eBPF 完成，实现了高性能的策略执行和转发。
性能调优应聚焦于 XDP 启用、路由模式选择、BPF Map 大小调整和 Hubble 采样率控制。