題目與適用場景
你負責 Kubernetes 集群上的分散式訓練平台。工作負載由 PodGroup 表示，Pod 需要共享機架或可用區以降低通訊延遲；若同一拓撲網域無法容納至少 minCount 個 Pod，工作負載應保持不可調度。
本文適合平台工程、SRE 與系統設計職位。假設使用 Kubernetes v1.36 的 alpha Topology-Aware Scheduling，功能預設關閉，且每個 PodGroup 目前只宣告一個拓撲約束。
面試官考察什麼
- 能否區分「跨域均勻分散」的 topology spread 與「同域共置」的拓撲感知 Gang 調度。
- 能否把 PodGroup、節點標籤、候選放置、資源評估與綁定原子性串成完整資料流。
- 能否說清楚
minCount、容量不足、擴容與搶占尚未滿足時的狀態。 - 能否識別 alpha 功能、異質 PodGroup 與失敗回滾的生產風險。
回答前要釐清的問題
- 要共置在機架、可用區還是 NUMA 網域？拓撲鍵不同，通訊與容量假設也不同。
- 是所有 Pod 必須同時啟動，還是達到
minCount就可開始？這決定 Gang 策略與彈性。 - Pod 是否同質？不同資源請求會影響候選放置是否能找到，即使理論上存在解。
- 集群是否允許擴容或搶占？v1.36 的拓撲感知調度本身不會為了約束觸發搶占。
30 秒回答框架
「我先把目標定義為同一拓撲網域內的 group-level feasibility，而不是把副本分散到多個網域。Workload 範本產生 PodGroup，PodGroup 使用 gang 與 minCount，節點標籤提供唯一拓撲鍵。調度器產生候選節點子集，檢查整組是否能放入，再為可行放置評分；找不到就讓整組不可調度。控制器與 autoscaler 依整組資源形狀重試，搶占能力另行評估，因為 v1.36 TAS 不會主動搶占。上線前用網域容量、節點故障與異質請求演練，並保留 alpha 功能開關。」
逐步深入解法
1. 明確共置而非分散
topologySpreadConstraints 透過 maxSkew 追求網域間平衡；本題要求 PodGroup 成員共享同一個拓撲標籤值。混用兩種語意會得到相反放置結果，因此先把網路延遲目標寫成「單一網域可容納至少 minCount」。
2. 設計 PodGroup 契約
在範本宣告 Gang 策略、minCount 與單一拓撲鍵。示意設定如下：
apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
schedulingPolicy:
gang:
minCount: 4
schedulingConstraints:
topology:
- key: topology.example.com/rack節點必須有穩定且受治理的標籤值。PodGroup 只表達放置約束，Workload 控制器仍負責成員生成、版本與生命週期。
3. 解釋候選放置演算法
調度器先依資源、污點、親和性與拓撲鍵產生候選節點子集，再驗證完整 PodGroup 是否能在該子集內滿足 minCount，最後為可行放置評分。這比逐一 Pod 綁定更能避免「前幾個 Pod 已占滿不同網域，剩餘成員無處可放」。
4. 處理容量、擴容與搶占
候選網域沒有足夠容量時，整組保持不可調度；autoscaler 應讀取完整工作負載的 CPU、記憶體、GPU 與網域約束，擴容目標不能只看第一個 Pending Pod。v1.36 TAS 不會為滿足拓撲約束觸發 Pod 或 Workload preemption，因此需要獨立的容量預留、佇列或明確的上游搶占策略。
5. 處理成員重建與網域黏性
若已有成員在某個網域執行，重建的新 Pod 會被強制放回同一網域；該網域容量不足時，即使其他網域有空間也會 Pending。控制器應把這個狀態暴露為「網域黏性導致等待」，並決定等待、恢復檢查點，或建立新一代 PodGroup 放寬約束。
6. 評估 alpha 與異質限制
v1.36 API 是 alpha 且預設關閉。官方說明中，異質 PodGroup 或存在成員間依賴時，演算法不保證找到已有的可行放置。生產閘門應包含版本、feature gate、scheduler plugin、autoscaler 與回滾清單；不能把一次成功調度當作普遍保證。
7. 建立驗證與回滾閉環
用同一組訓練任務測試單域容量剛好足夠、少一個節點、網域標籤缺失、GPU 不同型與成員重建。記錄候選網域、可行成員數、Pending 原因、等待時間、跨域流量與訓練吞吐。灰度失敗時關閉 feature gate 或回到普通 Gang 調度，保留 PodGroup 事件以便稽核。
高品質示範回答
我會把目標定義成「至少 minCount 個成員能在同一拓撲網域內同時放置」，而不是使用 spread constraint 做均勻分散。Workload 控制器先建立帶 gang 策略、minCount 與單一拓撲鍵的 PodGroup，再產生引用它的 Pod。調度器依資源與節點標籤產生候選網域，驗證整組能否放入，並只對可行網域評分；找不到就讓整組保持 Pending。Autoscaler 依整組資源形狀擴容，搶占另行處理，因為 v1.36 TAS 不會主動搶占。成員重建時保持網域黏性，網域不足則等待或建立新一代。最後在 alpha 功能開關下演練節點故障、標籤缺失、異質 GPU 與回滾，觀察等待時間、跨域流量與訓練吞吐。
常見失分點
- 錯誤表現：用
maxSkew解釋同域共置。失敗原因：spread 的目標是分散，與 Gang 共置相反。修正方法：先說明 PodGroup 拓撲鍵的單域不變量。 - 錯誤表現：按 Pod 逐一綁定。失敗原因：前面的綁定可能消耗多個網域容量，剩餘成員無法滿足
minCount。修正方法：先產生並評估完整候選放置。 - 錯誤表現：假設 TAS 會自動搶占。失敗原因：v1.36 文件明確指出拓撲感知調度不會觸發搶占。修正方法：設計容量預留、佇列或獨立搶占控制器。
- 錯誤表現：忽略異質 PodGroup 與 alpha 狀態。失敗原因：演算法不保證找到理論上存在的放置，且功能預設關閉。修正方法：加入版本、feature gate、外掛與回滾閘門。
追問深入
如果同一機架放不下 minCount，但兩個機架合計放得下怎麼辦？
該工作負載的同域不變量未滿足，應保持 Pending 或降低 minCount，前提是應用允許彈性。不能靜默退化成跨機架，否則通訊假設已經改變。
如何讓 autoscaler 正確擴容？
把整組資源請求、拓撲鍵與 minCount 當作一個擴容單元，預測目標網域需要的節點類型與數量。擴容後重新產生候選放置，並設定等待上限。
成員重建時為什麼不能搬到另一個網域？
官方語意要求新成員與已執行成員保持同一拓撲網域；遷移會改變網路延遲與共享資源假設。若網域永久損壞，應建立新一代 PodGroup，而不是偷偷改變舊組。
這和 topology spread constraints 如何共存？
組內訓練成員使用 TAS 共置；跨多個訓練作業的副本分布才可使用 spread。把兩者放在同一 Pod 前要驗證交集是否為空，否則硬約束會讓 Pod 長期 Pending。
什麼時候選擇普通 Gang 而不啟用 TAS？
當跨域通訊成本低、網域容量經常不足、版本仍在 alpha 灰度，或工作負載不需要共享機架時，普通 Gang 更簡單。只有同域帶來的吞吐收益能覆蓋容量與維運成本時才啟用 TAS。