[[278523]]

概述

做k8s集群工作節(jié)點的規(guī)劃時,首先需要考慮的問題是: 應(yīng)該使用哪種類型的服務(wù)器(Linux)實例節(jié)點,節(jié)點數(shù)量又需要多少個?

集群容量

通常k8s集群可以看作將多個服務(wù)器(Linux)節(jié)點抽象為一個大的”超級服務(wù)器節(jié)點”,該超級節(jié)點的總計算能力(如CPU和內(nèi)存)是所有組成節(jié)點的能力之和.假如要在群集上運行的一組應(yīng)用程序需要,需要一個總?cè)萘繛?個CPU內(nèi)核和32 GB 內(nèi)存的集群,可能的兩種實例類型及數(shù)量配置如下圖:

方案一: 使用2臺4核16GB服務(wù)器實例作為k8s工作節(jié)點

方案二: 使用4臺2核8GB服務(wù)器實例作為k8s工作節(jié)點

哪種方案更好呢? 我相信大多數(shù)人此時有點懵逼了吧,為解決大家的這個疑惑下面我分別對這兩種方案的利弊。

方案一

使用2臺4核16GB服務(wù)器實例作為k8s工作節(jié)點的情況

優(yōu)勢

1.減少管理開銷

與必須管理大量計算機(jī)相比，管理少量計算機(jī)較省力

2. 降低每個節(jié)點的成本

雖然功能更強(qiáng)大的機(jī)器比低端機(jī)器更昂貴，但價格上漲并不一定是線性的;如一臺具有10個CPU內(nèi)核和10 GB RAM的計算機(jī)可能比10臺具有1個CPU內(nèi)核和1 GB RAM的計算機(jī)便宜

3.允許運行需要大量資源的應(yīng)用程序

如果您有一個需要8 GB內(nèi)存的機(jī)器學(xué)習(xí)應(yīng)用程序，則不能在只有1 GB內(nèi)存的節(jié)點的群集上運行它;但是您可以在具有10 GB內(nèi)存節(jié)點的群集上運行它

劣勢

1.每個節(jié)點有大量Pod

每個Pod都會在該節(jié)點上運行的Kubernetes代理上引入一些開銷，例如容器運行時(例如Docker)，kubelet和cAdvisor。

kubelet對節(jié)點上的每個容器執(zhí)行常規(guī)的活動性和就緒性探測-更多的容器意味著kubelet在每次迭代中需要進(jìn)行更多的工作。

cAdvisor會收集節(jié)點上所有容器的資源使用情況統(tǒng)計信息，而kubelet會定期查詢此信息，并將其公開在其API上-同樣，這意味著cAdvisor和kubelet在每次迭代中都需要做更多的工作。

如果Pod的數(shù)量變大，這些事情可能會開始減慢系統(tǒng)速度，甚至使系統(tǒng)不可靠。

2.有限復(fù)制

少量節(jié)點可能會限制應(yīng)用程序的有效復(fù)制程度，如果您有一個由5個副本組成的高可用性應(yīng)用程序，但是只有2個節(jié)點，則該應(yīng)用程序的有效復(fù)制程度將降低為2。

3.爆炸半徑更大

如果您只有幾個節(jié)點，那么發(fā)生故障的節(jié)點的影響會比擁有多個節(jié)點的影響大。

4.大縮放比例

Kubernetes 為云基礎(chǔ)架構(gòu)提供了一個集群自動伸縮器，可根據(jù)當(dāng)前需求自動添加或刪除節(jié)點。

方案二

使用4臺2核8GB服務(wù)器實例作為k8s工作節(jié)點的情況;這種方法包括由許多小節(jié)點而不是幾個大節(jié)點組成集群。

這種方法的優(yōu)缺點是什么?

使用許多小節(jié)點的優(yōu)點主要對應(yīng)于使用少量大節(jié)點的缺點。

優(yōu)勢

1.爆炸半徑減小

如果您有100個Pod和10個節(jié)點，則每個節(jié)點平均僅包含10個Pod。因此，如果其中一個節(jié)點發(fā)生故障，則影響的pod數(shù)量較少。

很有可能只有您的某些應(yīng)用程序受到影響，并且可能只有少量的副本受到影響，因此整個應(yīng)用程序都不會受到影響。

2.允許高復(fù)制,實現(xiàn)高可靠性

Kubernetes調(diào)度程序可以將每個副本分配給更多不同的節(jié)點，這意味著，如果一個節(jié)點發(fā)生故障，最多將影響一個副本，并且您的應(yīng)用程序仍然可用。

劣勢

1.大量節(jié)點

使用較小的節(jié)點，則自然需要更多的節(jié)點才能達(dá)到給定的群集容量，對于Kubernetes控制平面而言，大量節(jié)點可能是一個挑戰(zhàn)。

如每個節(jié)點都需要能夠與其他每個節(jié)點進(jìn)行通信，這使得可能的通信路徑的數(shù)量與節(jié)點數(shù)量的平方成正比增長，所有這些都必須由控制平面進(jìn)行管理。

2.更多的系統(tǒng)開銷

Kubernetes在每個工作程序節(jié)點上運行一組系統(tǒng)守護(hù)進(jìn)程，如容器運行時Docker、kube-proxy、kubelet等，這些守護(hù)程序一起消耗固定數(shù)量的資源，如果使用許多小節(jié)點，則這些系統(tǒng)組件使用的資源部分會更大。

3.降低資源利用率

如果使用較小的節(jié)點，那么最終可能會遇到大量資源片段，這些資源片段太小而無法分配給任何工作負(fù)載，因此導(dǎo)致資源浪費。

4.小節(jié)點上的Pod限制

在某些云基礎(chǔ)架構(gòu)上，小節(jié)點上允許的最大Pod數(shù)量比您預(yù)期的受到更多限制，如Amazon Elastic Kubernetes服務(wù)(EKS)就是這種情況，其中每個節(jié)點的Pod的最大數(shù)量取決于實例類型。

結(jié)論

因此您應(yīng)該在集群中使用幾個大型節(jié)點還是多個小型節(jié)點?與往常一樣,通常沒有確定的答案!

如果您的應(yīng)用程序需要10 GB的內(nèi)存，則您可能不應(yīng)該使用小型節(jié)點-群集中的節(jié)點應(yīng)至少具有10 GB的內(nèi)存;

如果您的應(yīng)用程序需要10倍的復(fù)制才能實現(xiàn)高可用性，那么您可能不應(yīng)該僅使用2個節(jié)點-您的集群至少應(yīng)包含10個節(jié)點