如果使用Kubernetes，會遇到一些有關使用集群方式的基本問題，比如應該有幾個集群?它們應該多大?應該包含什么?

集群分析

在不同的應用開發環境中，你通常會開發和運行多個應用程序。此外，通常在不同的環境中運行這些應用程序的多個實例，比如你可能用開發環境，測試環境和生產環境。

于是，這將導致應用程序和環境組成不同的交集。在下面的示例中，有3個應用程序和3個環境，產生了9個應用程序的實例。每個應用程序實例都是一個可獨立運行的獨立部署單元。

請注意，一個應用程序實例可能由多個組件組成，如前端，后端，數據庫等。在微服務應用程序中，一個應用程序實例將由所有微服務組件構成。

作為Kubernetes的用戶，一些問題會引發你的思考。是否應該在單個群集上運行所有應用程序實例?還是應該為每個應用程序實例都有一個單獨的集群?還是應該結合使用呢?

下面是一些你可以選擇選項：

• 一個大型共享集群
• 許多小型一次性集群
• 每個應用程序的集群
• 每個環境的集群

前兩種方法是從幾個大型集群到多個小型集群的規模極限，如下圖所示：

通常，如果集群包含更大的節點和Pod之和，則可以將其定義為“更大”。例如，具有10個節點和100個Pods的集群大于包含1個節點和10個Pods的集群。

一個大型共享集群

第一種選擇是在同一集群中運行所有工作負載。通過這種方法，可以像通用基礎架構平臺一樣使用這個集群。無論需要運行什么，都可以將其部署到現有的Kubernetes集群中。

Kubernetes提供了命名空間，以在邏輯上將集群的各個部分彼此分開，在上述情況下，可以為每個應用程序實例使用單獨的命名空間。

優點：有效利用資源

如果只有一個Kubernetes集群，則只需擁有運行和管理Kubernetes集群所需的所有資源的一個副本。

例如，這包括主節點，一個Kubernetes集群通常有3個主節點，如果只有一個集群，則總共只需要3個主節點(如果有10個Kubernetes集群，則只有30個主節點)。

但這還包括其他集群范圍的服務，例如負載均衡，入口控制器，身份驗證，日志記錄和監控。

如果只有一個集群，則可以為所有工作負載重用這些服務，并且不必為多個集群擁有多個服務副本。

優點：低成本

較少的集群通常成本更低，因為集群數量多，資源開銷越多。對于主節點而言尤其如此，這可能會花費大量的費用，無論是在本地還是在云中。

一些托管的Kubernetes服務免費提供了Kubernetes控制平臺，如谷歌GKE或Azure的AKS，所以在這種情況下，成本效益不是問題。

但是，還有托管的Kubernetes服務，它們為運行Kubernetes集群收取固定的費用，例如AWS的EKS。

優點：高效管理

管理單個集群比管理多個集群容易。這可能包括以下任務：升級Kubernetes版本，設置CI/CD管道，安裝CNI插件，設置用戶認證系統，安裝準入控制器。

如果只有一個集群，則只需完成一次。如果有許多集群，那么需要多次應用所有內容，這可能需要開發一些自動化的流程和工具，才能始終如一地做到這一點。

缺點：單點故障

如果只有一個集群并且集群發生故障，那么所有工作負載都將出問題。還有許多操作可能會導致故障，比如Kubernetes升級，集群范圍內的組件(例如CNI插件)無法正常工作，對集群組件進行了錯誤的配置，基礎架構發生故障。所以，如果只有一個共享集群，則可能會對所有工作負載造成影響。

缺點：沒有硬安全隔離

如果多個應用程序在同一個Kubernetes集群中運行，所以這些應用程序在集群的節點上共享硬件，網絡和操作系統。具體而言，在同一節點上運行的兩個不同應用程序的兩個容器在技術上是在相同硬件和操作系統內核上運行的兩個進程。

Linux容器提供某種形式的隔離，但是這種隔離不如虛擬機提供的隔離強。在后臺，容器中的進程仍然只是在主機操作系統上運行的進程。從安全角度來看，這可能是一個問題。從理論上講，它允許無關的應用程序產生意外的交互。

此外，所有在Kubernetes集群共享某些集群范圍的服務，如工作負載DNS，這使得應用可發現集群中的其他應用程序的服務。

所以，這些問題可能是否會出現問題，具體取決于應用程序的安全要求。

Kubernetes提供了各種防止安全漏洞的方法，例如PodSecurityPolicies和NetworkPolicies，但是，它需要經驗來以完全正確的方式來調整這些工具，并且它們也不能防止所有的安全漏洞。

而且，Kubernetes是為共享而設計的，而不是為了隔離和安全而設計的。

缺點：多租戶資源侵占

Kubernetes集群中有許多共享資源，不同的應用程序可以通過多種方式侵占資源。比如，一個應用程序可能會占據某個共享資源(例如CPU或內存)，從而使同一節點上運行的其他應用程序無法運行。

Kubernetes提供了多種方法來控制這種行為，例如資源請求和限制，ResourceQuotas和LimitRanges。但是，以完全正確的方式調整這些工具并不是一件容易的事，它們也無法防止所有不必要的副作用。

缺點：用戶權限復雜

如果只有一個集群，則企業中的許多人必須有權訪問集群。用戶使用系統的機會越多，破壞的風險就越高。在集群中，你可以控制哪些人可以使用基于角色的訪問控制(RBAC)進行操作。但是，這仍然不能防止用戶破壞其授權范圍內的某些行為。

缺點：集群不能無限大

如果將單個群集用于所有工作負載，則集群可能會很大(就節點和Pods而言)。但是，Kubernetes集群不能無限增長。

對于集群的大小，存在一些理論上限，Kubernetes大約在5000個節點，150000個Pods和300000個容器的定義。但是，實際上，使用較小的集群大小(例如500個節點)可能已經出現了挑戰。

原因是較大的集群對Kubernetes控制平面施加了更高的壓力，這需要仔細計劃來保持集群的功能和效率。

許多小型一次性集群

使用這種方法，可以為每個部署單元使用單獨的Kubernetes集群(本文中，部署單元是一個應用程序實例，例如單個應用程序的開發版本)，通過這種策略，Kubernetes專用于各個應用程序實例。

優點：故障半徑減小

如果集群發生故障，則損害僅限于這個集群上運行的工作負載，而其他所有工作負載均不受影響。

優點：隔離

在各個集群中運行的工作負載不會共享任何資源，例如CPU，內存，操作系統，網絡或其他服務。

這樣可以在不相關的應用程序之間提供強大的隔離，這對于這些應用程序的安全性是一大優勢。

優點：很少的用戶

如果每個集群僅運行一組工作負載，則需要訪問該集群的人數將減少。訪問集群的人越少，發生故障的風險越低。

缺點：資源利用效率低

如前所述，每個Kubernetes集群都需要一組管理資源，例如主節點，控制平面組件，監控和日志記錄解決方案。如果有許多小型集群，則必須為這些管理功能犧牲更高的總資源。

缺點：成本高

資源使用效率低下會自動導致更高的成本。如果必須運行30個主節點而不是3個主節點才能獲得相同的計算能力，那么成本高是必然的。

缺點：綜合管理

管理許多Kubernetes集群比管理單個Kubernetes集群更為復雜。比如需要為每個集群設置身份驗證和授權，如果要升級Kubernetes版本，則也需要執行多次。你可能需要開發一些自動化工具。

每個應用程序的集群

使用這種方法，可以為特定應用程序的所有實例創建一個單獨的集群。可以將其視為每個團隊負責集群的范圍，因為通常一個團隊會開發一個或多個應用程序。

優點：可以為應用程序定制集群

如果應用程序有特定要求，則可以將這些要求安裝在集群中，而不會影響任何其他集群。這樣的要求可能包括工作節點，某個CNI插件，服務網格或任何其他服務。每個群集都可以完全配備相應應用程序所需的配置。

缺點：同一集群中的不同環境

這種方法的缺點是來自不同環境的應用程序實例在同一群集中運行。例如，應用程序的生產版本與開發版本在同一集群中運行，這也意味著開發人員在與應用程序的生產版本相同的集群中工作。所以，如果一個開發人員或開發版本創建集群中的一些損壞，生產版本可能也受到影響。

每個環境的集群

使用這種方法，可以為每個環境創建一個單獨的集群。例如，可以擁有一個開發，測試和生產集群，在其中運行特定環境的所有應用程序實例。

優點：產品環境的隔離

通常，這種將所有環境相互隔離，但是實際上，這對于產品環境尤其重要。現在，應用的生產版本不受任何其他集群和應用環境中發生的任何事情的影響。

因此，如果某些配置錯誤在開發集群中造成破壞，則應用程序的生產版本將繼續運行。

優點：可以針對環境定制集群

可以針對每個集群的環境進行優化，比如，在開發集群中安裝開發和調試工具;在測試集群中安裝測試框架和工具;對產品集群使用更強大的硬件和網絡連接;可以提高應用程序的開發和運行效率。

優點：鎖定對生產集群的訪問

沒有人需要在生產集群上進行開發工作，因此可以限制對其的訪問。甚至可以根本不向任何人授予對生產集群的訪問權限，可以通過自動CI/CD工具對該集群進行部署。這將極大地減少生產集群中人為錯誤的風險。

缺點：應用之間缺乏隔離

主要缺點是應用之間缺少硬件和資源隔離。不相關的應用程序共享集群資源，例如操作系統內核，CPU，內存和其他一些服務。這可能有潛在的安全問題。

缺點：應用要求未本地化

如果應用程序有特殊要求，則所有集群中都必須滿足這些要求。如一個應用程序需要一個GPU，則每個集群必須至少有一個GPU工作節點，即使它僅由一個應用程序使用。這可能會導致成本增加和資源使用效率低。