4. Cilium 基础架构：eBPF 数据面、L3/L4/L7 策略、Hubble 可观测性
Cilium 是构建于 eBPF（extended Berkeley Packet Filter）之上的云原生网络、安全与可观测性项目。它利用 Linux 内核的 eBPF 技术，在无需修改内核或应用代码的前提下，动态注入高效的网络处理与安全策略逻辑。本章将拆解 Cilium 的核心架构：eBPF 数据面转发路径、多层网络策略模型以及 Hubble 可观测性组件。
4.1 整体架构概览
Cilium 采用控制面与数据面分离的架构。控制面组件（如 Operator、Agent）通过 Kubernetes API 监听资源变化，生成 eBPF 程序并加载到节点内核；数据面完全由 eBPF 程序在内核态完成网络转发、负载均衡与策略执行，避免传统 iptables 或 IPVS 的线性遍历开销。
4.2 eBPF 数据面：内核态网络处理
Cilium 的数据面完全基于 eBPF 实现，主要利用以下内核钩子：
| 钩子类型 | 触发位置 | 典型用途 | 性能特征 |
|---|---|---|---|
| XDP | 网卡驱动层（最早） | DDoS 防护、早期丢包、重定向 | 纳秒级，无 skb 分配 |
| TC（Traffic Control） | 内核协议栈入口/出口 | Pod 间转发、封装/解封装、策略执行 | 微秒级，可访问完整 skb |
| cgroup/sock | Socket 创建/连接 | Socket 级策略、DNS 解析拦截 | 连接级，开销极低 |
Cilium 使用 BPF Map 在 eBPF 程序与用户态 Agent 之间共享数据，包括端点信息、策略规则、服务后端列表等。数据包处理流程如下：
- 入口：数据包到达节点网卡，XDP 程序优先处理（若启用），决定放行、重定向或丢弃。
- TC Ingress：数据包进入内核协议栈前，TC 程序执行身份识别（Identity）、策略查找、封装（VXLAN/Geneve）或直接转发。
- 转发决策：根据 BPF Map 中的端点信息，判断目标是否在同一节点；若是，通过 veth pair 直接送达目标 Pod；若否，查找隧道或原生路由。
- 负载均衡：Service 访问在 eBPF 中完成 DNAT 和后端选择，无需 conntrack 遍历。
- 出口：TC Egress 程序执行出站策略，然后通过 veth 或物理网卡发出。
4.3 L3/L4/L7 网络策略模型
Cilium 的网络策略比 Kubernetes 原生 NetworkPolicy 更精细，支持从网络层到应用层的多层控制。策略通过 CiliumNetworkPolicy（CNP）和 CiliumClusterwideNetworkPolicy（CCNP）CRD 定义。
| 策略层级 | 匹配维度 | 典型规则示例 | eBPF 实现方式 |
|---|---|---|---|
| L3 | IP CIDR、标签、集群 | 允许来自 10.0.0.0/8 的流量 | BPF Map 中存储 CIDR 前缀树 |
| L4 | 协议（TCP/UDP/SCTP）、端口 | 允许 TCP 2379（etcd 客户端端口） | BPF Map 中存储端口范围 |
| L7 | HTTP 方法/路径、gRPC 服务/方法、Kafka 主题 | 允许 GET /v3/kv/range，拒绝 DELETE | 用户态代理（Envoy）或 eBPF 原生 L7 解析 |
策略执行的核心机制是 Identity（身份）：Cilium 为每个 Pod 分配一个 24 位安全身份标识，策略规则基于身份而非 IP 地址。当 Pod 重启或迁移时，身份保持不变，策略无需重新计算。
4.4 Hubble 可观测性：网络流与延迟可视化
Hubble 是 Cilium 的可观测性层，利用 eBPF 在内核态采集网络事件，提供实时流量监控、延迟分析和依赖关系图。Hubble 组件包括：
- Hubble Agent：每个节点运行，从 Cilium Agent 获取 eBPF 事件，通过 gRPC 暴露流数据。
- Hubble Relay：聚合多节点数据，提供集群级查询接口。
- Hubble UI：基于 Web 的图形界面，展示服务拓扑和流量详情。
- hubble CLI：命令行工具，支持实时观察和过滤。
Hubble 在 etcd 压测中的核心价值：
- 逐跳延迟分解：通过 Hubble 的流记录，可以精确测量 etcd 集群中每个 Raft 消息从源 Pod 到目标 Pod 的每一跳延迟，区分网络排队、eBPF 策略处理、隧道封装等各阶段耗时。
- 丢包与重传检测：Hubble 可以标记 TCP 重传和丢包事件，帮助定位 etcd 集群中的网络不稳定问题。
- 服务依赖拓扑：自动生成 etcd 集群内 Pod 之间的通信拓扑，验证网络策略是否按预期生效。
# 实时观察 etcd 命名空间下的网络流
hubble observe --namespace etcd --since 5m --output json
# 查看特定 Pod 的延迟分布
hubble observe --pod etcd-0 --verdict DROPPED --since 1h
# 通过 Hubble Metrics 暴露延迟直方图到 Prometheus
# 在 CiliumAgent 中启用：--hubble-metrics="drop:sourceContext=identity;destinationContext=identity"