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