4. Cilium 网络基础：eBPF 技术原理、Cilium 数据路径、CiliumNetworkPolicy 与 Hubble 可观测性
本章是 Cilium 网络的基石。在 etcd 压测沙盘中，Cilium 负责承载 etcd 节点间的所有数据流。理解 eBPF 技术原理、Cilium 数据路径、网络策略以及 Hubble 可观测性，是后续进行网络故障诊断与性能恢复的前提。
4.1 eBPF 技术原理
eBPF（extended Berkeley Packet Filter）是一项革命性的内核技术，允许用户在 Linux 内核中安全、高效地运行沙箱化程序，而无需修改内核源代码或加载内核模块。Cilium 正是基于 eBPF 构建其网络、安全与可观测性能力。
4.1.1 eBPF 程序挂载点与生命周期
| 挂载点类型 | 触发事件 | Cilium 典型用途 |
|---|---|---|
| XDP | 网卡驱动层收到数据包 | DDoS 防御、早期丢包、负载均衡 |
| TC（Traffic Control） | 内核协议栈处理前后 | 数据路径转发、封装/解封装、策略执行 |
| cgroup | 进程创建、套接字操作 | 容器网络隔离、套接字级策略 |
| kprobe/uprobe | 内核/用户函数调用 | Hubble 可观测性、延迟追踪 |
| Tracepoint | 内核静态跟踪点 | 系统调用监控、网络事件采集 |
4.1.2 eBPF 与 Cilium 的关系
Cilium 将 eBPF 程序编译为 BPF 字节码，通过 bpf() 系统调用加载到内核，并使用 BPF Maps 在用户态与内核态之间共享数据。Cilium Agent 负责管理这些 eBPF 程序的加载、更新与卸载。
4.2 Cilium 数据路径：Overlay 与 Direct Routing
Cilium 支持两种主要的数据转发模式，决定了 etcd 节点间的网络流量如何封装与路由。在压测沙盘中，选择正确的模式对性能有直接影响。
4.2.1 Overlay 模式（默认）
使用 VXLAN 或 Geneve 隧道封装。每个节点上的 Cilium Agent 维护一个简单的网络拓扑，将跨节点的容器流量封装在 UDP 隧道中发送。此模式对底层网络基础设施要求最低，适用于任何 IP 可达的网络。
- 优点： 无需修改底层网络设备配置，天然支持跨子网通信，网络隔离性好。
- 缺点： 额外的封装/解封装开销，MTU 减少约 50 字节，CPU 占用略高。
- 适用场景： 公有云、混合云、底层网络不支持大规模路由的环境。
4.2.2 Direct Routing 模式（原生路由）
Cilium 直接利用底层网络的路由能力，将容器 IP 路由到目标节点。Cilium Agent 通过 BGP 或静态路由将 Pod CIDR 通告给上游路由器。数据包无需隧道封装，直接以原生格式传输。
- 优点： 零封装开销，网络吞吐更高，延迟更低，MTU 无额外损耗。
- 缺点： 需要底层网络设备支持路由协议（如 BGP），配置复杂度较高。
- 适用场景： 自建数据中心、高性能计算、对延迟敏感的 etcd 集群。
| 对比维度 | Overlay 模式 | Direct Routing 模式 |
|---|---|---|
| 封装开销 | VXLAN/Geneve 头部（50-70 字节） | 无 |
| 网络吞吐 | 受封装影响，略低 | 接近线速 |
| 延迟 | 增加微秒级封装延迟 | 原生延迟 |
| 底层依赖 | 仅需 IP 可达 | 需支持路由协议 |
| 运维复杂度 | 低 | 中高 |
| etcd 压测推荐 | 开发/测试环境 | 生产/性能敏感环境 |
4.3 CiliumNetworkPolicy
CiliumNetworkPolicy 是基于 eBPF 实现的 Kubernetes 网络策略增强版，支持 L3/L4 到 L7 的精细化访问控制。与标准 Kubernetes NetworkPolicy 相比，CiliumNetworkPolicy 提供了更丰富的匹配条件和更低的性能开销。
4.3.1 策略层级与匹配规则
| 层级 | 匹配条件 | 示例 |
|---|---|---|
| L3/L4 | IP、CIDR、端口、协议 | 允许 etcd 节点间 2379 端口通信 |
| L7 | HTTP 方法、路径、头部、gRPC 方法 | 仅允许 etcd 的 Range/RangeResponse 请求 |
| DNS | 域名、DNS 请求类型 | 仅允许 etcd 集群内部域名解析 |
| CIDR | 外部 IP 范围 | 允许监控系统访问 etcd 指标端口 |
4.3.2 典型 etcd 策略示例
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: etcd-peer-access
namespace: etcd-cluster
spec:
endpointSelector:
matchLabels:
app: etcd
ingress:
- fromEndpoints:
- matchLabels:
app: etcd
toPorts:
- ports:
- port: "2379"
protocol: TCP
- port: "2380"
protocol: TCP
egress:
- toEndpoints:
- matchLabels:
app: etcd
toPorts:
- ports:
- port: "2379"
protocol: TCP
- port: "2380"
protocol: TCP4.4 Hubble 可观测性
Hubble 是 Cilium 原生的可观测性层，基于 eBPF 实时采集网络流量、策略命中、DNS 请求、TCP 连接状态等数据。在 etcd 压测沙盘中，Hubble 是诊断网络故障、分析性能瓶颈的核心工具。
4.4.1 Hubble 核心能力
- 实时流量监控： 查看 Pod 级别的网络流量、连接数、丢包率。
- 策略审计： 显示哪些策略被命中、哪些流量被拒绝。
- 延迟分析： 通过 TCP RTT、HTTP 请求延迟等指标定位性能瓶颈。
- 服务依赖图： 自动生成 etcd 集群内的服务调用拓扑。
- 事件导出： 支持 Prometheus 指标、Flow 日志、Grafana 仪表盘。
4.4.2 Hubble 常用命令与指标
| 命令/指标 | 用途 | etcd 压测场景 |
|---|---|---|
hubble observe |
实时查看网络流 | 观察 etcd 节点间心跳与请求流 |
hubble status |
检查 Hubble 健康状态 | 确认可观测性数据采集正常 |
cilium hubble port-forward |
暴露 Hubble UI | 可视化查看服务依赖图 |
hubble metrics |
Prometheus 指标 | 采集丢包率、延迟、吞吐量 |
hubble flows |
导出 Flow 日志 | 分析被策略拒绝的流量 |
4.5 本章小结
- eBPF 是 Cilium 的技术基石，通过在内核态安全执行程序，实现高性能网络与安全。
- Overlay 模式 提供良好的兼容性，适合复杂网络环境；Direct Routing 模式 提供极致性能，适合 etcd 压测场景。
- CiliumNetworkPolicy 支持 L3/L4 到 L7 的精细化控制，在压测中应优先使用 L3/L4 策略以减少开销。
- Hubble 提供基于 eBPF 的零侵扰可观测性，是诊断 etcd 网络故障的核心工具。