📚 课程目录第4章 Hubble流量数据模型

4. Hubble 流量数据模型：Flow、L4/L7 元数据、Service Map、TCP/UDP/HTTP/gRPC 协议解析

Hubble 作为 Cilium 的可观测性层，其核心价值在于将 eBPF 捕获的原始网络事件转化为结构化的、可检索的流量数据模型。理解这一数据模型是进行节点池容量规划的基础——它决定了我们能从集群网络中“看到”什么，以及如何量化流量特征。本章将深入剖析 Hubble 的四大核心数据抽象：Flow、L4/L7 元数据、Service Map 以及多协议解析机制。

4.1 核心数据单元：Flow

Flow 是 Hubble 数据模型中最基本的记录单元。每当一个网络数据包或一次连接事件被 eBPF 程序捕获，Hubble 便会将其聚合为一个 Flow 对象。一个 Flow 并非简单的数据包转储，而是包含了从 L2 到 L7 的上下文信息。

  关键理解： Flow 是对“谁在什么时间、通过什么协议、与谁通信、结果如何”的一次完整记录。在容量规划中，我们关注的是 Flow 的速率（FPS, Flows Per Second）和大小分布，而非单个数据包。

一个典型的 Flow 记录包含以下关键字段：

字段类别	具体字段	容量规划用途
身份标识	源/目的 IP、源/目的 Pod 标签、Kubernetes 命名空间、服务名	识别流量来源与目的地，用于分析 Pod 间的通信模式
时间与状态	起始时间戳、结束时间戳、Verdict（DROPPED / FORWARDED / ERROR）	计算流量持续时间与丢包率，评估网络健康度
L4 信息	协议（TCP/UDP/SCTP）、源端口、目的端口	区分连接类型，识别关键服务端口（如 443, 53）
L7 信息	HTTP 方法/路径/返回码、gRPC 状态码、DNS 域名	解析应用层协议，量化 API 调用频率与错误率
字节与包计数	总字节数、总数据包数（仅 L4 可见）	直接用于计算吞吐量（bps）和包速率（pps）

4.2 L4 与 L7 元数据：从连接到请求

Hubble 的数据模型在 L4（传输层）和 L7（应用层）之间做了清晰的划分。这种分层设计使得我们既能进行粗粒度的连接级容量评估，也能进行细粒度的请求级性能分析。

4.2.1 L4 元数据：连接的生命周期

对于 TCP 连接，Hubble 的 eBPF 程序会跟踪其完整生命周期：SYN、SYN-ACK、数据交换、FIN/RST。L4 元数据主要关注连接本身，而非连接内的具体请求。在容量规划中，L4 指标（如并发连接数、连接建立速率）是评估节点网络栈压力的关键。

连接数（Connections）： 单位时间内新建的 TCP 连接数。高连接建立速率会消耗节点 CPU 和内存（用于维护连接跟踪表）。
连接持续时间： 短连接（如 HTTP/1.0）与长连接（如 gRPC Stream）对节点资源的消耗模式不同。
重传与 RTT： 通过 eBPF 可观测 TCP 重传次数和往返时间，间接反映网络拥塞程度。

4.2.2 L7 元数据：请求的语义

当 Hubble 配置了 L7 可见性（通过 Cilium 的 L7 策略或 Hubble 的 HTTP/gRPC 过滤），它能够解析应用层协议，提取请求级别的元数据。这为容量规划提供了更精确的“业务负载”视角。

规划提示： 在节点池扩容场景中，L7 元数据比 L4 元数据更具预测性。例如，1000 QPS 的 HTTP 请求可能只复用 10 个 TCP 连接，仅看 L4 连接数会严重低估负载。

4.3 Service Map：服务依赖的可视化

Service Map 是 Hubble 基于 Flow 数据自动构建的服务级拓扑图。它不关心具体的 Pod IP，而是抽象为 Kubernetes Service 之间的通信关系。在容量规划中，Service Map 帮助我们回答：“哪些服务之间的流量最大？哪些服务是流量枢纽？”

Service Map 的数据结构本质上是一个加权有向图。节点是 Kubernetes Service，边的权重可以是 Flow 速率、字节吞吐量或请求错误率。在容量规划中，我们特别关注“扇出”和“扇入”服务：

扇出服务（Fan-out）： 一个上游服务调用多个下游服务。该服务的节点池需要更高的网络吞吐上限。
扇入服务（Fan-in）： 多个上游服务调用同一个下游服务。该服务的节点池需要更高的并发连接处理能力。

4.4 多协议解析：TCP/UDP/HTTP/gRPC

Hubble 的 eBPF 程序能够识别并解析多种网络协议。不同的协议在数据模型中的呈现方式不同，对容量规划的影响也不同。下表总结了四种核心协议的解析特征与规划关注点：

协议	Hubble 解析层级	关键元数据	容量规划关注点
TCP	L4	Flags (SYN, FIN, RST)、序列号、窗口大小	连接建立速率、并发连接数、重传率
UDP	L4	数据包长度、源/目的端口	包速率（pps）、DNS 查询量（端口 53）
HTTP/1.x & HTTP/2	L7	Method、Path、Status Code、Headers、Latency	QPS、请求大小分布、P99 延迟、错误率（4xx/5xx）
gRPC	L7	Service、Method、gRPC Status Code、Message Size	RPS、Stream 持续时间、Payload 大小、Unary vs Streaming 比例

4.4.1 HTTP/gRPC 解析的深度价值

对于微服务架构，HTTP 和 gRPC 是主要的通信协议。Hubble 的 L7 解析能力使得我们能够将网络负载直接关联到业务 API。例如，一个“查询订单”API 的 QPS 激增，会直接反映在 Hubble 的 HTTP 请求指标中，从而触发对该 API 所在节点池的扩容评估。

注意： L7 解析会带来额外的 CPU 开销。在节点池容量规划时，需要为开启 L7 可见性的节点预留约 5%-10% 的 CPU 余量用于协议解析。对于高吞吐场景（如网关节点），建议仅对关键服务开启 L7 解析。

4.5 数据模型在容量规划中的映射

理解 Hubble 的数据模型后，我们需要将其映射到节点池容量规划的量化指标上。以下是核心的映射关系：

Flow 速率 (FPS) → 节点 CPU 负载： 每个 Flow 的创建、跟踪和聚合都需要 CPU 周期。FPS 是评估 Hubble Agent 自身资源消耗的关键指标。
L4 并发连接数 → 节点内存消耗： 连接跟踪表（Conntrack）的大小直接受并发连接数影响。内存不足会导致连接跟踪表溢出，引发丢包。
L7 QPS/RPS → 业务容量阈值： 这是最直接的业务指标。当某个服务的 QPS 接近其所在节点池的承载上限时，需要扩容。
Service Map 边权重 → 网络带宽规划： 两个服务之间的总字节吞吐量决定了它们所在节点之间的网络带宽需求。

  实践建议： 在 Prometheus 中记录 Hubble 导出的 hubble_flows_processed_total、hubble_tcp_connections_total 和 hubble_http_requests_total 指标。这些指标将作为后续章节中构建容量规划模型的基础数据源。