對於剛接觸 Kubernetes (K8s) 運維的工程師來說，大家最擔心的通常不是如何部署應用，而是當叢集發生災難或需要遷移時，該如何把資料和設定完整地救回來。在 K8s 生態系中，Velero 是一個極其重要的工具，而最近 Broadcom 宣布將 Velero 捐贈給 CNCF (Cloud Native Computing Foundation，雲端原生計算基金會) 作為 Sandbox 專案，這在技術治理上是一個重要的轉折點。
為了讓大家理解這件事為什麼重要，我們需要先從 Velero 到底在做什麼開始講起。
什麼是 Velero 及其技術核心
在傳統的虛擬機時代，我們習慣用快照 (Snapshot) 來備份整個磁碟。但 K8s 是分散式的，僅靠底層儲存快照不足以還原整個服務。Velero 採取的是 K8s 原生 (Kubernetes-native) 的做法，它直接在 K8s API 層級運作。
它利用 CRD (Custom Resource Definitions，自定義資源定義) 來記錄叢集的狀態。簡單來說，Velero 會把你的 Namespace 定義、RBAC 權限設定、Persistent Volume Claims (PVC，持久化儲存卷請求) 等配置資訊，全部轉換成可攜式的 K8s 物件。
最關鍵的設計在於，Velero 將外部的物件儲存 (Object Storage，例如 AWS S3 或 Google Cloud Storage) 視為唯一事實來源 (Source of Truth)。這意味著你在 A 叢集做的備份，只要 B 叢集能讀取同一個儲存桶 (Bucket)，就能將服務還原到 B 叢集。這讓 Velero 不僅是備份工具，更是跨雲端遷移 (Migration) 的核心利器。
從 VMware 到 Broadcom 再到 CNCF 的治理變遷
Velero 最初由 Heptio 創立，後來被 VMware 收購，隨後 VMware 又被 Broadcom 收購。雖然 Velero 一直是開源的，但其治理權長期掌握在單一公司手中。
對企業級用戶來說，這會產生一個心理障礙：廠商鎖定 (Vendor Lock-in)。許多公司在選擇標準化工具時，會擔心如果該工具是由某個特定廠商主導，未來可能會被強行轉為收費，或者開發方向會過度傾向該廠商的產品線。
這次將 Velero 捐贈給 CNCF，其本質是將治理權從單一公司移交給中立的基金會。這解決了信任問題，讓那些之前因為不希望依賴 VMware/Broadcom 而猶豫的團隊，現在可以放心將 Velero 作為公司標準的備份方案。
對工程師而言，這意味著什麼
如果你是負責維運的工程師，你需要知道這次變更對你的實際影響：
首先，技術架構沒有改變。Velero 依賴的外部物件儲存、IAM 權限鏈以及目標叢集的運作邏輯完全一樣。你不需要修改任何設定檔或程式碼。
其次，開發方向將變得更開放。未來 Velero 的路線圖 (Roadmap) 將由 Broadcom、Red Hat、Microsoft 等多個維護者以及社群共同決定，而非由單一公司拍板。目前社群討論的方向包括：建立一個可管理多叢集的集中式控制平面、強化 CSI (Container Storage Interface) 資料管理規範以支援應用感知備份 (Application-aware backup)，以及導入 Sigstore 來對備份產出物進行數位簽章以確保安全性。
總結與實務建議
Velero 的 CNCF 化是一個正向信號，它將備份與災難恢復 (DR) 從廠商功能轉變為雲端原生的基礎設施標準。
對於 Junior 工程師的建議是：在設計 K8s 備份方案時，不要只關注如何儲存資料，更要關注如何儲存 K8s 的狀態配置。Velero 證明了透過 API 層級捕捉狀態並儲存在中立儲存空間，是目前最靈活且具備可移植性的做法。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。