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