如果你使用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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/38889.html
標籤：其他