3. Hubble 架构深度解析：组件架构、数据流与通信机制
Hubble 是 Cilium 原生的网络观测层，基于 eBPF 实时捕获内核数据路径事件。其架构采用无状态采集 + 有状态中继 + 可视化的分层设计，核心组件包括 hubble-relay、hubble-ui 和 hubble-observability。理解各组件职责及数据流是进行资源配额校准与容量预测的前提。
3.1 核心组件架构
Hubble 组件以微服务形式部署在 Kubernetes 集群中，通常与 Cilium Agent 同节点运行。下表列出各组件的定位与关键特性：
| 组件 | 部署模式 | 核心职责 | 数据接口 |
|---|---|---|---|
| hubble-relay | 独立 Deployment（无状态） | 聚合所有 Cilium Agent 的 gRPC 流，提供全局统一查询视图 | gRPC Server（Peer / Observer API） |
| hubble-ui | 独立 Deployment（无状态） | Web 可视化面板，展示服务拓扑、流量矩阵、实时流日志 | HTTP → hubble-relay gRPC（通过 grpc-web 或 envoy） |
| hubble-observability | DaemonSet（与 Cilium Agent 同节点） | 采集 eBPF 事件、生成 metrics 和流日志，暴露本地 gRPC 端点 | 本地 Unix Socket / TCP gRPC |
架构要点：hubble-observability 是 eBPF 数据的第一跳消费者，hubble-relay 是集群级聚合层，hubble-ui 是用户交互入口。三者形成“采集 → 聚合 → 展示”的流水线。
3.2 组件通信机制与数据流
Hubble 的数据流从内核 eBPF 程序开始，经过用户态代理、中继，最终到达 UI 或 Prometheus。下图展示完整的端到端通信路径：
3.3 关键通信协议与端口
Hubble 组件间通信全部基于 gRPC，使用 Protocol Buffers 序列化。核心 API 包括：
- Peer API：hubble-observability 向 hubble-relay 注册自身，告知可观测的节点和端点信息。
- Observer API：hubble-relay 向 hubble-observability 请求流日志，支持过滤、分页、跟随模式。
- gRPC-web / Envoy：hubble-ui 通过 HTTP 代理将浏览器请求转换为 gRPC 调用。
| 通信对 | 协议 | 默认端口 | 传输方向 |
|---|---|---|---|
| hubble-observability → Cilium Agent | Unix Socket / 本地 IPC | N/A | 双向 |
| hubble-observability → hubble-relay | gRPC (TLS 可选) | 4244 | Server → Client 流 |
| hubble-relay → hubble-ui | gRPC-web / HTTP | 4245 | 双向流 |
| hubble-observability → Prometheus | HTTP / Metrics | 9962 | 拉取 |
3.4 数据流关键路径
一次完整的 Hubble 流日志从产生到展示经历以下步骤：
- eBPF 捕获：内核 eBPF 程序在
connect、accept、sendmsg、recvmsg等 hook 点捕获网络事件，写入 Perf Ring Buffer。 - 用户态轮询：hubble-observability 通过
bpf_perf_event_read轮询 Ring Buffer，解析原始事件为结构化 Flow 对象。 - 本地缓存与去重：hubble-observability 维护本地 Flow 缓存（默认 1 分钟），合并重复事件，附加 Kubernetes 元数据（Pod、Service、Identity）。
- gRPC 推送：hubble-relay 通过 Observer API 从每个节点的 hubble-observability 拉取 Flow 流，执行全局排序与去重。
- UI 渲染：hubble-ui 订阅 hubble-relay 的聚合流，在前端渲染服务拓扑、流量矩阵和实时日志。
容量规划关注点：hubble-relay 是全局瓶颈点。每个节点的 hubble-observability 推送速率受 eBPF 事件密度影响，relay 需要足够的 CPU 和内存处理排序与去重。建议在压测沙盘中监控 relay 的 gRPC 流数量、内存占用和排序延迟。
3.5 组件间依赖与容错
Hubble 架构设计遵循无状态 + 最终一致原则，组件间依赖关系如下：
- hubble-ui 强依赖 hubble-relay：relay 不可用时 UI 无法展示数据，但历史数据不受影响。
- hubble-relay 弱依赖 hubble-observability：部分节点采集失败不影响全局视图，relay 会标记缺失节点。
- hubble-observability 强依赖 Cilium Agent：Agent 重启会导致短暂数据中断，但 eBPF 程序在内核中持续运行，数据不丢失。
下表总结组件故障的影响范围：
| 故障组件 | 影响范围 | 恢复方式 |
|---|---|---|
| hubble-observability (单节点) | 丢失该节点流日志 | DaemonSet 自动重启 |
| hubble-relay | UI 和 CLI 无法查询 | K8s Deployment 滚动更新 |
| hubble-ui | Web 界面不可用 | K8s Deployment 自动恢复 |
| Cilium Agent | 该节点 eBPF 事件中断 | Agent 重建后自动恢复 |
压测沙盘注意事项：在资源配额校准场景中，hubble-relay 的内存使用量与集群节点数、每秒流日志数成正比。建议在沙盘中设置 relay 的
--sort-buffer-len-ms 和 --sort-buffer-drain-ms 参数，观察不同负载下的资源消耗曲线。