在 Kubernetes 集群中，如何正確選擇工作節(jié)點資源大小

簡要概述： 本文討論了在Kubernetes集群中選擇較少數(shù)量的較大節(jié)點和選擇較多數(shù)量的較小節(jié)點之間的利弊。

當創(chuàng)建一個Kubernetes集群時，最初的問題之一是：“我應該使用什么類型的工作節(jié)點，以及需要多少個？”

如果正在構(gòu)建一個本地集群，是應該采購一些上一代的高性能服務器，還是利用數(shù)據(jù)中心中閑置的幾臺老舊機器呢？

或者，如果正在使用像Google Kubernetes Engine（GKE）這樣的托管式Kubernetes服務，是應該選擇八個n1-standard-1實例還是兩個n1-standard-4實例來實現(xiàn)所需的計算能力呢？

目錄

1. 集群容量
2. Kubernetes工作節(jié)點中的預留資源
3. 工作節(jié)點中的資源分配和效率
4. 彈性和復制
5. 擴展增量和前導時間
6. 拉取容器鏡像
7. Kubelet和擴展Kubernetes API
8. 節(jié)點和集群限制
9. 存儲
10. 總結(jié)和結(jié)論

集群容量

一般來說，Kubernetes集群可以被看作是將一組獨立的節(jié)點抽象為一個大的“超級節(jié)點”。

這個超級節(jié)點的總計算能力（包括CPU和內(nèi)存）是所有組成節(jié)點的能力之和。

有多種實現(xiàn)這一目標的方法。例如，假設您需要一個總計算能力為8個CPU核心和32GB內(nèi)存的集群。以下是兩種可能的集群設計方式：

Kubernetes集群中的小型節(jié)點與大型節(jié)點

這兩種選擇都會得到相同容量的集群。

左邊的選擇使用了四個較小的節(jié)點，而右邊的選擇使用了兩個較大的節(jié)點。

問題是：哪種方法更好呢？

為了做出明智的決策，讓我們深入了解如何在工作節(jié)點中分配資源。

Kubernetes工作節(jié)點中的預留資源

Kubernetes集群中的每個工作節(jié)點都是一個運行kubelet（Kubernetes代理）的計算單元。

kubelet是一個連接到控制平面的二進制文件，用于將節(jié)點的當前狀態(tài)與集群的狀態(tài)同步。

例如，當Kubernetes調(diào)度程序?qū)⒁粋€Pod分配給特定節(jié)點時，它不會直接向kubelet發(fā)送消息。相反，它會創(chuàng)建一個Binding對象并將其存儲在etcd中。

kubelet定期檢查集群的狀態(tài)。一旦它注意到將一個新分配的Pod分配給其節(jié)點，它就會開始下載Pod的規(guī)范并創(chuàng)建它。

通常將kubelet部署為SystemD服務，并作為操作系統(tǒng)的一部分運行。

kubelet、SystemD和操作系統(tǒng)需要資源，包括CPU和內(nèi)存，以確保正確運行。

因此，并不是所有工作節(jié)點的資源都僅用于運行Pod。

CPU和內(nèi)存資源通常分配如下：

操作系統(tǒng)。Kubelet。Pods。驅(qū)逐閾值。

Kubernetes節(jié)點中的資源分配

您可能想知道這些組件分配了哪些資源。雖然具體配置可能會有所不同，但CPU分配通常遵循以下模式：

第一個核心的6%。后續(xù)核心的1%（最多2個核心）。接下來的兩個核心的0.5%（最多4個核心）。四個核心以上的任何核心的0.25%。內(nèi)存分配可能如下：

小于1GB內(nèi)存的機器分配255 MiB內(nèi)存。前4GB內(nèi)存的25%。接下來的4GB內(nèi)存的20%（最多8GB）。接下來的8GB內(nèi)存的10%（最多16GB）。接下來的112GB內(nèi)存的6%（最多128GB）。超過128GB的任何內(nèi)存的2%。最后，驅(qū)逐閾值通常保持在100MB。

驅(qū)逐閾值 驅(qū)逐閾值代表內(nèi)存使用的閾值。如果一個節(jié)點超過了這個閾值，kubelet將開始驅(qū)逐Pod，因為當前節(jié)點的內(nèi)存不足。

考慮一個具有8GB內(nèi)存和2個虛擬CPU的實例。資源分配如下：

70毫核虛擬CPU和1.8GB供kubelet和操作系統(tǒng)使用（通常一起打包）。保留100MB用于驅(qū)逐閾值。剩余的6.1GB內(nèi)存和1930毫核可以分配給Pod。只有總內(nèi)存的75%用于執(zhí)行工作負載。

但這還不止于此。

您的節(jié)點可能需要在每個節(jié)點上運行一些Pod（例如DaemonSets）以確保正確運行，而這些Pod也會消耗內(nèi)存和CPU資源。

例如，Kube-proxy、諸如Fluentd或Fluent Bit的日志代理、NodeLocal DNSCache或CSI驅(qū)動程序等。

這是一個固定的成本，無論節(jié)點大小如何，您都必須支付。

帶有DaemonSets的Kubernetes節(jié)點中的資源分配 考慮到這一點，讓我們來看一下"較少數(shù)量的較大節(jié)點"和"較多數(shù)量的較小節(jié)點"這兩種截然相反的方法的利弊。

請注意，本文中的"節(jié)點"始終指的是工作節(jié)點。關于控制平面節(jié)點的數(shù)量和大小的選擇是一個完全不同的主題。

工作節(jié)點中的資源分配和效率

隨著更大實例的使用，kubelet預留的資源會減少。

讓我們來看兩種極端情況。

您想要為一個請求0.3個vCPU和2GB內(nèi)存的應用部署七個副本。

在第一種情況下，您將為一個單獨的工作節(jié)點提供資源以部署所有副本。在第二種情況下，您在每個節(jié)點上部署一個副本。為簡單起見，我們假設這些節(jié)點上沒有運行任何DaemonSets。

七個副本所需的總資源為2.1個vCPU和14GB內(nèi)存（即7 x 300m = 2.1個vCPU和7 x 2GB = 14GB）。

一個4個vCPU和16GB內(nèi)存的實例能夠運行這些工作負載嗎？

我們來計算一下CPU的預留：

第一個核心的6% = 60m +
第二個核心的1% = 10m +
剩余核心的0.5% = 10m
總計 = 80m

用于運行Pod的可用CPU為3.9個vCPU（即4000m - 80m）——綽綽有余。

接下來，我們來看一下kubelet預留的內(nèi)存：

前4GB內(nèi)存的25% = 1GB
接下來的4GB內(nèi)存的20% = 0.8GB
接下來的8GB內(nèi)存的10% = 0.8GB
總計 = 2.8GB

分配給Pod的總內(nèi)存為16GB -（2.8GB + 0.1GB）——這里的0.1GB考慮到了100MB的驅(qū)逐閾值。

最后，Pod可以使用最多13.1GB的內(nèi)存。

帶有2個vCPU和16GB內(nèi)存的Kubernetes節(jié)點中的資源分配

不幸的是，這還不夠（即7個副本需要14GB的內(nèi)存，但您只有13.1GB），您應該為部署這些工作負載提供更多內(nèi)存的計算單元。

如果使用云提供商，下一個可用的增量計算單元是4個vCPU和32GB內(nèi)存。

帶有2個vCPU和16GB內(nèi)存的節(jié)點不足以運行七個副本

太好了！

接下來，讓我們看一下另一種情況，即我們嘗試找到適合一個副本的最小實例，該副本的請求為0.3個vCPU和2GB內(nèi)存。

我們嘗試使用具有1個vCPU和4GB內(nèi)存的實例類型。

預留的CPU總共為6%或60m，可用于Pod的CPU為940m。

由于該應用僅需要300m的CPU，這足夠了。

kubelet預留的內(nèi)存為25%或1GB，再加上額外的0.1GB的驅(qū)逐閾值。

Pod可用的總內(nèi)存為2.9GB；由于該應用僅需要2GB，這個值足夠了。

太棒了！

帶有2個vCPU和16GB內(nèi)存的Kubernetes節(jié)點中的資源分配 現(xiàn)在，讓我們比較這兩種設置。

第一個集群的總資源只是一個單一節(jié)點 — 4個vCPU和32GB。

第二個集群有七個實例，每個實例都有1個vCPU和4GB內(nèi)存（總共為7個vCPU和28GB內(nèi)存）。

在第一個示例中，為Kubernetes預留了2.9GB的內(nèi)存和80m的CPU。

而在第二個示例中，預留了7.7GB（1.1GB x 7個實例）的內(nèi)存和360m（60m x 7個實例）的CPU。

您已經(jīng)可以注意到，在配置較大的節(jié)點時，資源的利用效率更高。

在單一節(jié)點集群和多節(jié)點集群之間比較資源分配情況

但還有更多。

較大的實例仍然有空間來運行更多的副本 — 但有多少個呢？

預留的內(nèi)存為3.66GB（3.56GB的kubelet + 0.1GB的驅(qū)逐閾值），可用于Pod的總內(nèi)存為28.44GB。預留的CPU仍然是80m，Pods可以使用3920m。此時，您可以通過以下方式找到內(nèi)存和CPU的最大副本數(shù)：

Total CPU   3920 /
Pod CPU      300
------------------
Max Pod       13.1

您可以為內(nèi)存重復進行計算：

總內(nèi)存 28.44 /
Pod內(nèi)存 2
最大Pod 14.22

以上數(shù)字表明，內(nèi)存不足可能會在CPU之前用盡，而在4個vCPU和32GB工作節(jié)點中最多可以托管13個Pod。

為2個vCPU和32GB工作節(jié)點計算Pod容量 那么第二種情況呢？

是否還有空間進行擴展？

實際上并沒有。

雖然這些實例仍然具有更多的CPU，但在部署第一個Pod后，它們只有0.9GB的可用內(nèi)存。

為1個vCPU和4GB工作節(jié)點計算Pod容量 總之，不僅較大的節(jié)點能更好地利用資源，而且還可以最小化資源的碎片化并提高效率。

這是否意味著您應該始終提供較大的實例？

讓我們來看另一個極端情況：節(jié)點意外丟失時會發(fā)生什么？

彈性和復制

較少數(shù)量的節(jié)點可能會限制您的應用程序的有效復制程度。

例如，如果您有一個由5個副本組成的高可用應用程序，但只有兩個節(jié)點，那么有效的復制程度將降低為2。

這是因為這五個副本只能分布在兩個節(jié)點上，如果其中一個節(jié)點失敗，可能會一次性失去多個副本。

具有兩個節(jié)點和五個副本的集群的復制因子為兩個

另一方面，如果您至少有五個節(jié)點，每個副本都可以在一個單獨的節(jié)點上運行，而單個節(jié)點的故障最多會導致一個副本失效。

因此，如果您有高可用性要求，您可能需要在集群中擁有一定數(shù)量的節(jié)點。

具有五個節(jié)點和五個副本的集群的復制因子為五 您還應該考慮節(jié)點的大小。

當較大的節(jié)點丟失時，一些副本最終會被重新調(diào)度到其他節(jié)點。

如果節(jié)點較小，僅托管了少量工作負載，則調(diào)度器只會重新分配少數(shù)Pod。

雖然您不太可能在調(diào)度器中遇到任何限制，但重新部署許多副本可能會觸發(fā)集群自動縮放器。

并且根據(jù)您的設置，這可能會導致進一步的減速。

讓我們來探討一下原因。

擴展增量和前導時間

您可以使用水平擴展器（即增加副本數(shù)量）和集群自動縮放器（即增加節(jié)點計數(shù)）的組合來擴展部署在Kubernetes上的應用程序。

假設您的集群達到總?cè)萘浚?jié)點大小如何影響自動縮放？

首先，您應該知道，當集群自動縮放器觸發(fā)自動縮放時，它不會考慮內(nèi)存或可用的CPU。

換句話說，總體上使用的集群不會觸發(fā)集群自動縮放器。

相反，當一個Pod因資源不足而無法調(diào)度時，集群自動縮放器會創(chuàng)建更多的節(jié)點。

此時，自動縮放器會調(diào)用云提供商的API，為該集群提供更多的節(jié)點。

集群自動縮放器在Pod由于資源不足而處于掛起狀態(tài)時提供新的節(jié)點。

集群自動縮放器在Pod由于資源不足而處于掛起狀態(tài)時提供新的節(jié)點。

不幸的是，通常情況下，配置節(jié)點是比較緩慢的。

要創(chuàng)建一個新的虛擬機可能需要幾分鐘的時間。

提供較大或較小實例的配置時間是否會改變？

不，通常情況下，無論實例的大小如何，配置時間都是恒定的。

此外，集群自動縮放器不限于一次添加一個節(jié)點；它可能會一次添加多個節(jié)點。

我們來看一個例子。

有兩個集群：

第一個集群有一個4個vCPU和32GB的單一節(jié)點。第二個集群有13個1個vCPU和4GB的節(jié)點。一個具有0.3個vCPU和2GB內(nèi)存的應用程序部署在集群中，并擴展到13個副本。

這兩種設置都已達到總?cè)萘?/p>

當部署擴展到15個副本時會發(fā)生什么（即增加兩個副本）？

在兩個集群中，集群自動縮放器會檢測到由于資源不足，額外的Pod無法調(diào)度，并進行如下配置：

對于第一個集群，增加一個具有4個vCPU和32GB內(nèi)存的額外節(jié)點。對于第二個集群，增加兩個具有1個vCPU和4GB內(nèi)存的節(jié)點。由于在為大型實例或小型實例提供資源時沒有時間差異，這兩種情況下節(jié)點將同時可用。

然而，你能看出另一個區(qū)別嗎？

第一個集群還有空間可以容納11個額外的Pod，因為總?cè)萘渴?3個。

而相反，第二個集群仍然達到了最大容量。

你可以認為較小的增量更加高效和更便宜，因為你只添加所需的部分。

但是讓我們觀察一下當您再次擴展部署時會發(fā)生什么——這次擴展到17個副本（即增加兩個副本）。

第一個集群在現(xiàn)有節(jié)點上創(chuàng)建了兩個額外的Pod。而第二個集群已經(jīng)達到了容量上限。Pod處于待定狀態(tài)，觸發(fā)了集群自動縮放器。最終，又會多出兩個工作節(jié)點。

在第一個集群中，擴展幾乎是瞬間完成的。

而在第二個集群中，您必須等待節(jié)點被配置完畢，然后才能讓Pod開始提供服務。

換句話說，在前者的情況下，擴展速度更快，而在后者的情況下，需要更多的時間。

通常情況下，由于配置時間在幾分鐘范圍內(nèi)，您應該謹慎考慮何時觸發(fā)集群自動縮放器，以避免產(chǎn)生更長的Pod等待時間。

換句話說，如果您能夠接受（潛在地）沒有充分利用資源的情況，那么通過使用較大的節(jié)點，您可以實現(xiàn)更快的擴展。

但事情并不止于此。

拉取容器鏡像也會影響您能夠多快地擴展工作負載，這與集群中的節(jié)點數(shù)量有關。

拉取容器鏡像

在Kubernetes中創(chuàng)建Pod時，其定義存儲在etcd中。

kubelet的工作是檢測到Pod分配給了它的節(jié)點并創(chuàng)建它。

kubelet將會：

• 從控制平面下載定義。
• 調(diào)用容器運行時接口（CRI）來創(chuàng)建Pod的沙箱。CRI會調(diào)用容器網(wǎng)絡接口（CNI）來將Pod連接到網(wǎng)絡。
• 調(diào)用容器存儲接口（CSI）來掛載任何容器卷。

在這些步驟結(jié)束時，Pod就已經(jīng)存在了，kubelet可以繼續(xù)檢查活躍性和就緒性探針，并更新控制平面以反映新Pod的狀態(tài)。

kubelet與CRI、CSI和CNI接口需要注意的是，當CRI在Pod中創(chuàng)建容器時，它必須首先下載容器鏡像。

這當然是在當前節(jié)點上的容器鏡像沒有緩存的情況下。

讓我們來看一下這如何影響以下兩個集群的擴展：

第一個集群有一個4個vCPU和32GB的單一節(jié)點。第二個集群有13個1個vCPU和4GB的節(jié)點。讓我們部署一個使用基于OpenJDK的容器鏡像的應用程序，該應用程序使用0.3個vCPU和2GB內(nèi)存，容器鏡像大小為1GB（僅基礎鏡像大小為775MB）的13個副本。

對這兩個集群會發(fā)生什么？

在第一個集群中，容器運行時只下載一次鏡像并運行13個副本。在第二個集群中，每個容器運行時都會下載并運行鏡像。在第一個方案中，只需要下載1GB的鏡像。

容器運行時下載一次容器鏡像并運行13個副本 然而，在第二個方案中，您需要下載13GB的容器鏡像。

由于下載需要時間，第二個集群在創(chuàng)建副本方面比第一個集群要慢。

此外，它會使用更多的帶寬并發(fā)起更多的請求（即至少每個鏡像層一個請求，共計13次），這使得它更容易受到網(wǎng)絡故障的影響。

13個容器運行時中的每一個都會下載一個鏡像 需要注意的是，這個問題會與集群自動縮放器緊密關聯(lián)。

如果您的節(jié)點較小：

• 集群自動縮放器會同時配置多個節(jié)點。
• 一旦準備好，每個節(jié)點都開始下載容器鏡像。
• 最終，Pod被創(chuàng)建。

當您配置較大的節(jié)點時，容器鏡像很可能已經(jīng)在節(jié)點上緩存，Pod可以立即開始運行。

想象一下?lián)碛?個節(jié)點的集群，每個節(jié)點上有一個副本。

最終，Pod會被創(chuàng)建在節(jié)點上。

想象一下?lián)碛?個節(jié)點的集群，每個節(jié)點上有一個副本。

該集群已經(jīng)滿載；將副本擴展到16個會觸發(fā)集群自動縮放器。

一旦節(jié)點被配置完畢，容器運行時會下載容器鏡像。最終，Pod會在節(jié)點上創(chuàng)建。

所以，您是否應該始終配置較大的節(jié)點？

未必如此。

您可以通過容器注冊表代理來減輕節(jié)點下載相同容器鏡像的情況。

在這種情況下，鏡像仍然會被下載，但是從當前網(wǎng)絡中的本地注冊表中下載。

或者您可以使用諸如spegel之類的工具來預熱節(jié)點的緩存。

使用Spegel，節(jié)點是可以廣告和共享容器鏡像層的對等體。

在這種情況下，容器鏡像將從其他工作節(jié)點下載，Pod幾乎可以立即啟動。

但是，容器帶寬并不是您必須控制的唯一帶寬。

Kubelet與Kubernetes API的擴展

kubelet被設計為從控制平面中獲取信息。

因此，在規(guī)定的間隔內(nèi)，kubelet會向Kubernetes API發(fā)出請求，以檢查集群的狀態(tài)。

但是控制平面不是會向kubelet發(fā)送指令嗎？

拉取模型更容易擴展，因為：

• 控制平面不需要將消息推送到每個工作節(jié)點。
• 節(jié)點可以以自己的速度獨立地查詢API服務器。
• 控制平面不需要保持與kubelet的連接打開。

請注意，也有顯著的例外情況。例如，諸如kubectl logs和kubectl exec之類的命令需要控制平面連接到kubelet（即推送模型）。

但是Kubelet不僅僅是為了查詢信息。

它還向主節(jié)點報告信息。

例如，kubelet每十秒向集群報告一次節(jié)點的狀態(tài)。

此外，當準備探針失敗時（以及應從服務中刪除pod端點），kubelet會通知控制平面。

而且kubelet會通過容器指標將控制平面保持更新。

換句話說，kubelet會通過從控制平面發(fā)出請求（即從控制平面和向控制平面）來保持節(jié)點正常運行所需的狀態(tài)。

在Kubernetes 1.26及更早版本中，kubelet每秒可以發(fā)出多達5個請求（在Kubernetes >1.27中已放寬此限制）。

所以，假設您的kubelet正以最大容量運行（即每秒5個請求），當您運行幾個較小的節(jié)點與一個單一的大節(jié)點時會發(fā)生什么？

讓我們看看我們的兩個集群：

• 第一個集群有一個4個vCPU和32GB的單一節(jié)點。
• 第二個集群有13個1個vCPU和4GB的節(jié)點。
• 第一個集群生成5個每秒的請求。

一個kubelet每秒發(fā)出5個請求

第二個集群每秒發(fā)出65個請求（即13 x 5）。

13個kubelet每秒各自發(fā)出5個請求

當您運行具有許多較小節(jié)點的集群時，您應該將API服務器的擴展性擴展到處理更頻繁的請求。

而反過來，這通常意味著在較大的實例上運行控制平面或運行多個控制平面。

節(jié)點和集群限制

Kubernetes集群的節(jié)點數(shù)量是否有限制？

Kubernetes被設計為支持多達5000個節(jié)點。

然而，這并不是一個嚴格的限制，正如Google團隊所演示的，允許您在15,000個節(jié)點上運行GKE集群。

對于大多數(shù)用例來說，5000個節(jié)點已經(jīng)是一個很大的數(shù)量，可能不會是影響您決定選擇較大還是較小節(jié)點的因素。

相反，您可以運行在節(jié)點中運行的最大Pod數(shù)可能會引導您重新思考集群架構(gòu)。

那么，在Kubernetes節(jié)點中，您可以運行多少個Pod？

大多數(shù)云提供商允許您在每個節(jié)點上運行110到250個Pod。

如果您自己配置集群，則默認為110。

在大多數(shù)情況下，這個數(shù)字不是kubelet的限制，而是云提供商對重復預定IP地址的風險的容忍度。

為了理解這是什么意思，讓我們退后一步，看看集群網(wǎng)絡是如何構(gòu)建的。

在大多數(shù)情況下，每個工作節(jié)點都被分配一個具有256個地址的子網(wǎng)（例如10.0.1.0/24）。

每個工作節(jié)點都被分配一個子網(wǎng)

其中兩個是受限制的，您可以使用254來運行您的Pods。

考慮這種情況，其中在同一個節(jié)點上有254個Pod。

您創(chuàng)建了一個更多的Pod，但已經(jīng)耗盡了可用的IP地址，它保持在掛起狀態(tài)。

為了解決這個問題，您決定將副本數(shù)減少到253。

那么掛起的Pod會在集群中被創(chuàng)建嗎？

可能不會。

當您刪除Pod時，其狀態(tài)會變?yōu)椤罢诮K止”。

kubelet向Pod發(fā)送SIGTERM信號（以及調(diào)用preStop生命周期鉤子（如果存在）），并等待容器優(yōu)雅地關閉。

如果容器在30秒內(nèi)沒有終止，kubelet將發(fā)送SIGKILL信號到容器，并強制進程終止。

在此期間，Pod仍未釋放IP地址，流量仍然可以到達它。

當Pod最終被刪除時，IP地址被釋放。

kubelet通知控制平面Pod已成功刪除。IP地址終于被釋放。

想象一下您的節(jié)點正在使用所有可用的IP地址。

當一個Pod被刪除時，kubelet會收到變更通知。

如果Pod有一個preStop鉤子，首先會調(diào)用它。然后，kubelet會向容器發(fā)送SIGTERM信號。

默認情況下，進程有30秒的時間來退出，包括preStop鉤子。如果在這之前進程沒有退出，kubelet會發(fā)送SIGKILL信號，強制終止進程。

kubelet會通知控制平面Pod已成功刪除。IP地址最終被釋放。

當一個Pod被刪除時，IP地址不會立即釋放。您必須等待優(yōu)雅的關閉。

這是一個好主意嗎？

好吧，沒有其他可用的IP地址 - 所以您沒有選擇。

想象一下，您的節(jié)點正在使用所有可用的IP地址。

一旦Pod被刪除，IP地址就可以被重新使用。

kubelet通知控制平面Pod已成功刪除。IP地址終于被釋放。

此時，掛起的Pod可以被創(chuàng)建，并且分配給它與上一個相同的IP地址。

想象一下，您的節(jié)點正在使用所有可用的IP地址。

下一頁

那后果會怎樣？

還記得我們提到過，Pod應該優(yōu)雅地關閉并處理所有未處理的請求嗎？

嗯，如果Pod被突然終止（即沒有優(yōu)雅的關閉），并且IP地址立即分配給另一個Pod，那么所有現(xiàn)有的應用程序和Kubernetes組件可能仍然不知道這個更改。

入口控制器將流量路由到一個IP地址。

如果IP地址在沒有等待優(yōu)雅關閉的情況下被回收并被一個新的Pod使用，入口控制器可能仍然會將流量路由到該IP地址。

因此，一些現(xiàn)有的流量可能會錯誤地發(fā)送到新的Pod，因為它與舊的Pod具有相同的IP地址。

為了避免這個問題，您可以分配較少的IP地址（例如110）并使用剩余的IP地址作為緩沖區(qū)。

這樣，您可以相當肯定地確保不會立即重新使用相同的IP地址。

存儲

計算單元對可以附加的磁盤數(shù)量有限制。

例如，在Azure上，具有2個vCPU和8GB內(nèi)存的Standard_D2_v5實例最多可以附加4個數(shù)據(jù)磁盤。

如果您希望將StatefulSet部署到使用Standard_D2_v5實例類型的工作節(jié)點上，您將無法創(chuàng)建超過四個副本。

這是因為StatefulSet中的每個副本都附加有一個磁盤。

一旦創(chuàng)建第五個副本，Pod將保持掛起狀態(tài)，因為無法將持久卷聲明綁定到持久卷。

為什么呢？

因為每個持久卷都是一個附加的磁盤，所以您在該實例中只能有4個。

那么，您有哪些選擇？

您可以提供一個更大的實例。

或者您可以使用不同的子路徑字段重新使用相同的磁盤。

讓我們看一個例子。

下面的持久卷需要一個具有16GB空間的磁盤：

如果您將此資源提交到集群，您將看到創(chuàng)建了一個持久卷并綁定到它。

$ kubectl get pv,pvc

持久卷與持久卷聲明之間存在一對一的關系，因此您無法有更多的持久卷聲明來使用相同的磁盤。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app1
spec:
  selector:
    matchLabels:
      name: app1
  template:
    metadata:
      labels:
        name: app1
    spec:
      volumes:
        - name: pv-storage
          persistentVolumeClaim:
            claimName: shared
      containers:
        - name: main
          image: busybox
          volumeMounts:
            - mountPath: '/data'
              name: pv-storage

如果您想在您的Pod中使用該聲明，可以這樣做：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app2
spec:
  selector:
    matchLabels:
      name: app2
  template:
    metadata:
      labels:
        name: app2
    spec:
      volumes:
        - name: pv-storage
          persistentVolumeClaim:
            claimName: shared
      containers:
        - name: main
          image: busybox
          volumeMounts:
            - mountPath: '/data'
              name: pv-storage

您可以有另一個使用相同持久卷聲明的部署：

但是，通過這種配置，兩個Pod將在同一個文件夾中寫入其數(shù)據(jù)。

您可以通過在subPath中使用子目錄來解決此問題。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app2
spec:
  selector:
    matchLabels:
      name: app2
  template:
    metadata:
      labels:
        name: app2
    spec:
      volumes:
        - name: pv-storage
          persistentVolumeClaim:
            claimName: shared
      containers:
        - name: main
          image: busybox
          volumeMounts:
            - mountPath: '/data'
              name: pv-storage

          subPath: app2

部署將在以下路徑上寫入其數(shù)據(jù)：

• 對于第一個部署，是/data/app1
• 對于第二個部署，是/data/app2

這個解決方法并不是完美的，有一些限制：

所有部署都必須記住使用subPath。如果需要寫入卷，您應該選擇可以從多個節(jié)點訪問的Read-Write-Many卷。這些通常需要昂貴的提供。此外，對于StatefulSet，相同的解決方法無法起作用，因為這將為每個副本創(chuàng)建全新的持久卷聲明（和持久卷）。

總結(jié)和結(jié)論

那么，在集群中是使用少量大節(jié)點還是許多小節(jié)點？

這取決于情況。

反正，什么是小的，什么是大的？

這取決于您在集群中部署的工作負載。

例如，如果您的應用程序需要10GB內(nèi)存，那么運行一個具有16GB內(nèi)存的實例等于“運行一個較小的節(jié)點”。

對于只需要64MB內(nèi)存的應用程序來說，相同的實例可能被認為是“大的”，因為您可以容納多個這樣的實例。

那么，對于具有不同資源需求的混合工作負載呢？

在Kubernetes中，沒有規(guī)定所有節(jié)點必須具有相同的大小。

您完全可以在集群中使用不同大小的節(jié)點混合。

這可能讓您在這兩種方法的優(yōu)缺點之間進行權(quán)衡。

鏈接：https://url.hi-linux.com/cK1vB

（版權(quán)歸原作者所有，侵刪）