科技 · 實用指南
容器以 137 結束或顯示「OOMKilled」？先證明 SIGKILL 邊界，再增加記憶體
137 表示程序收到 SIGKILL，卻沒有說明是誰發出的。先在同一事故時窗關聯執行環境、cgroup、節點與編排器證據，再調整限制。
容器結束碼是線索，不是根因。137 通常對應 SIGKILL，但程序無法回報發送者；只有綁定同一次容器嘗試與時窗的 OOMKilled 才是較強證據。
調整記憶體前建立含時間戳的證據帳本，比較執行環境終止紀錄、cgroup 計數器、節點核心證據與編排器事件。各層一致或矛盾被明確保留時才接受診斷。
1. 固定一次事故時窗
記錄正確的容器嘗試、節點、開始與結束時間、結束碼、訊號、執行環境原因及最後動作；重新啟動會覆蓋狀態。
統一時區並保留原始輸出，不要把目前計數器與舊核心訊息或另一副本混用。
2. 把 137 當作 SIGKILL 證據
列出可能發送者：核心 OOM、操作員或自動化、執行環境逾時、編排器寬限期升級或其他特權程序。
若顯示 OOMKilled，確認屬於同一次嘗試；若為 false 或缺失，只把 OOM 保留為假設。
3. 定位記憶體邊界
識別實際 cgroup 與限制，記錄 memory.max、用量與 memory.events，並比較葉節點及相關祖先的計數增量。
葉節點 oom_kill 增加支持該邊界內終止；節點 OOM 支持更廣邊界；沒有匹配增量就繼續驗證。
4. 關聯節點與編排器證據
讀取相同秒級時窗的節點日誌與事件，檢查記憶體壓力、驅逐、刪除、探針失敗、部署、排空或寬限期到期。
缺失證據要明確記為缺失；受限日誌和輪替事件降低信心，不能把假設變成事實。
5. 修復已證明的邊界
容器 OOM 要先測量工作集、配置尖峰與並行量；節點壓力、停止升級或外部終止則分別修復容量、關機處理或發送者。
受控重現後，以四層帳本無匹配 oom_kill、無節點 OOM、無未知升級且執行環境紀錄符合預期為驗收條件。
