Rancher 和知乎超大規(guī)模多集群管理聯(lián)合實踐

作者:趙夢@知乎 唐陽@知乎

來自知乎的分享:如何通過Rancher對大規(guī)模集群進行性能調(diào)優(yōu),提升75%訪問速度?

源起

知乎是中文互聯(lián)網(wǎng)高質量的問答社區(qū),每天有上千萬用戶在知乎分享知識、經(jīng)驗和見解,找到自己的答案。為配合不同階段的業(yè)務發(fā)展需求,知乎容器平臺也在不斷演進、提升,目前幾乎所有的業(yè)務都運行在容器上。

這兩年知乎開始使用 Rancher 管理 Kubernetes 集群,集群規(guī)模逐步達到近萬節(jié)點。本文將介紹 Rancher 如何針對大規(guī)模集群進行性能調(diào)優(yōu),最終訪問速度提升 75%,達到頁面訪問體驗可用的狀態(tài)。

對于為什么會選擇 Rancher作為我們的容器管理平臺,大致原因有以下幾點:

我們的業(yè)務部署在國內(nèi)多家公有云 Kubernetes 上,需要統(tǒng)一的平臺來管理這些 Kubernetes 集群,而 Rancher 針對國內(nèi)的公有云 Kubernetes 平臺兼容性非常友好。

Rancher 降低了 Kubernetes 集群的部署和使用門檻,我們可以借助 Rancher UI 輕松納管和使用各個 Kubernetes 集群。不是很深入了解 Kubernetes 的研發(fā)同學也可以輕松創(chuàng)建 Deployment、Pod、PV 等資源。

我們可以借助 Rancher Pipeline 在內(nèi)部實現(xiàn) CI/CD,使研發(fā)專注于業(yè)務應用的開發(fā)。盡管 Rancher 團隊告知 Pipeline 已經(jīng)停止維護,但是它的簡潔依然符合我們內(nèi)部對 CI/CD 的定位。

Rancher 的持續(xù)創(chuàng)新能力,還有圍繞著 Kubernetes 進行了一系列的生態(tài)擴展及布局,比如:輕量級 Kubernetes 發(fā)行版 k3s、Kubernetes 的輕量級分布式塊存儲系統(tǒng) Longhorn、基于 Kubernetes 的開源超融合基礎設施 (HCI) Harvester、以及 Rancher 的下一代 Kubernetes 發(fā)行版 RKE2。跟隨頭部創(chuàng)新廠商,對團隊的持續(xù)進步也是大有益處。

Rancher 作為國際化的容器廠商,在國內(nèi)有非常專業(yè)的研發(fā)團隊,溝通交流非常便捷。很多問題都可以在 Rancher 中文社區(qū)中找到答案,對于開源且免費的平臺來說,可以說是非常良心了。

迷局

起初,我們在使用 Rancher 管理中小規(guī)模集群時,Rancher UI 提供的功能幾乎可以滿足我們所有的需求,并且 UI 也非常流暢。

但隨著業(yè)務量的增加,集群規(guī)模不斷的擴大,當我們擴大到使用一個 Rancher 管理近十個集群、近萬節(jié)點和幾十萬 pod 時(單集群最大規(guī)模將近幾千個節(jié)點和數(shù)十幾萬 pod),操作 Rancher UI 頻繁會出現(xiàn)卡頓并且加載時間過長的問題,個別頁面需要 20 多秒的時間才能完成加載。嚴重時可能會造成連接不到下游集群的情況,UI 提示“當前集群 Unavailable ,在 API 準備就緒前,直接與 API 交互功能不可用。”

Rancher 和知乎超大規(guī)模多集群管理聯(lián)合實踐

沒錯,我們碰到了 Rancher 的性能問題。尤其是超級管理員用戶,登錄時需要加載的數(shù)據(jù)量較大,基本上UI處于一種不可用的狀態(tài),下游集群也斷連頻繁。

破曉

從上面的現(xiàn)象來看,使用 Rancher 管理超大規(guī)模集群似乎遇到了性能問題,影響了使用體驗。隨后尋求 Rancher 本土技術團隊幫忙,經(jīng)過幾次高效的線上會議溝通,基本找到根本原因:

雖然我們的集群數(shù)量不多,但是所有集群節(jié)點總量并不小。頁面加載時,依賴 node list 接口獲取數(shù)據(jù)(此node為 Rancher 創(chuàng)建的一種特殊CRD,它與實際下游集群的節(jié)點數(shù)有關),該接口處理時間較長,引起頁面加載緩慢。

我們的下游集群中,主要以公有云的 Kubernetes 為主,這些集群通過導入方式納管到Rancher 中。這種納管模式下,Rancher Server 通過與 cluster-agent 建立的 Tunnel,訪問下游集群的 Kube API,但是這里并非直接訪問,而是走 Tunnel 到 Kubernetes Service IP 訪問(如10.43.0.1:443)最終負載到多個 Kube-api server。通常這種模式并沒有問題,但是由于我們的訪問量和數(shù)據(jù)量都比較大,SVC IP 轉發(fā)能力無法支撐,嚴重影響了通信效率。

經(jīng)了解,如果要通過社區(qū)版解決該問題,操作會相當復雜。但企業(yè)版 Rancher 已經(jīng)針對性能優(yōu)化有了一套成熟的方案和策略,以下是 Rancher 工程師介紹的關于企業(yè)版和社區(qū)版 Rancher 的區(qū)別:

(免責聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時,應及時向本網(wǎng)站提出書面權利通知或不實情況說明,并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關文章源頭核實,溝通刪除相關內(nèi)容或斷開相關鏈接。 )