[[278523]]

概述

做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個節點