有時候，創新不只是功能更多，而是讓等待更少。Rancher Vai，讓每一次操作都快得剛剛好。

如果你正用 Rancher 在大規模環境中管理 Kubernetes，那么你一定知道，UI 性能不只是“錦上添花”——它對效率至關重要。Rancher 團隊一直在不斷努力提升平臺在更復雜環境下的處理能力。

在這篇文章里，我們將深入探討一個令人興奮、正不斷演進的改進項目：代號為 “Vai”（也稱 UI 服務器端分頁或基于 SQLite 的緩存）。目標是讓你在使用 Rancher 時擁有更流暢、更快速、更具可擴展性的體驗，尤其在你要管理大量 Kubernetes 資源的場景下。正因如此，Rancher 團隊構建了 Vai 項目，該項目現已成為 SUSE Rancher Prime 中的一項生產就緒功能。

Rancher Prime 的 Vai 引擎通過重新設計數據流向 UI 的方式，實現更快、更可靠的 Kubernetes 管理。這保證了企業能夠更順暢地管理大型復雜環境，同時降低成本、提高效率。

• 更快更順暢的 Rancher UI — 提升效率
• 減輕 Kubernetes API 服務器的壓力 — 保持集群健康、提升性能
• 默認啟用加密的安全緩存 — 保護敏感數據
• 可擴展的基礎設施 — 隨環境增長而擴展，并為未來洞察提供可能

問題所在：規模如何影響 UI 性能

隨著 Rancher 部署規模的擴大，管理海量集群、節點及其內部資源成為常態。我們明確聽到了用戶的反饋：UI 性能，尤其是 Rancher Dashboard 的響應，在某些極限場景下已成為瓶頸。

為應對這一挑戰，我們為 Rancher 的性能設定了一些目標。比如，為了保證 UI 在極端規模場景下也能正常應對，我們將一個基準目標設為：對某一種資源（以載荷 1MiB 的 ConfigMap 為例），能夠分頁顯示數萬個條目；在最壞情況下，分頁結果從 API 返回時間不超過 0.5 秒，以便最終渲染在 1 秒之內完成。

這些數字并不僅僅是理論目標；它們映射了真實場景中的痛點：一個遲緩的 UI 會妨礙你有效地管理和監控 Kubernetes 環境。正如我們在內部所說：“當 Dashboard 無法達到用戶期望時，用戶對 Rancher 的印象就會變差，使用效率也會降低?！?這正是我們決心解決的關鍵痛點。

問題的核心通常歸結于 UI 如何獲取與處理大量 Kubernetes 對象列表。將數千個項（如 Pod、Deployment 或其他資源）拉入瀏覽器端進行緩存、排序與過濾，會對網絡、瀏覽器內存造成壓力，并導致明顯延遲。此外，這樣的操作會對 Kubernetes API Server 造成過度負載，從而對被管理集群產生負面影響。

因此，我們知道，必須設計一種更智能、更高效的數據交付方式給 UI。

解決方案：Vai 如何帶來更快、可擴展的 UI

這正是 “Vai” 問世的原因。這個項目不僅僅是一次小優化，而是對 Rancher 內部 API（名為 Steve）如何向 UI 提供資源、以及其如何在大規模場景下與 Kubernetes 數據交互的根本性重構。

Vai 的主要目標是在服務器端實現高效的分頁、過濾和排序。與其將龐大的數據集拉到瀏覽器端再處理，不如讓服務器端先行處理這些操作，只將必要、已經處理過的那一頁數據發送給 UI。

核心思路是構建一個位于 Kubernetes API Server 和 Rancher UI 之間的強大緩存層。這個緩存層以 SQLite 為后端存儲，使 Steve（Rancher 的 Kubernetes API 代理組件）能夠更快地響應 UI 對對象列表的請求，因為排序、過濾和分頁操作都在服務器端完成，從而最小化數據傳輸量。

期望成果是什么？響應速度大幅提升的 UI、Kubernetes API Server 和 Rancher 本身負載顯著降低、在資源分頁瀏覽時獲得更好的體驗——即便在有數萬個資源的環境中也能流暢應對。

技術深潛：Vai 的 SQLite 支撐架構

那么，Vai 到底是如何運作的？其“魔法”在于它的架構：將 Kubernetes 原生的 Informer 機制與 SQLite 的高速、低內存開銷結合起來。

Vai 是對 Steve 的一種擴展，Steve 是 Rancher 用來將 UI 的 API 請求代理到 Kubernetes 的組件。Vai 利用專門的 Informer 來緩存 Kubernetes API 的信息。

如果你對 Kubernetes 控制器開發稍有了解，就知道 Informer 是一種標準機制，用于監聽資源變動并維護本地同步緩存。當 UI 第一次請求某一種資源（例如 Pods）的列表時，會為該資源類型創建一個 Vai Informer。這個 Informer 首先向 Kubernetes API 發起 LIST 請求，然后再開啟 WATCH，以保持緩存與 Kubernetes 實時同步。

關鍵區別在于：傳統 Informer 緩存通常駐留在內存中，而 Vai Informer 使用 SQLite 作為其后端持久化存儲。這意味著被緩存的 Kubernetes 對象被持久化寫入磁盤（默認情況下，會寫入 Rancher pod 或下游集群的 cattle-cluster-agent pod 內）。

與純內存解決方案相比，磁盤存儲提供了更大的緩存容量。這在處理我們測試的最壞情況時至關重要，例如前面提到的 80,000 個大型 ConfigMap 基準測試案例中約 80 GiB 的數據。

下面是一個簡化流程：

1. UI 請求：瀏覽器端（Rancher Dashboard 的 JavaScript 代碼）向 Steve 的某個 API 端點請求一頁 Pods，帶有排序（如按創建時間）和過濾（如按名稱）條件
2. Steve 與 Vai：Steve 接收到請求。如果對應資源類型的 Vai 緩存已被預熱（即緩存已就緒），則 Steve 會將該請求轉換成一個 SQL 查詢
3. SQLite 查詢：該 SQL 查詢在 SQLite 數據庫中執行，SQLite 引擎高效地完成過濾、排序、分頁，只挑選出請求頁所需的數據
4. 響應 UI：Steve 將這頁整理好的數據返回給 UI

美妙之處在于：后續對不同頁、或對同一種資源做略有不同的過濾/排序請求，都可以直接在本地 SQLite 緩存中處理，而無需再次對 Kubernetes API Server 發起完整的 LIST 請求。這樣便極大地減輕了對 kube-apiserver 和 etcd 的訪問壓力。

數據庫本身為每種資源類型設計了一組表。通常包括一個“對象表”（object table），存儲完整的資源對象 blob；以及一個“字段表”（fields table），包含可供排序或過濾使用的索引列，如 name、namespace、creation timestamp 以及其他模式定義屬性。這個 “感興趣字段”（fields of interest） 的概念至關重要。我們不會為每個對象的每個字段都建立索引，那樣效率太低；相反，我們只索引 UI 交互中最常用的字段。這是在常見用例和索引開銷之間的一個權衡。

Vai 的演進歷程與替代方案回顧

Vai 的開發是一次迭代的旅程，從 HackWeek 項目起步，經過多輪設計討論、RFC 制定、實現和優化。Rancher 2.8 提供了起步的基礎能力，隨著版本演進（2.9、2.10、2.11，直至 2.12），我們不斷在其之上構建、修正與完善。沿途我們通過多個 EPIC GitHub issue 跟蹤進展、修復 bug、調整實現，并解決諸如緩存預熱性能、功能一致性等挑戰。這個迭代方式使我們能夠漸進交付，并依據反饋做及時調整。

在 Vai 之前，我們并非第一次嘗試通過緩存優化 Steve 的 UI 性能。之前我們試過多種策略，并對它們做了系統化的評估和基準測試，最終選擇了當前設計。

下面是幾種我們在 Vai 之前探索過的替代方案，以及它們的利弊：

替代方案	初步收益	主要痛點	它如何引導我們走向 Vai 的設計
Steve 原本的內存 LRU 緩存	作為 UI 性能基線	由于對每種查詢參數變化或 RBAC 權限變化都可能產生新的緩存條目，導致內存效率低、數據重復	突顯出需要一種更高效的緩存機制，以避免冗余數據存儲，并能應對多樣的 UI 請求而不消耗過多內存
在從 Kubernetes API 返回后再做內存緩存	通過緩存原始 API 響應可略有提高效率	緩存頻繁失效，因為即便元素未發生變化，資源版本（resourceVersion）也可能改變，從而導致每次“最新”請求都寫入新的緩存條目	暴露出需要一種對資源版本頻繁變化更具魯棒性的緩存策略
為內存緩存追蹤 resourceVersion	在不常變化的列表上，內存使用減少且響應一致性提升	對于頻繁更新的資源（如 leader election leases），緩存幾乎總被認為“過期”，導致不斷重新獲取和加入新條目，對于包含數萬個資源的動態場景不可行	促使我們考慮引入 Informer 機制以實現實時高效更新

這段歷程展示了我們嚴謹的工程流程：我們并不是隨意選定一個方案，而是識別已有方案的局限性，逐步推進到更健壯的架構。頻繁更新的資源導致緩存抖動，是一個非常關鍵的推動因素。 Vai 正是為直接應對這些問題而選中的方案：通過 Informer 獲取高效實時更新，通過 SQLite 獲得更大、磁盤級持久緩存，并且能運用 SQL 提供服務器端排序、過濾、分頁。這樣便有效地將部分工作負載從 Kubernetes API Server 和客戶端瀏覽器中卸載。

對你（工程師）而言，Vai 的意義

那這一系列變革，對你這個使用 Rancher 的技術工程師來說，有什么實打實的好處？

• 異常靈敏的 UI 體驗：最直接的收益是，當你在 Cluster Explorer 中瀏覽成千上萬條資源（如 Pods、Secrets、ConfigMaps 等）時，排序、過濾、翻頁操作會感覺非常迅捷流暢，因為計算已在服務器端完成。
• Kubernetes API 服務器負擔減輕：由于大量 UI 數據請求可以直接從緩存返回，Vai 顯著減少 Rancher 向下游 API 服務器發起的 LIST 和 GET 請求次數。這不僅對 Rancher 有利，也能改善被管理集群的健康和性能，為你的實際工作負載釋放更多 API Server 資源。

圖 1：Rancher 2.11.1 上的 kubapiserver 負載，這是 QA 測試的一部分。Steve 的 “list” 負載由 k6 生成，然后 Steve 又加載 Kubernetes API Server，此處由 Rancher Monitoring 進行監控。

圖 2：Rancher 2.12.1（啟用 Vai）上的 kubapiserver 負載，這是 QA 測試的一部分。更重的 Steve “list” 負載由 k6 生成（比上圖高出 10 倍），而 Kubernetes API Server 的負載幾乎未受影響。

• 為更豐富的數據洞察建立基礎：使用 SQLite 為后端存儲為未來 Rancher 版本提供了 SQL 引擎的靈活性。未來可以做更復雜的查詢，比如在服務器端直接 JOIN 多種 Kubernetes 資源進行匯總視圖。以前在無 Vai 的情況下，這類操作通常需要多個大型 LIST，然后在瀏覽器端進行映射、JOIN，資源消耗極大。
• Rancher 更具可擴展性：這些效率提升意味著 Rancher 自身可以更有效地管理更多、更大的集群。其控制平面組件（如 Steve）也變得更加節省資源。
• 效率提升，減少等待：更快、更可靠的 UI 意味著你等待的時間更少，能做的事情更多。這正是我們設計 Vai 的出發點之一：避免一個緩慢的 Dashboard 給用戶留下不好的印象并削弱生產效率。

總之，Vai 是一個基礎性組件，能幫助 Rancher 隨著你的需求擴展。它確保即便你的 Kubernetes 規模增長得很大，Rancher 仍然是一款強勁、高性能的工具。同時，這種改進也為未來更高級的功能鋪路——響應式的數據訪問層常常是許多高級特性的前提。

安全考慮：保護你的數據

談到數據管理，特別是來自你 Kubernetes 集群的數據，安全問題至關重要。因為 Vai 會將 Kubernetes 對象的副本緩存到 Rancher server pod（對于本地集群）或 cattle-cluster-agent pod（對于下游集群）的磁盤上，我們在設計時就把“靜態加密”（encryption-at-rest）納入了架構之中。

具體來說，我們內建了兩道防線：

• 可選的全緩存加密：若你對 SQLite 緩存中的數據在磁盤上的安全性有顧慮，可以通過在相應的 Rancher 或 agent pod 中設置環境變量 CATTLE_ENCRYPT_CACHE_ALL=true 來啟用對所有緩存對象的加密。
• Secrets 和 Tokens 始終加密：無論你是否開啟全緩存加密，Kubernetes Secrets 和 Rancher Tokens 在緩存中始終被加密。這為最敏感的信息提供了最低保護門檻。

加密機制本身采用 AES-GCM，使用一個駐內存的 Key-Encryption Key（KEK）來加密 / 解密 Data Encryption Keys（DEKs）。這些 DEK 用于加密實際資源數據，并且定期輪換以增強安全性。

此外，還有一個重要的安全考量是訪問控制（RBAC、權限控制等）：由于我們改變了緩存邏輯，必須確保政策和權限機制在啟用 Vai 后仍然得到尊重。為此，我們與安全團隊密切合作，執行深入的審查和自動化測試（啟用與未啟用 Vai 的場景同時測試），以確保一致性。

Rancher 性能的未來之路

Vai 代表了 Rancher 在大規模數據處理方面的一次重大進步，但這并不是終點。這個特性正走在成為 Rancher 體驗核心的一條路徑上。

在 Rancher 2.11 及之前的版本中，Vai 被視為實驗性功能，默認關閉。但令人振奮的是，從 Rancher 2.12 開始，Vai 被認為是可用于生產環境的特性，并在默認情況下被啟用且受 SUSE 支持。對我們來說，這可是一個重要里程碑，我們將繼續根據真實使用反饋來增強它。

更進一步地，我們才剛剛開始挖掘底層 SQL 引擎所提供的額外靈活性。我們預期會利用這一基礎，在未來豐富 Rancher 的數據摘要和洞察功能。我們的終極目標是，在未來的某個版本中，讓這個強大的性能引擎默認開啟，使得高度可擴展的 UI 成為每個人的標準體驗。

幫我們測試與完善 Vai！

你的反饋非常重要！如果你愿意深度體驗并幫忙驗證，建議你先閱讀 Rancher 文檔中關于 UI Server-Side Pagination 的特性頁面，然后將你的體驗反饋給我們：在 GitHub 上開一個 Issue，分享你的發現和建議。

感謝你的閱讀！我們期待聽到你的使用體驗，一起打造更加快速、可擴展的 Rancher 平臺。