源起
知乎是中文網際網路高品質的問答社群，每天有上千萬使用者在知乎分享知識、經驗和見解，找到自己的答案。為配合不同階段的業務發展需求，知乎容器平台也在不斷演進、提升，目前幾乎所有的業務都運作在容器上。
這兩年知乎開始使用 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 管理中小規模叢集時，Rancher UI 提供的功能幾乎可以滿足我們所有的需求，并且 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 參數作為參考：
| 配置參數 | 配置說明 |
| --max-requests-inflight | 預設值400；用于read請求的通路頻率限制；建議1600或更高； |
| --max-mutating-requests-inflight | 預設值200；用于write請求的通路頻率限制；建議800或更高； |
| --event-ttl | 預設值1h0m0s；用于控制保留events的時長；叢集events較多時建議30m，以避免etcd增長過快； |
| --watch-cache-sizes | 系統根據環境啟發式的設定；用于pods/nodes/endpoints等核心資源，其他資源參考 default-watch-cache-size 的設定； K8s v1.19開始，該參數為動态設定，建議使用該版本。 |
| --default-watch-cache-size | 預設值100；用于List-Watch的緩存池；建議1000或更多； |
| --delete-collection-workers | 預設值1；用于提升namesapce清理速度，有利于多租戶場景；建議10； |
核心調優
Rancher 團隊也給我們提供了一些開源社群比較成熟的調優參數：kops/sysctls.go at master · kubernetes/kops
開啟資源緩存
開啟資源緩存後，一些涉及讀取 Local 叢集資料的接口，将會走 Cache 模式，極大提升 API list-all 的性能，針對我們環境中節點數特别多的場景有明顯效果。
目前增加了緩存的資源如下：
| 資源 | 釋義 |
| projectRoleTemplateBindings | Project 權限綁定 |
| clusterRoleTemplateBindings | 叢集權限綁定 |
| users | 使用者 |
| nodes | 節點（與我們的使用相關） |
| projects | Rancher 獨有的項目概念 |
| templates | Catalog 模闆 |
叢集連接配接模式
企業版中針對連接配接下遊叢集的方式進行了優化，并且支援多種連接配接下遊叢集的方式，企業版使用者常用的連接配接政策包括：
政策一：預設配置
預設政策，就是不修改連接配接方式，沿用社群版連接配接下遊叢集的政策。
企業版中預設 Tunnel 中的 k8s rest 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 中傳輸。相對政策二，性能進一步得到提升，但是比較依賴基礎網絡規劃。
最終，我們選擇了 “政策二” 去連接配接下遊叢集，因為我們有一個性能強大的Kubernetes API 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，來為你的叢集保駕護航！
作者:也無風雨也無晴
出處:https://zhuanlan.zhihu.com/p/453463882