在建立 Kubernetes 叢集時，可能會出現問題：我應該設定多少個工作節點以及什麼類型？對於內部部署叢集來說，哪個更好：購買幾台功能強大的伺服器還是使用資料中心中的十幾台舊機器？那麼在雲端，是採用八個單核心實例比較好還是採用兩個四核心實例比較好？
這些問題的答案都在文章裡 在團隊的翻譯中 .
叢集容量
一般來說，Kubernetes 叢集可以被認為是一個大型的「超級節點」。其總運算能力是其所有組成節點的能力總和。
有多種方法可以實現叢集所需的目標容量。例如，我們需要一個總容量為 8 個處理器核心和 32 GB RAM 的集群，因為這組應用程式需要那麼多的資源。然後，您可以安裝兩個具有 16 GB 記憶體的節點或四個具有 8 GB 記憶體的節點、兩個四核心處理器或四個雙核心處理器。
以下是建立叢集的兩種可能方法：
兩種選項都提供具有相同容量的集群，但底部配置有四個較小的節點，而頂部配置有兩個較大的節點。
哪個選項更好？
為了回答這個問題，讓我們來看看這兩個選項的優點。我們已將它們總結在一個表格中。
幾個大節點
很多小結
更容易的叢集管理（如果在本地）
平滑自動縮放
更便宜（如果在本地）
價格差異不大（在雲端）
您可以運行資源密集型應用程式
完全複製
資源利用效率更高（系統守護程式的開銷更少）
更高的集群容錯能力
請注意，我們只討論工作節點。選擇主節點的數量和大小是一個完全不同的主題。
因此，讓我們更詳細地討論表中的每一點。
選項 1：幾個大型節點
最極端的選擇是整個群集容量由一個工作節點承擔。在上面的例子中，這將是一個具有 16 個 CPU 核心和 16 GB RAM 的工作節點。
優點
加號#1。更容易控制
管理幾輛汽車比管理整個車隊更容易。更快推出更新和修復，更容易同步。絕對失敗次數也較低。
請注意，以上所有內容均適用於您自己的硬體、您自己的伺服器，而不適用於雲端實例。
在雲端，情況有所不同。在那裡，管理由雲端服務提供者負責。因此，管理雲端中的十個節點與管理一個節點沒有太大差異。
雲端中 Pod 之間的流量路由和負載平衡 ：來自互聯網的流量被定向到主負載平衡器，主負載平衡器將流量定向到其中一個節點的連接埠（NodePort 服務在每個叢集節點上設定一個 30000-32767 範圍內的連接埠）。 kube-proxy 設定的規則將流量從節點重定向到 pod。以下是兩個節點上的十個 pod 的情況：
優點2：每個節點的成本更低
動力強勁的汽車價格更高，但價格上漲並不一定是線性的。換句話說，一台具有 10 GB 記憶體的十核心伺服器通常比十台具有相同記憶體量的單核心伺服器便宜。
但請注意，此規則通常不適用於雲端服務。在所有主要雲端供應商的當前定價方案中，價格隨容量線性增加。
因此在雲端中，您通常無法在更強大的伺服器上節省金錢。
優點3：您可以運行資源密集型應用程式
一些應用程式需要叢集中強大的伺服器。例如，如果機器學習系統需要 8GB 內存，則除非您至少有一個大型工作節點，否則您將無法在 1GB 節點上運行它。
缺點
缺點 1：每個節點的 Pod 太多
如果在更少的節點上執行相同的任務，那麼每個節點自然會有更多的 pod。
這可能是一個問題。
原因是每個 pod 都會為容器運行時（例如 Docker）以及 kubelet 和 cAdvisor 帶來一些開銷。
例如，kubelet 定期偵測節點上所有容器的生存能力 - 容器越多，kubelet 需要做的工作就越多。
CAdvisor 收集節點上所有容器的資源使用情況統計信息，kubelet 定期查詢這些資訊並透過 API 提供。同樣，容器越多，cAdvisor 和 kubelet 的工作就越多。
如果模組數量增加，可能會降低系統速度，甚至破壞其可靠性。
Kubernetes 儲存庫中有一些 ，節點在 Ready/NotReady 狀態之間跳轉，因為 kubelet 對節點上所有容器的定期檢查花費了太多時間。
因此，Kubernetes 。根據節點效能，您可以在每個節點運行更多 pod，但很難預測是否會出現問題或一切是否會正常運作。值得提前測試這項工作。
減號#2。複製限制
節點太少會限制應用程式複製的有效程度。例如，如果您有一個具有五個副本但只有兩個節點的高可用性應用程序，則該應用程式的有效複製度將降低為兩個。
五個副本只能分佈在兩個節點上，如果其中一個節點發生故障，則會立即關閉幾個副本。
如果您有五個或更多節點，則每個副本將在單獨的節點上運行，並且單個節點故障最多會刪除一個副本。
因此，高可用性要求可能要求叢集中具有一定數量的最小節點。
減號#3。失敗的更嚴重後果
當節點數量較少時，每次故障都會產生更嚴重的後果。例如，如果您只有兩個節點，並且其中一個節點發生故障，則一半的模組會立即消失。
當然，Kubernetes 會將工作負載從故障節點遷移到其他節點。但如果數量很少，那麼可能沒有足夠的可用容量。因此，您的某些應用程式將不可用，直到您恢復故障節點為止。
因此，節點越多，硬體故障的影響就越小。
減#4。更多自動縮放步驟
Kubernetes 為雲端基礎架構提供了叢集自動擴展系統，可根據當前需求自動新增或刪除節點。隨著節點的增大，自動縮放變得更加不穩定和笨重。例如，在兩個節點上，增加一個額外的節點將使叢集容量立即增加50％。即使您不需要這些資源，您也必須為它們付費。
因此，如果您打算使用叢集自動擴展，節點越小，您將獲得越靈活、越經濟高效的擴展。
現在讓我們來看看擁有大量小節點的優點和缺點。
選項 2：許多小節點
這種方法的優點基本上來自於具有多個大節點的相反選項的缺點。
優點
優點 1：故障影響較小
節點越多，每個節點上的 pod 越少。例如，如果您在十個節點上有一百個模組，那麼每個節點平均會有十個模組。
因此，如果一個節點發生故障，您只會損失 10% 的工作量。很可能只有少數副本受到影響，整個應用程式仍將保持正常運作。
此外，剩餘節點可能具有足夠的備用容量來處理故障節點的工作負載，因此 Kubernetes 可以自由地重新安排 pod，並且您的應用程式將相對快速地恢復運作。
優點2：良好的複製性
如果有足夠的節點，Kubernetes 調度程式可以為所有副本分配不同的節點。這樣，如果一個節點發生故障，只有一個副本會受到影響，並且應用程式仍然可用。
缺點
缺點1：更難控制
節點數量越多，管理越困難。例如，每個 Kubernetes 節點都必須與所有其他節點通信，這意味著連接數量呈二次方增長，並且所有這些連接都需要被追蹤。
Kubernetes 控制器管理器中的節點控制器會定期遍歷叢集中的所有節點以檢查其健康狀況 - 節點越多，控制器上的負載就越大。
etcd 資料庫的負載也在增加—每個 kubelet 和 kube-proxy 調用 對於 etcd（透過 API），etcd 應該向其廣播物件更新。
一般來說，每個工作節點都會對主節點的系統元件施加額外的負載。
Kubernetes 官方支援以下集群 。但其實已經有 500 個節點 .
為了管理大量的工作節點，應該選擇更有效率的主節點。例如，kube-up 根據工作節點的數量來決定主節點的正確 VM 大小。也就是說，工作節點越多，主節點的生產力就必須越高。
為了解決這些具體問題，有一些特殊的發展，例如 。該系統允許您繞過限制並建立具有大量工作節點的叢集。
缺點2：開銷更大
在每個工作節點上，Kubernetes 運行一組系統守護程序 - 其中包括容器執行時間（例如 Docker）、kube-proxy 和 kubelet，以及 cAdvisor。它們總共消耗一定數量的資源。
如果您有許多小節點，則每個節點上此開銷的份額會更大。例如，假設單一節點上的所有系統守護程式一起使用 0,1 個 CPU 核心和 0,1 GB 記憶體。如果您有一個具有 10 GB 記憶體的 1 核心節點，那麼守護程式將消耗 1% 的叢集容量。另一方面，在 10 個具有 XNUMX GB 記憶體的單核心節點上，守護程式將佔用 XNUMX% 的叢集容量。
因此，節點越少，基礎設施的利用效率就越高。
缺點3：資源利用效率低下
在小型節點上，剩餘的資源片段可能太小而無法分配任何工作負載，因此它們未被使用。
例如，每個 pod 需要 0,75 GB 記憶體。如果您有十個節點，每個節點有 1GB 內存，那麼您可以運行十個 pod，這將使每個節點有 0,25GB 的未使用內存。
這意味著整個集群的25%的記憶體被浪費了。
在具有 10GB 記憶體的大型節點上，您可以運行 13 個這樣的模組，並且仍然只剩下一個未使用的 0,25GB 區塊。
在這種情況下，只有 2,5% 的記憶體被浪費。
因此，大型節點上的資源利用更為最佳化。
幾個大節點還是很多小節點？
那麼，叢集中有幾個大節點還是很多小節點比較好呢？一如既往，沒有明確的答案。這很大程度上取決於應用程式的類型。
例如，如果應用程式需要 10 GB 內存，那麼更大的節點是顯而易見的選擇。如果應用程式需要十倍複製才能實現高可用性，那麼將副本放置在兩個節點上的風險幾乎不值得——叢集至少應該有十個節點。
在中間情況下，根據每個選項的優點和缺點做出選擇。也許有些論點比其他論點更適合您的情況。
而且沒有必要將所有結都做成相同的大小。您可以先嘗試一種大小的節點，然後在其中添加不同大小的節點，並將它們組合成一個叢集。 Kubernetes 叢集的工作節點可以是完全異質的。因此您可以嘗試結合兩種方法的優點。
沒有單一的秘訣，每種情況都有其自身的細微差別，只有生產才能揭示真相。
由雲端平台團隊編寫的翻譯 .
有關 Kubernetes 的更多資訊： .
來源： www.habr.com
