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