作者：趙夢@知乎 唐陽@知乎
來自知乎的分享：如何通過Rancher對大規(guī)模集群進行性能調(diào)優(yōu)，提升75%訪問速度?
源起
知乎是中文互聯(lián)網(wǎng)高質(zhì)量的問答社區(qū)，每天有上千萬用戶在知乎分享知識、經(jīng)驗和見解，找到自己的答案。為配合不同階段的業(yè)務(wù)發(fā)展需求，知乎容器平臺也在不斷演進、提升，目前幾乎所有的業(yè)務(wù)都運行在容器上。
這兩年知乎開始使用 Rancher 管理 Kubernetes 集群，集群規(guī)模逐步達(dá)到近萬節(jié)點。本文將介紹 Rancher 如何針對大規(guī)模集群進行性能調(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 Pipeline 在內(nèi)部實現(xiàn) CI/CD，使研發(fā)專注于業(yè)務(wù)應(yīng)用的開發(fā)。盡管 Rancher 團隊告知 Pipeline 已經(jīng)停止維護，但是它的簡潔依然符合我們內(nèi)部對 CI/CD 的定位。
Rancher 的持續(xù)創(chuàng)新能力，還有圍繞著 Kubernetes 進行了一系列的生態(tài)擴展及布局，比如：輕量級 Kubernetes 發(fā)行版 k3s、Kubernetes 的輕量級分布式塊存儲系統(tǒng) Longhorn、基于 Kubernetes 的開源超融合基礎(chǔ)設(shè)施 (HCI) Harvester、以及 Rancher 的下一代 Kubernetes 發(fā)行版 RKE2。跟隨頭部創(chuàng)新廠商，對團隊的持續(xù)進步也是大有益處。
Rancher 作為國際化的容器廠商，在國內(nèi)有非常專業(yè)的研發(fā)團隊，溝通交流非常便捷。很多問題都可以在 Rancher 中文社區(qū)中找到答案，對于開源且免費的平臺來說，可以說是非常良心了。
迷局
起初，我們在使用 Rancher 管理中小規(guī)模集群時，Rancher UI 提供的功能幾乎可以滿足我們所有的需求，并且 UI 也非常流暢。
但隨著業(yè)務(wù)量的增加，集群規(guī)模不斷的擴大，當(dāng)我們擴大到使用一個 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ù)團隊幫忙，經(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ū)別：
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
