筆記。 翻譯。：該材料來自一個教育項目 這是設計基於 Kubernetes 的基礎設施時一個常見問題的答案。 我們希望對每個選項的優缺點的詳細描述將幫助您為您的專案做出最佳選擇。
TL博士：同一組工作負載可以在多個大型叢集（每個叢集將有大量工作負載）或許多小型叢集（每個叢集中具有少量負載）上運行。
下表評估了每種方法的優缺點：
當使用 Kubernetes 作為運行應用程式的平台時，經常會出現一些關於設定叢集的複雜性的基本問題：
- 我應該使用多少個集群？
- 我應該把它們做成多大？
- 每個集群應該包含什麼？
在本文中，我將嘗試透過分析每種方法的優缺點來回答所有這些問題。
問題陳述
作為軟體開發人員，您可能會同時開發和操作許多應用程式。
此外，這些應用程式的許多實例可能在不同的環境中運行 - 例如，這些可能是 開發, test и 產品.
結果是一個完整的應用程式和環境矩陣：
應用與環境
上面的範例代表 3 個應用程式和 3 個環境，總共有 9 個可能的選項。
每個應用程式實例都是一個獨立的部署單元，可以獨立於其他應用程式實例使用。
Обратитевнимание，что 應用實例 可能由許多組成 組件，如前端、後端、資料庫等。 對於微服務應用程序，實例將包括所有微服務。
因此，Kubernetes 用戶有幾個疑問：
- 是否應該將所有應用程式實例放置在一個叢集中？
- 是否值得為每個應用程式實例擁有一個單獨的叢集？
- 或者也許應該使用上述方法的組合？
所有這些選項都非常可行，因為 Kubernetes 是一個靈活的系統，不會限制使用者的能力。
以下是一些可能的方法：
- 一個大的共同簇；
- 許多小型的高度專業化的集群；
- 每個應用程式一個集群；
- 每個環境一個集群。
如下所示，前兩種方法處於選項範圍的兩端：
從幾個大簇（左）到許多小簇（右）
一般來說，如果一個叢集的節點和 Pod 總數較多，則該叢集被認為比另一個叢集「更大」。 例如，具有 10 個節點和 100 個 Pod 的叢集比具有 1 個節點和 10 個 Pod 的叢集要大。
好吧，讓我們開始吧！
1. 一個大的公共集群
第一個選項是將所有工作負載放置在一個叢集中：
一大群
在這種方法中，集群被用作通用的 基礎設施平台 — 您只需在現有 Kubernetes 叢集中部署所需的一切即可。
Kubernetes 允許叢集的各個部分在邏輯上彼此分離，以便每個應用程式實例都可以擁有自己的命名空間。
讓我們看看這種方法的優點和缺點。
+ 資源的有效利用
對於單一集群，您只需要運行和管理 Kubernetes 集群所需的所有資源的副本。
例如，對於主節點來說就是如此。 通常，每個 Kubernetes 叢集有 3 個主節點，因此對於一個叢集來說，它們的數量將保持不變（作為比較，10 個叢集將需要 30 個主節點）。
上述微妙之處也適用於整個叢集運行的其他服務，例如負載平衡器、入口控制器、身份驗證、日誌記錄和監控系統。
在單一叢集中，所有這些服務可以同時用於所有工作負載（無需像多個叢集那樣建立它們的副本）。
+ 便宜
由於上述原因，較少的叢集通常會更便宜，因為沒有管理成本。
對於主節點來說尤其如此，無論它們如何託管（本地或雲端），主節點都可能花費大量資金。
一些託管 Kubernetes 服務，例如 或 ，免費提供控制層。 在這種情況下，成本問題就沒那麼嚴重了。
還有一些託管服務對每個 Kubernetes 叢集的運作收取固定費用（例如， ).
+ 高效率的管理
管理一個叢集比管理多個叢集更容易。
管理可能包括以下任務：
- Kubernetes版本更新；
- 建立 CI/CD 管道；
- 安裝 CNI 插件；
- 建立用戶認證系統；
- 安裝門禁控制器；
還有許多其他人…
對於一個集群，您只需執行所有這些操作一次。
對於許多叢集來說，操作必須重複多次，這可能需要一些流程和工具的自動化來確保流程的一致性和一致性。
現在談談缺點。
− 單點故障
如果拒絕 唯一的 集群將立即停止工作 所有 工作量！
出錯的原因有很多：
- 更新 Kubernetes 會導致意想不到的副作用；
- 叢集範圍內的元件（例如 CNI 插件）開始無法如預期運作；
- 叢集組件之一配置不正確；
- 底層基礎設施故障。
此類事件可能會對共用叢集中託管的所有工作負載造成嚴重損害。
− 無剛性絕緣
在共享叢集中運行意味著應用程式共享叢集節點上的硬體、網路功能和作業系統。
從某種意義上說，在同一節點上運行兩個不同應用程式的兩個容器就像在運行相同作業系統核心的同一台機器上運行的兩個進程。
Linux 容器提供某種形式的隔離，但其強度不如虛擬機器等提供的隔離。 本質上，容器中的進程與主機作業系統上運行的進程相同。
這可能是一個安全問題：這種安排理論上允許不相關的應用程式相互通訊（有意或無意）。
此外，Kubernetes 叢集中的所有工作負載共用一些叢集範圍的服務，例如 - 這允許應用程式找到叢集中其他應用程式的服務。
根據應用程式的安全要求，上述所有要點可能具有不同的含義。
Kubernetes 提供了各種工具來防止安全問題，例如 и 。 然而，正確設置它們需要一些經驗；此外，它們無法完全堵住所有安全漏洞。
重要的是要永遠記住 Kubernetes 最初是為 分享， 不是為了 隔離和安全.
− 缺乏嚴格的多租戶
鑑於 Kubernetes 叢集中共享資源豐富，不同的應用程式可以透過多種方式互相干擾。
例如，應用程式可能會獨佔共享資源（例如 CPU 或記憶體）並拒絕在同一節點上執行的其他應用程式存取該資源。
Kubernetes 提供了各種機制來控制這種行為，例如 （另請參閱文章““ - 大約。 譯）, и 。 然而，與安全性一樣，它們的配置非常重要，而且它們無法絕對防止所有不可預見的副作用。
− 使用者數量大
對於單一集群，您必須向許多人開放對其的存取。 它們的數量越多，它們「破壞」某些東西的風險就越高。
在叢集內，您可以使用以下命令控制誰可以做什麼 （參見文章““ - 大約。 譯）。 但是，它不會阻止用戶「破壞」其職責範圍內的某些東西。
− 簇不能無限增長
用於所有工作負載的叢集可能會非常大（就節點和 Pod 的數量而言）。
但這裡又出現了另一個問題：Kubernetes 中的叢集無法無限成長。
簇大小存在理論上的限制。在 Kubernetes 中大約是 .
然而，在現實生活中，問題可能會更早開始——例如， .
事實上，大型叢集為 Kubernetes 控制層帶來了很高的負載。 換句話說，保持叢集高效運作需要仔細調整。
原始部落格上的一篇相關文章探討了這個問題，名為““。
但讓我們考慮相反的方法：許多小集群。
2. 許多小型專業集群
透過這種方法，您可以為部署的每個元素使用單獨的叢集：
許多小簇
就本文而言，根據 可展開元件 指應用程式的實例 - 例如，單獨應用程式的開發版本。
該策略使用 Kubernetes 作為專門的 運行 對於單一應用程式實例。
讓我們看看這種方法的優點和缺點。
+ 有限的“爆炸半徑”
當叢集發生故障時，負面後果僅限於該叢集中部署的那些工作負載。 所有其他工作負載保持不變。
+ 絕緣
各個叢集中託管的工作負載不共享處理器、記憶體、作業系統、網路或其他服務等資源。
結果是不相關的應用程式之間緊密隔離，這有利於它們的安全。
+ 使用者數量少
由於每個叢集僅包含有限的工作負載，因此可以存取該叢集的使用者數量會減少。
有權訪問集群的人越少，出現「故障」的風險就越低。
讓我們看看缺點。
− 資源利用效率低下
如前所述，每個 Kubernetes 叢集都需要一組特定的管理資源：主節點、控制層元件、監控和日誌記錄解決方案。
在小集群數量較多的情況下，必須分配更大份額的資源來管理。
− 昂貴
資源利用效率低下自然會帶來高昂的成本。
例如，維護30個主節點而不是XNUMX個具有相同運算能力的主節點必然會影響成本。
− 管理困難
管理多個 Kubernetes 叢集比管理一個叢集要困難得多。
例如，您必須為每個叢集配置身份驗證和授權。 Kubernetes版本也將要更新多次。
您可能需要使用自動化來提高所有這些任務的效率。
現在讓我們來看看不太極端的情況。
3. 每個應用一個集群
在這種方法中，您可以為特定應用程式的所有實例建立一個單獨的叢集：
每個應用程式的集群
這條路徑可以被認為是「原則」的概括每個團隊單獨的集群”，因為通常一組工程師正在開發一個或多個應用程式。
讓我們看看這種方法的優點和缺點。
+ 叢集可依應用程式進行調整
如果應用程式有特殊需求，可以在叢集中實現，而不影響其他叢集。
此類需求可能包括 GPU 工作執行緒、某些 CNI 外掛程式、服務網格或其他一些服務。
每個叢集都可以根據其中運行的應用程式進行定制，以便它僅包含所需的內容。
− 一個叢集中的不同環境
這種方法的缺點是來自不同環境的應用程式實例共存於同一個叢集中。
例如，應用程式的 prod 版本與 dev 版本在同一個叢集中運行。 這也意味著開發人員在運行應用程式生產版本的同一個叢集中進行操作。
如果由於開發人員的行為或開發版本中的故障，叢集中發生故障，那麼產品版本也可能會受到影響 - 這種方法的一個巨大缺點。
最後，我們清單中的最後一個場景。
4. 每個環境一個集群
此場景涉及為每個環境分配一個單獨的叢集：
每個環境一個集群
例如，您可能有集群 開發, test и 產品，您將在其中執行專用於特定環境的應用程式的所有實例。
以下是這種方法的優點和缺點。
+ 產品環境的隔離
在這種方法中，所有環境都是相互隔離的。 然而，實際上這在產品環境中尤其重要。
應用程式的生產版本現在獨立於其他叢集和環境中發生的情況。
這樣，如果開發叢集中突然出現問題，應用程式的生產版本將繼續工作，就像什麼都沒發生一樣。
+ 叢集可依環境調整
每個集群都可以根據其環境進行調整。 例如，您可以：
- 在開發集群中安裝開發和調試工具；
- 在叢集中安裝測試框架和工具 test;
- 在叢集中使用更強大的硬體和網路通道 產品.
這使您可以提高應用程式開發和營運的效率。
+ 限制對生產集群的訪問
直接使用產品群集的需求很少出現，因此您可以顯著限制有權存取它的人員範圍。
您可以更進一步，完全拒絕人們存取此集群，並使用自動化 CI/CD 工具執行所有部署。 這種方法將在最相關的地方最大限度地減少人為錯誤的風險。
現在談談缺點。
− 應用程式之間沒有隔離
該方法的主要缺點是應用程式之間缺乏硬體和資源隔離。
不相關的應用程式共享叢集資源：系統核心、處理器、記憶體和一些其他服務。
如前所述，這可能存在潛在危險。
− 無法本地化應用程式依賴項
如果應用程式有特殊要求，則所有叢集都必須滿足這些要求。
例如，如果應用程式需要 GPU，則每個叢集必須至少包含一個具有 GPU 的工作執行緒（即使它僅由該應用程式使用）。
因此，我們面臨成本上升和資源利用效率低下的風險。
結論
如果您有一組特定的應用程序，則可以將它們放置在多個大型叢集或許多小型叢集中。
本文討論了各種方法的優缺點，從一個全球集群到幾個小型且高度專業化的集群：
- 一個大的一般集群；
- 許多小型的高度專業化的集群；
- 每個應用程式一個集群；
- 每個環境一個集群。
那麼您應該採取哪一種方法呢？
像往常一樣，答案取決於用例：您需要權衡不同方法的優缺點並選擇最佳選項。
但是，選擇並不限於上面的範例 - 您可以使用它們的任意組合！
例如，您可以為每個團隊組織幾個叢集：一個開發叢集（其中將有環境 開發 и test) 並聚類為 生產 （生產環境所在的位置）。
根據本文的訊息，您可以針對特定場景進行相應的優缺點最佳化。 祝你好運！
聚苯乙烯
另請閱讀我們的博客：
- «“;
- «“;
- «“;
- «“。
來源： www.habr.com