为什么我们需要跨云迁移？
实际操作要点
随着多云战略成为企业常态，Kubernetes集群的跨云迁移需求日益频繁。无论是为了降低成本、规避供应商锁定，还是为了灾备与合规，将K8s应用从A云平滑迁移到B云，都是一个技术痛点。传统方式——手动导出YAML、重建存储、重新配置网络——耗时且易出错。而Velero的出现，让这一过程变得像“搬家”一样只需三步：打包、运输、复原。
相关阅读：此处可内链到“跨云迁移常见问题”专题。
进阶阅读：此处可内链到“跨云迁移性能优化”指南。
Velero是什么？
先看关键判断
Velero（原名Heptio Ark）是一个由VMware维护的开源工具，专门用于Kubernetes集群的备份、恢复和迁移。它支持将K8s资源（Deployment、Service、ConfigMap等）以及持久卷（PV）的数据备份到对象存储（如AWS S3、阿里云OSS、MinIO），并能将备份恢复到同一集群或不同的目标集群。其核心能力包括：
- 资源备份：通过API获取集群对象快照，支持按命名空间、标签筛选。
- 卷快照：集成CSI、插件、或原生云存储快照，备份PV数据。
- 迁移：备份到标准格式后，在目标集群恢复，实现跨集群、跨云。
- 调度策略：支持CronJob定时备份。
延伸阅读：此处可内链到“跨云迁移配置案例”相关文章。
跨云迁移的核心逻辑
容易忽略的细节
Velero的跨云迁移原理并不复杂：在源集群上创建备份（包含资源和卷快照），将备份数据上传至对象存储；然后在目标集群上安装Velero并指向同一存储，执行恢复命令。关键在于：
- 对象存储必须被两个集群都能访问（如公网S3或内网互通）。
- 卷快照依赖云提供商的快照API，跨云时需使用文件级备份（Restic/Kopia）或CSI通用快照。
- 目标集群的StorageClass需兼容，或通过存储映射自动转换。
实战：三步完成跨云迁移
第一步：在源集群安装并配置Velero
假设源集群运行在阿里云ACK上，目标集群运行在腾讯云TKE上。我们需要一个共用的对象存储桶——这里以AWS S3为例（也可用MinIO自建）。
# 安装velero命令行工具
wget https://github.com/vmware-tanzu/velero/releases/download/v1.14.0/velero-v1.14.0-linux-amd64.tar.gz
tar -xvf velero-*.tar.gz
sudo mv velero /usr/local/bin/
# 配置凭证（S3的access key）
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=xxx
# 安装Velero服务器，并启用Kopia（文件级备份）
velero install
--provider aws
--bucket your-bucket-name
--backup-location-config region=us-east-1
--snapshot-location-config region=us-east-1
--use-volume-snapshots=false
--use-node-agent
--plugins velero/velero-plugin-for-aws:v1.9.0
注意：关闭卷快照（–use-volume-snapshots=false）并启用node-agent（–use-node-agent），让Velero通过文件拷贝（Kopia）备份PV数据，从而摆脱云厂商快照API的限制——这是跨云迁移的关键技巧。
第二步：备份整个命名空间
假设我们要迁移production命名空间下的所有应用：
velero backup create my-backup --include-namespaces production --default-volumes-to-fs-backup --wait
参数解释：
--include-namespaces production：只备份production命名空间。--default-volumes-to-fs-backup：对所有PVC启用文件级备份（Kopia）。--wait：等待备份完成显示结果。
备份完成后，检查状态：velero backup describe my-backup。如果成功，你会看到Volume Backups状态为Completed。
第三步：在目标集群恢复
在腾讯云TKE上安装Velero（同样的版本），指向同一S3桶：
# 安装，注意使用不同的凭证（TKE节点可通过IAM授权）
velero install
--provider aws
--bucket your-bucket-name
--backup-location-config region=us-east-1
--use-node-agent
--plugins velero/velero-plugin-for-aws:v1.9.0
# 查看可用的备份列表
velero backup get
# 开始恢复，并自动调整StorageClass
velero restore create --from-backup my-backup --namespace-mappings production:production --storage-class-mappings aws-ebs:tke-ssd --wait
关键参数：
--namespace-mappings：如果目标集群的命名空间不同，可重映射。--storage-class-mappings：将源集群的StorageClass（如aws-ebs）映射为目标集群的StorageClass（如tke-ssd）。Velero会自动转换PV的StorageClass名称。
恢复完成后，检查Pod状态：kubectl get pods -n production。若一切正常，应用已成功在目标集群运行。
补充参考：此处可内链到“跨云迁移故障排查实例”。
关联教程：此处可内链到“跨云迁移部署与验证”内容。
验证与常见问题
如何验证迁移完整性？
- 资源对比：用
velero backup describe查看备份的资源列表，与目标集群对比。 - 数据校验：进入Pod检查PV内的文件是否与源一致，或通过数据库工具验证。
- 平滑割接：恢复前暂停源集群的写入，恢复后更新DNS指向目标集群。
常见问题处理
- 备份慢：文件级备份依赖节点上的Kopia容器，遇到大量小文件时较慢。建议先排除不必要的数据（如临时日志）。
- 恢复后Pod CrashLoopBackOff：可能是StorageClass映射错误或PVC名称冲突。检查PV的AccessMode、容量是否一致。
- 跨云网络延迟：S3桶若在海外，备份恢复速度可能受限于公网带宽。建议在源和目标集群就近区域创建存储桶，或使用对象存储的跨区域复制功能。
总结：Velero让跨云迁移不再头疼
容易忽略的细节
通过本文的实战演示，可以看到跨云迁移不再是高不可攀的挑战。Velero通过文件级备份加存储映射的方式，优雅地解决了云厂商之间的不兼容问题。只需一个公共对象存储桶，就能将整个K8s应用连同数据搬到任何Kubernetes集群。当然，生产环境迁移仍需谨慎，建议先在测试集群演练，确保业务无感知切换。
如果你还在为多云迁移方案发愁，不妨试试Velero——简单、强大、开源，值得加入你的运维工具箱。按这个顺序复查，跨云迁移遇到异常时也更容易定位。
延伸阅读