題幹與適用場景
一個批次 Job 需要日誌採集、代理或檔案同步 Sidecar。主容器完成後，Job 不應因為長時間運行的輔助容器而一直 Pending；Pod 終止時 Sidecar 還要盡量保留服務，收尾後再退出。請說明 Kubernetes Sidecar 的生命週期模型、資源共享和失敗處理。
這道題適合系統設計、平台工程和雲原生職位。重點是區分 Pod、Job、主容器和 Sidecar 的完成條件，以及設計可觀測、可重試的邊界。
面試官考察點
強回答會指出穩定版 Sidecar 可透過帶 restartPolicy: Always 的 init container 表達；它與主容器並發運行、共享網路和可選共享磁碟區；Job 在主容器完成後可結束；Pod 終止時 kubelet 延後停止 Sidecar，並按宣告順序的逆序關閉。回答還應涵蓋探針、資源配額、失敗重試、冪等和信號處理。
回答前需要釐清的問題
- Sidecar 提供日誌、代理、同步還是安全功能？它是否必須在主任務開始前就緒？
- 主容器成功、失敗、逾時和重試時，Sidecar 各自要保留哪些資料？
- 共享磁碟區的大小、寫入速率、權限和清理時機是什麼？
- Job 的完成條件是主容器退出、Sidecar 明確收尾，還是兩者都成功？
- 需要哪些指標、事件、日誌和 trace 來定位兩容器之間的故障？
30 秒回答框架
「我會把 Sidecar 建模為和主容器並發的支援服務，明確它的就緒、失敗和收尾契約。批次 Job 使用 Kubernetes 的 Sidecar 語義，讓主容器完成後 Job 可以結束，同時保留共享磁碟區和日誌收尾路徑。為兩類容器配置獨立探針、資源預算和可觀測性；處理逾時、重試、SIGTERM 和冪等清理，並用成功、失敗、Sidecar 崩潰和節點驅逐場景驗證。」
分步驟深入解答
第一步：定義容器角色和完成條件
主容器負責業務結果，Sidecar 只提供支援能力。Job 的成功判定應以主任務為核心，同時定義 Sidecar 在收尾窗口內必須完成的動作；不要把無限運行的輔助服務誤設為 Job 的唯一完成條件。
第二步：選擇 Sidecar 表達方式
Kubernetes 穩定版 Sidecar 可使用 init container 配置 restartPolicy: Always。它會在 Pod 啟動階段參與就緒，隨後和主容器並發運行，適合需要獨立生命週期的日誌或代理服務。
initContainers:
- name: log-shipper
image: example/log-shipper:1.0
restartPolicy: Always
volumeMounts:
- name: shared-data
mountPath: /var/app第三步：設計共享磁碟區和資源預算
Sidecar 與主容器可共享網路命名空間，並按需共享磁碟區。為寫入量、檔案輪替、權限、臨時空間和 CPU/記憶體設定上限，避免日誌突發擠壓主任務或讓節點驅逐順序失控。
第四步：建立探針和就緒契約
Sidecar 的 readiness 表示它能否提供服務，不等於主任務成功；liveness 失敗應有重啟策略和退避。主容器啟動前若必須等待 Sidecar，就要定義可觀測的就緒信號，避免透過固定 sleep 猜測啟動完成。
第五步：處理成功、失敗和重試
主容器成功後，Sidecar 應繼續讀取並發送剩餘日誌，隨後在明確的收尾信號或逾時後退出。主容器失敗時保留診斷資料；重試必須保證共享磁碟區、遠端發送和業務寫入冪等，避免重複計費或重複上傳。
第六步：設計終止順序和信號
Pod 終止時 kubelet 會等主應用容器停止，再終止 Sidecar，並按 Pod 規範中出現順序的逆序關閉 Sidecar。應用仍需正確處理 SIGTERM、有限的 termination grace period 和可能的 SIGKILL，不能假設總能優雅退出。
第七步：連接 Job、控制器和可觀測性
記錄主容器退出碼、Sidecar 收尾狀態、Job 條件、重試次數、共享磁碟區水位和日誌發送延遲。告警要區分主任務失敗、Sidecar 永不就緒、收尾逾時和節點驅逐，避免只看 Pod Ready 一個信號。
第八步：驗證故障矩陣
測試主容器快速成功、業務失敗、Sidecar 崩潰、日誌後端不可用、共享磁碟區寫滿、Job 逾時、節點驅逐和滾動升級。檢查 Job 是否按預期完成、資料是否可追溯、重試是否冪等、終止順序是否保留最後日誌。
設計取捨與邊界
Sidecar 適合與主任務強耦合、共享網路或檔案且需要獨立生命週期的支援能力。把所有基礎設施都塞進 Sidecar 會增加資源、升級和故障面；能由節點級 DaemonSet、託管日誌或獨立服務解決的能力，不必複製到每個 Pod。
Kubernetes 的收尾順序降低了日誌遺失風險，但不保證外部網路一定可用，也不替代應用層 flush、重試和資料一致性設計。Job 成功與 Sidecar 收尾應透過明確契約連接。
落地計畫與證據
先為一個日誌採集 Job 建立最小模型：主容器、Sidecar、共享磁碟區、探針、資源上限和收尾逾時。記錄完成條件與每種退出路徑，再逐步增加重試和告警。
把 Sidecar 版本、映像來源、磁碟區權限、探針、終止窗口、Job 條件和冪等規則寫入運行手冊。用真實日誌量和節點驅逐實驗驗證資源水位與最後一段日誌可追溯性。
常見誤區與追問
把普通 init container 當成並發 Sidecar
普通 init container 會在主容器啟動前結束，不能持續提供代理或日誌服務。需要並發運行時使用穩定的 Sidecar 語義。
讓 Job 等待永不退出的 Sidecar
Sidecar 應有收尾信號和逾時。Job 的成功條件以主任務為核心，並驗證控制器是否能在主容器完成後結束。
只給主容器設置資源限制
Sidecar 的 CPU、記憶體和臨時空間也會影響 Pod 調度與驅逐。為兩類容器分別設定請求、限制和監控。
只依賴 Pod Ready
Ready 不能說明業務成功或日誌已發送。組合 Job 條件、退出碼、收尾狀態、佇列水位和發送延遲。
最後一段日誌仍遺失怎麼辦？
檢查共享磁碟區 flush、發送重試、Sidecar 收尾信號、termination grace period 和後端可用性；重播同一故障矩陣，不要只延長 sleep。