原文首發於我的部落格：kaolengmian7.com/posts/k8s_cluster...
PC 端訪問我的部落格可以獲得最優質的閱讀體驗同時也可以翻閱我的其他博文。
Master 節點配置
Master 節點的機器配置與叢集節點總數有關，叢集規模越大，所需要的 Master 規格也越高，不同叢集規模的 Master 節點配置推薦如下：
| 節點規模 | Master 規格 |
|---|---|
| 1-10 個節點 | >=2 核 4G |
| 10-100 個節點 | >=4 核 8G |
| 100-250 個節點 | >=8 核 16G |
| 250-500 個節點 | >=16 核 32G |
| 500-1000 個節點 | >=32 核 64G |
| 1000 個以上節點 | 財富自由…… |
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。
參考：
本作品採用《CC 協議》，轉載必須註明作者和本文連結