2. 集群规划与设计：硬件选型、网络方案、存储方案与高可用架构
集群规划是K8s生命周期中最关键的决策阶段。硬件、网络、存储与高可用架构的选择直接影响集群的性能、运维复杂度与长期成本。本章从生产环境实战角度，给出可落地的选型建议与设计原则。
2.1 硬件选型：CPU / 内存 / 磁盘
硬件选型需根据集群规模、工作负载类型（计算密集型、内存密集型、IO密集型）以及控制面与数据面分离原则进行差异化配置。
| 节点角色 | CPU 推荐 | 内存推荐 | 磁盘推荐 | 关键考量 |
|---|---|---|---|---|
| Master / Control Plane | 4-8 核 (x86/ARM) | 8-16 GB | 100-200 GB SSD (etcd 专用盘) | etcd 对磁盘延迟极度敏感，必须使用 NVMe SSD；CPU 用于 API Server 与调度器 |
| Worker Node (通用) | 8-16 核 | 32-64 GB | 200-500 GB SSD (系统+容器镜像) | Pod 密度与资源预留比例需合理 |
| Worker Node (计算密集) | 32-64 核 | 64-128 GB | 500 GB SSD + 本地临时盘 | 考虑 CPU 亲和性与 NUMA 拓扑 |
| Worker Node (IO密集/存储) | 8-16 核 | 64-128 GB | 1-2 TB NVMe SSD (本地缓存) | 网络带宽与磁盘吞吐需匹配 |
选型避坑提示： 不要在所有节点上使用相同配置。控制面节点对磁盘延迟要求极高，但 CPU 利用率通常较低；Worker 节点则相反。混合配置可显著降低 TCO。
2.1.1 磁盘选型核心原则
- etcd 盘： 独立 NVMe SSD，建议 200GB+，禁用磁盘写入缓存，使用 ext4/xfs 文件系统。
- 系统盘： 通用 SSD，建议 200GB+，存放操作系统、容器运行时与 kubelet 日志。
- 容器镜像缓存盘： 建议 100GB+ SSD，避免镜像拉取成为 Pod 启动瓶颈。
- 本地临时卷 (emptyDir)： 使用内存或本地 SSD，注意 Pod 驱逐时数据丢失。
2.2 网络方案选型：Flannel / Calico / Cilium
容器网络是集群的血管。三种主流 CNI 插件在性能、安全策略与可观测性上差异明显。
| 特性 | Flannel | Calico | Cilium |
|---|---|---|---|
| 数据面 | VXLAN / Host-GW | BGP / VXLAN / IPIP | eBPF (XDP / TC) |
| 网络策略 | 不支持 | 支持 (iptables / eBPF) | 支持 (eBPF 原生) |
| 性能 | 中等 (VXLAN 封装开销) | 高 (BGP 直连) | 极高 (eBPF 绕过 iptables) |
| 可观测性 | 低 | 中等 (Felix 指标) | 高 (Hubble / 服务拓扑) |
| 运维复杂度 | 低 | 中 (BGP 配置) | 中高 (内核版本要求) |
| 适用场景 | 开发/测试、小规模集群 | 生产环境、多租户隔离 | 高性能、安全敏感、可观测性优先 |
选型建议： 生产环境优先选择 Calico 或 Cilium。若集群规模 < 50 节点且无网络策略需求，Flannel 可快速部署；若需要 L7 策略、服务网格集成或深度可观测性，Cilium 是当前最佳选择。
2.3 存储方案选型：NFS / Ceph / Longhorn
有状态应用需要持久化存储。三种方案在性能、运维复杂度与云原生集成度上各有优劣。
| 特性 | NFS | Ceph (RBD / CephFS) | Longhorn |
|---|---|---|---|
| 架构 | 中心化 (单点) | 分布式 (CRUSH) | 分布式 (微服务) |
| 性能 | 低 (网络 + 单点瓶颈) | 中高 (多副本写入) | 高 (本地优先 + 副本) |
| 运维复杂度 | 低 | 高 (MON/OSD/MGR) | 中 (Operator 管理) |
| K8s 集成 | CSI 驱动 (需 NFS 服务器) | 原生 CSI (RBD/CephFS) | 原生 CSI (Operator) |
| 数据高可用 | 需外部 HA (如 NFS-Ganesha) | 多副本 (默认 3) | 多副本 (默认 3) |
| 适用场景 | 开发/测试、共享只读数据 | 大规模生产、块存储/文件存储 | 中小规模生产、边缘集群 |
生产环境警告： NFS 在 K8s 中仅适用于开发测试或只读共享数据。生产环境的有状态应用（数据库、消息队列）应避免使用 NFS，因其单点故障风险与性能瓶颈难以接受。
2.3.1 存储选型决策清单
- 开发/测试集群： NFS 或 Longhorn（单副本模式）快速搭建。
- 生产集群（< 100 节点）： Longhorn 是云原生首选，运维简单，支持备份与灾备。
- 生产集群（> 100 节点 / 高性能需求）： Ceph 提供块、文件、对象统一存储，但需要专职运维团队。
- 边缘集群 / 资源受限： Longhorn 轻量级，适合低资源环境。
2.4 高可用架构设计
K8s 控制面高可用是集群稳定性的基石。设计目标：任意单点故障不影响集群 API 可用性。
2.4.1 控制面高可用架构
生产环境至少部署 3 个 Master 节点，使用负载均衡器分发 API Server 请求。etcd 集群与控制面组件分离部署。
2.4.2 Worker 节点高可用
- Pod 反亲和性： 将有状态应用副本调度到不同 Worker 节点。
- PodDisruptionBudget (PDB)： 设置最小可用副本数，防止节点维护时服务中断。
- 节点自动修复： 使用 Cluster API 或云厂商节点组实现故障节点自动替换。
- 多可用区部署： 将 Worker 节点分布在不同可用区，容忍区域故障。
2.4.3 高可用架构检查清单
| 组件 | 高可用要求 | 推荐配置 |
|---|---|---|
| API Server | 多副本 + 负载均衡 | 3 副本，轮询或最少连接 |
| etcd | 奇数节点，Raft 共识 | 3 或 5 节点，独立磁盘 |
| Scheduler / Controller Manager | Leader Election | 3 副本，自动选主 |
| CoreDNS | 多副本 + 反亲和 | 2-3 副本，HPA 自动扩缩 |
| Ingress Controller | 多副本 + 外部 LB | 2+ 副本，DaemonSet 或 Deployment |
架构设计原则： 控制面组件全部采用多副本 + 选主机制；数据面（Worker）通过反亲和与 PDB 保障；存储层使用分布式方案并配置多副本。三者结合才能实现真正的生产级高可用。