高昂算力成本下的觀測缺口與集中式監控難題
隨著人工智慧與機器學習技術快速融入各類應用，企業對繪圖處理器（GPU）這類昂貴硬體加速資源的需求急遽上升。在現代雲端架構中，許多技術團隊選擇將 Kubernetes 作為整合多租戶（Multi-tenant）運算負載的核心平台，讓不同的研發小組、資料科學團隊與應用服務共享實體基礎設施。然而，昂貴的硬體被分配出去，並不等於這些資源正在發揮實際價值。
根據技術媒體 InfoQ 的報導，軟體大廠 Adobe 的工程團隊在實際營運過程中發現，在缺乏精細觀測機制的情況下，硬體資源浪費的情況十分嚴重。他們曾記錄到一個令人警惕的案例：一張價格昂貴的 GPU 雖然已被排程分配且持續供電運作，但其運算使用率竟然連續整整 11 天維持在零。若團隊缺乏即時監控數據，例如 GPU 核心使用率、圖形記憶體（Framebuffer Memory）佔用量、功耗變化以及對應的應用程式請求流量，就無法察覺這類殭屍資源，更無從判斷特定服務是否在消耗大量電力的同時完全沒有承載任何實質負載。
要讓各個租戶團隊能夠自行排查資源浪費，最直接的方法就是讓他們查詢叢集中的監控系統。然而，在以 Prometheus（雲端原生運算基金會旗下的開源監控與時間序列資料庫系統）為主流的 Kubernetes 環境中，這項需求面臨著嚴峻的架構挑戰。在大型叢集中，中央 Prometheus 實例通常統一採集並儲存了跨數千個命名空間（Namespace）的遙測數據。如果平台團隊直接向所有開發者開放中央 Prometheus 的查詢權限，將會引發兩大風險：首先是安全性問題，使用者可能透過查詢語句跨越命名空間，窺視其他團隊的業務數據或機密指標；其次是效能與「吵鬧鄰居（Noisy Neighbour）」效應，當大量團隊同時發送繁重複雜的 PromQL（Prometheus 專用查詢語言）查詢時，中央監控系統的負載將被瞬間拉高，甚至導致整體叢集的監控鏈路崩潰。
以雲端原生技術重組多租戶代理與存取邊界
為了在不洩漏跨團隊數據且不拖垮核心監控效能的前提下，實現開發團隊的自主監控，Adobe 工程團隊選擇不引進全新或異質的第三方監控平台，而是全面利用 Kubernetes 生態系與雲端原生運算基金會（CNCF）的現有開源組件，建構了一套租戶感知代理機制（Tenant-Aware Proxy）。
在這套架構的存取流程中，使用者發起的查詢請求首先會經過反向代理伺服器 NGINX 以及 kube-rbac-proxy。kube-rbac-proxy 是一個能夠將 HTTP 請求與 Kubernetes 內建的角色型存取控制（RBAC, Role-Based Access Control）深度整合的代理工具，它負責驗證發起查詢的使用者身分與權限邊界。確認身分之後，請求會被遞交給多租戶 Prometheus 代理伺服器，由該代理識別使用者所屬的特定租戶，動態發現可用的 Prometheus 後端，並將資料檢索範圍嚴格鎖定在該租戶專屬的命名空間內。
在此環節中，最關鍵的元件是名為 prom-label-proxy 的查詢重寫工具。在實務上，平台管理者不能僅僅依賴開發者「自律地在查詢中指定正確的命名空間」，因為攻擊者或不熟悉的開發人員很容易刻意構造特定的 PromQL 查詢來繞過前端限制。prom-label-proxy 的作用在於攔截每一個即將進入 Prometheus 的原始查詢，並在協定層強制為其注入命名空間過濾標籤。這意味著限制規則是在查詢抵達資料庫引擎之前就已強制套用，從技術底層徹底消除了未經授權跨空間讀取指標的可能性。
此外，為了落實指標存取的自主化管理，該架構引進了 Kubernetes 的自訂資源定義（CRD, Custom Resource Definition），命名為 MetricAccess。各個專案團隊可以透過宣告式配置檔案，向平台聲明自己需要採集的指標項目，無論是使用精確的指標名稱、規則運算式（Regular Expression）或是特定的 PromQL 選擇器。這項設計讓業務團隊享有自主決定監控範圍的靈活性，同時將底層的收集機制與安全控制權穩固地保留在平台維運團隊手中。
雙軌儲存與指標隔離帶來的效能與安全紅利
除了在查詢路徑上進行標籤限制之外，Adobe 的架構還提供了一種更高安全等級的選項：為特定租戶部署專屬的小型 Prometheus 實例，並啟用指標隔離（metricIsolation）機制。
對於需要建立大量自訂儀表板、持續進行複雜即時運算或設定高頻警報規則的團隊，平台會透過 Prometheus 的遠端寫入（remote-write）機制，定期將經過篩選與核准的指標子集同步推送到該租戶的專屬實例中。這項做法帶來了顯著的架構優勢。首先是儲存量與查詢負載的大幅精簡，在 Adobe 公開的實際測試案例中，某個租戶在集中式系統中原本涵蓋的指標時間序列（Time Series）超過一萬條，但在經過客製化篩選後，同步至專屬實例的時間序列驟降至大約三百條。
這項轉變更建立了實體層面的安全邊界。在資訊安全架構中，最可靠的防禦往往不是查詢過濾，而是物理隔離：如果非授權的數據根本從未被寫入租戶的專屬儲存引擎中，那麼無論使用者如何撰寫查詢語句，都絕不可能透過該儲存端洩露其他命名空間的任何資訊。
同時，叢集的營運模式也獲得了根本性的改善。中央 Prometheus 實例得以擺脫繁雜的開發者日常查詢壓力，專心承擔整個叢集基礎設施等級的高效採集與整體健康狀態評估；而各團隊成員建立的 Grafana 儀表板與日常排查查詢，則完全分流至各自的小型 Prometheus 實例處理。如此一來，即使個別團隊發送了極度消耗記憶體的異常查詢，影響範圍也被嚴格限制在其自有的邊界內，不會威脅到叢集維運中樞的穩定度。
架構比較與平台工程的實務啟示
在雲端原生領域中，解決 Prometheus 多租戶隔離問題並非只有一種途徑。業界目前已有數個成熟的分散式監控系統專門應對此類需求，其中最具代表性的是 Grafana Mimir 與 Cortex。這類系統在其底層核心即內建了原生多租戶架構，主要依賴 HTTP 請求標頭中的租戶識別碼（例如 X-Scope-OrgID）來界定指標讀寫範圍，並透過獨立的查詢前端（Query-Frontend）組件來處理讀取路徑的水平擴展與快取。
相較於 Grafana Mimir 或 Cortex 這種需要維護複雜微服務組件的重型方案，Adobe 所採用的架構展現了一種不同的工程哲學。它並沒有推翻原有的標準 Prometheus 部署，而是圍繞著 Kubernetes 原生生態中的 RBAC 機制、自訂資源定義（CRD）以及輕量級代理工具，在既有設施周圍搭建出一層靈活且具備租戶感知能力的控制面。這種做法降低了架構重構的進入門檻，特別適合已經高度依賴標準 Prometheus 且希望深化權限控管的企業團隊。
雖然這套架構最初是為了解決 GPU 昂貴硬體在 AI 負載下的觀測需求而生，但其設計模式本質上具備廣泛的通用性。隨著愈來愈多企業將 Kubernetes 作為結合一般微服務、巨量資料串流與人工智慧訓練的統一大平台，如何在多租戶環境中安全開放指標能見度，已是所有平台工程團隊不可迴避的課題。透過身分認證、強制查詢標籤改寫、宣告式指標清單以及選擇性的儲存分流，企業得以在不犧牲系統效能與安全底線的前提下，賦予開發人員精確掌握算力運作狀態的能力，進而真正杜絕硬體資源閒置浪費的現象。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。