2. Cilium架构总览
Cilium 的架构设计遵循云原生微服务理念，将数据平面与控制平面职责分离，并通过多个独立组件协同工作。理解这些组件的角色、生命周期与交互方式，是编写和调试网络策略的前提。本章从组件职责、部署拓扑与数据流三个维度展开。
2.1 核心组件与职责矩阵
Cilium 集群由四个核心组件构成，每个组件运行在独立的容器或进程空间中，通过 gRPC、Kubernetes API 或 eBPF 程序共享状态。
| 组件 | 运行位置 | 核心职责 | 数据平面/控制平面 |
|---|---|---|---|
| Cilium Agent | 每个 Kubernetes 节点（DaemonSet） | 管理 eBPF 程序、同步网络策略、维护端点状态 | 数据平面 + 控制平面 |
| Cilium Operator | 集群内任意节点（Deployment） | 处理集群级任务：IPAM、身份管理、多集群服务 | 控制平面 |
| Cilium CNI 插件 | 每个节点（二进制文件） | 响应 kubelet CNI 请求，配置 Pod 网络命名空间 | 数据平面入口 |
| Hubble | 每个节点 + 集群级（DaemonSet + Deployment） | 可观测性：流量捕获、策略审计、服务依赖图 | 可观测平面 |
架构要点：Cilium Agent 是唯一直接操作 eBPF 的组件，所有网络策略最终由 Agent 编译为 BPF 字节码并加载到内核。Operator 不参与数据路径，只负责协调集群范围的元数据。
2.2 Cilium Agent：数据平面的执行者
Cilium Agent 是 Cilium 最核心的组件，以 DaemonSet 方式在每个节点上运行。它通过 eBPF 直接编程 Linux 内核，实现网络、安全和可观测性功能。
- 端点管理：监听 Kubernetes Pod 变化，为每个 Pod 创建 CiliumEndpoint 对象，分配安全身份（Security Identity）。
- 策略引擎：将 CiliumNetworkPolicy / CiliumClusterwideNetworkPolicy 转换为 BPF map 条目，实现 L3/L4/L7 过滤。
- eBPF 程序生命周期：编译、加载、附加和卸载 BPF 程序到网络设备、cgroup 或 XDP 挂载点。
- 服务负载均衡：通过 BPF 实现 kube-proxy 替代（kube-proxy replacement），支持 DSR、Maglev 一致性哈希。
- 节点间隧道/路由：管理 VXLAN、Geneve 隧道或直接路由，确保跨节点 Pod 通信。
# 查看节点上 Cilium Agent 状态
kubectl -n kube-system exec ds/cilium -- cilium status
KVStore: Ok etcd: 1/1 connected: 1.2.3.4:2379
Kubernetes: Ok 1.29 (v1.29.0) [linux/amd64]
Kubernetes APIs: ["cilium/v2", "networking/v1", "core/v1"]
Cilium: Ok OK
NodeMonitor: Disabled
Cilium health: Ok
IPAM: IPv4: 10.0.0.0/16, 10.0.0.1/24
BandwidthManager: EDT with BPF [eth0]
Host Routing: Legacy
Masquerading: IPtables
Controller Status: 18/18 healthy
2.3 Cilium Operator：集群级协调者
Cilium Operator 是一个单实例或多副本 Deployment，负责处理那些不需要在每个节点上重复执行的集群级任务。它不参与数据路径，但控制着整个集群的地址分配和身份管理。
| 功能模块 | 说明 | 影响范围 |
|---|---|---|
| IPAM（IP 地址管理） | 从 CRD（CiliumNode）分配 PodCIDR，支持 CRD、Kuberenetes HostScope、AWS ENI、Azure 等模式 | 集群 |
| 身份管理（Identity） | 为每个安全标签组合分配全局唯一的 Security Identity，写入 KV Store | 集群 |
| 多集群服务（ClusterMesh） | 同步跨集群 Service 和 Endpoint，生成全局网络策略 | 多集群 |
| CiliumEndpoint 垃圾回收 | 清理已删除 Pod 残留的 CiliumEndpoint CRD | 集群 |
| 健康检查 | 定期探测节点间连通性，更新 CiliumNode 状态 | 集群 |
运维注意：Operator 故障不会立即中断现有 Pod 的网络通信，但会导致新 Pod 无法分配 IP 或身份，以及跨集群服务同步停止。建议部署 2 个副本并设置 PodAntiAffinity。
2.4 Cilium CNI 插件：Pod 网络入口
Cilium CNI 插件是一个轻量级二进制文件（cilium-cni），由 kubelet 在创建 Pod 时调用。它不执行 eBPF 操作，而是将配置传递给本节点的 Cilium Agent，由 Agent 完成实际的网络配置。
- 调用流程：kubelet → CNI 插件 → Cilium Agent API（Unix Socket）→ Agent 配置网络命名空间。
- 配置内容：分配 IP 地址、设置路由、创建 veth pair、附加 BPF 程序。
- 性能优势：CNI 插件本身无状态，所有复杂逻辑由 Agent 异步处理，避免阻塞 kubelet 同步循环。
# 查看 CNI 配置（默认路径）
cat /etc/cni/net.d/05-cilium.conf
{
"name": "cilium",
"type": "cilium-cni",
"enable-debug": false,
"log-file": "/var/run/cilium/cilium-cni.log"
}
2.5 Hubble：可观测性平面
Hubble 是 Cilium 的可观测性层，基于 eBPF 捕获所有网络事件，提供实时流量监控、策略审计和服务依赖分析。它由两个子组件构成：
| 子组件 | 部署方式 | 功能 |
|---|---|---|
| Hubble Relay | Deployment（集群级） | 聚合所有节点的 Hubble 数据，提供统一 gRPC API |
| Hubble Agent | DaemonSet（每个节点） | 从 Cilium Agent 获取 eBPF 事件，缓存并暴露本地数据 |
- 流量日志：记录每个网络流的五元组、Verdict（ALLOW/DENY）、L7 协议详情。
- 策略审计：当策略处于“审计模式”时，Hubble 记录被拒绝的流量但不实际丢弃。
- 服务依赖图：通过 Hubble UI 或 CLI 生成实时拓扑，展示服务间通信关系。
策略调试最佳实践：在编写新策略时，先使用
hubble observe --verdict DROPPED 查看被拒绝的流量，再结合 cilium policy trace 验证策略预期。Hubble 的审计模式可以安全地观察策略影响而不中断业务。
2.6 组件交互架构图
下图展示了 Cilium 组件在单节点内的交互关系，以及 Hubble 如何从 Agent 获取事件流。
2.7 控制面与数据面分离的架构优势
Cilium 的组件分离设计带来了明确的运维边界和故障隔离能力：
- 故障域隔离：Operator 故障不影响现有 Pod 的数据路径；Agent 故障只影响所在节点的新连接。
- 升级灵活性：可以独立升级 Operator 或 Hubble，无需重启 Agent 或中断业务流量。
- 可观测性解耦：Hubble 从 Agent 订阅事件流，即使 Hubble Relay 宕机，Agent 仍正常转发流量。
- 策略执行确定性：所有策略最终由 Agent 编译为 eBPF 字节码，不存在控制面与数据面状态不一致的问题。
架构决策点：在控制面架构中集成 Cilium 网络策略时，应优先关注 Agent 的资源配额（CPU/内存）和 eBPF 内核兼容性，因为 Agent 是策略执行的唯一实体。Operator 和 Hubble 的可用性可以通过标准 Kubernetes 部署策略保障。