Velero 跨集群迁移实战基于 Backup 与 Restore 的 Kubernetes 应用搬迁指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero 提供了一套简洁而强大的跨集群迁移方案只要源、目标两个集群的 Velero 实例指向同一个云对象存储位置就可以通过源集群备份、目标集群恢复的方式将 Kubernetes 应用及其数据完整地搬迁到另一个集群。本指南以site/content/docs/v1.1.0/migration-case.md的迁移步骤为主线结合当前仓库中的 CLI 源码与控制器实现带你从原理到实操完整掌握集群迁移流程并理解 TTL、只读存储位置、备份同步周期等关键机制背后的实现细节。适用范围说明本文描述的操作适用于将应用从集群 A 迁移到集群 B且两个集群由同一云厂商托管、共用同一个对象存储桶的场景。Velero 不支持跨云厂商的持久化卷PV迁移。迁移原理同一个对象存储两个集群的交接棒Velero 的跨集群迁移不依赖集群之间的任何直接网络连接。其核心思路是源集群Cluster 1将集群状态与持久卷数据备份到云对象存储如 AWS S3、Azure Blob、GCP GCS中的某个 bucket。目标集群Cluster 2配置指向同一个 bucket的BackupStorageLocation备份存储位置与VolumeSnapshotLocation卷快照位置。目标集群的 Velero 服务器周期性从对象存储同步备份元数据将远端备份文件物化为集群内的 Backup 对象。用户基于该 Backup 对象执行恢复应用即在目标集群中重建。由于备份数据与快照数据都保存在共享的对象存储中两个集群的 Velero 只需在存储层交接即可完成整个迁移流程。这也是为什么文档中明确要求每个 Velero 实例指向相同的云对象存储位置。前提条件与关键限制在动手之前请确认以下前提同一云厂商两个集群必须由同一云厂商托管例如同为 AWS EKS、同为 Azure AKS因为VolumeSnapshotLocation的快照是云厂商绑定的资源。共享对象存储两个集群的BackupStorageLocation必须指向相同的 bucket 与 prefix。持久化卷不可跨云迁移Velero 不支持把 PV 从一家云厂商迁移到另一家云厂商。若你的目标确实需要跨云搬迁持久化数据需要配合其他数据迁移手段本文不展开。Velero 部署在相同命名空间如果恢复过程遇到异常优先检查两个集群中 Velero 是否都运行在同一个命名空间下默认velero。第一步Cluster 1备份整个源集群如果你此前没有通过 Velero 的schedule定时备份对集群做持续检查点checkpoint保护那么迁移的第一步就是在源集群上创建一个覆盖全集群的备份velero backup create BACKUP-NAME其中BACKUP-NAME替换为你期望的备份名称例如migration-backup-20260916。TTL 与备份生命周期默认情况下该备份的 TTL生存时间为30 天720 小时到期后备份会被垃圾回收机制清理无法再用于恢复。如果你需要更长的保留期可使用--ttl标志覆盖velero backup create BACKUP-NAME --ttl 2160h0m0s上述命令将 TTL 延长到 90 天。从源码结构看默认 TTL 定义在 pkg/cmd/server/config/config.go 中defaultBackupTTL 30 * 24 * time.Hour该值通过服务器参数--default-backup-ttl暴露最终由 backup_controller.go 在请求未显式指定 TTL 时填充到 Backup 对象的Spec.TTL。对应的单元测试TestDefaultBackupTTL见 backup_controller_test.go验证了默认 TTL 为24 * 30 * time.Hour且 Expiration 时间正确。此外--ttl参数的解析入口位于 pkg/cmd/cli/backup/create.go其帮助文本为 How long before the backup can be garbage collected.说明 TTL 直接决定了备份何时可被垃圾回收——迁移前请务必评估备份保留期是否覆盖完整的迁移窗口。迁移窗口提示备份完成后到恢复执行期间备份文件必须保持在 TTL 之内否则对象存储中的备份可能已被清理目标集群将无法同步到该备份。第二步Cluster 2配置指向源存储的备份位置在目标集群中需要配置两类存储位置让 Velero 知道去哪里读取源集群的备份数据velero backup-location create BSL-NAME \ --provider PROVIDER \ --bucket BUCKET-NAME \ --prefix PREFIX \ --access-modeReadOnly velero snapshot-location create VSL-NAME \ --provider PROVIDER \ ...参数说明以当前仓库 CLI 实现为准--provider对象存储厂商标识例如aws、azure、gcp来源pkg/cmd/cli/backuplocation/create.go。--bucket对象存储桶名称必须与 Cluster 1 使用的 bucket 一致同上L93。--prefix桶内 Velero 数据的存储前缀必须与 Cluster 1 的 prefix 一致同上L96。--access-modeReadOnly将BackupStorageLocation配置为只读模式防止目标集群误写入或覆盖源集群的备份数据。这是迁移场景中的关键安全措施。可选--backup-sync-period覆盖该位置的备份同步周期--validation-frequency覆盖存储位置有效性校验频率--cacert指定验证对象存储 TLS 连接用的 CA 证书包同上L97-L101。只读模式的实现--access-mode在 create.go 中被实现为一个枚举标志flag.Enum允许值仅为ReadWrite默认与ReadOnly其取值最终写入BackupStorageLocation.Spec.AccessMode见BuildBackupStorageLocationL168。只读位置不会参与备份写入从而保证迁移过程中源数据不被目标集群污染。关于 VolumeSnapshotLocationVolumeSnapshotLocation用于告诉 Velero 在哪个云区域、以何种方式创建/读取卷快照。迁移时它必须指向源集群快照所在的区域与配置否则恢复阶段无法找到对应的云快照。由于快照是云厂商级资源这也是文档强调集群需由同一云厂商托管的根本原因。第三步Cluster 2等待并确认备份同步配置好存储位置后目标集群的 Velero 会周期性地从对象存储同步备份文件将远端的备份物化为本地的 Backup API 对象。在 Cluster 2 上检查备份是否已经同步velero backup describe BACKUP-NAME同步间隔与默认值默认情况下备份同步间隔为1 分钟——刚配置完存储位置后立即执行命令可能还看不到该备份需要稍作等待。你可以通过 Velero 服务器的--backup-sync-period标志调整这个间隔默认值同样为 1 分钟定义于 pkg/cmd/server/config/config.go。从源码实现看备份同步由 backup_sync_controller.go 中的backupSyncReconciler驱动同步周期优先取每个BackupStorageLocation的Spec.BackupSyncPeriod未显式设置时回退到服务器默认值L406-L408。若该位置显式设置为0s则该位置的备份同步被禁用L409-L411。若周期为负值则回退到默认周期L414-L417。实际同步时机会根据Status.LastSyncedTime判断lastSync syncPeriod之前不会重复同步L420-L427。因此如果你想加速迁移验证可以临时将--backup-sync-period调小或在确认同步完成后恢复默认值。提示velero backup describe BACKUP-NAME也能用于确认备份内容包含的命名空间、资源、卷等与源集群预期一致相当于迁移前的数据清单核验。第四步Cluster 2从备份恢复确认 Cluster 2 上已经存在正确的 Backup 对象后执行恢复velero restore create --from-backup BACKUP-NAME该命令的入口定义在 pkg/cmd/cli/restore/create.go使用形式为velero restore create [RESTORE_NAME] [--from-backup BACKUP_NAME | --from-schedule SCHEDULE_NAME]。--from-backup标志L138指定恢复来源的备份名并且 CLI 提供了--from-backup的自动补全L85。恢复是可选的细粒度控制的——例如只恢复 PVC 与 PVvelero restore create --from-backup BACKUP-NAME --include-resources persistentvolumeclaims,persistentvolumes恢复默认会还原备份中的全部资源。如需限定范围可使用--include-namespaces、--exclude-namespaces、--include-resources、--exclude-resources等过滤器与备份创建命令同源见 pkg/cmd/cli/backup/create.go 的对应标志。验证两个集群的迁移结果恢复发起后在 Cluster 2 上确认恢复是否成功velero restore get该命令会列出集群中所有恢复及其状态InProgress、Completed、Failed等。找到本次恢复的名称后查看详细情况velero restore describe RESTORE-NAME-FROM-GET-COMMANDdescribe输出中包含恢复的总体状态、处理的资源项数、错误与警告统计等信息。如果恢复包含卷数据还可以进一步通过velero backup describe或云厂商快照控制台核验持久化数据是否完整。从源码结构看恢复执行路径由 pkg/controller/restore_controller.go 负责驱动它读取 Backup 中的资源清单逐一重建 Kubernetes 对象并触发卷数据恢复最终更新 Restore 对象状态。restore get/describe展示的正是该控制器写入的状态字段。常见问题与排查backup describe找不到备份大概率是同步尚未完成。默认同步间隔 1 分钟请等待后重试也可以调小--backup-sync-period加速。恢复报错找不到卷快照检查VolumeSnapshotLocation是否指向源集群快照所在区域与配置确认两个集群由同一云厂商托管。备份被清理确认备份仍在 TTL 内迁移窗口较长的场景建议在创建备份时显式设置足够大的--ttl。Velero 命名空间不一致文档特别强调遇到问题时务必确认 Velero 在两个集群中运行于同一个命名空间否则存储位置、备份等对象无法正确对齐。结语通过共享对象存储 只读备份位置 备份同步 恢复四个步骤Velero 让跨集群迁移变得清晰可控。理解 TTL、同步周期、AccessMode 这些参数背后的源码实现能帮助你在真实迁移场景中做出更稳妥的配置决策。如果想深入探索备份同步控制器、恢复控制器的完整实现可以直接阅读本仓库的 pkg/controller/backup_sync_controller.go、pkg/controller/restore_controller.go以及 CLI 层的 pkg/cmd/cli/backuplocation/create.go 与 pkg/cmd/cli/restore/create.go。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考