3. Cilium与Hubble架构：Cilium数据平面、Hubble作为可观测性组件、Hubble Relay与Hubble UI的职责划分
理解Cilium与Hubble的架构是掌握eBPF网络观测的基础。Cilium作为数据平面负责网络策略与转发，而Hubble则作为可观测性组件，将eBPF采集的元数据转化为可检索的流量视图。Hubble Relay与Hubble UI分别承担数据聚合与可视化呈现的职责，三者协同构成完整的观测链路。
3.1 Cilium数据平面：eBPF驱动的网络核心
Cilium的数据平面完全基于eBPF实现，运行在Linux内核中，负责处理节点内所有Pod的网络流量。它通过加载eBPF程序到网络钩子点（如XDP、TC、套接字）来实现网络策略、负载均衡与安全隔离，无需修改内核代码或依赖iptables规则。
| 组件 | eBPF挂载点 | 核心职责 |
|---|---|---|
| 网络策略引擎 | TC Ingress/Egress | 基于身份的安全策略执行，允许/拒绝Pod间通信 |
| 服务负载均衡 | XDP / TC | 实现ClusterIP、NodePort、ExternalIP的DNAT与转发 |
| 网络封装/路由 | TC / 隧道设备 | Overlay网络（VXLAN/Geneve）或直接路由模式 |
| 带宽管理 | EDT (Earliest Departure Time) | Pod级别的带宽限制与优先级调度 |
关键设计：Cilium数据平面不依赖iptables或ipvs，所有转发决策均在eBPF map中完成，单跳延迟可控制在微秒级，且策略变更无需重建连接。
3.2 Hubble作为可观测性组件：从eBPF事件到结构化流
Hubble是Cilium的可观测性子系统，它通过Cilium的eBPF数据路径被动监听网络事件，而非主动抓包。Hubble Agent运行在每个节点上，从Cilium的eBPF map中读取连接跟踪（CT）、策略命中、DNS解析等元数据，并将其聚合为结构化流（Flow）。
- 数据来源：Cilium eBPF map（连接跟踪、策略日志、服务映射）、kprobe/tracepoint（系统调用级事件）。
- 流（Flow）结构：包含五元组、L7协议信息（HTTP/gRPC/DNS）、Verdict（允许/拒绝/丢弃）、节点与Pod标签。
- 输出方式：通过gRPC流式API对外暴露，支持JSON或Protocol Buffers序列化。
观测粒度：Hubble可以观测到每个TCP连接的生命周期（SYN→数据→FIN/RST），以及每个HTTP请求的路径、方法、状态码和延迟，无需修改应用代码。
3.3 Hubble Relay与Hubble UI的职责划分
在集群规模下，每个节点运行独立的Hubble Agent，数据分散在各节点。Hubble Relay作为集群级聚合层，将所有节点的流数据合并，并提供统一的查询接口。Hubble UI则基于Relay的数据，提供可视化仪表盘。
| 组件 | 部署位置 | 核心职责 | 对外接口 |
|---|---|---|---|
| Hubble Agent | 每个Kubernetes节点 | 从Cilium eBPF map读取事件，生成Flow，本地缓存 | gRPC流（节点级） |
| Hubble Relay | 集群内Deployment | 聚合所有Agent的流数据，去重排序，提供集群级查询 | gRPC API（集群级） |
| Hubble UI | 集群内Deployment | 可视化服务依赖图、流量拓扑、策略审计 | HTTP/WebSocket |
注意：Hubble Relay本身不存储历史数据，它只作为实时流的中转与聚合层。如果需要持久化存储，需要对接外部存储（如TimescaleDB、Elasticsearch）或使用Hubble的导出器（Exporter）。
3.4 架构总结：数据平面与观测平面的协同
Cilium与Hubble的架构遵循“数据平面与观测平面分离”的设计原则。Cilium专注于高性能网络转发与策略执行，不承担观测数据的存储与展示负担；Hubble则作为观测平面，从Cilium的eBPF数据路径中“窃听”事件，转化为可消费的流数据。Hubble Relay与Hubble UI进一步将观测能力从单节点扩展到集群级，并提供交互式可视化界面。
生产部署建议：在大型集群中，建议为Hubble Relay和Hubble UI分配独立的资源配额，并启用Hubble的流导出功能，将数据持久化到外部存储，以支持历史回溯与长期趋势分析。