1. 课程导论：etcd压测沙盘与Cilium网络延迟分析全景图
在云原生基础设施中，etcd 作为 Kubernetes 的控制面存储，其性能直接决定集群的调度延迟与稳定性。而 Cilium 作为基于 eBPF 的新一代网络插件，在提供安全策略与可观测性的同时，也引入了额外的网络路径开销。本课程将构建一个可复现的 etcd 压测沙盘，系统性地分析 Cilium 网络延迟的构成，并给出可落地的调优方案。
1.1 为什么需要 etcd 压测沙盘？
生产环境中 etcd 的性能瓶颈往往难以隔离：磁盘 IO、网络抖动、CPU 争用、eBPF 钩子开销交织在一起。一个标准化的压测沙盘能够：
- 隔离变量：在容器化环境中固定 etcd 版本、存储后端、内核参数。
- 复现问题：模拟 leader 选举风暴、watch 堆积、大 key 写入等典型场景。
- 量化对比：在“裸机网络”与“Cilium 网络”两种模式下，测量 P99 延迟与吞吐差异。
沙盘设计原则：所有压测组件（etcd、benchmark 工具、Cilium agent）均运行在同一 Kubernetes 集群内，通过
hostNetwork: false 强制经过 Cilium 的 eBPF 数据路径，确保延迟数据真实反映 Cilium 开销。
1.2 Cilium 网络延迟的四大来源
基于 eBPF 的 Cilium 虽然比 iptables 模式有性能优势，但在高并发 etcd 场景下，以下四个环节仍可能成为延迟瓶颈：
| 延迟来源 | 触发场景 | 典型影响范围 |
|---|---|---|
| eBPF 钩子执行 | 每个数据包经过 tc_ingress / tc_egress 钩子 |
+10~50µs |
| 策略查找 | 启用 NetworkPolicy 或 FQDN 策略时 |
+20~200µs |
| 隧道封装 | 跨节点通信使用 VXLAN/Geneve 隧道 | +30~80µs |
| BPF map 竞争 | 高并发连接场景下 map 并发更新 | +5~30µs |
注意：etcd 的 gRPC 请求通常为小包（< 1KB），eBPF 钩子每包执行的开销占比相对更高。在 10K QPS 级别下，仅钩子执行就可能累积增加 100~500ms 的端到端延迟。
1.3 全景图：从压测到调优的闭环
本课程将围绕以下闭环路径展开，每个阶段都配有可执行的实验与指标：
压测沙盘搭建 → 延迟基线采集 → Cilium 路径分析 → 瓶颈定位 → 参数调优 → 效果验证
下图展示了 etcd 请求在 Cilium 网络中的完整数据流，以及每个环节可能引入的延迟点：
1.4 课程实验矩阵
整个课程将围绕以下 6 个核心实验展开，每个实验都对应一个具体的调优维度：
| 实验编号 | 实验名称 | 核心指标 | 调优目标 |
|---|---|---|---|
| E01 | 基线压测：裸机 vs Cilium | P99 延迟、QPS | 量化 Cilium 引入的额外延迟 |
| E02 | eBPF 钩子开销分析 | perf 事件、CPU 占比 | 减少不必要的钩子调用 |
| E03 | 策略引擎压力测试 | 策略匹配耗时 | 优化策略规则数量与复杂度 |
| E04 | 隧道模式对比 | 吞吐、延迟分布 | 选择最优封装模式 |
| E05 | BPF map 并发调优 | map 竞争次数 | 调整 map 大小与预分配 |
| E06 | 综合调优验证 | 端到端 P99 延迟 | 达到与裸机网络 < 5% 的性能差距 |
1.5 前置知识要求
为了最大化课程收益，建议学习者具备以下基础：
- 熟悉 etcd 的 Raft 共识算法与
etcdctl基本操作。 - 了解 Kubernetes 网络模型与 CNI 插件工作原理。
- 具备基本的 Linux 内核网络栈知识（socket、netfilter、eBPF）。
学习路径建议：如果对 eBPF 不熟悉，建议先阅读 Cilium 官方文档的
BPF and XDP Reference Guide 章节，再进入本课程的实验环节。