使用 Velero 实现跨集群迁移基于对象存储同步的迁移原理与完整实操【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Velero 官方的集群迁移Cluster Migration文档为核心系统讲解如何利用 Velero 的备份/恢复能力把整个集群的工作负载与数据从一个集群迁移到另一个集群。读完本篇你将掌握迁移前的兼容性判断要点、两个集群的完整安装与存储位置配置命令、备份/恢复操作流程并能从源码层面理解支撑迁移的关键机制——对象存储同步Object Storage Sync是如何把备份元数据从源集群搬运到目标集群的。一、核心原理集群迁移建立在对象存储同步之上Velero 的备份与恢复能力天然适合做集群迁移而迁移的底层机制正是 Velero 的对象存储同步功能。该机制负责把指定对象存储中的 Velero 资源与集群内的 Backup 自定义资源保持双向一致对象存储是事实来源source of truth如果存储桶中存在格式正确的备份文件但集群里没有对应的 Backup 资源Velero 会把对象存储中的备份信息同步进 Kubernetes反向清理如果集群里存在Completed的 Backup 对象而对象存储中对应备份 tar 包已不存在该 Backup 对象会被同步删除Failed或PartiallyFailed的备份则不会被同步流程清除。正是这一点让集群迁移场景成立新集群中原本不存在任何 Backup 对象但只要目标集群的 Velero 与源集群指向同一个云对象存储位置目标集群就会自动看到源集群写入的备份从而可以直接发起恢复。因此迁移的第一前提非常明确参与迁移的每个集群上的 Velero 实例必须配置指向同一个云对象存储位置相同的 bucket 与 region 等参数。对应的实现位于备份同步控制器 backup_sync_controller.go下文第四节会详细拆解。二、迁移前必须考虑的四个限制在开始迁移之前官方文档列出了四个必须评估的兼容性问题这些限制直接决定迁移方案是否可行跨云厂商的持久卷快照迁移不受原生支持。Velero 无法原生迁移持久卷PV快照数据到不同的云厂商。如果需要在云平台之间迁移卷数据必须启用文件级备份File System Backup以文件系统级别备份卷内容。不支持恢复到更低版本 Kubernetes 的集群。目标集群的 Kubernetes 版本不能低于备份创建时的版本。跨 Kubernetes 版本迁移需要评估 API 兼容性。在不一致版本的集群之间迁移工作负载可能可行但迁移前必须考虑各集群间 API 分组的兼容性尤其是每个自定义资源CR的情况。如果 Kubernetes 版本升级破坏了 core/native API 分组的兼容性在不先更新受影响的自定义资源的前提下将无法用 Velero 完成迁移。关于 API 分组版本可参见 EnableAPIGroupVersions 特性。AWS 与 Azure 插件不支持跨 Region 迁移数据。如果确实需要跨 Region 迁移数据只能走文件级备份的路径。三、迁移场景实操从 Cluster 1 迁移到 Cluster 2下面的场景演示把资源从 Cluster 1 迁移到 Cluster 2。两个集群使用相同的云厂商AWS并都安装 Velero 的 AWS 插件velero/velero-plugin-for-aws。3.1 步骤 1在 Cluster 1 安装 Velero 并指向对象存储在 Cluster 1 上确认 Velero 已安装并通过--bucket标志指向对象存储位置velero install --provider aws --image velero/velero:v1.8.0 --plugins velero/velero-plugin-for-aws:v1.4.0 --bucket velero-migration-demo --secret-file xxxx/aws-credentials-cluster1 --backup-location-config regionus-east-2 --snapshot-location-config regionus-east-2参数要点--provider aws指定云厂商为 AWS--bucket velero-migration-demo备份存储桶。安装时 Velero 会在其中创建一个名为default的 Backup Storage LocationBSL这就是 Velero 存放备份的位置--secret-file xxxx/aws-credentials-cluster1源集群的 AWS 凭证文件--backup-location-config regionus-east-2与--snapshot-location-config regionus-east-2备份位置与卷快照位置的 Region 配置。注意这两个参数与目标集群必须一致AWS 插件不支持跨 Region 迁移数据。执行velero backup-location get可以查看 Cluster 1 的备份存储位置velero backup-location get NAME PROVIDER BUCKET/PREFIX PHASE LAST VALIDATED ACCESS MODE DEFAULT default aws velero-migration-demo Available 2022-05-13 13:41:30 0800 CST ReadWrite true3.2 步骤 2在 Cluster 1 上创建备份将BACKUP-NAME替换为你要使用的备份名velero backup create BACKUP-NAME也可以创建定时备份Scheduled Backup用 Velero 的schedule操作按既定周期自动备份数据这是确保数据按你定义的调度自动备份的推荐方式。关于备份保留期默认备份保留期以 TTLtime to live表示为30 天720 小时可用--ttl DURATION标志修改。这一点在源码中得到印证Velero 服务器端配置的默认值定义于 config.go 的defaultBackupTTL 30 * 24 * time.Hour--ttl标志的解析逻辑位于 CLI 侧的 backup/create.goHow long before the backup can be garbage collected。备份过期机制的更多说明见 how velero works 中的 Set a backup to expire 章节。3.3 步骤 3在 Cluster 2 安装 Velero 并指向同一存储位置在 Cluster 2 上安装 Velero。注意下方安装命令与 Cluster 1 使用了相同的region和--bucket——这是迁移能成立的硬性条件velero install --provider aws --image velero/velero:v1.8.0 --plugins velero/velero-plugin-for-aws:v1.4.0 --bucket velero-migration-demo --secret-file xxxx/aws-credentials-cluster2 --backup-location-config regionus-east-2 --snapshot-location-config regionus-east-2与 Cluster 1 的唯一差别是凭证文件换成了目标集群的aws-credentials-cluster2。替代方案先安装、后配置存储位置。你也可以先在 Cluster 2 上安装 Velero再手动创建指向 Cluster 1 所用--bucket和region的BackupStorageLocations与VolumeSnapshotLocationsvelero backup-location create bsl --provider aws --bucket velero-migration-demo --config regionus-east-2 --access-modeReadOnlyvelero snapshot-location create vsl --provider aws --config regionus-east-2两个值得注意的要点强烈建议目标集群的 BSL 配置为只读。通过velero backup-location create的--access-modeReadOnly标志把 Backup Storage Location 设为只读可以避免恢复过程中备份被误从对象存储中删除。该标志的可选值ReadWrite/ReadOnly与 BSL 类型定义在 backuplocation/create.go。更多可用标志可参考velero backup-location --help快照位置命令同理可参考velero snapshot-location --help。--config regionus-east-2中的 region 必须与源集群备份时使用的 region 一致。3.4 步骤 4确认 Cluster 1 的备份对象已在 Cluster 2 上可用继续在 Cluster 2 上操作确认 Cluster 1 创建的 Velero Backup 对象已经可见BACKUP-NAME与在 Cluster 1 上创建备份时使用的名字相同velero backup describe BACKUP-NAME背后的机制是Velero 资源与对象存储中的备份文件是同步关系。Cluster 1 的备份所产生的 Velero 资源会通过共享的 Backup Storage Location 同步到 Cluster 2。同步完成后你就可以在 Cluster 2 上用 Velero 命令访问来自 Cluster 1 的备份了。默认同步间隔为 1 分钟因此在 Cluster 2 上检查备份可用性之前可能需要稍等。这个间隔可以通过 Cluster 2 上 Velero 服务器进程的--backup-sync-period标志配置——该标志定义在 pkg/cmd/server/config/config.go含义为多久确保对象存储中的所有 Velero 备份在集群中都存在对应的 Backup API 对象它是 BSL 未显式指定backupSyncPeriod时的默认值。3.5 步骤 5在 Cluster 2 上执行恢复确认正确的备份可用之后即可把全部内容恢复到 Cluster 2velero restore create --from-backup BACKUP-NAME务必确保BACKUP-NAME与 Cluster 1 上的备份名一致。四、源码级解析备份同步控制器如何让迁移成立上面 3.4 步中Cluster 1 的备份对象会自动出现在 Cluster 2的行为由 pkg/controller/backup_sync_controller.go 中的backupSyncReconciler实现。从源码可以看到其关键逻辑周期性触发SetupWithManager中使用kube.NewPeriodicalEnqueueSource以backupSyncReconcilePeriod1 分钟定义于 backup_sync_controller.go#L48-L50为节拍轮询所有 BSL而不是依赖事件驱动locationFilterFunc会检查该 BSL 的spec.backupSyncPeriod若设为0则跳过同步负数则回退默认值与status.lastSyncedTime未到同步时间的位置会被过滤掉。只同步已完成的备份Reconcile中先调用backupStore.ListBackups()列出对象存储里的备份再与集群内已有的 Backup 对象做差集backupsToSync : backupStoreBackups.Difference(clusterBackupsSet)。随后仅同步状态阶段为Completed、PartiallyFailed或Failed的备份元数据未完成如仍在 Finalizing且未过期的备份会被跳过防止新集群把别处正在执行的备份误当作新请求去执行——这正是从源码结构看迁移场景安全性的关键保护。适配目标集群的上下文同步时在 backup_sync_controller.go#L196-L214 处会清空Spec.Hooks同步来的备份只是执行记录不应在新集群上执行钩子、清空ResourceVersion、改写Spec.StorageLocation与对应标签以匹配目标集群的 BSL 名称并通过filterBackupOwnerReferences校验/清理指向已不存在 Schedule 的 OwnerReference最后创建 Backup CR。文件系统备份产生的 PodVolumeBackup 资源也会一并同步并修正其 OwnerReference UID 指向新创建的 Backup。清理孤儿备份deleteOrphanedBackups会删除对象存储中已不存在、但集群里仍是Completed/PartiallyFailed的备份对象与文档描述的对象存储是事实来源的行为一一对应。五、验证两个集群迁移操作完成后确认 Cluster 2 的行为符合预期在 Cluster 2 上运行velero restore get再运行用restore get输出中的恢复名替换占位符velero restore describe RESTORE-NAME-FROM-GET-COMMAND至此从 Cluster 1 备份的数据应当在 Cluster 2 上可用。排障提示如果迁移过程中遇到问题请先确认 Velero 在两个集群中运行于相同的命名空间namespace——备份同步控制器按命名空间列举 Backup 对象命名空间不一致会导致备份无法正确同步。六、要点回顾环节关键命令/配置注意事项源集群安装velero install --provider aws --bucket bucket --backup-location-config regionregion ...生成名为default的 BSL创建备份velero backup create BACKUP-NAME默认 TTL 30 天720 小时可用--ttl修改目标集群存储配置velero backup-location create ... --access-modeReadOnly两个集群必须同 bucket、同 region建议只读等待备份可见velero backup describe BACKUP-NAME默认同步间隔 1 分钟可用服务器端--backup-sync-period调整恢复velero restore create --from-backup BACKUP-NAME备份名须与源集群一致验证velero restore get/velero restore describe name排查时确认两集群 Velero 命名空间一致再次强调迁移的硬边界跨云厂商迁移卷数据需启用 File System Backup不支持恢复到更低 Kubernetes 版本的集群跨 K8s 版本迁移需先确认 API 分组兼容性AWS/Azure 插件不支持跨 Region 迁移数据。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考