跨集群调度etcd压测沙盘性能调优与Cilium故障排查 - 第1节
1.1 跨集群调度背景：为什么需要打破单集群边界？
在单 Kubernetes 集群中，所有工作负载共享同一套控制面（etcd、API Server、Scheduler）和同一组节点资源。当业务规模增长或需要满足地理分布、容灾隔离、合规要求时，单集群架构会暴露出以下瓶颈：
| 维度 | 单集群瓶颈 | 跨集群调度的价值 |
|---|---|---|
| 控制面容量 | etcd 存储上限约 8GB，超过 5000 节点后性能急剧下降 | 拆分多个小集群，每个集群控制面独立，避免单点过载 |
| 故障域 | etcd 脑裂或 API Server 故障导致整个集群不可用 | 跨集群调度可将工作负载分散到不同故障域，实现单元化容灾 |
| 网络延迟 | 所有 Pod 通信经过同一 CNI 平面，跨 AZ 延迟不可控 | 按地域就近调度，Pod 与用户或数据源同区域部署 |
| 资源碎片 | 单集群内节点规格混杂，碎片率可达 30% 以上 | 跨集群聚合异构资源，将批处理任务调度到空闲集群 |
| 合规与租户隔离 | Namespace 隔离无法满足数据驻留、PCI-DSS 等硬性要求 | 不同集群承载不同合规等级的工作负载，调度策略按集群绑定 |
核心结论：跨集群调度不是替代单集群，而是在单集群之上构建一层调度抽象层，将多个集群视为统一的资源池，按策略分发工作负载。
1.2 etcd 在 Kubernetes 中的核心地位
etcd 是 Kubernetes 控制面的“状态数据库”，所有集群对象（Pod、Service、ConfigMap、Secret、Node 信息等）都存储在 etcd 中。其性能直接决定了整个集群的响应速度和稳定性。
1.2.1 etcd 在 K8s 架构中的位置
1.2.2 etcd 性能关键指标
| 指标 | 推荐值 | 超出后的影响 |
|---|---|---|
| DB 总大小 | < 8 GB | 超过后 WAL 压缩变慢，读写延迟飙升 |
| 每秒写入请求 (QPS) | < 10,000 | 超出后 follower 日志复制落后，触发 leader 切换 |
| 请求延迟 (P99) | < 10 ms | 超过 100ms 时 API Server 清单缓存失效，调度器决策延迟 |
| 磁盘 fsync 延迟 | < 10 ms | SSD 性能不足直接导致 Raft 心跳超时，集群脑裂 |
压测重点：本课程沙盘将使用 etcd 性能压测工具模拟高 QPS 写入场景，观察 etcd 在极限负载下的行为，并验证调优措施（如调整心跳间隔、快照策略、磁盘 I/O 隔离）的实际效果。
1.3 Cilium 网络组件简介
Cilium 是基于 eBPF 的 CNI 插件，在 Kubernetes 网络模型中承担数据平面和控制平面的双重角色。与传统的 iptables 模式不同，Cilium 将网络策略、负载均衡、可观测性下沉到内核 eBPF 程序中执行。
1.3.1 Cilium 核心组件
1.3.2 Cilium 在跨集群场景中的角色
- 集群间网络连通：通过 Cluster Mesh 功能，Cilium 可以在多个集群之间建立加密隧道（WireGuard / IPsec），实现 Pod IP 直通。
- 全局服务发现：结合 ExternalDNS 或 Cilium 的 Service 映射，跨集群服务可以通过统一 DNS 名称访问。
- 网络策略统一管理：使用 CiliumNetworkPolicy CRD，可以编写跨集群的网络隔离规则，不受集群边界限制。
- 故障排查利器：Hubble 提供完整的流量日志和 Service Map，帮助定位跨集群通信中的丢包、延迟、策略拒绝等问题。
1.4 沙盘环境快速部署：Kind + Multipass
本课程使用两种沙盘方案，覆盖本地开发与多节点模拟两种场景：
| 方案 | 适用场景 | 节点数 | 资源要求 | 部署耗时 |
|---|---|---|---|---|
| Kind (Kubernetes in Docker) | 本地快速验证、单机多集群 | 1 控制面 + 1~3 worker | 4 vCPU / 8 GB RAM | 3~5 分钟 |
| Multipass (Ubuntu VM) | 模拟真实节点、跨主机网络 | 2~5 个独立 VM | 8 vCPU / 16 GB RAM | 10~15 分钟 |
1.4.1 Kind 部署命令（单集群）
# 1. 创建 Kind 配置文件
cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF
# 2. 创建集群
kind create cluster --config kind-config.yaml --name k8s-sandbox
# 3. 验证集群状态
kubectl cluster-info --context kind-k8s-sandbox
kubectl get nodes -o wide1.4.2 Multipass 部署命令（多节点）
# 1. 创建 3 个 Ubuntu VM
for i in 1 2 3; do
multipass launch 22.04 --name node$i --cpus 2 --memory 4G --disk 20G
done
# 2. 在 node1 上安装 K8s 控制面
multipass exec node1 -- bash -c "
curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644
"
# 3. 获取加入 并让 node2/node3 加入
=$(multipass exec node1 sudo cat /var/lib/rancher/k3s/server/node-)
SERVER_IP=$(multipass info node1 | grep IPv4 | awk '{print $2}')
for i in 2 3; do
multipass exec node$i -- bash -c "
curl -sfL https://get.k3s.io | K3S_URL=https://$SERVER_IP:6443 K3S_=$ sh -
"
done
# 4. 验证集群
multipass exec node1 -- kubectl get nodes
沙盘选择建议：如果仅用于学习跨集群调度和 etcd 压测，Kind 足够；如果需要模拟 Cilium Cluster Mesh 跨主机网络故障，建议使用 Multipass 创建至少 2 个独立集群。
1.5 本章小结
- 跨集群调度解决了单集群在容量、故障域、延迟、合规方面的硬性限制。
- etcd 是 K8s 控制面的性能瓶颈点，压测与调优是 SRE 必备技能。
- Cilium 通过 eBPF 提供高性能网络，在跨集群场景中承担连通、策略、可观测性三重角色。
- 沙盘环境已就绪，下一章将进入 etcd 压测工具选型与基准测试。