題目與背景
你負責推理服務，需要把模型、詞表或規則包作為 OCI 映像中的唯讀檔案掛載到 Pod。請設計發布方案，要求支援摘要固定、分批上線、啟動失敗可診斷、快速回滾，並說明 Kubernetes image volume 的邊界。
面試官考察什麼
- 能否把「制品身分」「排程相容性」「發布控制」拆成獨立風險。
- 能否準確說明
reference、pullPolicy、Pod 啟動時解析和唯讀掛載行為。 - 能否設計准入、觀測、回滾和節點快取策略，而不是只給一段 YAML。
- 能否識別版本、執行時和註冊表權限是前置條件。
先問清楚的澄清問題
資產生命週期
模型或規則包由誰建置、簽署和保留？發布需要按摘要不可變，還是允許按標籤追蹤最新版本？單一資產大小、更新頻率和並發啟動量是多少？
叢集與執行時
叢集版本、節點作業系統、容器執行時和映像拉取憑證是否支援 image volume？升級期間是否允許混合節點版本？
安全與回滾
誰可以修改 Pod 的 reference？註冊表是否支援私有存取和稽核？回滾只回到上一摘要，還是要保留可重現的簽章、設定和相容性證明？
30 秒回答框架
我會先把資產建成帶簽章的 OCI 制品，並在發布清單中固定摘要；再用 image volume 以唯讀方式掛載，結合准入策略拒絕未批准的註冊表或摘要。發布控制器按相容節點分批建立 Pod，觀測拉取、掛載、應用自檢和請求指標，失敗時把工作負載清單回滾到上一摘要。最後清理不再引用的制品，但保留稽核記錄和可回放的發布中繼資料。
深入解答步驟
1. 固定制品身分
reference 可以指向 OCI 映像引用；生產發布應使用摘要而不是可變標籤。簽章、SBOM 和建置來源與摘要綁定，發布記錄保存摘要、建置流水線、相容性矩陣及責任人。摘要固定解決「同一標籤內容改變」的重現問題，但不取代漏洞掃描或簽章驗證。
2. 設計 Pod 掛載
以下卷在容器內以唯讀方式掛載：
volumes:
- name: model
image:
reference: registry.example.com/models/ranker@sha256:0123456789abcdef
pullPolicy: IfNotPresent
containers:
- name: api
image: registry.example.com/services/ranker-api@sha256:abcdef0123456789
volumeMounts:
- name: model
mountPath: /opt/model
readOnly: trueKubernetes 文件規定 image volume 在 kubelet 主機上提供 OCI 物件，卷內容唯讀；Always、Never 和 IfNotPresent 分別表達每次拉取、禁止拉取和本地缺失時拉取。生產通常選擇摘要加 IfNotPresent，同時由節點快取和准入規則控制供應鏈邊界。
3. 加入准入與權限驗證
准入策略檢查註冊表網域、摘要格式、簽章、漏洞門檻和資產與服務版本的匹配關係。服務帳號只授予讀取所需的註冊表權限；節點身分、映像拉取密鑰和稽核日誌分開管理。策略拒絕應在 Pod 建立階段給出可定位原因，避免等到業務容器啟動後才暴露。
4. 驗證節點與執行時相容性
image volume 需要節點、容器執行時和叢集版本共同支援。把能力作為節點標籤和排程約束，滾動升級時先在相容節點上做小批量驗證。不能把「控制面接受欄位」當成「所有節點都能掛載」；混合版本叢集要明確最小能力版本和降級策略。
5. 規劃上線與快取預熱
發布控制器先建立少量 canary，確認 Pod 已就緒、資產檔案存在、摘要驗證通過且業務自檢成功，再擴大 Deployment。拉取失敗會阻止容器啟動並遵循常規重試退避，因此應區分註冊表驗證、網路、節點磁碟和制品損壞。大規模發布前可在目標節點預熱，但預熱不能繞過准入和摘要驗證。
6. 觀測啟動狀態與業務結果
記錄工作負載、Pod、節點、資產摘要和發布批次的關聯。監控拉取延遲、啟動退避、掛載失敗、磁碟占用、應用自檢和請求錯誤率。Kubernetes 文件也說明 Pod 重建時會重新解析遠端內容，因此控制器應記錄每次新 Pod 實際使用的摘要，並把差異作為告警訊號。
7. 回滾與垃圾回收
回滾只切換到已批准的舊摘要和對應服務版本，保留上一版本的簽章、SBOM 與設定。回滾完成後驗證舊資產仍可從註冊表取得，不能依賴節點快取永久存在。垃圾回收按「無活動引用、超過保留期、稽核已歸檔」三項條件執行；正在回滾或調查的摘要要有保護標記。
高品質示例回答
我會把模型映像當作不可變發布物：建置階段產生 SBOM、簽章和摘要，發布單記錄摘要及服務相容矩陣。Pod 用 image volume 唯讀掛載，准入層限制註冊表並驗證簽章；控制器按節點能力和 canary 批次推進。Kubernetes 會在 Pod 啟動階段解析並準備 image volume，拉取失敗會阻塞啟動，所以我會分別觀測驗證、網路、磁碟和退避事件。每個新 Pod 都記錄實際摘要，業務自檢和請求指標同時通過才擴大批次。失敗時恢復上一摘要，待無引用且超過保留期後再清理舊制品。
常見錯誤
- 只寫映像標籤，不說明標籤可變和摘要固定。
- 把 image volume 當作可寫共享盤，忽略其唯讀約束。
- 忽略節點、執行時和叢集版本差異，直接假設所有 Pod 都能掛載。
- 只看 Deployment 可用副本，不看拉取退避、掛載失敗和資產自檢。
- 預熱快取時跳過簽章、准入或稽核。
- 回滾只改服務映像，卻沒有同步恢復相容的資產摘要。
追問與回答
為什麼不用 ConfigMap 或普通持久卷？
大型、版本化且需要 OCI 供應鏈能力的資產更適合 image volume；ConfigMap 適合小型設定，持久卷適合可寫或跨 Pod 持久資料。最終選擇仍取決於大小、更新方式、權限和恢復目標。
Always 是否更安全？
Always 每次啟動都拉取，能減少陳舊快取，但會增加啟動延遲、註冊表依賴和故障面。摘要固定、簽章准入和可觀測回滾通常比單獨改變拉取策略更關鍵。
Pod 重建會發生什麼？
Pod 重建會重新解析遠端引用並準備卷，因此應把引用摘要、實際解析結果和事件寫入發布稽核；不要假設舊節點快取會決定新 Pod 的內容。
何時使用 subPath？
需要把制品內某個目錄映射到指定路徑時可以使用 subPath；目前 Kubernetes 文件註明 image volume 的 subPath 與 subPathExpr 從 v1.33 起支援，仍需檢查目標叢集版本。
如何處理摘要狀態能力差異？
按目前 Kubernetes 文件，image volume 在 v1.36 文件中為穩定能力；ImageVolumeWithDigest 狀態欄位仍標為需要對應版本和 feature gate 的 alpha 能力。發布流程不能把該狀態欄位當成所有叢集都可用的唯一依據。