2. 大型K8s集群架构设计：控制平面高可用、etcd集群规划、节点池与资源管理
在生产环境中部署大型Kubernetes集群，架构设计是稳定性的基石。本章聚焦于三个核心维度：控制平面高可用、etcd集群规划以及节点池与资源管理。错误的架构设计会导致集群在规模增长时出现性能瓶颈、脑裂甚至数据丢失。以下内容基于百节点以上集群的实战经验总结。
2.1 控制平面高可用设计
控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler）必须消除单点故障。推荐采用堆叠式etcd拓扑或外部etcd拓扑，但大型集群更倾向于外部etcd以获得更好的隔离性与扩展性。
关键指标： 控制平面节点数必须为奇数（3或5），避免因Leader选举平局导致集群不可用。5节点控制平面可容忍2个节点故障，3节点仅可容忍1个。
2.1.1 组件高可用部署策略
| 组件 | 高可用方式 | 关键配置 |
|---|---|---|
| kube-apiserver | 多实例 + 负载均衡（L4） | --advertise-address 指向本机IP；所有实例共享etcd |
| kube-controller-manager | Leader选举（--leader-elect=true） | --cluster-cidr 与 --service-cluster-ip-range 保持一致 |
| kube-scheduler | Leader选举（--leader-elect=true） | --profiling=false（生产建议关闭） |
实践建议： 使用Keepalived + HAProxy或云厂商NLB作为apiserver的前端入口。避免使用七层负载均衡（如Nginx Ingress）转发apiserver流量，因为apiserver对延迟极度敏感。
2.2 etcd集群规划
etcd是集群状态存储的核心，其性能直接决定控制平面的响应速度。大型集群必须对etcd进行独立规划，避免与控制平面组件争抢资源。
2.2.1 硬件与部署拓扑
- 磁盘： 必须使用SSD（NVMe优先），禁用磁盘缓存透传（Direct I/O）。etcd对写入延迟极其敏感，HDD或共享存储会导致频繁的Leader切换。
- 网络： 所有etcd成员之间延迟应小于10ms，建议部署在同一可用区或物理机架内。
- 内存： 至少8GB起步，推荐16GB以上。etcd的缓存大小由 --quota-backend-bytes 控制，默认2GB，大型集群建议提升至8GB。
避坑： 不要将etcd与控制平面节点混合部署在同一个Pod中（如Kind集群）。生产环境必须使用独立节点或独立虚拟机，并设置CPU pinning和内存预留。
2.2.2 集群规模与节点数
| 集群规模（节点数） | etcd节点数 | 推荐实例类型 | 存储配额 |
|---|---|---|---|
| 50 - 200 | 3 | 4C/16G + NVMe | 8GB |
| 200 - 1000 | 5 | 8C/32G + NVMe | 16GB |
| 1000+ | 5 或 7 | 16C/64G + NVMe | 32GB |
关键参数： --auto-compaction-retention=1（开启自动压缩，保留最近1小时的历史版本），--quota-backend-bytes=$((8*1024*1024*1024))（8GB）。定期执行 etcdctl defrag 释放碎片空间。
2.3 节点池与资源管理
大型集群通常承载多种类型的工作负载（在线服务、离线任务、GPU训练）。通过节点池（Node Pool）实现物理隔离与资源差异化配置，是保障SLA的基础。
2.3.1 节点池划分策略
- 系统节点池： 运行集群关键组件（CoreDNS、Ingress Controller、监控Agent）。建议使用高规格实例，并设置污点（Taint）防止普通Pod调度。
- 在线服务节点池： 运行延迟敏感型应用。使用包年包月实例，开启CPU Manager静态策略，避免CPU竞争。
- 离线任务节点池： 运行CI/CD、批处理作业。使用竞价实例或Spot实例，设置Pod优先级与抢占策略。
- GPU节点池： 运行AI训练任务。安装NVIDIA Device Plugin，配置NUMA对齐与拓扑调度。
2.3.2 资源配额与限制
| 资源类型 | 推荐限制策略 | 说明 |
|---|---|---|
| CPU | 每个节点预留1-2核给系统进程 | 通过 --system-reserved 和 --kube-reserved 配置 |
| 内存 | 预留20%给系统与kubelet | 避免内存超卖导致OOM Killer误杀系统进程 |
| PID | --pod-max-pids=4096 | 防止单节点Pod数过多导致PID耗尽 |
| 存储 | 每个节点限制本地临时存储使用量 | 通过 --eviction-hard=nodefs.available<10% 触发驱逐 |
实践建议： 使用 Descheduler 定期重平衡Pod分布，避免节点资源碎片化。结合 Cluster Autoscaler 实现节点池的弹性伸缩，但需设置最小/最大节点数防止成本失控。
2.4 架构总览图
下图展示了一个典型的大型K8s集群架构，包含外部etcd集群、多控制平面节点、以及按用途划分的节点池。
2.5 关键设计原则总结
- 奇数原则： 控制平面与etcd节点数始终为奇数，避免脑裂。
- 隔离原则： etcd与控制平面物理隔离；系统组件与业务组件通过节点池隔离。
- 预留原则： 节点资源必须预留（CPU、内存、PID、存储），防止系统组件被饿死。
- 监控原则： 对etcd的磁盘延迟、Leader变更次数、DB大小设置告警，阈值建议：磁盘延迟 < 10ms，Leader变更 < 0.1次/小时。
常见故障： 未设置 --kube-reserved 导致节点内存超卖，kubelet因OOM被杀死，进而触发大量Pod驱逐。务必在集群初始化阶段配置预留参数，后期修改需要重启kubelet。