題目與適用場景
這是面向平台與 Kubernetes 工程師的控制平面系統設計題。Kubernetes v1.36 引入服務端分片 List/Watch，屬於需開啟 ShardedListAndWatch 特性閘門的 alpha 功能。把它視為可選最佳化，控制器在閘門關閉時仍須正確。
面試官考察點
- 精確覆蓋鍵空間且只歸屬一次的分片模型。
- 正確的初始 List、resourceVersion 與 Watch 重連。
- 發現 API Server 忽略 selector 的機制。
- 重新分片、副本變化，以及重疊和缺口的取捨。
- API Server CPU、網路、informer 記憶體與恢復風暴的容量推理。
歸屬鍵是什麼？
alpha 實作支援 object.metadata.uid 與 object.metadata.namespace。UID 雜湊分布穩定；namespace 雜湊可保持租戶局部性但可能傾斜。選擇會改變均衡、隔離邊界與遷移成本。
正確性目標是什麼？
確認是否接受至少一次協調，以及重複處理是否冪等。業務副作用不能重複時，應增加持久化工作鍵與 fencing，不能只依賴事件流。
API Server 和客戶端能否同時升級？
預設存在混合版本，除非平台團隊證明全部升級。控制器要檢查回應中繼資料，閘門關閉或服務端不支援時回退到本地過濾，不能假稱負載已降低。
30 秒回答框架
「我會把確定性的 64 位元雜湊空間切成不重疊範圍，每個範圍分配給一個副本。每個 informer 在 List 與 Watch 都傳送 shard selector，並驗證回應包含匹配的分片中繼資料。缺少確認時安全回退到本地過濾或關閉最佳化。重新分片使用 generation 與交接協定，配合重疊、冪等協調及覆蓋率、重複數、延遲和回退流量指標。」
分步驟深入解答
分區與分配
用環上的半開範圍 [start, end) 表示 64 位元空間。每個範圍持久化 generation、owner 與 lease。兩個副本可各占一半，更多副本由控制器管理範圍表。不要只按副本序號推導歸屬，否則重啟可能製造缺口。
副本 A： [0000..., 8000...)
副本 B： [8000..., 1000...)讓 List 與 Watch 成為同一協定
初始 List 和每次 Watch 重連都攜帶相同 selector 與 resourceVersion。informer 收到完整初始清單後再替換本地 store，並從返回的 resourceVersion 開始 Watch。遇到 410 Gone 或版本過期時，只為該分片重新 List，不能盲目重放其他範圍。
驗證服務端支援
v1.36 部落格描述了回顯已套用 selector 的 shardInfo 回應欄位。缺失時要假設服務端返回完整集合。客戶端可本地過濾保持正確，但必須記錄回退指標並施加背壓，避免不支援的服務端讓每個副本都占滿記憶體。
無缺口地重新分片
建立新 generation 的範圍。交接期間舊 owner 繼續協調，新 owner 先完成 List 預熱，並在已知 resourceVersion 上建立 Watch。雙方 ready 後才提交歸屬變化；協調冪等時重複事件可接受。ready 失敗則讓 lease 過期並保留舊 owner。
容量與失敗路徑
服務端過濾減少被丟棄物件的位元組和反序列化成本，但 API Server 增加雜湊與 selector 計算。用特性閘門、每個控制器的並發上限和灰度保護它。API Server 過載時限制重連並指數退避，不能讓所有副本同時 relist。
高品質示範回答
「我會用物件 UID 的確定性雜湊建立帶 generation 的範圍表。informer 在 List 與 Watch 都攜帶 selector，只有看到 shardInfo 才把最佳化視為生效。缺失欄位時回退到本地過濾，並使用全域並發預算。重新分片建立新 generation，讓新 owner 從指定版本預熱，ready 後再切換 lease；協調冪等使短暫重疊安全。灰度開啟閘門，並比較 API CPU、位元組、List 延遲、Watch 重連、分片覆蓋、重複數和回退率。」
常見錯誤
- 按副本序號分片 → 重啟會改變歸屬並製造缺口 → 持久化帶 generation 的範圍表。
- 只給 Watch 加 selector → 初始 List 仍過載且可能與流不一致 → List 和 Watch 使用同一 selector 與版本規則。
- 信任不支援的服務端 → 每個副本收到完整流 → 要求
shardInfo並暴露回退流量。 - 瞬間移動範圍 → 交接期間可能遺失事件 → owner 重疊、generation fencing，並讓協調冪等。
- 只看控制器 CPU → API Server 雜湊或重連風暴不可見 → 同時監控控制平面與客戶端指標。
評分標準與自檢
評分分區正確性、List/Watch 語義、回退、重新分片、容量和可觀測性。強回答應明確不變量：每個物件屬於一個活動範圍 generation，交接有 resourceVersion 邊界；還要說明冪等協調時重複比缺失更安全。
追問及應對
某個 namespace 特別大怎麼辦？
優先用 UID 雜湊均衡，或把熱點 namespace 拆成多個 UID 範圍。測量各範圍負載，不要假設物件數量相等。
如何發現靜默缺口？
用全域物件數與分片數並集做抽樣比較，記錄 selector generation，並週期性建立經過所有範圍的合成物件。對延遲或覆蓋漂移告警。
API Server 升級期間怎麼辦？
在所有服務端點的 canary 都返回 shardInfo 前保持閘門關閉。混合回應觸發回退和有界重連速率。
控制器會重複處理物件嗎？
交疊或重連期間會。用物件版本和持久化工作鍵保證副作用冪等；不能為了避免重複而接受無限的遺失狀態風險。