概述
做k8s集群工作節點的規劃時,首先需要考慮的問題是: 應該使用哪種類型的服務器(Linux)實例節點,節點數量又需要多少個?
集群容量
通常k8s集群可以看作將多個服務器(Linux)節點抽象為一個大的”超級服務器節點”,該超級節點的總計算能力(如CPU和內存)是所有組成節點的能力之和.假如要在群集上運行的一組應用程序需要,需要一個總容量為8個CPU內核和32 GB 內存的集群,可能的兩種實例類型及數量配置如下圖:
方案一: 使用2臺4核16GB服務器實例作為k8s工作節點
方案二: 使用4臺2核8GB服務器實例作為k8s工作節點
哪種方案更好呢？ 我相信大多數人此時有點懵逼了吧,為解決大家的這個疑惑下面我分別對這兩種方案的利弊。
方案一
使用2臺4核16GB服務器實例作為k8s工作節點的情況
優勢
1.減少管理開銷
與必須管理大量計算機相比，管理少量計算機較省力
2. 降低每個節點的成本
雖然功能更強大的機器比低端機器更昂貴，但價格上漲並不一定是線性的;如一臺具有10個CPU內核和10 GB RAM的計算機可能比10臺具有1個CPU內核和1 GB RAM的計算機便宜
3.允許運行需要大量資源的應用程序
如果您有一個需要8 GB內存的機器學習應用程序，則不能在只有1 GB內存的節點的群集上運行它;但是您可以在具有10 GB內存節點的群集上運行它
劣勢
1.每個節點有大量Pod
每個Pod都會在該節點上運行的Kubernetes代理上引入一些開銷，例如容器運行時（例如Docker），kubelet和cAdvisor。
kubelet對節點上的每個容器執行常規的活動性和就緒性探測-更多的容器意味著kubelet在每次迭代中需要進行更多的工作。
cAdvisor會收集節點上所有容器的資源使用情況統計信息，而kubelet會定期查詢此信息，並將其公開在其API上-同樣，這意味著cAdvisor和kubelet在每次迭代中都需要做更多的工作。
如果Pod的數量變大，這些事情可能會開始減慢系統速度，甚至使系統不可靠。
2.有限複製
少量節點可能會限制應用程序的有效複製程度，如果您有一個由5個副本組成的高可用性應用程序，但是隻有2個節點，則該應用程序的有效複製程度將降低為2。
3.爆炸半徑更大
如果您只有幾個節點，那麼發生故障的節點的影響會比擁有多個節點的影響大。
4.大縮放比例
Kubernetes 為雲基礎架構提供了一個集群自動伸縮器，可根據當前需求自動添加或刪除節點。
方案二
使用4臺2核8GB服務器實例作為k8s工作節點的情況;這種方法包括由許多小節點而不是幾個大節點組成集群。
這種方法的優缺點是什麼?
使用許多小節點的優點主要對應於使用少量大節點的缺點。
優勢
1.爆炸半徑減小
如果您有100個Pod和10個節點，則每個節點平均僅包含10個Pod。因此，如果其中一個節點發生故障，則影響的pod數量較少。
很有可能只有您的某些應用程序受到影響，並且可能只有少量的副本受到影響，因此整個應用程序都不會受到影響。
2.允許高複製,實現高可靠性
Kubernetes調度程序可以將每個副本分配給更多不同的節點，這意味著，如果一個節點發生故障，最多將影響一個副本，並且您的應用程序仍然可用。
劣勢
1.大量節點
使用較小的節點，則自然需要更多的節點才能達到給定的群集容量，對於Kubernetes控制平面而言，大量節點可能是一個挑戰。
如每個節點都需要能夠與其他每個節點進行通信，這使得可能的通信路徑的數量與節點數量的平方成正比增長，所有這些都必須由控制平面進行管理。
2.更多的系統開銷
Kubernetes在每個工作程序節點上運行一組系統守護進程，如容器運行時Docker、kube-proxy、kubelet等，這些守護程序一起消耗固定數量的資源，如果使用許多小節點，則這些系統組件使用的資源部分會更大。
3.降低資源利用率
如果使用較小的節點，那麼最終可能會遇到大量資源片段，這些資源片段太小而無法分配給任何工作負載，因此導致資源浪費。
4.小節點上的Pod限制
在某些雲基礎架構上，小節點上允許的最大Pod數量比您預期的受到更多限制，如Amazon Elastic Kubernetes服務（EKS）就是這種情況，其中每個節點的Pod的最大數量取決於實例類型。
結論
因此您應該在集群中使用幾個大型節點還是多個小型節點？與往常一樣,通常沒有確定的答案！
如果您的應用程序需要10 GB的內存，則您可能不應該使用小型節點-群集中的節點應至少具有10 GB的內存;
如果您的應用程序需要10倍的複製才能實現高可用性，那麼您可能不應該僅使用2個節點-您的集群至少應包含10個節點
