系統設計面試：如何為 Kubernetes DRA 設計可解釋的裝置優先級與回退？
題干與適用場景
你負責一個執行訓練與推理工作的 Kubernetes 叢集。節點同時存在 H100、A100 與較小的加速器，業務希望同一個 Pod 優先使用 H100，資源不足時依宣告順序回退到 A100，再回退到其他相容裝置。請設計基於 Dynamic Resource Allocation（DRA）的裝置請求與排程方案，並說明確定性、公平性、故障處理、可觀測性、遷移和回滾。回答應面向能參與架構取捨的高階工程師。
面試官考察點
- 能否把「優先級」定義成可驗證的約束，而不是在客戶端硬編碼搶占。
- 能否解釋 ResourceClaim、ResourceSlice 與排程器之間的生命週期。
- 能否處理同一優先級下的確定性並列、裝置健康、重試和逾時。
- 能否同時討論容量公平、租戶隔離、指標和稽核。
- 能否給出從裝置外掛遷移到 DRA 的灰度與回滾邊界。
回答前需要釐清的問題
- 回退是「任一可用裝置即可」，還是必須保持顯存、架構和驅動能力等硬約束？
- 一個 Pod 可接受多張不同型號裝置嗎？拓撲、NUMA 和網路頻寬是否是硬約束？
- 業務需要嚴格的裝置型號承諾，還是允許在成功率與成本之間最佳化？
- 租戶是否有配額、優先級和搶占規則？故障中的裝置是否立即從候選集中移除？
- 現有工作負載能否改成 ResourceClaim，遷移期間是否必須與舊裝置外掛共存？
30 秒回答
我會把裝置偏好編碼為帶有硬約束和有序候選的 DRA 請求，由排程器在資源宣告階段完成匹配，而不是讓客戶端輪詢節點。排程器先過濾驅動、架構、拓撲和租戶配額等硬約束，再按 H100、A100、其他相容裝置的順序選擇。每一層都使用穩定的確定性並列規則，並把候選、拒絕原因和最終選擇寫入事件與指標。裝置健康變化或綁定失敗時只在宣告仍可重試的範圍內重新評估；公平性透過佇列配額和租戶權重保證。遷移採用雙軌灰度、可逆的 ResourceClaim 範本和舊外掛回滾開關。
分步驟深入解答
1. 定義偏好模型
把型號順序作為軟偏好，把驅動版本、架構、顯存下限、拓撲和安全隔離作為硬約束。範例請求可表達「首選 H100，次選 A100」，但不能讓回退繞過顯存或租戶配額。請求還應包含版本化的策略識別，便於稽核和回滾。
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
spec:
devices:
requests:
- name: accelerator
exactly:
deviceClassName: gpu
selectors:
- cel: "device.attributes['model'] == 'H100'"
- cel: "device.attributes['model'] == 'A100'"這裡的有序選擇表達業務偏好；實際部署仍要以叢集支援的 DRA API 版本和驅動能力為準。
2. 資源宣告與排程流程
Pod 透過 ResourceClaimTemplate 產生宣告。DRA 驅動發布 ResourceSlice，描述裝置屬性、容量和健康狀態。排程器在預選階段讀取宣告與切片，先驗證硬約束，再按候選順序尋找可綁定裝置；綁定成功後，驅動將分配結果注入容器。宣告必須是等冪的，重試不能產生第二份無法回收的分配。
3. 確定性選擇與解釋
同一候選層有多台裝置時，使用資源池、ResourceSlice 名稱和裝置識別的穩定字典序，或明確的容量與拓撲排序；規則必須寫入介面契約。每次排程記錄候選清單、過濾條件、拒絕原因、最終裝置和策略版本。如此重播同一輸入可以得到相同結果，排查「為什麼沒有拿到 H100」時也有證據。
4. 故障、健康與重試
健康狀態不可用時，新宣告應跳過該裝置；已綁定工作則由執行時和控制器決定是否終止、遷移或重建。綁定衝突、切片過期和節點下線要區分為可重試與不可重試錯誤。重試需帶退避和宣告等冪鍵，避免高峰期反覆掃描放大排程負載。回退到 A100 只能在硬約束仍滿足時發生，並應在 Pod 狀態中明確顯示實際型號。
5. 公平性、容量與可觀測性
優先級不應變成無限期占用 H100 的通行證。佇列層按租戶配額、權重和等待時間進行公平仲裁，裝置層按候選順序選擇。核心指標包括各型號請求量、回退率、等待時間、綁定失敗率、健康變化、每租戶占用量和策略命中率。事件中保留可讀的選擇鏈路，日誌避免洩露租戶敏感資料。
6. 遷移與回滾
先為少量工作負載提供 DRA 類別和 ResourceClaim 範本，舊裝置外掛繼續服務未遷移的 Pod。比較成功率、回退率、排程延遲和 GPU 利用率後擴大範圍。範本和策略版本化；發現驅動或排程問題時，停止新範本發布並把工作負載切回舊外掛，已綁定工作按既定終止策略處理，避免同時修改宣告和底層裝置分配。
高品質示範回答
我會把問題拆成偏好、約束和分配證明三層。偏好是有序候選，約束包含型號能力、顯存、驅動、拓撲、租戶配額和安全邊界。Pod 建立後透過 ResourceClaim 請求裝置，DRA 驅動發布 ResourceSlice，排程器先過濾硬約束，再按候選順序選擇；同層採用穩定的資源池與裝置識別排序，保證重播一致。每次選擇都寫入事件，包含候選、拒絕原因、策略版本和實際型號。
故障路徑要區分健康不可用、綁定衝突、宣告過期和節點下線。只有可重試錯誤才退避重試，回退不能越過硬約束，最終型號必須回寫狀態。公平性由租戶配額、佇列權重和等待時間控制，避免 H100 偏好壓垮低優先級租戶。遷移採用舊外掛與 DRA 雙軌灰度，範本可回滾，指標達到門檻後再擴大範圍。
常見錯誤
- 只說「按型號排序」，沒有定義硬約束和同層並列規則。
- 讓客戶端掃描節點或直接搶占裝置，繞開宣告與排程器。
- 把裝置健康、綁定衝突和不可滿足約束都當成無限重試。
- 只追求 H100 命中率，忽略租戶公平、配額和等待時間。
- 遷移時一次性刪除舊裝置外掛，導致無法快速回滾。
- 只記錄最終裝置，不記錄候選與拒絕原因，無法解釋回退。
追問及應對
如果 H100 和 A100 都滿足約束，為什麼不隨機選擇？
隨機會降低重播能力和除錯品質。可以在穩定排序後加入容量均衡，但必須保持規則可解釋、輸入可觀測，並避免把隨機種子當成隱藏契約。
裝置在預選後、綁定前變成不健康怎麼辦？
綁定階段再次校驗版本和健康狀態；失敗時返回分類錯誤，只有宣告仍有效且有候選時才退避重試，否則讓 Pod 暴露明確的不可滿足原因。
如何證明回退沒有破壞公平性？
按租戶和型號統計等待時間、占用量、回退率和佇列份額，進行離線重播與線上灰度比較。若某租戶長期拿不到首選裝置，應調整配額或權重，而不是繼續提高其請求優先級。