3. Cilium 与 Hubble 架构：数据平面、观测层与组件关系
Cilium 基于 eBPF 构建了高性能的 Kubernetes 网络与安全数据平面，而 Hubble 则在其之上提供了可观测性层。理解两者的分层架构与组件协作关系，是利用 Hubble 数据进行节点池扩缩容决策的前提。
3.1 Cilium 数据平面架构
Cilium 的数据平面完全运行在内核 eBPF 程序中，绕过了传统的 iptables 和用户态代理，实现了低延迟、高吞吐的网络转发与安全策略执行。
| 组件 | 所在层 | 核心职责 | eBPF 程序类型 |
|---|---|---|---|
| Cilium Agent | 用户态 (DaemonSet) | 与 Kubernetes API Server 交互，管理 Endpoint、策略下发，编译并加载 eBPF 程序 | — |
| Cilium CNI 插件 | 节点级 (二进制) | 处理 Pod 网络创建/删除，调用 Agent 完成接口配置与 IPAM | — |
| eBPF 数据路径 | 内核 (TC / XDP / cgroup) | 数据包转发、封装/解封装、负载均衡、网络策略过滤、加密 | BPF_PROG_TYPE_SCHED_CLS, BPF_PROG_TYPE_XDP, BPF_PROG_TYPE_CGROUP_SKB |
| eBPF Map | 内核 (共享内存) | 存储 Endpoint 信息、策略规则、连接跟踪 (CT)、NAT 状态 | BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_LRU_HASH |
| Cilium Identity | 集群级 (CRD) | 基于标签的安全标识，用于策略匹配，而非传统 IP | — |
关键设计： Cilium 将网络策略从 IP 地址解耦为基于标签的 Identity。每个 Pod 被分配一个 24 位数字标识，eBPF 程序直接基于 Identity 做转发决策，大幅降低了策略匹配的复杂度。
3.2 Hubble 观测层架构
Hubble 是 Cilium 原生的分布式网络观测平台。它通过 eBPF 程序在内核态捕获网络事件，并通过用户态组件提供流日志、指标和 Service Map 能力。
| 组件 | 部署形态 | 功能描述 |
|---|---|---|
| Hubble Agent | 每个节点 (sidecar 或独立进程) | 从 Cilium eBPF Map 读取事件，聚合流日志，暴露 gRPC 和 Prometheus 指标 |
| Hubble Relay | 集群级 (Deployment) | 聚合所有节点的 Hubble Agent 数据，提供全局查询 API，支持时间范围过滤 |
| Hubble UI | 集群级 (Deployment) | 基于 Relay API 的 Web 界面，展示 Service Map、流日志、策略可视化 |
| Hubble Exporter | 可选 (Deployment) | 将 Hubble 指标转换为标准 Prometheus 格式，供外部监控系统消费 |
观测数据来源： Hubble 不重新挂载 eBPF 程序，而是通过
perf_event 环形缓冲区或直接读取 Cilium 的 eBPF Map（如连接跟踪表）来获取数据。这种设计保证了观测层对数据平面零性能影响。
3.3 组件关系与数据流
下图展示了 Cilium 数据平面与 Hubble 观测层之间的组件关系，以及从内核事件到用户态观测数据的完整流动路径。
3.4 数据流与扩缩容决策链路
从 Hubble 观测数据到节点池扩缩容决策，数据流经过以下关键步骤：
- 内核捕获： eBPF 程序在 TC 或 XDP 挂载点捕获每个数据包，记录五元组、Identity、字节数、时间戳到 eBPF Map。
- 本地聚合： Hubble Agent 通过
perf_event或直接读取 eBPF Map，按 (源 Identity, 目的 Identity, 协议, 端口) 聚合为流记录，每 15 秒生成一次指标。 - 全局汇聚： Hubble Relay 从所有节点的 Hubble Agent 拉取数据，合并去重，提供按命名空间、标签、节点过滤的全局视图。
- 指标暴露： Hubble Exporter 将聚合后的指标（如
hubble_flows_processed_total、hubble_tcp_retransmit_total）暴露给 Prometheus。 - 决策触发： 扩缩容控制器（如 Cluster Autoscaler 或自定义 Operator）查询 Prometheus，根据预定义的指标阈值（如节点网络吞吐量 > 80% 或 TCP 重传率 > 5%）触发节点池扩缩容。
关键注意事项： 使用 Hubble 数据驱动扩缩容时，必须区分控制平面流量与数据平面流量。Hubble 观测到的流量包含 Kubernetes 健康检查、kube-proxy 替换后的 Service 流量等。建议在聚合指标时通过
destination=pod 或 verdict=FORWARDED 过滤，避免控制平面流量干扰决策。
3.5 组件依赖与版本兼容性
| 组件 | 依赖 | 版本要求 | 说明 |
|---|---|---|---|
| Cilium Agent | Linux Kernel ≥ 5.10 (推荐) | v1.14+ | 低版本内核需启用 cgroupv2 和 BPF_FS |
| Hubble Agent | Cilium Agent (同节点) | 与 Cilium 版本匹配 | 通过 Unix Socket 与 Cilium Agent 通信 |
| Hubble Relay | 所有节点的 Hubble Agent | ≥ v0.11 | gRPC 双向流，需网络可达 |
| Hubble UI | Hubble Relay | ≥ v0.11 | 前端无状态，可多副本部署 |
| Prometheus | Hubble Exporter 或 Agent 直接暴露 | ≥ v2.30 | 建议使用 honor_labels: true 保留原始标签 |
生产建议： 在节点池扩缩容场景中，Hubble Relay 和 Prometheus 应部署在独立的“观测节点池”中，避免因业务节点池扩缩容导致观测数据中断。同时，为 Hubble Agent 配置
--max-flows=100000 以控制内存占用，防止大规模集群下 OOM。