Kubernetes 数据迁移实战：使用 pv-migrate 工具高效迁移 PVC 数据

本文基于真实生产环境经验，分享如何利用 pv-migrate 工具安全、高效地完成 Kubernetes 持久卷数据迁移，包含完整操作步骤、常见场景解决方案和避坑指南。

一、为什么需要专门的 PVC 迁移工具？

在 Kubernetes 生产环境中，有状态应用（如 MySQL、Redis、Elasticsearch）的数据迁移是运维工程师经常面临的挑战。传统的手动方式（如 kubectl cp、挂载临时 Pod）存在诸多问题：

• 数据一致性风险：迁移过程中应用仍在写入，可能导致数据损坏
• 操作复杂易错：需要手动创建多个资源，步骤繁琐
• 缺乏回滚机制：迁移失败后难以快速恢复
• 跨集群迁移困难：网络配置、安全策略复杂

pv-migrate​ 正是为解决这些问题而生，它通过自动化流程、安全传输机制和多种迁移策略，让 PVC 数据迁移变得简单可靠。

---

二、环境准备与工具安装

2.1 前置条件确认

在开始迁移前，请确保：

• 已安装 kubectl 并配置好集群访问权限
• 源和目标 PVC 已创建（目标 PVC 容量应≥源数据量）
• 源应用已停止写入或设置为只读（重要！）

2.2 安装 pv-migrate

推荐使用 krew 插件管理器安装（最方便）：

# 安装 krew（如未安装）
(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

# 将 krew 加入 PATH
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

# 安装 pv-migrate 插件
kubectl krew install pv-migrate

验证安装：

kubectl pv-migrate --version

其他安装方式（备选）：

• Homebrew：brew install pv-migrate
• 二进制文件：从 GitHub Releases 下载对应版本
• Docker：docker run --rm -it -v ~/.kube:/root/.kube utkuozdemir/pv-migrate

---

三、实战场景：同命名空间 PVC 迁移

场景描述

MySQL 数据库需要从 20GB 的 PVC 扩容到 50GB 的新 PVC（原存储类不支持在线扩容）。

3.1 准备目标 PVC

# mysql-pvc-new.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc-new
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: standard

应用配置：

kubectl apply -f mysql-pvc-new.yaml

3.2 停止应用写入

重要提示：迁移前必须确保数据一致性！

# 方法1：停止应用（推荐）
kubectl scale deployment mysql --replicas=0 -n production

# 方法2：将源 PVC 设为只读（如果应用支持）
# 修改 Deployment 的 volumeMounts 添加 readOnly: true
# 或使用临时 Pod 挂载为只读

3.3 执行迁移

kubectl pv-migrate migrate \
  --source production/mysql-pvc-old \
  --dest production/mysql-pvc-new \
  --log-level DEBUG

关键参数说明：

• --source：格式为 namespace/pvc-name
• --dest：目标 PVC
• --log-level DEBUG：开启详细日志，便于排查问题
• --compress：启用压缩传输（网络带宽有限时建议使用）
• --dest-delete-extraneous-files：删除目标端多余文件（确保数据完全一致）

3.3 验证数据完整性

迁移完成后，建议进行数据验证：

# 临时挂载目标 PVC 进行验证
kubectl run verify-pod --rm -it --image=busybox \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "verify",
        "image": "busybox",
        "command": ["/bin/sh", "-c", "ls -la /data && echo '验证完成'"],
        "volumeMounts": [{
          "mountPath": "/data",
          "name": "data"
        }]
      }],
      "volumes": [{
        "name": "data",
        "persistentVolumeClaim": {
          "claimName": "mysql-pvc-new"
        }
      }]
    }
  }'

3.4 切换应用使用新 PVC

修改 MySQL Deployment 的 PVC 引用：

# 修改 volumes 部分
volumes:
- name: mysql-data
  persistentVolumeClaim:
    claimName: mysql-pvc-new  # 修改为新的 PVC

重启应用：

kubectl scale deployment mysql --replicas=1 -n production

3.5 清理旧资源（可选）

确认应用运行正常后，可删除旧 PVC：

 

kubectl delete pvc mysql-pvc-old -n production

 

---

四、进阶场景：跨命名空间迁移

场景描述

将 Redis 数据从 default命名空间迁移到专用的 redis命名空间。

4.1 准备目标环境

# 创建目标命名空间
kubectl create ns redis

# 创建目标 PVC（在 redis 命名空间）
kubectl apply -f redis-pvc.yaml -n redis

4.2 执行跨命名空间迁移

kubectl pv-migrate migrate \
  --source default/redis-pvc \
  --dest redis/redis-pvc-new \
  --log-level INFO

 

注意：跨命名空间迁移需要确保：

• 源和目标命名空间网络互通（默认情况下通常可以）
• 如有 NetworkPolicy 限制，需临时调整或使用 --network-policy参数

---

五、生产环境最佳实践与避坑指南

5.1 数据一致性保障

关键原则：迁移前必须停止应用写入！常见错误场景：

• ❌ 直接迁移正在运行的数据库 → 数据损坏风险
• ✅ 正确做法：先停止应用或设置只读模式

对于无法停止的应用（如生产数据库），可考虑：

1. 使用数据库的备份/恢复工具（如 mysqldump、pg_dump）
2. 使用存储级别的快照功能（如 AWS EBS Snapshot）
3. 在业务低峰期进行迁移

5.2 网络与性能优化

大文件迁移优化：

• 使用 --compress参数减少网络传输量
• 如果网络带宽有限，可考虑在集群内部节点间迁移（减少跨节点流量）
• 对于 TB 级数据，建议分批次迁移或使用存储层复制

跨集群迁移网络配置：

• 确保集群间网络互通（VPC Peering、VPN 等）
• 检查防火墙规则是否允许迁移 Pod 通信
• 使用 --strategy参数尝试不同迁移策略

5.3 权限与安全

RBAC 权限要求：

• 需要 create、list、deletePod、Service、Job 等资源的权限
• 建议使用最小权限原则，创建专用 ServiceAccount

安全传输机制：

• pv-migrate 使用 SSH over rsync，数据在传输过程中加密
• 临时密钥自动生成，迁移完成后自动清理
• 可自定义 SSH 密钥（通过 --ssh-secret参数）

5.4 故障排查技巧

常见问题与解决方案：

问题现象	可能原因	解决方案
迁移超时	网络慢/数据量大	使用 --timeout延长超时时间
权限不足	RBAC 配置问题	检查 ServiceAccount 权限
网络不通	NetworkPolicy 限制	使用 --network-policy或临时放宽策略
存储类不匹配	目标 PVC 特性不符	确认存储类支持 ReadWriteOnce 等模式

调试命令：

# 保留中间资源用于排查
kubectl pv-migrate migrate ... --skip-cleanup

# 查看迁移 Pod 日志
kubectl logs -f <migration-pod-name> -n <namespace>

# 查看迁移状态
kubectl get jobs,pods -l app.kubernetes.io/created-by=pv-migrate

---

六、总结

pv-migrate 工具通过自动化流程、多种迁移策略和安全传输机制，显著降低了 Kubernetes PVC 数据迁移的复杂度。在实际生产环境中，建议：

1. 测试先行：在测试环境验证迁移流程和数据完整性
2. 制定回滚计划：保留源 PVC 直到确认迁移成功
3. 监控迁移过程：使用 --log-level DEBUG实时观察进度
4. 建立标准化流程：将 pv-migrate 纳入 CI/CD 或运维自动化流程

通过本文的实践指南，希望你能在下次数据迁移任务中更加从容应对。工具虽好，但谨慎操作和充分验证仍是保障生产环境稳定的关键。