3. Cilium 与 Hubble 架构：核心组件详解

Cilium 基于 eBPF 实现 Kubernetes 网络、安全与可观测性，而 Hubble 则在其之上构建了分布式流量与策略可视化层。理解 Cilium Agent、Cilium Operator、Hubble Relay 与 Hubble UI 这四大组件的职责与协作关系，是进行节点池容量规划的前提。

3.1 组件总览与职责划分

下表从部署位置、核心功能与数据流角度，对四个组件进行对比：

3.2 Cilium Agent：eBPF 的执行者

Cilium Agent 是运行在每个 Kubernetes 节点上的 DaemonSet，是唯一直接与 eBPF 子系统交互的组件。其内部包含多个关键子系统：

• eBPF 程序管理器：负责将 Cilium 生成的 BPF 程序（如 bpf_lxc.c、bpf_overlay.c）加载到内核的 cgroup/tc/XDP 挂载点。
• Endpoint 管理器：维护节点上所有 Pod 的标识（Endpoint ID）、安全标签与网络策略映射。
• Service 转发引擎：基于 eBPF 实现 kube-proxy 替代，处理 ClusterIP、NodePort、ExternalIP 等流量转发。
• Hubble 观测模块：在内核 eBPF 数据路径中插入观测点，捕获 TCP/UDP 流元数据，并通过 gRPC 暴露给 Hubble Relay。

# 查看节点上 Cilium Agent 的 Hubble 观测状态
cilium status --verbose
# 输出示例中会包含 "Hubble: Ok" 以及当前缓存的流数量

3.3 Cilium Operator：集群级协调者

Operator 负责全局状态管理，不直接参与数据平面转发。其核心功能包括：

• IPAM（IP 地址管理）：从集群 CIDR 中分配 Pod IP，支持 CRD-backed、Kuberenetes HostScope 等多种模式。
• 多集群 Service 同步：在 Cluster Mesh 场景下，跨集群同步 Service 与 Endpoint。
• 策略状态管理：监控 CiliumNetworkPolicy 资源，确保策略在 Agent 间一致生效。

3.4 Hubble Relay：全局流量聚合层

Hubble Relay 是 Hubble 架构中的“中枢神经”。它通过 gRPC 流从所有 Cilium Agent 拉取观测数据，去重、排序后提供统一的查询接口。其关键设计包括：

• 无状态聚合：Relay 本身不持久化数据，所有流数据缓存在内存中，重启后需重新从 Agent 拉取。
• 时间戳对齐：对来自不同 Agent 的流事件进行时间戳排序，保证全局视图的一致性。
• 过滤与分页：支持基于 Pod 标签、IP、协议、端口等条件的实时过滤，避免全量数据传输。

# 通过 hubble CLI 查询过去 5 分钟内的 HTTP 流量
hubble observe --since 5m --protocol http --output json

3.5 Hubble UI：可视化交互界面

Hubble UI 提供基于 Web 的服务依赖图（Service Map）与流量策略可视化。它通过 Hubble Relay 的 API 获取数据，不直接连接 Agent。主要功能：

• 服务依赖图：动态展示集群内 Service 之间的流量流向、速率与延迟。
• 策略可视化：将 CiliumNetworkPolicy 规则叠加在流量图上，直观显示允许/拒绝的通信路径。
• 实时过滤：支持按命名空间、标签、IP 等维度过滤流量视图。

3.6 组件协作架构图

下图展示了四个组件在 Kubernetes 集群中的部署位置与数据流关系：

3.7 组件间通信协议与端口

了解组件间的通信方式有助于规划网络策略与资源隔离：