4. Hubble Server 与 Relay：数据采集、聚合转发与 gRPC 通信
在 Hubble 的架构中，Hubble Server 与 Hubble Relay 构成了数据面与控制面的核心枢纽。Server 负责从 eBPF 数据源采集流日志与指标，Relay 则负责将分散的 Server 数据聚合、缓存并转发给外部消费者（如 UI、CLI、告警系统）。两者通过 gRPC 协议实现高效、双向的流式通信。
4.1 Hubble Server：节点级数据采集
Hubble Server 是一个运行在每个 Kubernetes 节点上的守护进程（通常以 DaemonSet 部署），直接对接节点内的 Cilium eBPF 程序。它通过 Unix Domain Socket 或本地 TCP 端口暴露 gRPC 服务，供同节点的 Hubble Relay 或 CLI 工具访问。
| 组件 | 职责 | 数据来源 | 输出接口 |
|---|---|---|---|
| Hubble Server | 节点级流日志采集、L3/L4/L7 元数据解析、指标暴露 | Cilium eBPF Map、perf_event 环形缓冲区 | gRPC Observer / Recorder 服务 |
| eBPF 数据源 | 内核态捕获网络包、跟踪 TCP/UDP/HTTP/DNS 事件 | TC 钩子、XDP 钩子、Socket 追踪 | perf_event 或 BPF Map 共享内存 |
关键采集流程： eBPF 程序在钩子点生成事件 → 写入 perf_event 环形缓冲区 → Hubble Server 用户态轮询读取 → 解析为 Flow 结构体 → 通过 gRPC 流推送。
4.2 Hubble Relay：聚合、缓存与转发
Hubble Relay 是一个中心化组件（通常部署 1~2 个副本），负责从所有 Hubble Server 拉取流数据，执行去重、排序、聚合，并提供统一的查询接口。Relay 的存在使得上层消费者无需感知节点拓扑变化。
- 聚合策略： 按时间窗口（默认 1s）合并来自不同 Server 的相同 Flow，消除重复。
- 缓存机制： 内存中维护一个环形缓冲区（默认 1h 窗口），支持历史回溯查询。
- 转发目标： Hubble UI、
hubble observeCLI、Prometheus Metrics、外部告警 Webhook。
生产建议： Relay 的内存消耗与节点数、流速率正相关。建议为 Relay 配置 2~4 CPU 和 4~8 GB 内存，并启用
--flow-buffer-size 参数限制最大缓存流数。
4.3 gRPC 通信机制
Hubble 的整个数据管道基于 gRPC 双向流（Bidirectional Streaming）构建。Server 与 Relay 之间、Relay 与 UI 之间均使用 Protocol Buffers 定义的 Observer 服务。
| gRPC 服务 | 方法 | 方向 | 用途 |
|---|---|---|---|
Observer |
GetFlows |
Server → Relay (流式) | 实时推送流日志 |
Observer |
GetAgentEvents |
Server → Relay (流式) | 推送 Agent 状态变更事件 |
Observer |
GetNodes |
Relay → 消费者 (Unary) | 查询节点列表 |
Recorder |
Record |
消费者 → Server (控制) | 启动/停止 pcap 抓包 |
注意： gRPC 连接默认使用 TLS 加密。在非生产环境可通过
--tls=false 禁用，但生产环境必须配置证书，防止流数据被中间人窃听。
4.4 架构总览：Server ↔ Relay 数据流
下图展示了从 eBPF 内核事件到 Hubble Relay 聚合输出的完整数据路径：
4.5 关键配置参数
以下为 Hubble Server 与 Relay 在生产环境中的常用配置项：
| 组件 | 参数 | 默认值 | 说明 |
|---|---|---|---|
| Server | --listen-grpc |
unix:///var/run/hubble.sock |
gRPC 监听地址，建议使用 Unix Socket 减少开销 |
| Server | --max-flows |
4095 |
节点级最大缓存流数，超出后丢弃旧流 |
| Relay | --server |
k8s:// |
自动发现所有 Hubble Server 端点 |
| Relay | --flow-buffer-size |
100000 |
全局流缓冲区大小，影响历史查询深度 |
| Relay | --sort-buffer-len |
100 |
排序窗口长度，越大排序越精确但延迟增加 |
性能基准： 在 100 节点集群中，每个 Server 处理约 5000 flows/s，Relay 聚合后输出约 3000 flows/s（去重后）。gRPC 单连接吞吐可达 200 Mbps，CPU 占用 < 0.5 核。
4.6 故障排查与告警联动
当 Relay 与 Server 之间的 gRPC 连接中断时，Hubble 提供以下检测与恢复机制：
- 健康检查： Relay 定期向每个 Server 发送
GetNodesUnary 请求，超时 5s 标记节点为不可用。 - 自动重连： gRPC 客户端内置指数退避重试（初始 1s，最大 30s）。
- 告警指标： Prometheus 指标
hubble_relay_connections_failed_total和hubble_server_flows_dropped_total可直接对接告警引擎。
联动示例： 当
hubble_relay_connections_failed_total 在 5 分钟内持续 > 0，触发告警 → 自动拉起诊断 Job → 收集 Server 日志与 gRPC 连接状态 → 输出故障分析报告。