[[278523]]

概述

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

集群容量

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

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

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

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

方案一

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

優(yōu)勢

1.減少管理開銷

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

2. 降低每個(gè)節(jié)點(diǎn)的成本

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

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

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

劣勢

1.每個(gè)節(jié)點(diǎn)有大量Pod

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

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

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

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

2.有限復(fù)制

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

3.爆炸半徑更大

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

4.大縮放比例

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

方案二

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

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

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

優(yōu)勢

1.爆炸半徑減小

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

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

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

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

劣勢

1.大量節(jié)點(diǎn)

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

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

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

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

3.降低資源利用率

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

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

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

結(jié)論

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

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

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