3. Hubble 架构解析：Hubble Server、Hubble Relay、Hubble CLI 的数据流与组件交互
在 Cilium 集群中，Hubble 是构建在 eBPF 之上的可观测性层。它通过捕获节点上的网络流量与策略事件，提供细粒度的流量流向图、L3/L4/L7 可观测性以及安全事件审计能力。理解 Hubble 的组件架构与数据流，是进行节点池流量基线巡检的前提。
3.1 核心组件与职责
Hubble 由三个主要组件构成，它们各自运行在不同的进程上下文中，通过 gRPC 协议进行通信：
| 组件 | 部署位置 | 核心职责 | 数据来源 |
|---|---|---|---|
| Hubble Server | 每个 Cilium Agent 节点（DaemonSet） | 从本地 Cilium Agent 的 eBPF Map 中读取流事件；提供本地 gRPC 服务 | 本地 eBPF Map（conntrack、policy、endpoint） |
| Hubble Relay | 集群级 Deployment（通常 1-2 副本） | 聚合所有 Hubble Server 的流数据；提供全局查询视图；缓存与去重 | 所有节点的 Hubble Server gRPC 流 |
| Hubble CLI | 用户终端 / CI/CD 环境 | 向 Hubble Relay 或直接向 Hubble Server 发起查询；输出 JSON/文本/流式数据 | Hubble Relay 或 Hubble Server 的 gRPC 端点 |
关键认知： Hubble Server 是“数据生产者”，Hubble Relay 是“数据聚合器”，Hubble CLI 是“数据消费者”。在节点池巡检场景中，Hubble Relay 提供了跨节点的统一流量视图，是流量基线对比的核心入口。
3.2 组件交互与数据流路径
下图展示了 Hubble 三个组件之间的数据流关系，以及它们与 Cilium Agent、eBPF 内核层的交互方式：
数据流要点：
- 节点内路径： eBPF Map → Cilium Agent 事件管道 → Hubble Server（Unix Socket）→ gRPC 流
- 集群路径： 各节点 Hubble Server → Hubble Relay（gRPC 双向流）→ Hubble CLI / 外部系统
- 巡检场景： Hubble CLI 通过
--server参数指向 Hubble Relay 的 Service IP（通常为hubble-relay.kube-system.svc.cluster.local:4245），获取全局流量基线
3.3 Hubble Server：节点级数据生产者
Hubble Server 是每个节点上的核心数据源。它不直接读取 eBPF Map，而是通过 Cilium Agent 的 事件监听器（Event Listener） 获取流数据：
# Hubble Server 启动参数示例（实际由 Cilium Agent 自动管理）
hubble-server \
--listen-address :4244 \
--unix-socket /var/run/cilium/hubble.sock \
--metrics-server :9091| 特性 | 说明 |
|---|---|
| 数据来源 | Cilium Agent 内部事件管道（基于 eBPF perf_event_output） |
| 暴露接口 | gRPC 服务（TCP :4244）+ Unix Domain Socket（本地调试） |
| 数据范围 | 仅限本节点上的 endpoint 流量与策略事件 |
| 缓存策略 | 环形缓冲区（Ring Buffer），默认保留最近 1GB 或 5 分钟数据 |
| 关键指标 | hubble_flows_processed_total、hubble_ring_buffer_size |
节点池巡检注意： 当节点池中的某个节点发生升级时，该节点上的 Hubble Server 会随 Cilium Agent 一起重启。重启期间（通常 10-30 秒），该节点的流数据会中断。Hubble Relay 会自动处理这种断连，并在节点恢复后重新建立 gRPC 流。巡检脚本需要关注
hubble_relay_peer_status 指标，确认所有节点都已重新连入 Relay。
3.4 Hubble Relay：集群级数据聚合器
Hubble Relay 是集群可观测性的“大脑”。它维护一个 节点列表，与每个节点的 Hubble Server 建立 gRPC 双向流，并将所有流数据合并为一个统一的查询接口：
# Hubble Relay 启动参数示例
hubble-relay \
--listen-address :4245 \
--dial-targets k8s://cilium:4244 \
--cluster-name my-cluster \
--sort-buffer-duration 5s \
--sort-buffer-limit 10000| 功能 | 实现方式 | 巡检场景价值 |
|---|---|---|
| 节点发现 | 通过 Kubernetes API 监听 Cilium Agent Pod 变化 | 自动感知节点池扩缩容与升级导致的 Agent 重启 |
| 流聚合 | 多路 gRPC 流合并，按时间戳排序 | 提供跨节点的统一流量视图，无需逐个节点查询 |
| 去重 | 基于 Flow ID 与时间戳的滑动窗口去重 | 避免节点间重复流（如 Service 转发场景）干扰基线计算 |
| 缓存 | 内存中维护最近流数据的排序缓冲区 | 支持 --last 参数快速获取最近 N 条流 |
| 健康检查 | gRPC 健康探测 + 节点状态指标 | hubble_relay_peer_status{status="connected"} 确认节点池完整性 |
3.5 Hubble CLI：查询与数据消费
Hubble CLI 是运维人员与自动化巡检脚本的主要交互工具。它支持两种连接模式：
- Relay 模式（推荐）：
hubble observe --server hubble-relay:4245，获取全局流量视图 - Server 模式（调试）：
hubble observe --server node-ip:4244，获取单节点流量视图
# 巡检场景常用命令示例
# 1. 查看最近 100 条流（JSON 格式，便于程序解析）
hubble observe --server hubble-relay:4245 --last 100 -o json
# 2. 按节点过滤（升级节点池巡检）
hubble observe --server hubble-relay:4245 \
--node-pool upgraded-pool \
--since 5m -o json
# 3. 查看流量速率（基线对比）
hubble observe --server hubble-relay:4245 \
--since 1m --verdict DROPPED \
--output flows-json | jq 'length'
巡检脚本最佳实践： 在节点池升级前后，使用 Hubble CLI 的
--since 参数固定时间窗口（如 5 分钟），分别导出 JSON 格式的流量数据。通过对比 source.ip、destination.ip、verdict、l4.policy 等字段的分布，可以快速发现升级导致的流量异常。
3.6 组件交互总结
下表总结了三个组件在节点池升级巡检中的角色与数据流方向：
| 组件 | 巡检角色 | 数据流方向 | 关键端口 | 故障影响 |
|---|---|---|---|---|
| Hubble Server | 节点级数据源 | eBPF → Agent → Server → Relay | TCP 4244 | 单节点流数据缺失 |
| Hubble Relay | 全局聚合与缓存 | Server → Relay → CLI | TCP 4245 | 全局查询不可用 |
| Hubble CLI | 数据消费与基线导出 | CLI → Relay / Server | 客户端端口 | 巡检脚本无法获取数据 |