Cilium 与 Hubble 集成：Agent 与 Server 交互及策略观测联动
Cilium 与 Hubble 的深度集成是 eBPF 网络观测的核心能力。Cilium Agent 负责执行网络策略与数据平面转发，而 Hubble Server 则负责从 Agent 采集流数据并暴露观测接口。两者通过 gRPC 协议和共享的 eBPF Map 实现高效通信，使得每一次网络策略的变更都能被实时观测。
4.1 Cilium Agent 与 Hubble Server 的交互架构
Cilium Agent 运行在每个 Kubernetes 节点上，负责管理 eBPF 程序、NetworkPolicy 的加载以及服务负载均衡。Hubble Server 作为独立的观测组件，通过以下两种方式与 Agent 交互：
- gRPC 流式订阅： Hubble Server 通过 gRPC 连接到每个节点的 Cilium Agent，订阅
Observer服务，实时获取流事件（Flow Events）。 - 共享 eBPF Map： Agent 将 eBPF 程序采集的流元数据写入内核中的 perf ring buffer 或 BPF map，Hubble 通过读取这些共享数据结构获取低延迟的观测数据。
关键设计： Hubble 不直接修改 eBPF 程序，而是通过 Cilium Agent 暴露的 gRPC 接口消费数据。这种解耦设计使得观测层与数据平面层可以独立升级，且不会影响网络策略的执行性能。
4.2 Cilium NetworkPolicy 与 Hubble 观测的联动机制
Cilium 的 NetworkPolicy 不仅控制网络流量，还会自动生成丰富的观测事件。当一条策略被创建、更新或删除时，Hubble 会立即感知并开始记录与该策略相关的所有流。这种联动机制使得运维人员可以实时验证策略是否生效，以及策略对业务流量的影响。
| 策略事件 | Hubble 观测行为 | 典型观测指标 |
|---|---|---|
| 策略创建 | 开始记录匹配该策略的新建连接 | 策略命中次数、允许/拒绝计数 |
| 策略更新 | 对比新旧策略，标记受影响的流 | 策略变更时间、受影响 Pod 列表 |
| 策略删除 | 停止记录，保留历史流日志 | 策略存活时间、最后命中时间 |
| 策略拒绝 | 生成拒绝事件，包含源/目的/端口 | 拒绝次数、拒绝原因（eBPF 丢弃） |
实战建议： 在压测沙盘中，建议先创建一条 Deny 策略，然后通过 Hubble 观测拒绝事件是否立即出现。如果延迟超过 1 秒，说明 gRPC 流或 eBPF Map 读取存在瓶颈，需要校准资源配额。
4.3 策略观测数据流与标签注入
Hubble 观测的核心优势在于 标签注入。Cilium Agent 在转发数据包时，会将匹配的 NetworkPolicy 名称、规则 ID、以及决策结果（允许/拒绝）作为元数据写入 eBPF 事件。Hubble Server 在消费这些事件时，自动将这些标签附加到流记录中。
以下是一个典型的 Hubble 流事件 JSON 结构，展示了策略标签的注入：
{
"time": "2025-03-15T10:30:00.123456Z",
"source": {
"pod_name": "frontend-v1-abc",
"namespace": "prod",
"labels": {"app": "frontend", "version": "v1"}
},
"destination": {
"pod_name": "backend-v2-xyz",
"namespace": "prod",
"labels": {"app": "backend", "version": "v2"}
},
"verdict": "FORWARDED",
"policy_name": "allow-frontend-to-backend",
"policy_id": 1024,
"rule_index": 0,
"bytes": 1450,
"packets": 1
}4.4 集成验证与压测沙盘中的常见问题
在压测沙盘环境中，Cilium 与 Hubble 的集成需要关注以下验证点：
- gRPC 连接健康： 检查 Hubble Server 与每个 Cilium Agent 的 gRPC 连接数是否等于节点数。连接数不足会导致流事件丢失。
- eBPF Map 大小： 默认的 eBPF Map 大小可能在高并发压测下溢出，导致事件被丢弃。需要根据并发连接数校准
bpf_map_max_entries参数。 - 策略事件延迟： 从策略创建到 Hubble 观测到第一条匹配流的时间应小于 500ms。延迟过高说明 Agent 与 Server 之间的数据管道存在瓶颈。
容量规划警告： 在压测沙盘中，如果 Hubble Server 的 CPU 使用率超过 80%，或者 gRPC 流积压超过 10000 条，说明观测层已经无法跟上数据平面的速率。此时需要增加 Hubble Server 的副本数或调整流采样率。
通过以上集成机制，Cilium 与 Hubble 形成了一个闭环：策略驱动流量控制，流量产生观测数据，观测数据反过来验证策略效果。这种联动是构建可靠网络观测沙盘的基础，也是后续容量预测模型的数据来源。