題幹與適用場景
Kubernetes Pod 級資源允許 Pod 在容器資源之外宣告 CPU、記憶體或 hugepages 請求與限制。兩者同時存在時，Pod 級值優先，並影響調度、QoS 與 OOM 評分。發布前必須確認 PodLevelResources 功能閘和叢集版本。
假設代理和工作程序共享突發負載，但代理有延遲 SLO，工作程序可以使用剩餘容量。目標是在不讓調度器或 kubelet 強制執行錯誤預算的前提下表達這種關係。
面試官考察點
面試官關注資源所有權模型、優先順序規則是否正確，以及是否知道 Pod 級資源會改變調度和 QoS。強回答會討論總量與容器保證、限制、自動擴縮、可觀測性和遷移測試。
普通回答把容器請求相加後填入 spec.resources。強回答會說明 Pod 預算是否為共享池、哪個容器需要底線，以及如何防止工作程序占用代理延遲餘量。
回答前需要釐清的問題
- Pod 級請求是共享預算，還是每個容器的硬性最低值？
- 涉及哪些 Kubernetes 版本、功能閘、資源管理器和作業系統？
- 代理是否需要獨立於工作程序的 CPU 底線或記憶體限制？
- HPA、VPA 和驅逐策略如何觀察新的資源範圍？
- 遷移期間同時設定 Pod 級和容器級請求會怎樣？
如果容器需要獨立擴縮或故障域，拆成不同 Pod 可能更安全。如果它們確實共享生命週期和突發預算，Pod 級資源更能表達關係。
30 秒回答框架
「我會先確認功能閘和版本，再把 Pod 建模為共享預算並明確代理底線。Pod 級請求優先，所以要避免混合設定產生意外。我會測試 QoS、OOM 和自動擴縮輸入，先灰度清單，對比延遲、節流、驅逐和成本，並保留回滾到容器級請求的路徑。」
分步驟深入解答
- 劃分資源角色。 測量代理延遲敏感度、工作程序突發、穩態用量和記憶體增長，決定共享預算還是隔離保證。
- 確認能力。 核對伺服器版本、控制平面和節點上的
PodLevelResources、支援的資源類型及作業系統限制。 - 設定 Pod 預算。 用請求影響調度，用限制設定總上限，並為代理延遲底線與工作程序突發留出空間。
- 消除優先順序歧義。 遷移期間記錄 Pod 級值覆蓋容器級值，刪除衝突設定，或明確保留兩層的目的。
- 檢查 QoS 與驅逐。 重新計算 QoS 和 OOM 行為，測試節點壓力、節流和工作程序爭用；總量健康仍可能掩蓋代理飢餓。
- 灰度觀察。 先發布一個工作負載，追蹤 p95 延遲、CPU 節流、記憶體壓力、OOM、驅逐、重啟和成本，護欄穩定後再擴大。
替代方案包括拆分 Deployment、只使用容器級請求，或給 sidecar 設定明確限制。Pod 級資源適合生命週期和突發容量有意共享的場景。
高品質示範回答
「代理需要延遲底線，工作程序可以借用剩餘 CPU。我會設定反映正常總量的 Pod 請求和突發上限，然後驗證工作程序高負載時代理不會飢餓。遷移時刪除衝突容器請求，或明確它們保留的目的，因為 Pod 級值會優先。我會在兩台節點上灰度，觀察 p95 延遲、節流、OOM、驅逐和自動擴縮行為；如果代理 SLO 退化，就回滾到舊的容器策略。」
常見錯誤
- 錯誤表現： 認為 Pod 請求自動提供每容器保證 → 失敗原因： 預算可能是共享的 → 修正方法： 明確底線和隔離。
- 錯誤表現： 不記錄衝突容器值 → 失敗原因： Pod 優先順序會讓運維意外 → 修正方法： 文件化並測試生效資源。
- 錯誤表現： 只看 CPU 利用率 → 失敗原因： 記憶體壓力和 OOM 行為可能改變 → 修正方法： 聯合觀察 CPU、記憶體、QoS、驅逐和延遲。
- 錯誤表現： 只在一個控制平面元件啟用 → 失敗原因： 所有必要節點和元件都要支援 → 修正方法： 灰度前驗證叢集能力。
追問及應對
Pod 沒達到限制但代理仍然飢餓，怎麼辦？
視為爭用故障。增加代理底線、拆分工作負載或使用容器級隔離；總量餘量不保證延遲。
Pod 級請求如何影響 QoS？
兩層同時存在時 Pod 級值優先，並影響 Pod QoS 與 OOM 計算。遷移時重新計算類別並測試節點壓力。
Windows Pod 能使用 Pod 級資源嗎？
檢查對應版本限制。Kubernetes 1.35 文件不支援 Windows Pod 的 Pod 級資源，因此應繼續使用容器級策略。
什麼時候應該拆 Pod？
當容器需要獨立擴縮、失敗處理或 SLO 時拆分。只有在共享生命週期和突發預算有意且可觀測時才保留同一 Pod。