題目與背景
你負責 Kubernetes GPU 平台。租戶提交的訓練與批次推理作業要等待配額、節點資源、維護窗口和安全政策全部滿足後才能建立 Pod。請用 Kueue 的 Workload、ClusterQueue、ResourceFlavor 與 AdmissionCheck 設計准入流程，並說明如何避免飢餓與錯誤放行。
面試官考察什麼
回答應分開「排隊」和「准入」：Workload 進入佇列不等於可以建立 Pod。ClusterQueue 根據資源組與 nominal quota 選擇 flavor，AdmissionCheck 讓外部或內部控制器參與放行。還要涵蓋狀態一致性、撤銷、部分准入、租戶公平、退避和稽核。
先問清楚的澄清問題
資源與優先級
確認 GPU 型號、顯存、CPU、記憶體、拓撲與可搶占性，以及租戶優先級、佇列公平和最大等待時間。只按 GPU 數量計算可能造成硬體不符的假容量。
外部准入依賴
確認維護窗口、映像掃描、預算核准和資料權限由哪些控制器檢查，檢查結果能否重放，逾時後是拒絕或等待。外部檢查必須有 owner 和 TTL。
失敗與撤銷策略
釐清准入後遇到節點變更、配額回收或政策撤銷時如何處理。准入記錄、Pod 建立和外部檢查要有冪等關聯，避免重複放行。
30 秒回答框架
「Workload 先進入 LocalQueue，再由 ClusterQueue 根據資源組、flavor 和 cohort 配額判斷是否可分配。所有 AdmissionCheckState 必須為 Ready 才能准入；Pending 繼續排隊，Rejected 或逾時依策略重試或終止。准入寫入可追蹤狀態，建立 Pod 前再次確認資源與政策仍有效，並用配額利用率、等待時間、檢查延遲、拒絕和撤銷指標驗證公平與安全。」
深入解答步驟
第一步：定義 Workload 與佇列邊界
把使用者 Job 轉成可調度 Workload，記錄 PodSet、資源請求、優先級和租戶佇列。LocalQueue 只負責等待與排序，不應直接建立 Pod 或繞過 ClusterQueue。
第二步：用 ClusterQueue 選擇資源 flavor
ClusterQueue 以 ResourceGroup 描述 CPU、記憶體和 GPU 資源，從 flavor 清單選擇滿足 nominal quota 的組合。把 GPU 型號、區域、節點標籤與拓撲作為 flavor 約束，避免數量足夠但硬體不符。
第三步：編排 AdmissionCheck 狀態機
每項檢查暴露 Pending、Ready、Rejected 或終止等狀態。安全掃描、維護窗口和預算控制器應用 Workload UID 冪等更新；只有所有必要檢查 Ready 才准入。Pending 不能誤寫成失敗，Rejected 也不能被調度器忽略。
第四步：處理部分准入與資源變化
若允許部分准入，明確 PodSet 可減少的並行度、最小規模與後續擴容規則。資源釋放或節點失效時重新評估 flavor 和檢查狀態，不能沿用過期快照。不可滿足的請求要給出可解釋原因。
第五步：保證公平、配額與防飢餓
按租戶、佇列與優先級定義 cohort 共享配額與借用邊界。限制高優先級作業長期占滿稀缺 GPU，為低優先級佇列設定等待或老化策略。分開觀測配額分配、檢查等待和 Pod 啟動。
第六步：設計撤銷、重試與稽核
控制器逾時或失敗時使用帶抖動退避並限制次數。准入撤銷必須安全處置 Workload 與 PodSet，不能只修改狀態欄位。記錄變更者、時間、原因、flavor、配額版本與檢查版本，支援重放。
第七步：驗證可觀測性與故障演練
監控排隊等待、准入延遲、各檢查 Pending 時長、拒絕率、撤銷數、quota 利用率、flavor 命中、GPU 閒置和 Pod 啟動延遲。演練控制器宕機、重複回調、配額回收、節點故障與網路分區。
高品質示例回答
我會讓 Workload 先進入 LocalQueue，ClusterQueue 根據資源組、flavor 和 cohort 配額選擇可行資源；AdmissionCheck 控制安全、維護和預算條件。只有所有必要檢查 Ready 且資源快照仍有效時才准入並建立 Pod。Pending 繼續排隊，Rejected 或逾時使用有限退避。GPU 型號、拓撲和區域寫入 flavor，並監控等待、檢查延遲、拒絕、撤銷和啟動延遲。
常見錯誤
- 錯誤： Workload 入隊就代表 Pod 已獲准。→ 原因： 排隊與准入是不同狀態。→ 改進： 只讓 ClusterQueue 和全部檢查 Ready 觸發准入。
- 錯誤： 只按 GPU 數量選資源。→ 原因： 型號、顯存、拓撲或區域可能不符。→ 改進： 用 ResourceFlavor 表達硬體約束。
- 錯誤： Pending 逾時就無限重試。→ 原因： 可能掩蓋永久不可滿足或控制器故障。→ 改進： 區分 Pending、Rejected 與原因，設上限與退避。
- 錯誤： 撤銷只改 Workload 狀態。→ 原因： Pod 可能繼續消耗資源。→ 改進： 定義 PodSet 處置、稽核與回滾流程。
追問與回答
追問 1：AdmissionCheck 與 Kubernetes Admission Webhook 有何不同？
AdmissionCheck 是 Kueue Workload 能否開始的業務准入狀態；Webhook 是 API 請求層擴充。兩者可協作，但 Webhook 通過不代表資源已分配。
追問 2：為什麼需要 ResourceFlavor？
同樣數量的 GPU 可能來自不同型號、區域或拓撲。Flavor 把可調度屬性與資源組配額綁定，讓選擇可解釋並避免錯誤放行。
追問 3：如何防止重複回調讓狀態倒退？
以 Workload UID、檢查名稱和版本作冪等鍵，拒絕舊版本覆蓋新狀態；重複 Ready 更新不能觸發第二次 Pod 建立。
追問 4：何時應拒絕而不是繼續等待？
若資源 flavor、政策或預算永遠不可能滿足，應明確拒絕並給原因。短暫節點不足、維護窗口或控制器重試可 Pending，但要有最大等待時間與告警。