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