Velero 数据迁移实战：从 AWS EKS 到本地 K3s 集群的存储方案转换

背景与挑战

在现代云原生架构中，数据迁移是一个常见但充满挑战的任务。本文将以一个真实案例为基础，探讨如何利用 Velero 工具将 PostgreSQL 和 Elasticsearch 从 AWS EKS 集群（使用 gp2 存储类）迁移到本地 K3s 集群（使用 local-path 存储类）。

技术方案设计

1. 源集群准备

在 AWS EKS 源集群中，我们首先部署 Velero 并配置 AWS S3 作为备份存储位置。关键配置包括：

• 使用 AWS 凭证文件进行认证
• 指定 S3 存储桶和区域
• 启用文件系统备份模式（--default-volumes-to-fs-backup）
• 包含必要的命名空间（test-ns）

2. 目标集群准备

在目标 K3s 集群中，我们同样部署 Velero 并连接到相同的 S3 存储桶。特别注意：

• 配置存储类映射（gp2 → local-path）
• 禁用卷快照功能（因为目标环境是本地存储）
• 确保使用相同的插件版本以保证兼容性

迁移过程中的关键发现

在执行迁移后，虽然大部分资源成功迁移，但发现数据库中的原有数据未能正确迁移。这揭示了文件系统备份（fs-backup）方法的一个重要限制：对于数据库类应用，fs-backup 无法保证数据一致性。

专业建议与最佳实践

1. 数据一致性保障

对于数据库类应用（如 PostgreSQL、Elasticsearch），推荐使用 Velero 的 Data Mover 功能进行备份迁移。Data Mover 提供了：

• 基于快照的备份机制
• 更好的数据一致性保证
• 对运行中数据库的支持

2. 存储类转换策略

当源和目标环境使用不同的存储类时，可通过 ConfigMap 实现自动转换：

apiVersion: v1
data:
  gp2: local-path
kind: ConfigMap
metadata:
  labels:
    velero.io/change-storage-class: RestoreItemAction
    velero.io/plugin-config: ""
  name: change-storage-class-config
  namespace: velero

3. 排除资源策略

在复杂环境中，某些资源可能不需要迁移或需要特殊处理。Velero 支持通过 --exclude-resources 参数排除特定资源类型：

velero restore create restore-jan20 \
  --from-backup backup-jan20 \
  --exclude-resources orders.acme.cert-manager.io,certificaterequests.cert-manager.io,certificates.cert-manager.io

经验总结

1. 环境差异评估：在跨云/本地迁移前，必须充分评估源和目标环境的差异，特别是存储类的不同。

2. 备份方法选择：根据应用类型选择合适的备份方法，数据库类应用优先考虑 Data Mover。

3. 验证机制：建立完善的验证流程，确保数据完整性和一致性。

4. 渐进式迁移：对于生产环境，建议采用渐进式迁移策略，先迁移非关键组件，验证无误后再迁移核心数据。

通过本文的实践案例，我们展示了 Velero 在复杂环境迁移中的强大能力，同时也强调了正确选择备份方法和充分验证的重要性。这些经验对于计划进行类似迁移的团队具有重要参考价值。