3. Cilium与Hubble生态：Cilium CNI基础、Hubble组件架构、Hubble与eBPF的关系
Cilium 是当前云原生领域最具代表性的 eBPF 驱动 CNI 插件，而 Hubble 则是其原生的网络可观测性层。理解 Cilium 的 CNI 基础、Hubble 的组件架构以及两者与 eBPF 的深度绑定关系，是构建节点级流量审计与告警联动能力的核心前提。
3.1 Cilium CNI 基础
Cilium 并非传统意义上的 CNI 插件。它利用 eBPF 程序直接在内核中完成数据包的转发、过滤、加密与负载均衡，彻底绕过了 iptables 和用户态代理。其核心设计理念是：将网络策略与安全身份（Security Identity）绑定，而非 IP 地址。
关键特性： Cilium 通过 eBPF 实现 L3/L4 与 L7 网络策略、透明加密（WireGuard/IPsec）、集群内外负载均衡、以及基于 Service 的 DNS 感知策略。
Cilium 的数据路径完全由 eBPF 程序构成，主要包含以下关键组件：
| 组件 | eBPF 程序类型 | 功能描述 |
|---|---|---|
| cilium_veth | TC (traffic control) ingress/egress | Pod 侧网络接口，负责 Pod 出入站流量的策略执行与封装/解封装 |
| cilium_host | TC ingress/egress | 主机侧网络接口，处理节点间流量与主机网络命名空间流量 |
| cilium_net | TC ingress/egress | 用于节点间 Overlay 或 Direct Routing 的封装接口 |
| lxc | TC ingress/egress | 每个 Pod 对应的 veth pair 主机端，执行策略与监控 |
| XDP | XDP (eXpress Data Path) | 在驱动层处理入站流量，用于 DDoS 防护与高性能转发 |
运维提示： 在节点巡检中，通过
cilium status 和 cilium bpf tunnel list 可以快速验证 Cilium 的 eBPF 数据路径是否健康，以及隧道端点是否与预期一致。
3.2 Hubble 组件架构
Hubble 是构建在 Cilium 之上的分布式网络可观测性平台。它并非独立运行，而是作为 Cilium Agent 的 Sidecar 或独立 DaemonSet 部署，通过 gRPC 接口从 Cilium 的 eBPF 程序中获取实时事件流。
Hubble 的架构分为三个核心层次：
- 数据采集层（Hubble Agent）： 运行在每个节点上，通过 Cilium 的 eBPF 程序（如
cilium_tcp6、cilium_connect）捕获网络事件，包括 TCP 连接建立/关闭、DNS 请求、HTTP 请求等。Agent 将这些原始 eBPF 事件转换为结构化的 Flow 事件。 - 存储与查询层（Hubble Relay）： 作为集群级别的聚合器，从所有 Hubble Agent 收集 Flow 事件，并提供统一的 gRPC 查询接口。Relay 支持按时间、标签、IP、端口、协议等维度进行过滤和检索。
- 可视化与消费层（Hubble UI / CLI）： Hubble UI 提供基于 Web 的流量拓扑图与事件列表；Hubble CLI（
hubble observe）则用于命令行实时追踪与调试。
巡检要点： 使用
hubble observe --from-pod <pod-name> --to-pod <pod-name> 可以实时查看两个 Pod 之间的所有 eBPF 捕获流量，无需 tcpdump 或 sidecar 代理。
3.3 Hubble 与 eBPF 的关系
Hubble 与 eBPF 的关系可以概括为：eBPF 是数据引擎，Hubble 是数据消费者与呈现者。没有 eBPF，Hubble 将失去其核心数据源；没有 Hubble，eBPF 捕获的原始内核事件将难以被运维人员直接理解和使用。
具体而言，两者的协作体现在以下三个层面：
| 层面 | eBPF 角色 | Hubble 角色 |
|---|---|---|
| 事件捕获 | 在内核中挂载 kprobe/tracepoint/TC 程序，捕获网络系统调用、数据包收发、连接状态变更 | 通过 perf ring buffer 或 BPF map 读取 eBPF 程序输出的事件，转换为 Flow 对象 |
| 策略关联 | 执行 CiliumNetworkPolicy 的 eBPF 规则，决定数据包放行/丢弃/重定向 | 读取 Cilium 的 Identity map，将丢弃事件与具体策略规则关联，展示“被策略拒绝”的流量 |
| 指标导出 | 在 eBPF 程序中维护计数器 map，记录字节数、包数、连接数 | 定期从 BPF map 中读取计数器，暴露为 Prometheus 指标（如 hubble_flows_processed_total） |
关键理解： Hubble 并不直接编写或加载 eBPF 程序。它依赖 Cilium Agent 已经加载的 eBPF 程序。如果 Cilium 的 eBPF 数据路径出现故障（如内核版本不兼容、BPF 文件系统挂载失败），Hubble 将无法获取任何流量数据。因此，节点巡检的第一步永远是确认 Cilium 的 eBPF 状态。
从数据流的角度看，一次完整的 Hubble 流量审计路径如下：
- 内核事件触发： Pod A 向 Pod B 发送 TCP SYN 包，触发 Cilium 在
cilium_veth上的 TC egress eBPF 程序。 - eBPF 程序处理： eBPF 程序执行策略检查，通过后封装 VXLAN/Geneve 头部，同时将连接四元组、安全身份、动作（Allow/Deny）写入 BPF perf event buffer。
- Hubble Agent 消费： Hubble Agent 的用户态进程通过
bpf_perf_event_output读取事件，解析为包含源/目的 Pod 名称、命名空间、Service 名称、HTTP 方法等丰富元数据的 Flow。 - Relay 聚合与查询： Hubble Relay 收集所有 Agent 的 Flow，支持按
--label k8s:app=nginx或--verdict DROPPED过滤。 - 告警联动： 当 Hubble 检测到特定模式（如大量 DNS 查询到未知域名、频繁的连接重置），可通过 Prometheus Alertmanager 触发告警，联动节点巡检脚本执行
hubble observe --verdict DROPPED --last 5m获取详细上下文。
实践总结： 在节点巡检场景中，理解 eBPF 与 Hubble 的关系意味着：当发现 Hubble 数据缺失时，应首先检查
cilium bpf metrics list 确认 eBPF 程序是否正常运行；当需要审计特定 Pod 的流量时，应使用 hubble observe --identity <id> 而非 IP 过滤，因为 eBPF 程序内部使用 Security Identity 作为核心标识。