原文首發于我的博客：https://kaolengmian7.com/posts/k8s_cluster_server_performance_configuration_guide.htmlPC 端訪問我的博

原文首發于我的博客：https://kaolengmian7.com/posts/k8s_cluster_server_performance_configuration_guide.html

PC 端訪問我的博客可以獲得最優質的閱讀體驗同時也可以翻閱我的其他博文。

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