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

4、Hubble流量数据模型：Flow、L4/L7元数据、Service Map、Endpoint与Identity

Hubble 作为 Cilium 的分布式观测层，其核心价值在于将 eBPF 采集的原始网络事件转化为结构化的、可检索的流量数据模型。理解这个数据模型是进行节点池巡检和通信链路分析的基础。本章将深入剖析 Hubble 的五大核心数据实体：Flow、L4/L7 元数据、Service Map、Endpoint 与 Identity。

4.1 核心数据实体总览

Hubble 的数据模型围绕网络流量的生命周期设计，从底层的原始包事件到上层的服务依赖关系，层层抽象。下表总结了各实体的角色与数据来源：

数据实体	抽象层级	核心作用	主要数据来源
Flow	L3/L4 网络层	记录一次单向网络连接的五元组及事件类型	eBPF 的 `__sk_buff` / `connect` / `sendmsg` 探针
L4/L7 元数据	传输层/应用层	解析协议细节，如 HTTP 方法、gRPC 状态码、TCP 标志位	eBPF 的 `sockops` / `kprobe` / 用户态代理解析
Service Map	服务依赖层	展示服务间的实时连接拓扑与健康状态	基于 Flow 聚合 + Kubernetes Service 元数据
Endpoint	工作负载层	标识 Pod、容器或节点的网络端点	Cilium Agent 本地 Endpoint 列表
Identity	安全标识层	为端点分配安全标签，用于策略匹配	Cilium 安全标识 (Security Identity)

4.2 Flow：流量事件的基本单元

Flow 是 Hubble 数据模型中最基础的原子事件。每当 eBPF 程序在内核态捕获到一个网络事件（如连接建立、数据包发送、连接关闭），Hubble Agent 就会将其封装为一个 Flow 对象。一个典型的 Flow 包含以下关键字段：

时间戳 (Time)：事件发生的纳秒级时间。
五元组 (Tuple)：源/目的 IP、源/目的端口、传输层协议 (TCP/UDP)。
事件类型 (Type)：如 L3_L4、L7、END、DROP。
判决 (Verdict)：FORWARDED、DROPPED、ERROR。
节点信息 (Node)：捕获该事件的 Cilium 节点名称。
关联的 Endpoint 与 Identity：源和目的端点的 ID 及安全标识。

  巡检要点： 在节点池巡检中，重点关注 Verdict = DROPPED 的 Flow。通过分析 DROP 原因（如策略拒绝、无路由、STP 过滤），可以快速定位网络策略冲突或节点间连通性问题。

4.3 L4/L7 元数据：深入协议细节

仅靠五元组无法诊断应用层问题。Hubble 通过 eBPF 探针或用户态代理，能够解析 L4 和 L7 协议的详细元数据，为巡检提供更深层次的可见性。

4.3.1 L4 元数据

主要针对 TCP 协议，提供连接状态和标志位信息：

TCP 标志位：SYN、SYN-ACK、FIN、RST 等。
序列号与确认号：用于追踪 TCP 流状态。
窗口大小：反映接收端缓冲区压力。

4.3.2 L7 元数据

Hubble 支持多种应用层协议的解析，包括 HTTP/1.x、HTTP/2、gRPC、Kafka 和 DNS。解析后的元数据直接附加在 Flow 上：

协议	解析出的关键元数据	巡检应用场景
HTTP	Method, URL, Status Code, Headers	分析 API 调用成功率、延迟分布
gRPC	Service, Method, Status Code (gRPC)	诊断微服务间 RPC 调用失败原因
DNS	Query, Response IPs, RCode	排查服务发现异常、DNS 解析延迟
Kafka	Topic, , Error Code	监控消息队列的生产消费状态

# 示例：通过 hubble observe 查看包含 L7 HTTP 元数据的 Flow
# 输出中会包含 http.method、http.url、http.status 等字段
hubble observe --from-pod default/my-app-xxxx --to-pod default/backend-yyyy --protocol http

4.4 Service Map：服务依赖拓扑

Service Map 不是一个新的数据实体，而是基于 Flow 数据实时聚合出的服务依赖关系图。它通过分析 Flow 中的源/目的 Identity 和 Kubernetes Service 标签，自动绘制出服务间的通信拓扑。

节点 (Node)：代表一个 Kubernetes Service 或一组具有相同标签的 Pod。
边 (Edge)：代表两个服务之间的通信流量，边上会聚合出 QPS、延迟、错误率等指标。
健康状态：通过边的颜色（绿/黄/红）直观展示通信是否健康。

巡检技巧： 在节点池巡检中，如果发现某个节点池内的 Pod 无法访问外部 Service，可以查看 Service Map 中该 Pod 对应的节点是否与目标 Service 之间存在边。如果边缺失，说明流量可能被网络策略阻断或路由不可达。

4.5 Endpoint 与 Identity：流量归属与安全上下文

在 Kubernetes 环境中，仅凭 IP 地址无法确定流量的归属。Hubble 通过 Endpoint 和 Identity 两个实体，将网络流量与工作负载和安全策略关联起来。

4.5.1 Endpoint

Endpoint 是 Cilium 管理的网络端点，通常对应一个 Pod 或容器。每个 Endpoint 拥有一个唯一的数字 ID，并关联以下信息：

Kubernetes 元数据：Pod 名称、命名空间、标签、Service 归属。
网络状态：MAC 地址、IP 地址、安全标识 ID。
策略状态：当前生效的入站/出站策略列表。

4.5.2 Identity

Identity 是 Cilium 安全模型的核心。它基于 Endpoint 的 Kubernetes 标签派生出一个 24 位的安全标识。这个标识被用于：

网络策略匹配：在 eBPF 程序中，直接比较源/目的 Identity 来决定是否放行流量，无需进行复杂的标签匹配。
流量可视化：在 Hubble Flow 中，Identity 字段替代了原始的 IP 地址，使得流量可以按“应用角色”进行聚合分析。

常见巡检误区： 不要仅依赖 IP 地址进行流量分析。在动态的 Kubernetes 环境中，Pod 重建会导致 IP 变化。始终使用 Identity 或 Endpoint 标签 来追踪服务间的通信关系，这样才能保证巡检结果的准确性和可复现性。

4.6 数据模型在节点池巡检中的应用

理解上述数据模型后，在节点池巡检中可以执行以下操作：

按 Identity 过滤异常流量：使用 hubble observe --identity 12345 查看特定安全标识的所有流量，快速定位被策略影响的 Pod 组。
分析 L7 错误率：通过 Hubble Metrics 或 hubble observe --verdict DROPPED --protocol http 统计节点池内所有 HTTP 请求的 5xx 错误分布。
验证 Service Map 拓扑：对比 Service Map 中的服务依赖关系与实际的业务架构图，发现非预期的通信路径（如跨节点池的流量绕行）。
关联 Endpoint 生命周期：当节点池扩缩容时，监控 Endpoint 的创建和销毁事件，确保新 Pod 的 Identity 正确继承，且网络策略及时生效。