具代表性的面試主題

系統設計面試題:Kubernetes PodGroup 如何實作 gang scheduling?

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

題幹

Kubernetes PodGroup 如何實作 gang scheduling?

題幹

Kubernetes v1.35 提供 alpha 的 Scheduling Group。請設計批次平台:一組相互依賴的 worker,只有至少 minCount 個 Pod 能同時放置時才啟動。說明 PodGroup、排程器、控制器、自動擴縮與故障處理如何協作,並標明版本與 feature gate 前提。

面試官在考察什麼

題目考察你能否把「單一 Pod 可排程」提升為「群組可行性」,並維持 API、排程與執行狀態一致。回答要區分 basicgang,處理 PodGroup 尚未建立、資源不足、成員失敗、搶占與監控閉環。

先確認這些問題

  1. worker 必須全部同時啟動,還是達到可用下限即可?
  2. 成員是一次性 Job 還是長時間服務?
  3. 是否跨命名空間、需要 GPU 或拓撲限制?官方引用是同一命名空間的 PodGroup。
  4. 等待多久算失敗?是否允許排隊、借用低優先級資源或降級?

30 秒回答框架

先說明 v1.35 alpha、預設關閉,需啟用 GenericWorkload。接著依序回答 API 契約、群組排程、生命週期與營運護欄:Workload 建立 PodGroup,Pod 引用它;排程器依策略與 minCount 做原子判斷;控制器負責超時、重試與清理;指標和回滾保護發布。

逐步拆解方案

1. 模型與不變量

控制器為每次執行建立唯一 PodGroup,記錄期望成員、策略、版本與租戶。Pod 以 spec.schedulingGroup.podGroupName 指向同命名空間物件;欄位不可變,換組需建立新物件。gang 未達 minCount 前不得綁定節點。

2. 策略選擇

basic 用於只需聚合觀測、成員可獨立執行的工作,Pod 仍可各自排程。gang 用於緊耦合訓練或批次,至少 minCount 個成員同時可行才接受。minCount 小於總成員數可保留彈性,等於總數則要求全員。

3. 提交與等待狀態機

控制器先建立 PodGroup 再建立 Pod,避免引用不存在。若物件暫缺,Pod 保持 Pending,物件出現後排程器會重新考慮。狀態可包含 PendingGroupWaitingCapacityFeasibleBoundRunningFailedCancelled,並記錄 generation、原因與時間。

4. 排程與資源協調

先按過濾、拓撲、裝置與優先級計算每個成員候選節點,再判斷群組可行性。只有候選數達到 minCount 才綁定,操作必須可重試且冪等。擴縮容器依群組資源輪廓擴容,避免只替第一個 Pod 增加節點。

5. 搶占、逾時與公平

群組使用一致 priority 與 queue weight,避免只搶到部分成員。逾時後取消整組並釋放資源;重試使用新 generation。租戶配額、最大群組大小與隊列老化可限制大型 gang 長期佔用叢集。

6. 成員失敗與回滾

執行中成員崩潰時,不能把曾經達標當成目前可用。依作業語意重啟成員或終止整組;訓練作業可從 checkpoint 重建新組。刪除 Workload 時按 owner 關係清理並保留終態事件。

7. 可觀測性與安全邊界

提供群組等待時長、可行成員數、minCount、擴容與搶占次數及失敗原因。Admission webhook 驗證命名空間、配額、大小與 gate。alpha API 要有明確開關、相容性測試與快速回滾。

合格回答示例

「我會由 Workload 控制器建立同命名空間 PodGroup,策略使用 gang,minCount 設為可前進所需的最小 worker 數。Pod 以不可變 schedulingGroup 引用它。先建群組再建 Pod;缺少群組時成員保持 Pending。排程器同時計算資源、拓撲與優先級,候選數達到 minCount 才綁定。擴縮容按整組資源輪廓處理,逾時取消整組並釋放資源,失敗以新 generation 從 checkpoint 恢復。發布清單標示 v1.35 alpha 與 GenericWorkload,先在隔離叢集驗證。」

常見失分點

  • basic 說成 all-or-nothing。
  • 只用標籤,沒有說明同命名空間 PodGroup 引用與不可變欄位。
  • 忽略缺少群組、擴容、逾時、搶占與重試。
  • 忽略 alpha 和 GenericWorkload feature gate。
  • 只講綁定成功,沒有群組級指標和取消語意。

追問方向

PodGroup 晚於 Pod 建立怎麼辦?

Pod 保持 Pending,群組建立後排程器會重新考慮;控制器仍應採先群組後 Pod。

minCount 如何決定?

依應用所需並發下限、單 Pod 資源與可接受等待時間設定,並配合配額和上限。

如何避免 gang 飢餓?

採用公平隊列、老化、群組大小上限、租戶配額與逾時取消,觀察等待時間。

與 schedulingGates 的差異?

Gate 控制單一 Pod 何時進入可排程隊列;Scheduling Group 讓排程器按 PodGroup 評估一組成員,兩者可組合但指標要分開。

何時暫緩上線?

版本、feature gate、排程插件或擴縮容器未相容,或無法驗證 alpha API 升級回滾時,先使用顯式隊列控制器。

參考資料

  • Kubernetes 文件《Scheduling Group》。
  • Kubernetes 文件《PodGroup Scheduling Policies》。
  • Kubernetes 文件《Scheduling API Reference》。

公開來源

同類題目

相關面試工具

用 Solve 整理系統設計回答

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

查看工具