如果你使用Kubernetes作為應用程序的操作平臺，那麼你應該會遇到一些有關使用集群的方式的基本問題：
- 你應該有多少集群？
- 它們應該多大？
- 它們應該包含什麼？
本文將深入討論這些問題，並分析你所擁有的一些選擇的利弊。
問題所在
作為一個軟件創建者，你應該開發並運行了多個應用程序。而且，你應該在不同的環境中運行這些應用程序的多個實例——例如，你應該有開發、測試以及生產環境。那麼，不同的環境和應用程序的組合，我們可以得到一個“矩陣”：
在以上例子中，有3個應用程序和3個環境，兩兩組合為9個應用程序實例。每個應用程序實例是一個獨立的部署單位，可以獨立運行。
請注意，一個應用程序實例可能由多個組件組成，如前端、後端、數據庫等。在一個微服務應用程序中，一個應用程序實例將由所有微服務構成。
那麼作為一個Kubernetes用戶，此時會遇到一些問題：
- 應該在一個集群中運行所有應用程序實例嗎？
- 或者每個應用程序實例都應該有一個單獨的集群嗎？
- 或者應該以上兩者相結合？
以上這些都是行之有效的方法——Kubernetes是一個靈活的系統，它並不會直接告訴你某一條指定的使用方法。
關於集群的搭配你有以下選擇：
- 一個大型的共享集群
- 許多小型的一次性集群
- 每個應用程序有一個集群
- 每個環境中有一個集群
前兩種方法分別是大型集群和小型集群的極端，其規模大小關係如下：
總而言之，如果一個集群包含了大量的節點和Pod，那麼它就可以被定義為大於另一個集群。例如，一個有10個節點和100Pod的集群大於有1個節點和10個Pod的集群。
釐清了概念和選項，那麼我們現在開始吧！
一個大型共享集群
這個方法是指將你所有的工作負載都運行在一個集群中：
通過這種方法，我們可以像通用基礎架構平臺一樣使用該集群——無論你需要運行什麼，都可將其部署到現有的Kubernetes集群中。
Kubernetes中有一個命名空間的概念，可以 在邏輯上將集群的各個部分彼此分開。在上述情況下，你可以為每個應用程序實例創建單獨的命名空間。
接下來，我們來看看這個方法的優劣勢。
高效的資源使用
如果你只有一個Kubernetes集群，那麼你只需要擁有運行和管理Kubernetes集群所需的所有資源的一個副本。這包含了master節點——一個Kubernetes集群通常有3個master節點。如果你只擁有一個集群，你一共只需要3個master節點（比起擁有10個集群，需要30個master節點來說輕鬆不少）。
當然了，肯定不止master節點，還包括其他集群範圍的服務，例如負載均衡器、Ingress controller、身份驗證、日誌和監控。如果你只有一個集群，你可以為所有工作負載重複使用這些服務，並且不需要擁有多個副本。
便宜
由於上述原因，較少的集群通常更便宜，因為集群數量較大，意味著資源更多，因此會花費更多的費用。對於主節點來說尤其如此，這可能會用掉你大量的費用——無論你的集群是在本地還是在雲中。
有一些Kubernetes託管服務會提供免費的控制平面，如Google Kubernetes Engine（GKE）或Azure Kubernetes Service（AKS），在這種情況下成本也許就不是問題。然而，有些託管的Kubernetes服務會為運行一個Kubernetes集群收取固定的費用，如Amazon Elastic Kubernetes Service（EKS）。
高效管理
管理一個集群總比管理多個集群簡單很多。管理集群可能包含以下任務：
- 升級Kubernetes版本
- 設置CI/CD流水線
- 安裝一個CNI插件
- 設置用戶身份驗證系統
- 安裝一個admission controller
等等……
如果你只有一個集群，這一切你只需要完成一次即可。如果你有許多集群，那麼你需要將以上任務執行很多次，這需要你開發一些自動化流程以及工具，使其能夠在所有集群中同步。
現在來說說缺點
“雞蛋都放在一個籃子裡”
如果你只有一個集群，如果這個集群恰好崩潰了，那麼你的所有工作負載都會宕機。
有很多方式可能會導致出錯：
- Kubernetes升級過程中產生的“副作用”
- 集群範圍的組件（如CNI 插件）無法正常運行
- 對集群的其中一個組件進行了錯誤的配置
- 底層基礎架構發生故障
如果只有一個共享集群，那麼只要類似的事情發生可能會對所有工作負載造成重大損害。
沒有嚴格的安全隔離
如果有多個app運行在同一個Kubernetes集群中，這意味著這些應用程序在集群的節點上共享硬件、網絡和操作系統。具體而言，在同一節點上運行的兩個不同的應用程序的兩個容器是在相同硬件和操作系統內核上運行的兩個進程。
Linux容器提供了一些隔離的形式，但這種隔離不如虛擬機所提供的隔離強。在後臺，容器中的進程仍然只是在主機操作系統上運行的進程。
從安全角度來看，這的確是一個問題。從理論上講，它允許不相關的應用程序（有意地和無意地）彼此交互。而且，在一個Kubernetes集群中的所有工作負載共享某些集群範圍的服務，如DNS——它可以允許應用程序發現集群內的其他APP的服務。
以上所提到的這些也許會成為一個問題，也許不會，這取決於應用程序對安全性的要求。
Kubernetes本身提供了各種方法來防止安全漏洞，如PodSecurityPolicies以及NetworkPolicies。但是，要完全正確地使用這些工具需要一些經驗，並且它們也無法防止所有的安全漏洞。
請牢記一點，Kubernetes是為共享而設計的，而不是隔離和安全。
沒有嚴格的多租戶
既然在Kubernetes集群中有許多共享資源，那麼許多不同的應用程序就可以通過各種方式互相擠佔資源。例如，一個app可能獨佔了某些共享資源，如CPU或內存，因此導致同一節點上運行的其他應用沒有資源可用。
Kubernetes提供各種方法來控制這一行為，如resource requests and limits、ResourceQuota以及LimitRanges。但是，同樣地，要正確使用這些工具並非易事，而且它們也無法防止所有不必要的副作用。
許多用戶可以訪問同一集群
如果你只有一個集群，那麼在企業內部會有許多人必須得訪問這一集群。越多的人訪問，破壞的風險就會越高。
在集群內部，你可以控制哪些人可以使用基於角色的訪問控制（RBAC）進行操作。但是，這仍然不能防止用戶在授權範圍內進行破壞。
集群不能無限擴大
如果你給所有的工作負載使用一個集群，這個集群規模大概率已經很大了（從節點和Pod的角度來說）。然而，Kubernetes集群無法無限擴大。理論上，集群的大小是有上限的，在Kubernetes中的定義大概事5000節點、150,000Pod以及300,000個容器。
然而，實際上，比上述規模更小的集群已經會開始面臨諸多挑戰，例如500節點。原因是較大的集群對Kubernetes控制平面造成了更大的壓力，這需要仔細計劃以保持集群的功能和效率。
接下來，我們來看看第二個選項——許多小型集群
許多小型一次性集群
使用這種方法，你可以為每個部署單元使用單獨的Kubernetes集群：
在本文中，一個部署單元即為一個應用程序實例——如一個應用程序的開發版本。
通過這種策略，Kubernetes就可以像用於各個應用程序實例的專用應用程序運行時一樣使用。
接下來，我們看看這種方法的優勢和劣勢。
宕機規模減小
如果一個集群出現故障，那麼僅會損害運行在該集群上的工作負載，並不是所有工作負載都會受到影響。
更好地隔離
各個集群中運行的工作負載不會共享資源，如CPU、內存、操作系統、網絡以及其他服務。這樣可以在不相關的應用程序之間提供強大的隔離，對於提升應用程序安全性十分有效。
少量用戶訪問同一集群
如果每個集群僅運行一小組工作負載，那麼就只需要更少的人訪問這一集群。越少的人訪問集群，集群出現故障的概率就越低。
接下來看一下這一方法的缺點。
低效的資源利用率
正如之前所提及的，每個Kubernetes集群需要一組管理資源，如master節點、控制平面組件、監控和日誌解決方案等。如果你有許多小型集群，那麼你只能為這些管理功能犧牲資源使用的百分比。
高昂的成本
低效的資源利用自然就會導致更高的成本。例如，如果你必須運行30個master節點，而不是3個才能獲得相同的計算機功能，你看看每月的賬單就能體會到這一點。
複雜的管理流程
同時管理許多Kubernetes集群比管理單個集群要複雜得多。例如，你需要為每個集群設置身份驗證和授權；如果你想升級Kubernetes版本，你需要執行這一操作很多次。你可能需要開發一些自動化流程，這樣會使這些操作更高效。
接下來，我們看一下其他場景的集群。
每個應用程序有一個集群
使用這種方法，對於特定應用程序的所有實例，你都有一個單獨的集群：
你可以將其視為每個團隊單獨擁有自己的集群，因為通常一個團隊會開發一個或多個應用程序。
接下來，我們看看這個方法的優劣。
可以為應用程序定製集群
如果一個應用程序有特定的需求，這些需求可以在它的集群內安裝，而無需影響其他集群。這樣的要求可能包括GUI worker節點、一個特定的CNI插件、一個服務網格或其他服務。如此以來，每個集群都可以完全配備相應應用程序所需的配置——不多也不少。
在同一個集群中包含不同的環境
這個方法的一個不足時來自不同環境的應用程序實例運行在同一個集群中。例如，應用程序的生產版本和開發版本都運行在同一個集群中，這意味著開發人員需要在生產版本應用程序運行的相同集群中工作。
所以，如果開發人員或一個有bug的開發版本在集群中造成了某些損害，那麼生產版本絕對會因此受到影響——這是一個巨大的不足。
每個環境有一個集群
使用這種方法，你可以為每個環境創建一個單獨的集群：
例如，你可以分別有一個開發、測試和生產集群，你可以在其中運行特定環境中的所有應用程序實例。
對生產環境的隔離
通常情況下，這個方法會使得所有環境彼此隔離，而這對生產環境而言十分重要。生產版本的應用程序現在不會受到其他集群以及應用程序環境的任何影響。所以，如果某些錯誤配置在你的開發集群中造成破壞，你的生產版本的app依舊可以持續運行，彷彿什麼也沒發生。
為環境定製集群
你可以為環境優化每個集群，例如：
- 安裝開發和調試工具在開發集群中
- 安裝測試框架和工具在測試集群中
- 給生產集群使用性能更好的硬件和網絡
這樣能夠同時提升app的開發和運維效率。
鎖定對生產集群的訪問
沒有人真的需要在生產集群內工作，所以你可以限制訪問它。你甚至可以根本不向任何人授予生產集群的訪問權限——可以通過自動化CI/CD工具對該集群進行部署。這將極大降低生產集群中人為錯誤的風險，這十分重要！
現在，來看看缺點。
缺少應用程序之間的隔離
這一方法的主要不足是應用程序之間缺少硬件和資源的隔離。不相關的應用程序共享集群資源，例如操作洗頭膏內核、CPU、內存和其他服務。如上文所述，這可能是一個安全問題。
滿足應用程序要求的成本增加
如果一個app有特殊的要求，這些要求則必須在所有集群中得到滿足。例如，如果一個應用程序需要一個GPU，那麼每個集群至少必須得有一個GPU worker節點——即便只有一個應用程序使用它。這會導致更高的成本和更低效的資源利用。
結 論
總而言之，如果你有給定的一組應用程序，你可以將它們運行在幾個大型集群上或多個小型集群上。本文討論了從幾個大型集群到多個小型集群的各種方法的優缺點：
- 一個大型的共享集群
- 許多小型的一次性集群
- 每個應用程序有一個集群
- 每個環境中有一個集群
以下一張表格，總結了不同方法的優劣勢：
所以你應該選擇哪種方法呢？
通常情況下，這取決於你的實際用例——你必須權衡不同方法的優缺點，才能找到最合適你的解決方案。但是，選擇不僅限於上述示例，也可以是它們的任意組合。例如，您可能考慮為每個團隊建立兩個集群：一個開發集群（用於開發和測試環境）和一個生產集群（用於生產環境）。
通過了解以上示例方案，您可以相應地結合特定方案的利弊。
Daniel Weibel
原文鏈接：
https://learnk8s.io/how-many-clusters
閱讀更多 RancherLabs 的文章
