源起
知乎是中文網際網路高質量的問答社群，每天有上千萬使用者在知乎分享知識、經驗和見解，找到自己的答案。為配合不同階段的業務發展需求，知乎容器平臺也在不斷演進、提升，目前幾乎所有的業務都執行在容器上。
這兩年知乎開始使用 Rancher 管理 Kubernetes 叢集，叢集規模逐步達到近萬節點。本文將介紹 Rancher 如何針對大規模叢集進行效能調優，最終訪問速度提升75%，達到頁面訪問體驗可用的狀態。
對於為什麼會選擇 Rancher 作為我們的容器管理平臺，大致原因有以下幾點：
我們的業務部署在國內多家公有云 Kubernetes 上，需要統一的平臺來管理這些 Kubernetes 叢集，而 Rancher 針對國內的公有云 Kubernetes 平臺相容性非常友好。
Rancher 降低了 Kubernetes 叢集的部署和使用門檻，我們可以藉助 Rancher UI 輕鬆納管和使用各個 Kubernetes 叢集。不是很深入瞭解 Kubernetes 的研發同學也可以輕鬆建立 Deployment、Pod、PV 等資源。
我們可以藉助 Rancher Pipeline 在內部實現 CI/CD，使研發專注於業務應用的開發。儘管 Rancher 團隊告知 Pipeline 已經停止維護，但是它的簡潔依然符合我們內部對 CI/CD 的定位。
Rancher 的持續創新能力，還有圍繞著 Kubernetes 進行了一系列的生態擴充套件及佈局，比如：輕量級 Kubernetes 發行版 k3s、Kubernetes 的輕量級分散式塊儲存系統 Longhorn、基於 Kubernetes 的開源超融合基礎設施 (HCI) Harvester、以及 Rancher 的下一代 Kubernetes 發行版 RKE2。跟隨頭部創新廠商，對團隊的持續進步也是大有益處。
Rancher 作為國際化的容器廠商，在國內有非常專業的研發團隊，溝通交流非常便捷。很多問題都可以在 Rancher 中文社群中找到答案，對於開源且免費的平臺來說，可以說是非常良心了。
迷局
起初，我們在使用 Rancher 管理中小規模叢集時，RancherUI 提供的功能幾乎可以滿足我們所有的需求，並且 UI 也非常流暢。
但隨著業務量的增加，叢集規模不斷的擴大，當我們擴大到使用一個 Rancher 管理近十個叢集、近萬節點和幾十萬 pod 時（單叢集最大規模將近幾千個節點和數十幾萬 pod），操作 Rancher UI 頻繁會出現卡頓並且載入時間過長的問題，個別頁面需要 20 多秒的時間才能完成載入。嚴重時可能會造成連線不到下游叢集的情況，UI 提示“當前叢集 Unavailable ，在 API 準備就緒前，直接與 API 互動功能不可用。”
沒錯，我們碰到了 Rancher 的效能問題。尤其是超級管理員使用者，登入時需要載入的資料量較大，基本上 UI 處於一種不可用的狀態，下游叢集也斷連頻繁。
破曉
從上面的現象來看，使用 Rancher 管理超大規模叢集似乎遇到了效能問題，影響了使用體驗。隨後尋求 Rancher 本土技術團隊幫忙，經過幾次高效的線上會議溝通，基本找到根本原因：
- 雖然我們的叢集數量不多，但是所有叢集節點總量並不小。頁面載入時，依賴node list 介面獲取資料（此 node 為 Rancher 建立的一種特殊 CRD，它與實際下游叢集的節點數有關），該介面處理時間較長，引起頁面載入緩慢。
- 我們的下游叢集中，主要以公有云的 Kubernetes 為主，這些叢集通過匯入方式納管到 Rancher 中。這種納管模式下，Rancher Server 通過與 cluster-agent 建立的Tunnel，訪問下游叢集的 Kube API，但是這裡並非直接訪問，而是走 Tunnel 到 Kubernetes Service IP 訪問（如10.43.0.1:443）最終負載到多個 Kube-api server。通常這種模式並沒有問題，但是由於我們的訪問量和資料量都比較大，SVC IP 轉發能力無法支撐，嚴重影響了通訊效率。
經瞭解，如果要通過社群版解決該問題，操作會相當複雜。但企業版 Rancher 已經針對效能優化有了一套成熟的方案和策略，以下是 Rancher 工程師介紹的關於企業版和社群版 Rancher 的區別：
企業版和社群版 Rancher 針對查詢資源最主要的區別在於：針對一些慢查詢API，社群版是通過 Kubernetes API 讀取資料，企業版通過 Cache 中讀取。同時，支援多種下游叢集的連線策略，從而提升和下游叢集的管理效率。另外，企業版還對監控/日誌/GPU/網路等基礎設施能力有一定增強，並且對本土商業客戶的 BUG 響應上會更快速。
出於國情需要，企業版是一種特殊的存在。海外客戶基本只能訂閱開源版本，本土客戶可以額外享受企業版的特性，並且企業版是完全本土研發團隊開發。秉承 SUSE Rancher 的開放理念，使用者可以來去自如，企業版與開源版之間隨意切換。
針對以上分析，我們經過權衡，決定暫時使用企業版對叢集進行調優實踐。
抉擇
切換到企業版
首先我們從社群版 Rancher 切換到了企業版，企業版的迭代偏穩重一些，發版策略不會嚴格遵循開源版。好在我們使用的社群版有對應的企業版版本，並且支援從社群版平滑切換到企業版。基本上是無損切換，直接替換映象即可，相當方便。
優化下游叢集引數
Rancher工程師推薦了一些下游 Kubernetes 叢集的引數優化方案，不過我們對自定義 RKE 叢集使用不是很多且主要以公有云 Kubernetes 為主，這種下游叢集元件引數的優化和實際的環境相關，這裡只列出了一些比較常用的 kube-apiserver 引數作為參考：
核心調優
Rancher 團隊也給我們提供了一些開源社群比較成熟的調優引數：kops/sysctls.go at master · kubernetes/kops · GitHub（https://github.com/kubernetes...）
開啟資源快取
開啟資源快取後，一些涉及讀取Local 叢集資料的介面，將會走 Cache 模式，極大提升 API list-all 的效能，針對我們環境中節點數特別多的場景有明顯效果。目前增加了快取的資源如下：
叢集連線模式
企業版中針對連線下游叢集的方式進行了優化，並且支援多種連線下游叢集的方式，企業版使用者常用的連線策略包括：
策略一：預設配置
預設策略，就是不修改連線方式，沿用社群版連線下游叢集的策略。
企業版中預設 Tunnel 中的 k8srest client 的 timeout 值為 60s，可以有效減少 heavy load 時下游叢集資料查詢的失敗機率，效能提升有限，但是請求成功率會有很大提升。
策略二：優化 Tunnel鏈路
預設情況下，通過 Tunnel 使用下游叢集的 Kubernetes API Service（如10.43.0.1）進行通訊。如果自建叢集的外部，有一個效能更好的 Kubernetes API LB，可以將連線下游叢集的apiEndpoint 改為 LB 入口地址，這樣可以通過 Kubernetes API LB 分擔壓力，提升連線下游叢集的速度。
策略三：直接和 Tunnel 雙鏈路
啟用直連和 Tunnel 雙鏈路模式之前，需要確保下游叢集有一個從 Rancher Server 網路直接可達的 apiEndpoint（參考策略二）。優化後，Rancher API 中針對下游叢集請求的 v3 介面走直連，其餘還是走Tunnel，這樣可以有效分散流量，避免大量資料都在 Tunnel 中傳輸。相對策略二，效能進一步得到提升，但是比較依賴基礎網路規劃。
最終，我們選擇了 “策略二” 去連線下游叢集，因為我們有一個效能強大的KubernetesAPI LB。當切換連線下游叢集的鏈路會出現短暫的下游叢集不可達的情況，但不會影響下游叢集的業務執行。
碩果
首先，Rancher 企業版 UI 對於我們團隊來說十分方便，左側導航欄可以輕鬆找到各種功能，適合國人的使用習慣。可能是我們從事基礎設施管理的緣故，對這種極簡UI 風格可以說是非常喜歡。
其次，通過上述策略優化後，提升了 Dial Kubernetes API 時的 Timeout，最終幾乎看不到因超時導致的請求失敗。另外，使用下游叢集的 Kube api-server 的 LB Endpoint 作為請求目標，下游叢集斷聯現象已經消失，堪稱從村道換成了高速公路。**此外，支援部分介面通過快取快速檢索，尤其對於 Node 資源，從20+ 秒的響應時間縮短至不到 5 秒。其他比較重要的介面也進行了比對，平均速度提升了大概 75% 以上。
在 Rancher 企業版中，使用者可以通過優化下游叢集的引數、設定連線下游叢集的策略、開啟快取等方式來大幅度優化叢集效能，進而輕鬆管理大規模叢集。從上述實踐可以看到，只要合理的做好調優和規劃，即便是像知乎這樣超大規模的叢集，也能和小規模叢集有一樣的使用體驗。
本文撰寫時，Rancher 本土團隊正在對企業版效能做二次調優，據說可以從 UI 角度管理單個 Project/NS 中萬級的 workload，基本上完全能覆蓋我們的使用極限了。期待我們和 Rancher 再次合作，然後給大家奉上新的效能實踐分享。
如果你也有管理大規模叢集的使用場景或需求，可以通過中文官網（https://www.rancher.cn）聯絡 SUSE Rancher，來為你的叢集保駕護航！