具代表性的面試主題

系統設計面試:如何用 Kubernetes v1.36 DRA 管理 Node Allocatable 資源?

系統設計困難
Offer.cc 編輯團隊發佈 更新

題幹

DRA 驅動為加速卡分配資源時還會消耗 CPU、記憶體或 hugepages。請設計一套 Node Allocatable 資源治理方案,避免 DRA 資源與普通 Pod 請求重複計數或超賣。

題目與適用場景

一個多租戶推理叢集透過 Dynamic Resource Allocation(DRA)分配加速卡。驅動為每個裝置申請一份 CPU、記憶體或 hugepages,且部分裝置需要 NUMA 對齊。請設計 Kubernetes v1.36 的 Node Allocatable 資源方案:讓排程器同時考慮 DRA 分配和普通 Pod 請求,解釋 ResourceSlice 對映、Pod status、灰度、監控與回滾邊界。

官方 v1.36 DRA 更新把 Node Allocatable 資源作為第一輪能力,支援把 DRA 管理的 CPU、記憶體和 hugepages 納入標準節點帳本;該能力仍屬 alpha,應按實驗性特性設計發布護欄。

背景與邊界

本題只討論排程前的資源會計、拓撲約束和發布安全。裝置驅動如何實作硬體分配、業務如何容錯屬於外部依賴;回答應明確 API 版本、feature gate、容量新鮮度、帳本一致性和回滾條件。

面試官考察點

  • 能否從資源帳本、排程器、DRA driver、ResourceSlice 和 Pod status 畫出閉環。
  • 能否區分裝置容量、裝置分配帶來的節點資源占用和普通 Pod request,避免雙重計費。
  • 能否處理 NUMA、hugepages、節點更新亂序、驅動重啟和 ResourceSlice 陳舊資料。
  • 能否為 alpha feature gate 設計灰度、觀測、回滾和相容舊 driver 的路徑。
  • 能否把狀態更新權限限制在 DRA 合成子資源和節點範圍內。

30 秒回答框架

「我會讓 DRA driver 在 ResourceSlice 的 nodeAllocatableResourceMappings 中宣告每種裝置對 CPU、記憶體或 hugepages 的對映。排程器把已分配 claim 的對映與普通 Pod requests 合併到節點帳本,裝置本身只計入一次。對映支援 allocationMultiplier,必要時用 capacityKey 表示消耗容量;Pod status 的 nodeAllocatableResourceClaimStatuses 記錄實際分配結果。上線先在少量節點開啟 DRANodeAllocatableResources,驗證 NUMA、亂序更新和 pending 行為,異常時停止新 claim 並回退 driver 對映。」

分步驟深入解答

  1. 定義資源模型。 將裝置 ID、ResourceClaim、節點、NUMA 區域、資源名稱、單位、對映版本和觀察時間放入可重播帳本。區分裝置容量與其占用的 CPU、記憶體、hugepages;同一 claim 的占用只能進入帳本一次。
  1. 發布 ResourceSlice 對映。 DRA driver 在 ResourceSlice 中填寫 nodeAllocatableResourceMappings。對映鍵可以是 CPU、memory、ephemeral-storage 或 hugepages;每個裝置的固定占用可用 allocationMultiplier 表達,按容量消耗的資源可用 capacityKey 表達。
yaml
resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

上例只表達對映語義;欄位型別和單位必須以目前 Kubernetes API schema 及 driver 實作為準,不能把示意 YAML 直接當作可提交物件。

  1. 合併排程帳本。 排程器讀取 ResourceSlice 和已綁定 ResourceClaim,計算 DRA 貢獻,再疊加普通 Pod request。對同一 claim 使用穩定分配鍵去重;ResourceSlice 版本落後或對映缺失時,讓 Pod pending 並告警,不要用舊容量繼續放行。
  1. 處理 NUMA 與更新順序。 對映記錄 NUMA 親和性和版本。只有同一節點的分配、釋放和 ResourceSlice 版本滿足單調條件才提交帳本;驅動重啟時先重建對映,再恢復新 claim,避免短暫重複占用。
  1. 暴露狀態與觀測。 Pod 的 status.nodeAllocatableResourceClaimStatuses 記錄 claim 對節點資源的實際狀態。監控帳本容量、已用量、對映年齡、pending 原因、重複計數拒絕次數和 NUMA 放置失敗率,並把狀態寫入與排程決定關聯到 claim UID。
  1. 灰度與回滾。 在控制面、排程器和 driver 相容後,只對 canary 節點開啟 DRANodeAllocatableResources。先驗證 ResourceSlice、普通 Pod 與 claim 混排、節點重啟、驅動升級和回收;異常時停止新 claim,保留已有綁定,匯出帳本並修復對映,再按版本恢復。alpha 能力不得預設假設所有叢集都可安全開啟。
  1. 安全邊界。 DRA driver 只獲得完成自身狀態更新所需的合成子資源權限;節點本地 driver 使用節點感知的 verbs 和最小 RBAC。狀態寫入失敗應告警並重試,不能透過擴大權限繞過帳本不一致。

高品質示範回答

我會把 Node Allocatable 當成一個有版本的資源帳本。driver 在 ResourceSlice 的 nodeAllocatableResourceMappings 宣告裝置對 CPU、記憶體或 hugepages 的貢獻,固定貢獻用 allocationMultiplier,按容量消耗的貢獻用 capacityKey。排程器讀取已綁定 claim,把每個 claim 的貢獻與普通 Pod request 合併,使用 claim UID 去重,避免裝置占用和節點資源占用被重複計算。

帳本必須記錄節點、裝置、NUMA、對映版本和觀察時間。ResourceSlice 過期、版本倒退或 driver 重啟重建期間,寧可讓新 Pod pending,也不能依據舊容量放行。Pod 的 nodeAllocatableResourceClaimStatuses 用於回讀分配結果和診斷,不能取代帳本一致性檢查。

因為 v1.36 仍是 alpha,我會先在 canary 節點開啟 DRANodeAllocatableResources,驗證 claim 與普通 Pod 混排、NUMA、節點重啟、釋放和 driver 升級。回滾時停止新 claim,保留已有綁定並匯出帳本;修復對映後再恢復。RBAC 只授予 DRA 合成子資源和節點範圍權限。

常見錯誤

  • 錯誤表現: 每個裝置都直接扣一次節點 CPU,claim 重試後再扣一次 → 失敗原因: 缺少穩定冪等鍵 → 修正方法: 以 claim UID、裝置 ID 和對映版本去重。
  • 錯誤表現: 把示意 YAML 當作正式 API 物件提交 → 失敗原因: 對映欄位的 schema 與單位需要按版本核對 → 修正方法: 以 ResourceSlice API 定義和 driver 版本驗證。
  • 錯誤表現: ResourceSlice 暫時失聯仍沿用舊容量 → 失敗原因: 陳舊資料會造成超賣 → 修正方法: 設定 freshness 視窗,超時讓新 claim pending。
  • 錯誤表現: alpha gate 一次性全量開啟 → 失敗原因: 相容性和回滾面未驗證 → 修正方法: canary、指標、停止新 claim 和可恢復帳本。
  • 錯誤表現: 用擴大 RBAC 解決狀態寫入失敗 → 失敗原因: 權限越界且無法消除資料一致性問題 → 修正方法: 使用合成子資源、節點感知 verbs 和審計日誌。

追問及應對

allocationMultipliercapacityKey 怎麼選?

裝置每次分配都消耗固定 CPU 或記憶體時使用 allocationMultiplier。資源消耗隨裝置容量或工作負載變化時使用 capacityKey,並讓 driver 提供可審計的容量語義;兩者都要在 schema、單位和版本中固定。

普通 Pod request 與 DRA 對映如何避免重複?

建立單一帳本:普通 Pod request 進入 request 流,DRA 貢獻按 claim UID 進入 allocation 流,排程匯總時只對每個 claim 套用一次對映。帳本應記錄來源和版本,出現重複鍵時拒絕放行並告警。

driver 重啟時是否立即恢復排程?

不立即恢復。先重建 ResourceSlice、校驗已綁定 claim、確認版本單調和容量一致,再恢復新 claim;重建視窗內只保留已有綁定並讓新 Pod pending。

如何證明 NUMA 放置沒有破壞資源帳本?

回放跨 NUMA、同 NUMA、釋放重試和節點重啟事件,比較節點總帳、NUMA 子帳和 Pod status。指標包括放置失敗率、帳本差異、pending 時長和重複計數拒絕次數。

何時可以從 alpha 推廣?

至少要有相容 driver 覆蓋、回滾演練、節點重啟和升級回放、帳本差異為零的觀察視窗,以及明確的容量和 pending SLO。不能僅憑構建通過或單節點成功就全量開啟。

參考資料

  • Kubernetes v1.36 DRA 更新(Kubernetes Blog)
  • Feature Gates(Kubernetes Documentation)
  • ResourceSlice API(Kubernetes Documentation)
  • Pod API(Kubernetes Documentation)
  • DRA hardening guide(Kubernetes Documentation)

面試作答要點

先畫出 driver、ResourceSlice、claim、排程器、Node Allocatable 帳本和 Pod status 的資料流,再補冪等、版本、NUMA、灰度和最小權限。

一句話總結

DRA Node Allocatable 的核心是把 claim 對節點資源的真實貢獻納入單一、有版本、可回滾的排程帳本。

繼續練習

把資源對映擴展到多節點 ResourceClaim,並說明跨節點拓撲、容量新鮮度和故障恢復如何改變排程決策。

公開來源

同類題目

相關面試工具

用 Solve 整理系統設計回答

從澄清需求開始,展開規模、架構、元件選擇和取捨。

查看工具