前 言
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容器技術都有豐富的運維和實踐經驗。