Velero 跨集群迁移实战基于对象存储同步的 Kubernetes 数据迁移指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本篇文章以 Velero 官方迁移场景文档migration-case.md为核心系统讲解如何利用 Velero 的**对象存储同步Object Storage Sync**机制将 Kubernetes 应用及其持久化卷数据从源集群平滑迁移到目标集群。读完本文你将掌握跨集群迁移的完整操作流程、迁移前的关键注意事项、Backup Storage Location / Volume Snapshot Location 的配置要点以及不同云环境下的迁移方案选择并理解其背后的底层实现原理。迁移原理为什么共享对象存储就能迁移集群Velero 之所以能实现跨集群迁移核心依赖的是它的对象存储同步能力。Velero 将对象存储视为数据真相的来源source of truth它会持续检查对象存储中的备份文件与集群内 Backup 自定义资源CRD 对象是否一致。如果存储桶中存在格式正确的备份文件但 Kubernetes API 中还没有对应的 Backup 资源Velero 会自动将对象存储中的信息同步到 Kubernetes详见 how-velero-works.md。这意味着只要参与迁移的每个集群上运行的 Velero 实例指向同一个云对象存储位置相同的 bucket源集群创建的备份就能被目标集群看到从而在目标集群上直接执行恢复。这就是velero restore create --from-backup BACKUP-NAME在目标集群上能够生效的根本原因——即使在目标集群中从未创建过对应的 Backup 对象同步机制也会把它从对象存储带回来。从源码实现看这一同步由 backup_sync_controller.go 中的backupSyncReconciler驱动。其locationFilterFuncpkg/controller/backup_sync_controller.go#L405-L429会按照每个 Backup Storage Location 的同步周期BackupSyncPeriod决定是否执行同步周期为0时跳过同步为负值时回退到默认周期否则按lastSync syncPeriod判断是否到达下一次同步时间。迁移前的关键考量在开始迁移之前需要评估以下几个限制条件它们直接决定了你的迁移方案是否可行快照不能跨云厂商迁移Velero不原生支持跨云厂商迁移持久卷快照。如果你需要跨云平台如 AWS 迁移到 Azure迁移卷数据应启用文件系统备份File System Backup它会在文件系统层面备份卷内容。目标集群 Kubernetes 版本限制Velero不支持恢复到 Kubernetes 版本低于备份来源集群的环境中。API 组兼容性跨运行不同 Kubernetes 版本的集群迁移负载可能是可行的但需要提前考虑各自定义资源 API 组在集群间的兼容性。如果 Kubernetes 版本升级导致核心/原生 API 组不兼容必须先更新受影响的 CR 资源才能用 Velero 迁移。更多细节可参考 EnableAPIGroupVersions 特性文档。其原理是Velero 使用 API server 的preferred version备份每个 group/resource恢复时目标集群必须存在该 API 组/版本不要求是首选版本。同厂商区域限制AWS 与 Azure 的 Velero 插件不支持跨区域迁移数据。若确有跨区域需求必须使用文件系统备份。迁移场景AWS 集群间的完整步骤下面以一个具体场景演示从 Cluster 1 迁移到 Cluster 2 的全过程。假设两个集群均使用同一云厂商 AWS以及 Velero 的 AWS 插件插件清单见 supported-providers.md。步骤 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注上述命令中的镜像版本与插件版本来自官方迁移文档示例实际部署时请以你计划使用的 Velero 发布版本及对应插件版本为准。安装过程中Velero 会在--bucket指定的桶本例为velero-migration-demo内创建一个名为default的Backup Storage LocationBSL这是 Velero 存放备份的位置。通过以下命令可以查看 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 true从输出可以看到该 BSL 的访问模式ACCESS MODE为ReadWrite且被标记为默认DEFAULTtrue。BSL 与 Volume Snapshot LocationVSL这两个自定义资源是 Velero 存储配置的核心详见 locations.md。步骤 2在 Cluster 1 创建备份确保 Cluster 1 已有备份将BACKUP-NAME替换为你的备份名称velero backup create BACKUP-NAME更推荐的做法是使用velero schedule创建定时备份按你定义的 Cron 调度自动备份数据确保数据持续得到保护。备份的默认保留期TTL存活时间为30 天720 小时可通过--ttl DURATION参数调整例如--ttl 24h0m0s。关于备份过期机制的详细说明见 how-velero-works.md当备份过期后gc-controller 会删除 Backup 资源、对象存储中的备份文件、所有 PV 快照及关联的 Restore 资源。步骤 3在 Cluster 2 安装 Velero 并指向相同存储在 Cluster 2 上安装 Velero。注意下面的安装命令与 Cluster 1使用相同的region和--bucketAWS 插件不支持跨区域迁移数据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 2 安装完成后通过velero backup-location create和velero snapshot-location create命令手动配置 BSL 与 VSL指向 Cluster 1 使用的 bucket 和 regionvelero backup-location create bsl --provider aws --bucket velero-migration-demo --config regionus-east-2 --access-modeReadOnly强烈建议用--access-modeReadOnly将目标集群的 Backup Storage Location 配置为只读模式防止在恢复过程中误删对象存储里的备份。在源码层面--access-mode是一个枚举参数合法值为ReadWrite与ReadOnly默认值为ReadWrite见 pkg/cmd/cli/backuplocation/create.go#L83-L87。从 how-velero-works.md 可知恢复场景下将 BSL 设为只读会禁用该位置的备份创建与删除从而保证备份数据安全。可运行velero backup-location create --help查看该命令的全部可用参数。接着创建卷快照位置velero snapshot-location create vsl --provider aws --config regionus-east-2VSL 完全由厂商特定字段定义如 AWS region、Azure resource group 等其 CLI 支持--provider、--config、--labels、--credential等参数见 pkg/cmd/cli/snapshotlocation/create.go#L74-L77。可运行velero snapshot-location create --help查看更多参数说明。步骤 4在 Cluster 2 确认备份可用继续在 Cluster 2 上操作确认 Cluster 1 创建的 Backup 对象已同步过来velero backup describe BACKUP-NAMEBACKUP-NAME应与 Cluster 1 创建备份时使用的名称一致。Velero 资源会与对象存储中的备份文件同步Cluster 1 备份产生的 Velero 资源会通过共享的 Backup Storage Location 自动同步到 Cluster 2。同步完成后你就能在 Cluster 2 上通过 Velero 命令访问来自 Cluster 1 的备份了。默认同步间隔为 1 分钟因此在 Cluster 2 上检查备份可用性前可能需要稍等片刻。可以通过给 Cluster 2 的 Velero server 添加--backup-sync-period参数来调整该间隔。源码中该参数的定义位于 pkg/cmd/server/config/config.go#L235其作用是定期确保对象存储中的所有 Velero 备份都以 Backup API 对象的形式存在于集群中同时 pkg/cmd/cli/backuplocation/create.go#L97 表明 BSL 级别也支持该参数且设为0s可禁用同步默认值为 1 分钟。步骤 5在 Cluster 2 执行恢复在 Cluster 2 上确认正确的备份可用后即可将全部资源恢复到 Cluster 2velero restore create --from-backup BACKUP-NAME确保BACKUP-NAME与 Cluster 1 的备份名一致。默认情况下 Velero 执行的是非破坏性恢复不会删除目标集群上的任何数据如果备份中的资源在目标集群已存在将跳过该资源。如需更新策略可在恢复时使用--existing-resource-policy参数设为update时Velero 会尝试将目标集群中的已有资源更新为与备份一致详见 restore-reference.md。验证两个集群的迁移结果迁移完成后需要确认 Cluster 2 的行为符合预期在 Cluster 2 上运行velero restore get然后运行velero restore describe RESTORE-NAME-FROM-GET-COMMAND此时从 Cluster 1 备份的数据应该已经可以在 Cluster 2 上正常访问。排障提示如果遇到问题请确认两个集群中 Velero 运行在相同的命名空间。补充说明无法共享快照时的迁移方案如果两个集群无法共享备份生成的快照例如从 EKS 迁移到 AKS跨云厂商场景则建议改用以下两种方案之一文件系统备份File System Backup基于 kopia 在文件系统层面备份/恢复 Kubernetes 卷不依赖特定存储平台的快照能力可支持 EFS、AzureFile、NFS、emptyDir、local 等没有原生快照概念的卷类型并且可以将备份数据保存到与卷所在平台不同的存储平台上。需要注意它属于 beta 质量特性且备份的是活跃文件系统数据一致性不如快照方案。安装时使用velero install --use-node-agent启用 Node Agent daemonset。快照数据移动器Snapshot Data Mover通过 CSI 快照后再将快照数据移动到不同存储位置适用于基于 CSI 的卷迁移场景。选择哪种方案取决于你的存储环境是否支持原生/CSI 快照、是否跨云厂商以及你对数据一致性的要求。提前评估这些前提条件是保证迁移一次成功的关键。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考