1. 为什么说Kubernetes迁移像“搬家”？

当你的应用从本地机房搬到公有云，或者需要在多云环境切换集群时，就相当于给整个系统「搬家」。想象这样的场景：

  • 案例A：某电商平台要从AWS迁移到阿里云迎接双十一
  • 案例B：游戏公司将测试环境的微服务迁移到生产集群
  • 案例C：金融企业为实现灾备需要同步两地集群

就像搬家要打包家具、转移贵重物品，迁移的关键在于：应用的YAML部署文件是「家具」，数据库等持久化数据是「传家宝」，而如何减少搬迁期间的停机时间（downtime）则决定了搬家是否顺利。

2. 打包工具怎么选？

2.1 Velero：搬家公司的王牌车队

（技术栈：Velero + Restic + CSI）

# 安装搬家专用卡车（Velero客户端）
wget https://github.com/vmware-tanzu/velero/releases/download/v1.9.3/velero-v1.9.3-linux-amd64.tar.gz
tar -xvf velero-v1.9.3-linux-amd64.tar.gz
sudo mv velero /usr/local/bin/

# 配置搬家公司的专属货舱（使用AWS S3存储桶）
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.6.0 \
  --bucket migration-backup-2023 \
  --secret-file ./credentials-velero \
  --use-restic \
  --use-volume-snapshots=false

注释说明：这里选择了无需快照功能的方案，通过文件系统级备份更适用于通用存储类型

2.2 Argo CD：实时同步的搬运助手

（技术栈：Argo CD + GitOps）

# application-sync.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: product-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://gitlab.com/your-repo.git
    targetRevision: HEAD
    path: k8s/manifests/prod
  destination:
    server: https://new-cluster-api:6443
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

注释说明：该配置实现Git仓库与应用状态的双向同步，跨集群时修改destination参数即可

3. 应用迁移

3.1 打包阶段（原集群操作）

# 将订单服务整套配置打包（包含关联的ConfigMap和Secret）
velero backup create order-service-backup \
  --include-namespaces=order-system \
  --include-resources=deployments,services,configmaps,secrets \
  --selector app=order-service

# 查看打包清单的完整性
velero backup describe order-service-backup --details

输出结果验证要点：

  • Completed状态表示备份成功
  • PV（持久卷）数据量应与实际数据目录一致
  • Warnings字段需保持空白

3.2 运输阶段（目标集群操作）

# 恢复订单服务整套配置（保留原NodePort配置）
velero restore create from-order-service-backup \
  --from-backup order-service-backup \
  --preserve-nodeports \
  --restore-volumes=true \
  --mapping-namespaces order-system:prod-order

# 监测运输过程中的实时状态
watch velero restore describe from-order-service-backup

关键参数解释：--mapping-namespaces实现命名空间重定向，旧集群的order-system在目标集群变为prod-order

4. 数据迁移的三种姿势

4.1 方案一：同步复制（适合PB级大数据）

# 使用rsync进行增量同步
rsync -avz --progress \
  --exclude 'tmp/' \
  --exclude 'logs/' \
  -e "ssh -i ~/migration-key.pem" \
  /mnt/data-volume/ \
  admin@new-cluster-storage:/mnt/migrated-data/

# 创建校验文件确保数据一致性
find /mnt/data-volume -type f -exec md5sum {} + | sort -k 2 > source.md5
ssh admin@new-cluster-storage "find /mnt/migrated-data -type f -exec md5sum {} + | sort -k 2" > target.md5
diff source.md5 target.md5

注释说明：需提前建立SSH免密登录，排除临时文件和日志目录

4.2 方案二：存储快照（适用于块存储）

# velero-volume-backup.yaml
apiVersion: velero.io/v1
kind: VolumeSnapshotLocation
metadata:
  name: aws-ebs-snapshot
  namespace: velero
spec:
  provider: aws
  config:
    region: us-west-2
    profile: "migration-profile"

# 创建带快照的备份
velero backup create full-snapshot-backup \
  --snapshot-volumes \
  --volume-snapshot-locations aws-ebs-snapshot

5. 方案选择的五维评测

评估维度 文件同步方案 存储快照方案
迁移速度 慢（依赖网络带宽） 快（基于存储API）
数据一致性 最终一致 强一致
操作复杂度 需手动校验 全自动
存储成本 仅消耗传输流量 产生快照存储费用
回滚难度 重新同步 一键恢复

特别提示：数据库类有状态服务必须停机维护才能保证一致性，推荐在业务低谷期操作

6. 五个必看的注意事项

  1. 版本陷阱
    Kubernetes 1.23→1.25的API版本变更可能导致Deployment配置失效

  2. 存储类的改名风波
    原集群使用ebs-storage的StorageClass，目标集群需提前创建同名存储类

  3. 网络策略的隐形墙
    目标集群的NetworkPolicy可能阻挡跨命名空间通信

  4. 证书的时空穿越
    TLS证书中包含旧集群域名会导致验证失败

  5. 监控系统的信号丢失
    Prometheus的采集配置需重新适配新集群节点发现规则

7. 迁移后的验收清单

  • [ ] 执行curl http://新集群IP/health验证服务状态
  • [ ] 对比新旧集群的deployment副本数
  • [ ] 检查Pod日志中是否有数据库连接错误
  • [ ] 验证Ingress配置的域名解析正确性
  • [ ] 运行压力测试确保性能达标

8. 总结：迁移成功的三个定律

  1. 墨菲定律应对法则
    总是准备两种备份方案，当rsync失败时立即切换至存储快照方案

  2. 蝴蝶效应预防原则
    用kube-score工具扫描YAML文件，提前发现兼容性问题

  3. 敏捷迁移方法论
    采用蓝绿部署模式，旧集群下线前维持72小时观察期