4. Hubble 事件流核心：Server 与 Relay 架构，gRPC 流式传输与 Flow 对象

Hubble 是 Cilium 的可观测性层，负责采集、存储和转发网络流事件。在生产环境中，运维人员通过 Hubble 还原容器网络的通信时间线，定位故障根因。本章深入 Hubble 的两大核心组件——Hubble Server 与 Hubble Relay，解析 gRPC 流式事件传输机制，并完整拆解 Flow 对象 的数据结构。

4.1 Hubble 整体架构：Server 与 Relay 的分工

Hubble 采用 Agent + Server + Relay 三层架构。Cilium Agent 内嵌 Hubble 模块，在每个节点上采集 eBPF 事件；Hubble Server 作为本地事件出口；Hubble Relay 作为集群级聚合查询层。

4.2 gRPC 流式事件传输机制

Hubble 使用 gRPC 双向流 实现事件传输。Relay 作为 gRPC 客户端，向每个节点的 Hubble Server 发起 GetFlows 或 GetAgentEvents 请求，Server 端持续推送事件流。

4.3 Flow 对象数据结构

Flow 是 Hubble 中最核心的数据模型，记录一次完整的网络通信事件。每个 Flow 对象包含时间戳、五元组、L4/L7 信息、策略 verdict 等字段。以下为关键字段结构：

4.4 L4 与 L7 信息详解

Flow 对象中的 l4 和 l7 字段采用 protobuf oneof 联合体设计，根据实际协议类型填充对应子字段。

4.4.1 L4 层信息

• TCP：源端口、目的端口、TCP 标志位（SYN/ACK/FIN/RST）、序列号
• UDP：源端口、目的端口
• SCTP：源端口、目的端口、chunk 类型
• ICMPv4 / ICMPv6：类型、代码

4.4.2 L7 层信息

4.5 时间戳与事件排序

Flow 对象中的 time 字段使用 protobuf Timestamp 类型，精度为纳秒。Relay 在聚合多节点事件时，按照时间戳进行全局排序，确保事件流的时间线一致性。

// Flow 时间戳示例 (protobuf 定义)
message Flow {
  google.protobuf.Timestamp time = 1;
  // ...
}

// 实际 JSON 输出
{
  "time": "2025-03-15T10:30:45.123456789Z",
  "verdict": "FORWARDED",
  "IP": {
    "source": "10.0.1.5",
    "destination": "10.0.2.10"
  },
  "l4": {
    "TCP": {
      "source_port": 34567,
      "destination_port": 8080
    }
  },
  "l7": {
    "http": {
      "method": "POST",
      "path": "/order",
      "code": 201
    }
  }
}

4.6 事件流还原实战场景

在蓝绿发布故障时间线还原中，Hubble 事件流提供以下关键能力：

• 时间线重建：通过 Flow 的纳秒时间戳，精确还原每个请求的到达、处理、响应时间
• 路径追踪：源/目的 Endpoint 信息结合 Kubernetes 标签，定位故障 Pod
• 策略审计：Verdict 字段标记 DROPPED 的事件，快速识别网络策略拦截
• L7 故障分析：HTTP 500 / gRPC 错误码 / DNS 解析失败等应用层异常