前 言
Rancher 作為一個開源的企業級 Kubernetes 集群管理平台。你可以導入現有集群，如 ACK、TKE、EKS、GKE，或者使用 RKE、RKE2、K3s 自定義部署集群。
作為業界領先的多集群管理平台，Rancher 可以同時納管上千個集群和上萬個節點。同時，大家也不必擔心運維管理大規模集群和節點會增加額外的負擔，社交通訊軟件LINE 5 個人就足以管理 130 個集群的 2000 個節點。
如何在 Rancher 中管理大規模的集群和節點這次暫且不談，之前已經介紹過很多次了。今天我們只聊如何在單個集群中管理大規模的項目、命名空間等資源。
如何在單個集群中管理大規模的項目和命名空間
-
命名空間：命名空間是 Kubernetes 的一個概念，它允許在一個集群中建立一個虛擬集群，這對於將集群划分為單獨的“虛擬集群”很有用，每個虛擬集群都有自己的訪問控制和資源配額。
-
項目：一個項目就是一組命名空間，它是 Rancher 引入的一個概念。項目允許您將多個命名空間作為一個組進行管理並在其中執行 Kubernetes 操作。您可以使用項目來支持多租戶，例如設置團隊可以訪問集群中的某個項目，但不能訪問同一集群中的其他項目。
從層次上來說，集群包含項目，項目包含命名空間。如果把公司理解成是一個集群，那么項目對應的就是部門或者團隊，我們可以給某個部門或者團隊針對不同的項目去划分權限來管理多個命名空間。
所以，我們在生產環境中會創建大量的項目和命名空間，那么如何規划這些項目和命名空間呢？
建議項目按照部門或者團隊去划分，針對不同的項目授予相關訪問控制
每個項目內具有不同目的的環境使用命名空間去隔離，例如：生產環境和測試的環境
為了驗證在 Rancher 單集群中具有管理大規模項目和命名空間的能力，我們在一個集群中創建了 500 個項目，並且在每個項目中創建了 10 個命名空間，最后，在每個命名空間創建：1 個 Deployment、2 個 Secret、1 個 Service、2 個 ConfigMap 來模擬真實場景下的使用。
以下是測試集群規模：
這樣我們在單集群中創建了共計： **500+個項目、5000+個命名空間、5000+個 Deployment/pod、10000+個 ConfigMap、10000+個 Secret 和 5000+的 Service **的資源。
接下來，我們來體驗通過 Rancher UI 來管理這些資源：
首先登錄 Rancher UI，因為只有一個集群，無論集群下有多少資源，都不會被加載，所以加載速度和普通規模集群無差別
當項目非常多時，我們可以在搜索框快速定位到我們需要查詢的項目：
進入到某個項目，1.5 秒左右即可完成加載
接下來我們來創建一個 Deployment，從結果來看，和普通規模的集群的加載速度無區別
其他的資源的管理就不給大家一一展示，測試結果和普通規模集群的加載速度幾乎一致。從以上的場景分析，單集群包含大規模項目、命名空間等資源並沒有給 Rancher 帶來太大的性能壓力。
由於測試環境主機資源有限，這次驗證只創建了 5000 個 deployment，只要合理的分配資源到項目，相信再多幾倍的資源規模使用 Rancher 管理也會非常輕松。
一個不建議的場景
雖然是不建議的場景，但還是要說明，避免大家在單集群中管理大規模項目和命名空間時踩坑。
非常不建議大家將所有的資源都堆積在同一個項目中，就比如將 5000+個命名空間都放在同一個項目中。
為什么不建議呢？簡單來說，從 Rancher Cluster Manager 上進入到某個項目時，會加載項目中包含的所有資源。項目中包含的資源越多，加載項目中資源的速度也會隨之變慢，如果數據量特別特別龐大，有時候會出現 timeout 的情況。而 Rancher 管理平面是通過 cluster tunnel 與下游集群的 API 通信，如果資源數量過於龐大，這條 websocket tunnel 的負擔會很重。
雖然不建議大家將所有的資源都堆積在同一個項目中，但是並不代表在 Rancher 中沒辦法管理這種場景。如果在你的生產環境中必須將所有的命名空間等資源放在同一個項目中，而且數據量非常龐大。那么推薦你使用 Rancher v2.5 新增的 Cluster Explorer，Cluster Explorer 針對單個項目中加載資源進行了優化，幾乎不會出現 timeout 的情況。
下圖展示的是在 Cluster Explorer 的同一個項目中加載 3000 個命名空間、3000 個 Deployment、3000 個 Service、6000 個 ConfigMap、6000 個 Secret 的示例：
由此可見，通過Rancher 2.5的新Dashboard，Cluster Explorer，也能夠在單個項目管理上千個資源。
大規模集群管理調優建議
作為一個多集群的管理平台，無論是集群數量的增長還是單個集群 workload 數量的增長，都會對管理平面形成一定性能挑戰。所有組件的默認參數是常用規模的最佳的產品配置，而面向大規模場景，部分平台參數甚至系統內核參數都需要進行調優，以便管理平面的核心可以獲得最佳性能。
用戶可根據自身的使用規模來采取相應的優化方案，所有的優化措施並不是必須的，需要針對自身的場景“量體裁衣”。Rancher 的默認的配置參數已經是絕大多數使用場景的最佳方案，如果是管理大規模集群，則需要調整相關配置，以下是一些大規模集群中的一些常見優化參數：
針對管理平面大量的 TCP 連接，從 OS Kernel 層面進行優化，已盡量發揮硬件配置的最佳性能。常見配置及其功能說明如下：
以下參數屬於個人總結，僅供參考
Kernel Tuning
Kube-apiserver
針對原生資源和 CRD 的 API 的並發能力與緩存優化，提升 API List-Watch 的性能：
本文的重點不是調優，所以只介紹一些常用的參數，更詳細的參數(例如：kube-controller-manager、kube-scheduler、kubelet、kube-proxy)說明還請大家參考 Kubernetes 官網。
后 記
從以上驗證結果來看，Rancher 具有在單個集群中管理大規模項目和命名空間的能力，只要合理的使用正確的方式搭建集群和部署業務，就不會對 Rancher 帶來太大的壓力，也不存在性能問題，同時也要根據集群規模來調優主機和 Kubernetes 參數，使其發揮出最佳性能。
作者介紹
王海龍，SUSE Rancher社區技術經理，負責Rancher中國技術社區的維護和運營。擁有6年的雲計算領域經驗，經歷了OpenStack到Kubernetes的技術變革，無論底層操作系統Linux，還是虛擬化KVM或是Docker容器技術都有豐富的運維和實踐經驗。ack到Kubernetes的技術變革，無論底層操作系統Linux，還是虛擬化KVM或是Docker容器技術都有豐富的運維和實踐經驗。