一、引言：硬件配置对k8s部署的重要性

Kubernetes（k8s）作为容器编排领域的标杆技术，其稳定性和性能高度依赖底层硬件资源的合理配置。无论是开发测试环境还是生产级集群，硬件选型不当可能导致资源争用、调度延迟甚至服务中断。本文将从CPU、内存、存储、网络四大核心维度，结合不同规模集群的典型场景，提供可落地的硬件配置建议。

二、CPU配置建议：核心数与主频的平衡

1. 控制平面（Control Plane）CPU需求

控制平面组件（API Server、Scheduler、Controller Manager、etcd）对CPU的计算能力敏感，尤其在集群规模扩大时：

• 小型集群（<50节点）：4核CPU（2.4GHz+）可满足基础需求，但需预留20%资源缓冲。
• 中型集群（50-200节点）：建议8核CPU（2.8GHz+），etcd需独立分配2核以避免I/O阻塞。
• 大型集群（>200节点）：推荐16核CPU（3.0GHz+），并采用多实例部署分散负载。

示例配置：

# etcd资源限制示例（需根据实际节点数调整）
resources:
  requests:
    cpu: "2000m"
  limits:
    cpu: "4000m"

2. 工作节点（Worker Node）CPU需求

工作节点的CPU配置需考虑Pod密度和业务类型：

• 计算密集型负载（如AI训练）：每节点至少16核，优先选择高主频（3.5GHz+）处理器。
• 通用型负载：8-12核可支持中等密度部署（每节点10-20个Pod）。
• I/O密集型负载：可适当降低核心数（6-8核），但需搭配高速存储。

优化建议：

• 启用CPU Manager静态策略（--cpu-manager-policy=static）提升高性能容器性能。
• 通过TopologySpreadConstraints避免Pod集中调度到同一物理核。

三、内存配置建议：容量与延迟的权衡

1. 控制平面内存需求

内存不足会导致API Server响应延迟或etcd崩溃：

• 小型集群：16GB内存（预留4GB缓冲）。
• 中型集群：32GB内存，etcd需独立8GB。
• 大型集群：64GB+内存，etcd建议配置32GB并启用--quota-backend-bytes=8G限制。

监控指标：

# 监控etcd内存使用
kubectl top pods -n kube-system | grep etcd

2. 工作节点内存需求

内存配置需匹配业务类型和Pod密度：

• 通用型负载：每节点32GB可支持20-30个普通Pod。
• 内存密集型负载（如数据库）：每节点64GB+，并启用MemoryPressure驱逐策略。
• 无状态服务：可适当降低至16GB，但需监控container_memory_working_set_bytes。

优化建议：

• 设置--kube-reserved和--system-reserved保留系统资源（如--kube-reserved=cpu=500m,memory=1Gi）。
• 使用--eviction-hard参数配置内存驱逐阈值（如memory.available<10%）。

四、存储配置建议：性能与可靠性的双重保障

1. etcd存储需求

etcd对存储延迟敏感，推荐使用SSD或NVMe：

• IOPS要求：至少500 IOPS（读）/200 IOPS（写）。
• 容量规划：每1000节点预留10GB存储空间（日志压缩后）。
• RAID配置：避免RAID 5，优先选择RAID 10或单盘。

示例配置：

# etcd存储卷配置
volumeClaimTemplates:
- metadata:
    name: etcd-data
  spec:
    accessModes: [ "ReadWriteOnce" ]
    storageClassName: "ssd-storage"
    resources:
      requests:
        storage: 50Gi

2. 工作节点存储需求

根据业务类型选择存储类型：

• 状态ful应用：推荐本地SSD（如hostPath）或云盘（如AWS EBS gp3）。
• 无状态应用：可使用网络存储（如NFS），但需监控I/O延迟。
• 日志存储：独立分配存储卷，避免与业务数据争用。

优化建议：

• 启用StorageClass动态 provisioning，结合VolumeBindingMode: WaitForFirstConsumer优化拓扑调度。
• 使用local存储类型时，通过nodeAffinity绑定特定节点。

五、网络配置建议：带宽与低延迟的协同

1. 控制平面网络需求

API Server需处理大量请求，推荐：

• 带宽：千兆网卡（小型集群）或万兆网卡（中型以上）。
• 负载均衡：使用F5或Nginx Ingress，配置健康检查和会话保持。

2. 工作节点网络需求

网络性能直接影响Pod通信效率：

• Overlay网络：Calico/Flannel需确保MTU≥1400。
• SR-IOV支持：高性能场景（如NFV）建议启用SR-IOV虚拟化。
• 多网卡绑定：通过bonding模式提升可用性。

监控命令：

# 检查网络延迟
kubectl exec -it <pod-name> -- ping <service-ip>

六、不同规模集群的硬件配置方案

1. 小型集群（<50节点）

• 控制平面：4核CPU/16GB内存，etcd独立2核/8GB。
• 工作节点：8核CPU/32GB内存，SSD存储。
• 网络：千兆网卡，单负载均衡器。

2. 中型集群（50-200节点）

• 控制平面：8核CPU/32GB内存，etcd独立4核/16GB。
• 工作节点：16核CPU/64GB内存，NVMe存储。
• 网络：万兆网卡，双负载均衡器。

3. 大型集群（>200节点）

• 控制平面：16核CPU/64GB内存，etcd分布式部署（3节点集群）。
• 工作节点：32核CPU/128GB内存，本地SSD+网络存储混合。
• 网络：25G网卡，SDN解决方案（如Cilium）。

七、总结与最佳实践

1. 预留资源缓冲：控制平面和工作节点均需预留20%-30%资源。
2. 监控与调优：通过Prometheus+Grafana监控kubelet_volume_stats_*等指标。
3. 定期升级：硬件生命周期管理，避免使用过时设备。
4. 混合部署：根据业务类型隔离节点（如计算型、存储型）。

附：硬件选型检查清单

• CPU核心数是否匹配Pod密度？
• 内存是否预留系统缓冲？
• 存储是否满足IOPS和延迟要求？
• 网络带宽是否支持高峰流量？

通过科学规划硬件资源，可显著提升k8s集群的稳定性和性能，为业务发展提供坚实基础。