4. Cilium与eBPF生态：Cilium简介、eBPF在Cilium中的应用、Hubble可观测性
4.1 Cilium 简介：基于 eBPF 的云原生网络、安全与可观测性平台
Cilium 是 CNCF 毕业项目，核心设计理念是“利用 eBPF 在 Linux 内核中动态注入程序，为容器工作负载提供高速网络、安全策略与可观测性”。它摒弃了传统 CNI 插件依赖 iptables 或用户态代理的架构，将数据面完全下沉到内核 eBPF 钩子中执行。
关键定位： Cilium 不是单纯的 CNI 网络插件，而是一个集成了网络（L3/L4/L7）、安全（基于身份的策略、API 感知）、可观测性（Hubble）以及服务网格（基于 Envoy 的 L7 治理）的统一平台。
Cilium 的核心组件与职责：
| 组件 | 运行位置 | 核心职责 | 与 eBPF 的关系 |
|---|---|---|---|
| Cilium Agent | 每个节点（DaemonSet） | 与 K8s API Server 交互，管理 eBPF Map/Program 的加载与更新 | eBPF 程序的编排者 |
| Cilium Operator | 集群级单副本 | 处理集群范围任务（如 IPAM、CiliumEndpoint 同步） | 间接管理 eBPF 资源分配 |
| Cilium CNI Chainer | 节点级 | 实现 CNI 接口，调用 Agent 配置 Pod 网络命名空间 | 触发 eBPF 程序附着到 Pod 端 |
| Envoy (L7 代理) | 可选组件 | 处理 L7 HTTP/gRPC 策略与流量治理 | 通过 eBPF 加速流量重定向到 Envoy |
| Hubble Relay/UI | 集群级 | 聚合节点 eBPF 事件，提供可观测性 API 与 UI | 消费 eBPF 导出的可观测性数据 |
4.2 eBPF 在 Cilium 中的核心应用
Cilium 是 eBPF 技术在生产环境最成功的落地案例。它利用 eBPF 的多个钩子点，实现了传统 CNI 无法比拟的性能与灵活性。
4.2.1 网络数据面：eBPF 替代 iptables 与 Overlay 隧道
- TC (Traffic Control) 钩子： Cilium 在 Pod 的 veth 对宿主端和物理网卡上附着 eBPF 程序，直接处理数据包的封装、路由、转发。无需经过 iptables 规则链，延迟降低 40%-60%。
- XDP (eXpress Data Path) 钩子： 在网卡驱动层（RX 最早阶段）执行 eBPF，实现 DDoS 防护、负载均衡的源地址转换（Maglev 一致性哈希），吞吐量可达线速。
- 直接路由与隧道模式： 无论哪种模式，Cilium 都通过 eBPF 完成封装（VXLAN/Geneve）或路由决策，避免在用户态和内核态之间切换。
性能对比： 在同等硬件条件下，Cilium (eBPF) 相比 Calico (iptables) 在 PPS 转发性能上提升约 3-5 倍，连接建立速率提升 10 倍以上。
4.2.2 安全策略：基于身份（Identity）的 L3/L4/L7 执行
Cilium 不依赖 IP 地址或安全组标签，而是为每个 Pod 分配一个全局唯一的 Security Identity（基于 Label 的哈希值）。eBPF 程序在 sk_lookup 和 sk_skb 钩子中直接查询 BPF Map（cilium_ipcache、cilium_policy），实现微秒级的策略匹配。
- L3/L4 策略： 在 eBPF 中直接检查 IP 协议、端口、Identity，拒绝非法包，无需 iptables 遍历。
- L7 策略： 通过 eBPF 的
sockops和cgroup/connect钩子，将匹配特定 HTTP 方法或路径的流量重定向到本地 Envoy 代理，由 Envoy 执行精细的 L7 策略。
4.2.3 负载均衡：Maglev 一致性哈希与 DSR
Cilium 的 kube-proxy 替代模式完全基于 eBPF。它在 connect 系统调用或 XDP 层拦截 Service 请求，使用 Maglev 一致性哈希算法选择后端，并支持直接服务器返回（DSR），避免流量经过节点二次转发。
// 简化示意：eBPF 程序在 connect 钩子中执行 Service 负载均衡
// 实际代码位于 bpf/bpf_lxc.c 和 bpf/bpf_xdp.c
int cilium_connect4(struct bpf_sock_addr *ctx) {
struct lb4_key key = { .address = ctx->user_ip4, .dport = ctx->user_port };
struct lb4_service *svc = map_lookup_elem(&LB4_SERVICES_MAP, &key);
if (svc) {
// Maglev 哈希选择后端
struct lb4_backend *backend = select_backend_maglev(svc, ctx->cookie);
ctx->user_ip4 = backend->address;
ctx->user_port = backend->port;
}
return 0;
}
4.3 Hubble：基于 eBPF 的可观测性层
Hubble 是 Cilium 的可观测性组件，它不依赖 sidecar 或应用埋点，而是直接从 eBPF 程序导出的元数据中构建服务拓扑、流量日志和指标。
4.3.1 Hubble 的数据采集架构
4.3.2 Hubble 的核心可观测性能力
| 能力维度 | 数据来源（eBPF 钩子） | 典型输出 | 运维价值 |
|---|---|---|---|
| 服务依赖拓扑 | tracepoint/skb/consume、kprobe/tcp_connect |
实时服务地图，显示流量方向、协议、速率 | 快速定位调用链断裂或异常依赖 |
| 网络流日志 | TC 入口/出口钩子 |
五元组、Verdict（允许/丢弃）、字节数、延迟 | 安全审计、故障排查（如 DNS 解析失败） |
| HTTP/gRPC 指标 | sockops + Envoy 导出 |
请求速率、P99 延迟、状态码分布 | 应用性能监控，无需 Prometheus 埋点 |
| DNS 可观测性 | kprobe/udp_sendmsg |
DNS 查询域名、响应 IP、响应时间 | 排查服务发现延迟或 DNS 劫持 |
| TCP 状态跟踪 | kprobe/tcp_set_state |
TCP 连接建立/关闭、重传、RTT | 网络性能调优，识别连接泄漏 |
4.3.3 Hubble 与 Cilium 的集成优势
- 零开销采集： eBPF 事件导出是内核原生操作，相比 Prometheus 拉取或 sidecar 抓包，CPU 开销可忽略不计（通常 < 1%）。
- 安全策略审计： Hubble 可以展示每条流量的 Verdict（ALLOWED / DENIED），并关联到具体的 CiliumNetworkPolicy 规则，帮助验证安全策略是否生效。
- 与 Prometheus/Grafana 集成： Hubble 暴露标准的 Prometheus 指标端点（
:9965/metrics），可直接被 Prometheus 抓取，无需额外 exporter。
注意： 在大型集群（节点数 > 500）中，Hubble Relay 的内存消耗可能较高，建议为 Relay 分配至少 2GB 内存，并启用事件采样（
--hubble-event-queue-size）以避免 OOM。