題干與適用場景
Kubernetes v1.36 將 VolumeGroupSnapshot、VolumeGroupSnapshotContent 與 VolumeGroupSnapshotClass 提升為 groupsnapshot.storage.k8s.io/v1。面試官希望你說明：多個 PersistentVolumeClaim 如何形成同一復原點、CSI 驅動負責什麼，以及快照不等於應用一致性時如何補足方案。
面試官考察點
- 能否區分當機一致性、應用一致性與最終一致性。
- 能否解釋 Kubernetes 控制器、外部快照控制器與 CSI 驅動的邊界。
- 能否辨識只支援 CSI 驅動、容量與區域限制、快照生命週期等前置條件。
- 能否把復原目標、演練指標與失敗回滾寫成可執行流程。
回答前需要釐清的問題
先確認資料庫是否支援線上備份、磁碟區是否都由同一個 CSI 驅動管理，以及業務的 RPO、RTO 與跨可用區需求。還要確認快照由儲存系統保證寫入順序，或需要應用程式先 flush、凍結或暫停寫入。
30 秒回答框架
我會把方案分成四層：應用層先建立一致性點；Kubernetes 層用 VolumeGroupSnapshot 記錄一組 PVC；CSI 驅動在儲存側建立群組快照；復原層把快照還原成新磁碟區並做校驗。該 API 在 v1.36 GA，但只解決磁碟區群組的當機一致性編排，不能取代資料庫日誌、金鑰管理與定期復原演練。
分步驟深入解答
1. 建立一致性點
資料庫先執行可證明的備份動作，例如短暫凍結寫入、flush WAL 或產生檢查點。記錄交易位點、快照時間與應用程式版本，接著建立磁碟區群組快照。若只呼叫儲存快照而沒有應用程式協作，復原結果可能是磁碟層一致、業務層不一致。
2. 建立並觀測群組快照
為同一資料庫實例的 PVC 建立 VolumeGroupSnapshot，並等待狀態中的 ready 訊號。控制器負責物件生命週期，CSI 驅動負責具體儲存操作；驅動必須支援磁碟區群組快照擴充 API。對每個成員記錄快照句柄、容量、區域與錯誤原因，避免把部分成功誤判為可復原。
3. 復原與校驗
復原時為每個成員建立新 PVC，保持檔案系統與資料庫磁碟區的對應關係。先在隔離環境啟動資料庫，校驗 WAL 位點、資料表數量、校驗和與關鍵業務查詢，再切換流量。跨區域復原要驗證快照副本是否可讀，以及 CSI 驅動對目標拓撲的限制。
4. 維運邊界
設定保留策略、加密與存取控制，監控快照建立耗時與失敗率。把快照視為復原材料而非永久封存：定期匯出到獨立媒介，並透過演練量測實際 RPO、RTO。刪除 PVC、快照物件或儲存後端物件前，要確認回收策略不會誤刪仍在使用的復原點。
高品質示範回答
我會先定義復原目標，再選擇由同一 CSI 驅動管理的 PVC 集合。應用程式產生檢查點並記錄 WAL 位點，必要時短暫停止寫入；接著建立 groupsnapshot.storage.k8s.io/v1 的 VolumeGroupSnapshot。控制器只負責 Kubernetes 物件協調，真正的群組快照語意由 CSI 驅動與儲存系統提供，所以我會檢查驅動版本、區域、容量與快照配額，並把每個成員的 ready 狀態納入告警。
復原流程不會直接覆蓋正式磁碟區，而是從群組快照建立新 PVC，在隔離命名空間啟動資料庫，驗證 WAL、校驗和與業務查詢，再執行切換。若某個成員失敗，整組標記為不可用並回滾，不把部分快照宣稱為完整備份。最後用定期演練證明 RPO、RTO，配合獨立封存、加密與最小權限，避免快照成為單點或洩露來源。
常見錯誤
- 把 GA 誤解為所有儲存驅動都自動支援；該能力依賴 CSI 驅動與儲存實作。
- 只描述建立快照，不說明群組內成員的部分失敗、拓撲與生命週期。
- 把當機一致性當成應用一致性，遺漏 flush、WAL 或檢查點。
- 只保存快照中繼資料，從未在隔離環境啟動並驗證復原結果。
追問及應對
如果一個成員磁碟區建立失敗怎麼辦？
將群組快照標記為不可用，保留錯誤事件與已建立句柄，清理孤兒資源後重試。復原流程只接受完整成員集合，並把部分成功計入告警與容量稽核。
為什麼不用每個 PVC 個別建立快照？
單卷快照缺少共同復原點，跨卷寫入順序可能不一致。群組快照把成員集合與群組級操作交給儲存系統，仍需應用層檢查點來取得業務一致性。
如何證明方案真的符合 RPO 與 RTO？
按固定週期在隔離叢集復原，記錄從檢查點到可查詢服務的時間、資料位點差異與失敗率。演練結果納入發布門禁；未達到閾值就調整快照頻率、封存路徑或切換流程。