具代表性的面試主題

系統設計面試:Kubernetes 如何動態更新 CSI 節點卷掛載容量?

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

題幹

一個節點的 CSI 驅動可掛載卷數會因雲端配額和健康狀態變化。如何讓調度器取得新容量,同時避免過度調度、永久 Pending 和控制面抖動?

題幹與適用場景

一個節點的 CSI 驅動可掛載卷數會因雲端配額和健康狀態變化。請設計 Kubernetes Mutable CSINode Allocatable 的容量上報、調度一致性、故障保護與升級方案。回答要說明 CSI 驅動、節點物件、調度器和掛載失敗之間的責任邊界。

面試官考察點

  • 是否理解 CSINode.spec.drivers[].allocatable.count 是調度參考而非即時鎖。
  • 是否能說明 CSI 驅動如何週期性或因錯誤更新容量。
  • 是否處理舊資料、並發更新、調度快取和 attach 失敗。
  • 是否能設計告警、退避、相容升級與容量恢復路徑。

回答前需要釐清的問題

  1. 容量變化來自雲端 API 配額、驅動健康狀態,還是節點本地資源?
  2. 更新允許的延遲和誤差是多少,是否接受少量保守 Pending?
  3. 現有叢集和 CSI 驅動版本是否支援可變 allocatable?
  4. attach 失敗時希望自動重試、遷移 Pod,還是先凍結該節點?

30 秒回答框架

先說明物件:CSI 驅動把節點可用卷數寫入 CSINode,調度器據此做容量過濾;該值可能滯後,因此 attach 階段仍需最終校驗。驅動在週期或明確失敗後更新值,控制器和調度器透過 watch 收斂。更新要限頻、單調處理版本並在異常時保守降容,避免把錯誤的高容量擴散到整個叢集。

分步驟深入解答

1. 責任鏈與資料模型

每個節點和 CSI 驅動組合對應 CSINode.spec.drivers[].allocatable.count。CSI 驅動最了解雲端或儲存後端的 attach 上限,因此負責提供可用容量;調度器把它作為預過濾資訊。這個欄位不是分散式鎖,也不能保證多個調度決策之間沒有競爭,真正建立或掛載卷時仍需驅動和控制器校驗。

2. 更新觸發與一致性

驅動可以按 CSIDriver 設定的週期刷新,也可以在 attach 返回容量不足等明確錯誤後立即更新。寫入要帶資源版本條件,避免舊驅動覆蓋新值;更新頻率設定最小間隔和抖動,防止雲端 API 抖動造成控制面寫放大。調度器 watch 到新物件後刷新快取,短暫不一致期間採取保守決策。

3. 失敗保護與恢復

當驅動無法取得配額或健康狀態時,不應上報無限高容量;可以保留最近成功值並縮短有效期,或將容量降為零觸發新 Pod Pending。attach 失敗需要區分容量耗盡、權限、拓撲和暫時網路錯誤,只有容量類錯誤才更新 allocatable。恢復後逐步增加容量並觀察 attach 成功率,避免一次性放量。

4. 升級、觀測與驗證

Kubernetes v1.36 將 Mutable CSINode Allocatable 穩定化。升級前驗證 API Server、調度器、kubelet 和 CSI 驅動版本矩陣,先在少量節點啟用週期更新。監控物件更新延遲、容量變化頻率、調度 Pending 原因、attach 失敗分類、控制面寫入 QPS 和節點實際使用量。若指標惡化,暫停更新、恢復相容設定並保留最後一次可信容量。

高品質示範回答

我會把可變 allocatable 當作調度提示,不當作即時鎖。CSI 驅動在 CSINode.spec.drivers[].allocatable.count 上報節點與驅動組合的可掛載卷數,週期刷新或在明確的容量不足錯誤後更新。調度器透過 watch 更新快取,但 attach 階段仍由驅動做最終校驗。

更新必須限頻、帶資源版本條件並加入抖動;無法取得可靠配額時保守降容,不能把無限高容量寫入叢集。attach 失敗按容量、權限、拓撲和網路分類,只有容量類錯誤觸發更新。v1.36 穩定化後,我會先灰度節點,觀察更新延遲、Pending、attach 失敗、寫入 QPS 和實際使用量,異常時暫停更新並恢復最近可信值。

常見錯誤

  • 把 allocatable 當作不會競爭的即時鎖。
  • 任何 attach 失敗都把容量降為零,造成誤傷。
  • 讓驅動高頻寫 CSINode,引發控制面寫放大。
  • 配額查詢失敗時繼續上報過高容量。
  • 升級只看 API 版本,忽略 CSI 驅動、調度器和 kubelet 的相容矩陣。

追問及應對

追問一:為什麼調度器看到足夠容量,Pod 仍可能掛載失敗?

容量欄位存在傳播延遲和並發競爭,多個 Pod 可能同時消耗同一配額。調度過濾只能降低失敗機率,attach 階段必須由 CSI 驅動再次校驗並返回可分類錯誤。

追問二:多久刷新一次最合適?

取決於雲端配額變化頻率、控制面寫入預算和業務對 Pending 的容忍度。應從保守週期開始,結合更新延遲、失敗率和寫入 QPS 調整,並在錯誤觸發時提供退避更新。

追問三:如何防止舊 CSI 驅動覆蓋新容量?

使用資源版本條件更新和驅動版本門禁,升級期間限制舊驅動寫入。監控欄位的寫入者、時間戳和異常回退,發現回退就暫停自動擴容。

公開來源

同類題目

相關面試工具

用 Solve 整理系統設計回答

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

查看工具