3、Hubble架构深度解析：Hubble Server、Hubble Relay、Hubble UI、Hubble CLI的组件职责与数据流
Hubble 并非一个单体服务，而是由多个职责分明的组件构成的观测系统。理解每个组件的边界、数据流向以及它们如何协同工作，是进行后续部署调优和租户隔离策略设计的基础。本章将深入剖析 Hubble Server、Relay、UI 和 CLI 四大核心组件，并揭示其内部数据流转路径。
3.1 组件全景与职责划分
Hubble 的架构遵循“采集-聚合-存储-展示”的分层设计。Cilium Agent 内置的 Hubble Server 负责节点级数据采集，Hubble Relay 作为集群级聚合层，而 Hubble UI 和 CLI 则分别提供图形化和命令行交互界面。
| 组件 | 部署位置 | 核心职责 | 对外接口 |
|---|---|---|---|
| Hubble Server | 每个 Kubernetes 节点（与 Cilium Agent 同 Pod） | 通过 eBPF 程序捕获网络事件，维护服务映射，提供本地 gRPC 流式查询 | gRPC (unix socket / TCP) |
| Hubble Relay | 集群级独立 Deployment | 聚合所有 Hubble Server 的观测数据，实现跨节点、跨 Namespace 的全局视图，缓存与去重 | gRPC (TCP) |
| Hubble UI | 集群级独立 Deployment | 基于 Relay 提供可视化服务拓扑、流量矩阵、策略审计与实时流日志 | HTTP/WebSocket → gRPC (Relay) |
| Hubble CLI | 用户终端 / 运维容器 | 通过命令行直接连接 Server 或 Relay，执行过滤、观察、调试命令 | gRPC (TCP / Unix Socket) |
3.2 Hubble Server：节点级观测引擎
Hubble Server 是数据采集的起点，运行在每个 Kubernetes 节点的 Cilium Agent 容器内。它通过 gRPC 服务暴露本节点的观测数据，数据源完全来自内核中的 eBPF 程序和 Map。
3.2.1 核心职责
- eBPF 事件监听： 从 Cilium 加载的 eBPF 程序（如
cilium_net、cilium_lxc）中读取网络事件，包括 TCP 连接建立/关闭、DNS 请求/响应、HTTP 请求/响应、ICMP 等。 - 服务映射维护： 将内核中的 IP 地址、端口、安全标识（Identity）实时映射为 Kubernetes 资源（Pod、Service、Namespace、Label）。
- 本地流式查询： 提供
GetFlowsgRPC 接口，支持基于时间戳、IP、Label、Verdict（ALLOW/DENIED）等过滤条件的流式推送。 - 指标暴露： 通过 Prometheus 格式暴露节点级观测指标，如
hubble_flows_processed_total、hubble_tcp_dropped_total。
3.2.2 数据流起点
// Hubble Server 内部简化数据流
eBPF Perf Event Ring Buffer
↓ (内核态 → 用户态)
Cilium Agent (Go 用户态程序)
↓ (事件解析、Identity 解析)
Hubble Server gRPC Service
↓ (流式响应)
gRPC Client (Relay / CLI / UI Backend)3.3 Hubble Relay：集群级聚合与缓存层
Hubble Relay 是 Hubble 架构中实现“全局视野”的关键组件。它作为一个无状态聚合层，连接所有 Hubble Server，并为上层客户端提供统一的查询入口。
3.3.1 核心职责
- 节点发现与连接管理： 通过 Kubernetes API 自动发现所有运行 Cilium Agent 的节点，并建立与对应 Hubble Server 的 gRPC 长连接。
- 请求扇出与结果合并： 将来自 UI/CLI 的查询请求扇出到所有相关的 Hubble Server，并将返回的流式结果按时间戳排序、去重、合并后返回给客户端。
- 缓存与去重： 维护一个有限大小的环形缓冲区，缓存最近的事件流，用于处理重复连接或断线重连时的数据补偿。
- 多集群支持： 支持配置多个上游 Relay，实现跨集群的联邦观测。
3.3.2 数据流聚合模式
Hubble UI / Hubble CLI
↓ (单个 gRPC 请求)
Hubble Relay (聚合层)
├──→ Hubble Server (Node-1)
├──→ Hubble Server (Node-2)
└──→ Hubble Server (Node-N)
↓ (合并、排序、去重)
聚合后的流式响应 → 返回给客户端--hubble-grpc-address 连接池和请求超时控制，避免单个慢节点拖慢全局查询。
3.4 Hubble UI：可视化拓扑与流量洞察
Hubble UI 是一个基于 React 的前端应用，后端通过 gRPC 连接 Hubble Relay。它提供了服务依赖图、TCP 流量矩阵、策略审计日志等核心视图，是运维人员理解租户隔离策略效果的主要界面。
3.4.1 核心视图与数据源
| 视图 | 数据源 | 用途 |
|---|---|---|
| 服务拓扑图 | Relay 的 GetFlows + GetNodes |
展示服务间通信关系、流量方向、策略允许/拒绝状态 |
| TCP 流量矩阵 | Relay 的 GetFlows (聚合统计) |
展示 Namespace/Identity 级别的流量吞吐、连接数、丢包率 |
| 策略审计日志 | Relay 的 GetFlows (Verdict=DENIED) |
展示被网络策略拒绝的流量，用于调试租户隔离规则 |
| 实时流日志 | Relay 的 GetFlows (流式) |
实时滚动显示经过过滤条件的网络事件 |
3.5 Hubble CLI：命令行观测利器
Hubble CLI 是运维人员进行快速诊断和自动化脚本的首选工具。它可以直接连接本地的 Hubble Server（通过 Unix Socket）或集群级的 Hubble Relay（通过 TCP）。
3.5.1 常用命令与连接模式
# 1. 直接连接本地节点 Hubble Server (Unix Socket)
hubble observe --server unix:///var/run/cilium/hubble.sock \
--namespace tenant-a --verdict DROPPED
# 2. 通过 Hubble Relay 查询集群全局视图
hubble observe --server hubble-relay.kube-system.svc.cluster.local:4245 \
--label "k8s:app=frontend" --last 100
# 3. 查看服务依赖图 (JSON 格式)
hubble status --server hubble-relay:4245
# 4. 实时监控特定流
hubble observe --server hubble-relay:4245 \
--from-pod default/my-client --to-namespace tenant-b \
--follow3.6 端到端数据流与组件交互
下图展示了从 eBPF 事件捕获到用户界面展示的完整数据流路径，以及各组件之间的通信协议。
3.7 组件间通信协议与端口
理解各组件之间的通信协议和默认端口，对于部署网络策略和防火墙规则至关重要。
| 通信方向 | 协议 | 默认端口 | 认证方式 |
|---|---|---|---|
| Hubble Server → Cilium Agent | 内部进程通信 | Unix Socket | 本地文件权限 |
| Relay → Hubble Server | gRPC (TLS 可选) | 4244 (Server) | mTLS / 令牌 |
| UI → Relay | gRPC (WebSocket 转换) | 4245 (Relay) | 会话令牌 |
| CLI → Relay | gRPC (TLS 可选) | 4245 (Relay) | mTLS / 令牌 |
| CLI → Server (本地) | gRPC (明文) | Unix Socket | 本地文件权限 |
3.8 组件部署拓扑与高可用考虑
在生产环境中，Hubble 组件的部署拓扑直接影响观测数据的可靠性和查询性能。下图展示了推荐的高可用部署模式。