4. Hubble 架构深度解析：Hubble Relay、Hubble UI、Hubble CLI 组件交互与数据流

Hubble 是 Cilium 原生的可观测性层，基于 eBPF 实现无侵入的流量捕获与策略审计。其架构由三个核心组件构成：Hubble Relay、Hubble UI 和 Hubble CLI。理解这三者的角色、交互方式以及数据流转路径，是进行故障排查和自动化回滚的基础。

4.1 核心组件角色与职责

下表总结了三个组件在 Hubble 生态中的定位与关键职责：

4.2 组件交互与数据流架构

下图展示了 Hubble 组件之间的通信路径与数据流向：

4.3 数据流详细路径

Hubble 的数据流遵循“采集 → 聚合 → 消费”的三层模型。以下是每个阶段的详细说明：

1. 采集层（Cilium Agent）
   • 每个 Kubernetes 节点上的 Cilium Agent 通过 eBPF 程序挂载到网络钩子（XDP、TC、cgroup）捕获数据包。
   • eBPF Map 存储流元数据（五元组、标签、Verdict、TCP 标志等）。
   • Hubble 嵌入式服务定期从 eBPF Map 读取数据，封装为 gRPC 流（Flow 消息）。
   • Agent 本地 gRPC 端点监听 :4244，支持直接连接调试。
2. 聚合层（Hubble Relay）
   • Relay 通过 --relay-agent-address 发现所有 Agent，建立双向 gRPC 流。
   • Relay 维护全局服务缓存（ServiceCache），将 Pod IP 映射到 Kubernetes Service。
   • Relay 对来自多个 Agent 的流进行去重、排序、合并，提供一致的时间序视图。
   • Relay 自身暴露 gRPC 端点 :4245，支持过滤、分页、跟随（Follow）模式。
3. 消费层（UI / CLI）
   • Hubble UI：通过 gRPC 查询 Relay 获取流数据，渲染为服务拓扑图、流量列表、策略审计日志。UI 后端（Go）将 gRPC 响应转换为 JSON API，前端（React）负责可视化。
   • Hubble CLI：直接调用 Relay 的 gRPC 接口，支持 hubble observe（实时流）、hubble status（节点健康）、hubble metrics（Prometheus 指标导出）。

4.4 关键交互协议：gRPC 流

Hubble 组件间通信全部基于 gRPC，使用 Protocol Buffers 定义消息格式。核心的 RPC 定义如下：

// 定义在 hubble.proto 中的关键 RPC
service Observer {
  // 获取流列表（支持过滤、分页、排序）
  rpc GetFlows(GetFlowsRequest) returns (stream GetFlowsResponse);

  // 获取 Agent 状态
  rpc GetAgentEvents(GetAgentEventsRequest) returns (stream GetAgentEventsResponse);

  // 获取调试事件
  rpc GetDebugEvents(GetDebugEventsRequest) returns (stream GetDebugEventsResponse);

  // 获取节点状态
  rpc GetNodes(GetNodesRequest) returns (GetNodesResponse);

  // 获取服务映射
  rpc GetNamespaces(GetNamespacesRequest) returns (GetNamespacesResponse);
}

4.5 组件交互的故障模式

下表列出了组件交互中常见的故障模式及其影响：

4.6 架构设计要点总结

• 无状态消费：UI 和 CLI 不直接连接 eBPF，所有数据通过 Relay 聚合，消费端无状态，便于水平扩展。
• gRPC 双向流：Agent 到 Relay 使用 gRPC 流推送，Relay 到消费者也使用流，实现低延迟实时观测。
• 服务发现解耦：Relay 通过 Kubernetes API 动态发现 Agent，无需静态配置，适应集群扩缩容。
• 故障隔离：单个 Agent 故障不影响其他节点数据，Relay 会标记该节点为 Unreachable 并继续服务。