通用面試：如何為 Kubernetes Pod 級資源伸縮制定准入政策？
題幹與適用場景
平台團隊準備開放 Kubernetes Pod 級 CPU/記憶體 resize。業務團隊希望自動調優，財務擔心成本失控，SRE 擔心記憶體變更觸發容器重啟。請制定一套跨團隊准入、審計、事故響應和回滾政策。
面試官考察點
- 能否把技術能力轉成清楚的責任、權限和預算邊界。
- 能否用風險分級決定哪些工作負載可自動伸縮。
- 能否把狀態條件、重啟策略和 SLO 作為審批依據。
- 能否透過審計和演練證明政策在事故中可執行。
回答前需要釐清的問題
- 哪些命名空間、環境和工作負載允許 resize？
- 誰批准上限、誰承擔成本，誰有緊急凍結權限？
- 如何識別容器級
resizePolicy、有狀態連線和記憶體重啟風險？ - 組織是否已有配額、變更窗口、審計和事故指揮流程？
30 秒回答
我會先按環境、業務關鍵性和容器重啟風險分級：開發環境可自動調優，生產關鍵服務預設需審批。政策固定最小/最大 CPU 和記憶體、步長、冷卻時間、命名空間配額和 SLO 護欄，要求請求通過 /resize 子資源並記錄 owner、原因和 observedGeneration。准入控制器拒絕越界或無法解釋的請求，事件中區分 Pending、InProgress、Infeasible 和 Deferred。審計記錄成本與重啟，定期演練凍結、回滾和責任交接。
分步驟深入解答
定義風險等級
按環境、SLO、資料狀態、連線可中斷性和容器 resizePolicy 分級。關鍵有狀態服務、支付和控制面預設禁止自動記憶體變更；低風險無狀態服務可在上限內自動調整。
建立准入規則
規則至少包含 namespace allowlist、資源上下限、步長、冷卻時間、節點容量、配額、變更窗口和必要標籤。任何請求都要說明指標來源、目標和預計成本。
綁定 Kubernetes 狀態
政策要求控制器讀取 desired/actual resources、observedGeneration 和 resize conditions。只有 InProgress 完成且實際值符合目標才算成功；Pending、Infeasible 或 Deferred 必須進入佇列並顯示原因。
處理重啟與回滾
記憶體變更可能觸發容器重啟，政策要求服務聲明連線排空、狀態恢復和最大重啟次數。超過閾值自動凍結，恢復最後穩定預算，不允許只把 Pod phase Running 當作無事故。
做好成本與審計
記錄每次變更前後 CPU/記憶體、持續時間、成本估算、owner、審批人和結果。財務按 namespace、團隊和工作負載查看預算偏差，SRE 查看 SLO、OOM 和重啟關聯。
事故演練與治理迭代
定期演練節點容量不足、控制器失聯、錯誤預算和大規模回滾。演練後更新規則、runbook 和聯絡人；任何例外都要有過期時間，避免臨時白名單永久存在。
高品質示範回答
我會把 Pod resize 作為受治理的變更能力，而不是預設開放的開關。根據環境、SLO、狀態和 resizePolicy 分級，關鍵有狀態服務預設需要審批。准入規則固定 namespace、上下限、步長、冷卻、配額、節點容量和變更窗口，並要求透過 /resize 子資源、帶 owner、原因和 observedGeneration。控制器只在實際狀態完成後確認成功，Pending/Infeasible/Deferred 都要可見。記憶體重啟有排空和恢復門檻，超限就凍結並回滾。審計連接成本、SLO、OOM 和 restartCount，定期演練凍結、回滾和責任交接。
常見錯誤
- 只寫資源上下限，不定義審批人、凍結權和責任邊界。
- 允許所有生產 namespace 自動記憶體伸縮。
- 忽略
/resize狀態條件和容器重啟策略。 - 用 Pod phase Running 代替業務無中斷證據。
- 沒有成本審計、例外過期時間和回滾演練。
- 發生事故時才臨時尋找 owner 和 runbook。
追問及應對
哪類服務應預設禁止自動記憶體 resize？
無法快速排空連線、狀態恢復代價高或重啟會影響一致性的關鍵服務，應先審批並完成演練。
如何防止團隊繞過政策直接改 Pod？
用准入控制器、RBAC、欄位管理和審計拒絕未授權寫入；緊急權限要限時、可追蹤並自動過期。
成本與 SLO 衝突時誰決定？
政策預先定義優先級和預算閾值，超閾值由指定業務與 SRE 負責人共同決定，不能由控制器默默選擇。
如何判斷政策有效？
比較越界請求攔截率、SLO 回歸、OOM、重啟、預算偏差、回滾耗時和演練完成率，並按團隊復盤調整。