如何将手动创建的ZooKeeper StatefulSet存储卷迁移至Helm部署

我帮你梳理下在AWS EKS环境下，把手动创建的ZooKeeper StatefulSet存储卷迁移到Helm部署版本的具体步骤，都是实际操作过的靠谱方案：

一、迁移前准备工作 #

1. 备份原有数据（重中之重）
   • 先暂停旧ZooKeeper集群的写入：可以把旧StatefulSet的副本数临时缩为0，避免迁移过程中数据变更：

     kubectl scale statefulset <旧ZK StatefulSet名称> --replicas=0
     

   • 为每个旧PVC对应的EBS卷创建快照（用AWS CLI或控制台），留好兜底备份：

     # 先获取旧PVC对应的EBS卷ID
     kubectl describe pvc <旧PVC名称> | grep VolumeID
     # 创建快照
     aws ec2 create-snapshot --volume-id <EBS卷ID> --description "ZK迁移前数据备份"
     

2. 确认Helm Chart配置
   • 提前准备好Helm Zookeeper Chart的values.yaml，重点确认：
     • persistence.enabled: true（开启持久化）
     • persistence.storageClass 和旧PVC使用的存储类一致（比如AWS的gp2/gp3）
     • persistence.size 不小于旧PVC的容量
     • 确保新旧ZooKeeper版本兼容（比如旧版本是3.6.x，Helm也部署同大版本）

二、两种核心迁移方案 #

方案1：基于EBS快照直接复用数据卷（适合大数据量场景） #

这种方式不需要拷贝数据，直接把旧数据卷的快照转为新PVC的底层EBS卷，效率最高：

1. 生成新EBS卷
   • 用之前创建的快照，为每个旧ZK节点生成对应AZ的新EBS卷：

     aws ec2 create-volume --snapshot-id <快照ID> --availability-zone <旧卷所在AZ> --volume-type <同旧卷类型>
     

2. 提前创建新PVC
   • Helm部署的ZooKeeper StatefulSet会自动生成命名为 <HelmRelease名>-zk-0、<HelmRelease名>-zk-1 这类格式的PVC，所以我们要提前手动创建这些PVC，并绑定到刚生成的新EBS卷：

     # 示例：创建第一个节点的PVC
     apiVersion: v1
     kind: PersistentVolumeClaim
     metadata:
       name: my-zk-zk-0  # 要和Helm生成的PVC名称完全一致
       namespace: <你的命名空间>
     spec:
       accessModes:
         - ReadWriteOnce
       storageClassName: <你的存储类>
       resources:
         requests:
           storage: 10Gi  # 和旧PVC容量一致或更大
       volumeName: <新创建的EBS卷ID>  # 绑定到新EBS卷
     

   • 为每个ZK节点都创建对应的PVC。
3. 部署Helm版ZooKeeper
   • 直接执行Helm install，因为PVC已经提前创建好，StatefulSet会直接复用这些PVC：

     helm install my-zk zookeeper --values ./values.yaml --namespace <你的命名空间>
     

方案2：数据直接拷贝（适合小数据量场景） #

如果数据量不大，不想操作AWS底层资源，可以用kubectl直接拷贝数据：

1. 先部署Helm版ZooKeeper但暂不启动副本

   helm install my-zk zookeeper --values ./values.yaml --set replicaCount=0 --namespace <你的命名空间>
   

2. 逐个启动副本并拷贝数据
   • 启动旧ZK的一个副本：

     kubectl scale statefulset <旧ZK StatefulSet名称> --replicas=1
     

   • 启动新ZK的对应副本：

     kubectl scale statefulset my-zk-zk --replicas=1
     

   • 用kubectl cp拷贝数据（注意路径要和新旧ZK的实际数据目录匹配，旧ZK可能是/var/lib/zookeeper/data，Helm版可能是/bitnami/zookeeper/data）：

     kubectl cp <旧ZK Pod名>:/<旧数据目录> <新ZK Pod名>:/<新数据目录>
     

   • 拷贝完成后，停掉旧ZK的该副本，再启动下一个新副本，重复上述步骤直到所有节点数据拷贝完成。
3. 启动所有副本
   所有节点数据拷贝完成后，把Helm版ZK的副本数调整为预期值：

   helm upgrade my-zk zookeeper --set replicaCount=3 --namespace <你的命名空间>
   

三、验证与收尾 #

1. 验证集群状态
   • 检查所有Pod是否正常Running：kubectl get pods -l app=zookeeper
   • 进入Pod用zkCli连接集群，验证数据是否存在：

     kubectl exec -it my-zk-zk-0 -- zkCli.sh
     # 执行数据查询，比如 get /your/test/node
     

   • 测试写入新数据，确认集群读写正常。
2. 清理旧资源
   确认新集群完全正常后，删除旧的StatefulSet、PVC、Service等资源：

   kubectl delete statefulset <旧ZK StatefulSet名称>
   kubectl delete pvc <旧PVC列表>
   

关键注意事项 #

• 业务停机窗口：迁移期间建议暂停业务对ZK的写入，避免数据不一致，最好选择低峰期操作。
• AZ一致性：AWS EBS卷是AZ绑定的，新卷必须和旧卷在同一个AZ，否则Pod无法挂载。
• 版本兼容性：新旧ZK版本必须兼容，跨大版本迁移可能导致数据格式不兼容，建议先在测试环境验证。

内容的提问来源于stack exchange，提问作者Guillaume Alouege