K8s集群服务器性能配置指南

Master 节点配置

Master 节点的机器配置与集群节点总数有关，集群规模越大，所需要的 Master 规格也越高，不同集群规模的 Master 节点配置推荐如下：

Node 节点配置

Node 节点的配置一般不小于 2C4G，为保证系统的稳定运行，要预留 0.2C1G 给系统及K8s服务进程使用。 额外的，当可用内存小于 5% 时会根据 pod 资源优先级开始驱逐，pod 实际可使用的内存约为 （{节点内存} - 1G）✖️ 95%(例如：4G内存，可用约为2.8G)

如何分配节点配置

单个 Node 节点可创建的 Pod 数和 CPU 核心数有关，一般情况下Pod数 == CPU核心数 ✖️ 8，这意味着集群总CPU核心数✖️8要大于总Pod数。 此外还要考虑故障率与可用性，通常来讲机器数与可用性成正比，假设集群总核数为 240，如果可以容忍 10% 的错误，则需要保证至少 216 个核心在运行，这时候可以选择 10 台 24C 的机器，即便挂了一台剩下的 9 台仍能保证提供 216 个核心。 如果容忍度小于 5%，那么可以选择 20 台 12C 的机器，这样就算有一台节点出现故障，剩余节点仍可以支持现有业务正常运行（19✖️12=228）。 通过上面例子我们可以得出一个结论：在集群总核心数一定的情况下，节点配置越低，节点数量越多，随之可用性也会相应地提高。但也存在另外两个弊端：

• 一是需要预留给 K8S 的资源过多，造成浪费。
• 二是不便于容器调度。一个极端的例子，3 台 8 核的节点，可创建 6 个需要预留4核的Pod，但 12 台 2 核的节点，却无法响应一个需要预留 4 核资源的Pod请求。

总结

关于到底该给集群分配多少算力，首先需要看实际业务场景，业务膨胀了当然需要更多的机器。 至于到底需要多少机器，要结合总Pod数及单个Pod的算力申请上限、故障率与可用性、资源浪费率、容器调度能力等指标来考虑。 最后关于 CPU 和 内存的比例，对于 CPU 密集型的应用一般建议 1:2，如果是 Java 应用，可以给到 1:4。

参考：

1. https://docs.ucloud.cn/uk8s/introduction/node_requirements