3. Cilium 架构总览：核心组件与协作流程
Cilium 并非单一二进制，而是一组协同工作的组件集合。理解每个组件的职责及其交互方式，是进行数据传输优化和故障排查的基础。本章将深入剖析 Cilium Agent、Cilium Operator、Cilium CLI 和 Hubble 这四大核心模块。
3.1 核心组件概览
下表总结了四个组件在集群中的角色、部署形态和主要职责，帮助你快速建立全局认知。
| 组件 | 部署形态 | 核心职责 | 关键特性 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每个节点一个） | 数据平面编程、策略执行、节点状态上报 | 直接操作 eBPF 程序，管理本地 Endpoint |
| Cilium Operator | Deployment（通常 1-2 副本） | 集群级控制面协调、资源清理、状态同步 | 处理集群范围的 CRD，如 CiliumNetworkPolicy |
| Cilium CLI | 客户端二进制（用户操作） | 集群状态诊断、策略验证、调试命令 | 提供 cilium status、cilium connectivity test 等命令 |
| Hubble | DaemonSet + Deployment | 可观测性、流量监控、安全审计 | 基于 eBPF 的 Service Map 和流日志 |
3.2 Cilium Agent：数据平面的执行者
Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程，是唯一直接与内核 eBPF 子系统交互的组件。它负责将用户意图（如网络策略、负载均衡规则）转换为 eBPF 程序并加载到内核。
- Endpoint 管理：Agent 监控本地节点上的 Pod 创建/删除事件，为每个 Pod 创建对应的 Endpoint 对象，并分配唯一的标识（Security Identity）。
- 策略执行：当 CiliumNetworkPolicy 被创建或更新时，Agent 从 Kubernetes API Server 或 Operator 处获取策略，将其编译为 eBPF 的 map 和程序，实现 L3/L4/L7 的访问控制。
- 服务负载均衡：Agent 利用 eBPF 的 XDP 或 TC hook 实现高性能的 Service 转发，替代传统的 kube-proxy iptables 模式，显著降低延迟。
- 节点状态同步：Agent 定期向 Operator 或 KV Store（如 etcd）上报本地节点状态、Endpoint 列表和健康信息。
3.3 Cilium Operator：集群控制面的协调者
Operator 是集群级别的控制器，负责处理那些需要全局视角的任务。它通常以 Deployment 形式运行，推荐部署 2 个副本以保证高可用。
- CRD 控制器：监听 CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy、CiliumEndpoint 等自定义资源的变化，并将变更事件分发给各节点的 Agent。
- 身份管理：维护全局的 Security Identity 到标签的映射关系。当新的安全策略需要引用某个标签时，Operator 负责分配或查找对应的 Identity。
- 资源清理：当节点从集群中移除时，Operator 负责清理该节点上残留的 CiliumEndpoint 对象和相关的 KV Store 条目，防止数据残留。
- 状态聚合：收集所有 Agent 上报的健康状态，提供集群级别的健康视图。
3.4 Cilium CLI：运维诊断的瑞士军刀
Cilium CLI 是管理员与 Cilium 集群交互的主要命令行工具。它既可以用于本地节点调试，也可以用于集群范围的连通性测试。
常用命令示例：
# 查看本地 Agent 状态
cilium status
# 查看集群中所有 Endpoint 及其安全标识
cilium endpoint list
# 执行集群连通性测试（需先安装 cilium-cli）
cilium connectivity test
# 抓取特定 Pod 的 eBPF 跟踪日志
cilium monitor --from-pod default/my-app-xxxxxCLI 工具通过 gRPC 与本地 Cilium Agent 通信，获取实时的 eBPF map 数据和事件流。它不依赖 Kubernetes API Server，因此在 API Server 不可用时仍能进行节点级诊断。
3.5 Hubble：基于 eBPF 的可观测性层
Hubble 是 Cilium 生态中的可观测性组件，它利用 eBPF 程序在内核中直接捕获网络事件，提供低开销、高保真的流量监控能力。
- Hubble Agent（DaemonSet）：运行在每个节点上，从 Cilium Agent 获取 eBPF 事件，进行聚合和过滤，并通过 gRPC 暴露流日志和指标。
- Hubble Relay（Deployment）：作为集群级别的查询入口，聚合所有 Hubble Agent 的数据，提供统一的 API 接口，支持跨节点的流量查询。
- Hubble UI：基于 Relay API 的可视化界面，展示 Service Map、流量拓扑和实时流日志。
Hubble 的核心价值在于：
- 零侵入：无需修改应用代码或 Sidecar，即可获得 Pod 级别的网络流量视图。
- 安全审计：记录所有被策略允许或拒绝的连接，支持基于 DNS、HTTP 等 L7 协议的审计。
- 延迟分析：通过 eBPF 的 TCP 跟踪点，精确测量请求/响应延迟，识别网络瓶颈。
3.6 组件协作流程（SVG 架构图）
下图展示了 Cilium Agent、Operator、CLI 和 Hubble 在 Kubernetes 集群中的协作关系。数据流从用户操作（kubectl 或 cilium CLI）出发，经过控制面组件，最终由 Agent 编程 eBPF 内核。
3.7 组件间通信机制
各组件之间的通信方式决定了系统的可靠性和可扩展性。下表总结了主要的通信路径和协议：
| 通信路径 | 协议 | 用途 | 可靠性要求 |
|---|---|---|---|
| Agent ↔ API Server | HTTP/gRPC | 监听 Pod/Policy 事件 | 高（断连会导致策略更新延迟） |
| Agent ↔ Operator | gRPC / CRD | 获取 Security Identity | 中（可缓存 Identity 降级运行） |
| Agent ↔ Agent | 直接路由 / VXLAN | 跨节点 Pod 通信 | 高（直接影响数据路径） |
| CLI ↔ Agent | gRPC (Unix Socket) | 本地诊断和监控 | 低（仅运维时使用） |
| Hubble Agent ↔ Hubble Relay | gRPC | 流日志聚合 | 中（丢失日志不影响网络功能） |
3.8 部署架构最佳实践
在生产环境中，建议遵循以下配置原则：
- Agent 资源预留：每个节点预留 0.5-1 核 CPU 和 512MB-1GB 内存给 Cilium Agent，具体取决于节点上的 Pod 密度。
- Operator 高可用：至少部署 2 个 Operator 副本，设置
--operator-replicas=2，并配置 Pod Anti-Affinity 避免调度到同一节点。 - Hubble 存储规划：Hubble 流日志默认存储在内存中，建议配置持久化后端（如 S3、GCS）用于长期审计，或使用 Prometheus 抓取 Hubble 指标。
- CLI 版本匹配：确保
cilium-cli的版本与集群中 Cilium Agent 的版本一致，避免 gRPC 协议不兼容。