題幹與適用場景
一個 Job Pod 包含批次主容器、日誌轉送容器與設定同步容器。主容器完成後，日誌容器仍執行，Job 一直未完成；同步容器還必須先於主容器準備設定。請說明如何利用 Kubernetes 原生 Sidecar 語義解決啟動、退出與 Job 完成問題，同時避免日誌遺失與舊版本叢集的行為差異。
題設元件與時序是面試場景，不代表所有叢集預設設定。題目適合後端平台、雲原生執行時與 SRE 職位。核心能力是 Pod 生命週期與工作負載可靠性，因此歸為 backend。
面試官考察點
第一，能否區分普通 containers、initContainers 與原生 Sidecar。原生 Sidecar 使用 init container 位置並設定重啟策略，使其可在初始化階段啟動後持續執行。
第二，能否正確描述 Job 完成語義。原生 Sidecar 會在一般容器完成後終止，且不會阻止 Job 判定完成；普通 Sidecar 需要額外退出協調。
第三，能否處理依賴與訊號。同步 Sidecar 必須報告 ready，主容器才開始；終止時 Sidecar 應在主容器之後收到終止訊號，並有逾時與強制終止路徑。
第四，能否面對失敗。Sidecar 啟動失敗、持續重啟、日誌後端不可用或主容器提前失敗，都應有明確重試、降級與可觀測性。
第五，能否規劃相容升級。舊叢集不識別原生語義時，清單可能被拒絕或按舊方式執行；必須用能力探測、版本門檻與回退清單控制風險。
回答前需要釐清的問題
- 叢集 Kubernetes 版本與准入策略是否支援 native sidecar？
- 同步容器是一次性初始化，還是主任務期間要持續更新？
- 日誌必須傳送到哪個邊界，允許遺失多少尾部日誌？
- 主容器退出碼、Sidecar 退出碼與 Job 重試策略如何定義？
- Pod 使用
restartPolicy: Never還是OnFailure？ - 是否有多個 Sidecar 之間的順序依賴與共享卷競爭？
30 秒回答框架
「我會把需要先啟動且要持續執行的容器放入 initContainers，設定 Sidecar 所需的重啟策略，讓同步容器以就緒訊號表示設定可用。主容器完成後，控制器按原生 Sidecar 語義終止 Sidecar，Job 可以結束；日誌 Sidecar 收到終止訊號後先清空緩衝，再於逾時後強制終止。舊叢集用版本探測與普通容器回退清單，驗證啟動順序、退出碼、尾部日誌、重試次數與 Job 完成延遲。」
分步驟深入解答
第一步：確認原生 Sidecar 能力
Kubernetes 原生 Sidecar 以 initContainers 表達，並透過容器級 restartPolicy: Always 表示它在初始化後持續執行。先檢查 API server 版本、feature gate、准入控制器與部署工具是否保留欄位；不能只看客戶端 kubectl 版本。
第二步：表達啟動順序
init container 按順序啟動並完成；原生 Sidecar 可以啟動後保持執行，後續初始化或主容器才繼續。同步 Sidecar 應以檔案已寫入、權限正確、版本校驗通過作為就緒條件，主容器讀取共享卷前必須檢查。
initContainers:
- name: config-sync
image: example/config-sync:v2
restartPolicy: Always
readinessProbe:
exec:
command: ["/bin/sh", "-c", "test -f /work/config.ready"]
- name: migrate
image: example/migrate:v4
command: ["/bin/sh", "-c", "./migrate && touch /work/migrate.done"]
containers:
- name: batch
image: example/batch:v7第三步：設計退出與日誌清空
主容器完成後，日誌 Sidecar 要收到終止訊號並在有限視窗內傳送緩衝日誌。它應處理 SIGTERM、停止接收新輸入、清空並確認傳送，再退出。terminationGracePeriodSeconds 要覆蓋最長清空時間；超時後的 SIGKILL 可能遺失尾部日誌，必須記錄與告警。
第四步：定義失敗與重試
同步 Sidecar 持續重啟時，主容器不應讀取半成品設定。readiness、探針失敗與共享卷原子替換要配合使用。主容器失敗時，Job 控制器按 backoffLimit 決定重試；Sidecar 重啟不應被誤判為新的業務嘗試。把主任務退出碼、Pod phase 與 Sidecar 狀態分開記錄。
第五步：處理 Job 完成語義
原生 Sidecar 在所有一般容器完成後會被終止，Job 不會像普通常駐 Sidecar 那樣因它一直執行而懸掛。若 Sidecar 提前失敗，需確認叢集版本對 Pod readiness、重啟與 Job 條件的實際行為，並用整合測試驗證。
第六步：相容舊叢集
部署前做版本門檻：不支援原生 Sidecar 的叢集使用普通 containers 清單，並由 wrapper 在主容器結束時通知 Sidecar 退出。兩套清單必須互斥，避免同一 Pod 同時出現兩種語義。升級期間觀測 Job 完成時間、失敗原因與尾部日誌完整率。
第七步：驗證資源與安全邊界
Sidecar 與主容器共享 Pod 的網路、卷與資源配額。為同步與日誌設定獨立 requests/limits，避免挤壓批次；只授予讀取設定或寫入日誌所需的 ServiceAccount 權限。探針不應洩露憑據，暫存設定檔要有正確權限。
高品質示範回答
「我先確認 API server 與准入鏈支援原生 Sidecar。設定同步容器放入 initContainers 並設定 restartPolicy: Always，完成版本校驗、原子寫入後才讓主容器繼續；一次性遷移仍是普通 init container。日誌 Sidecar 在主容器完成後接收終止訊號，停止接收、清空並確認傳送，優雅終止時間覆蓋最長清空時間，逾時則告警。
我會分別記錄主容器退出碼、Sidecar 重啟、Pod 條件、Job backoff 與尾部日誌遺失。舊叢集透過版本門檻選擇普通容器回退清單，並由 wrapper 通知日誌程序退出。灰度驗證啟動順序、Job 完成延遲、失敗重試、設定原子性、資源上限與日誌完整率。」
常見錯誤
- 把普通 Sidecar 放進 containers → Job 可能永遠等待 → 使用原生語義或顯式退出協調。
- 把持續同步容器寫成一次性 init → 主任務期間不會更新設定 → 先明確生命週期需求。
- 只設定 readiness 不做原子寫入 → 主容器可能讀到半成品 → 暫存檔校驗後 rename。
- 忽略日誌清空視窗 → SIGKILL 造成尾部遺失 → 按最長傳送時間設定優雅終止。
- 把 Sidecar 失敗當業務失敗 → backoff 統計失真 → 分開記錄容器與 Job 狀態。
- 假設所有叢集都支援 → 舊版本拒絕欄位或改變語義 → 版本門檻與回退清單。
- 未限制 Sidecar 資源 → 日誌高峰擠壓主任務 → 獨立 requests/limits 與告警。
- 共享卷權限過寬 → 設定或日誌被越權修改 → 最小 ServiceAccount 與檔案權限。
追問及應對
追問一：為什麼原生 Sidecar 放在 initContainers？
這樣保留初始化順序語義，同時透過容器級重啟策略讓它在初始化後持續執行。後續容器等待必要條件，Job 結束時控制器再處理 Sidecar 生命週期。
追問二：Sidecar 是否一定能把日誌發完？
不能保證。網路故障、優雅終止視窗或後端限流都可能造成遺失。應設定有限清空時間、持久化緩衝或重試策略，並以尾部完整率與遺失告警驗收。
追問三：主容器失敗時要不要繼續同步設定？
取決於重試語義。若設定版本固定，同步容器應停止新寫入並保留可診斷狀態；若每次重試要重新拉取，應讓新 Pod 或明確版本策略負責，避免同一次嘗試被隱式改變。
追問四：如何測試啟動順序？
讓同步容器延遲、寫入半成品並故意校驗失敗，確認主容器不會開始；再寫入完成標記並觀察主容器讀到完整版本。測試重啟、共享卷與 probe 競態。
追問五：舊叢集的回退如何避免分叉？
把版本判斷放在發布流水線，生成互斥清單並對兩種清單執行同一 Job 契約測試。不要讓應用在執行時猜測 Kubernetes 版本。
追問六：如何判斷 Job 真正完成？
同時檢查 Job 條件、主容器退出碼、Pod phase、Sidecar 終止原因與日誌確認標記。只看 Pod 變成 Succeeded 可能漏掉尾部日誌或同步失敗。