自建NFS迁移至KFS

KCE支持用户使用自建的NFS，本文将介绍如何将自建的NFS迁移至金山云文件系统（KFS）。

步骤一：新建KFS实例

1. 进入文件存储KFS控制台。
2. 单击新建文件系统，进行文件系统的创建，详细操作参考创建文件系统及挂载点。
3. 点击进入已创建的文件系统查看详情。
   
   如上图所示：
   server：10.x.x.xx
   share：/cfs-xxxxxxxxxx

步骤二：新建StorageClass

创建 StorageClass 的 YAML 文件如下：

kind: StorageClass
metadata:
  name: kfsplugin
provisioner: com.ksc.csi.nfsplugin  
allowVolumeExpansion: false
parameters:
  server: 10.x.x.xx                 ## server地址从步骤1中获取 固定值  
  share: /cfs-xxxxxxxxxx            ## 从步骤1中获取 固定值
reclaimPolicy: Retain                
volumeBindingMode: Immediate
mountOptions:
  - vers=3
  - nolock
  - proto=tcp
  - noresvport

步骤三：复制数据

1. 缩减应用的副本数量缩减为0

kubectl scale deployment <deployment-name> --replicas=0

2. 按照旧 PVC 的配置创建 PVC，指定新的StorageClass

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "data-new"
  namespace: "default"
spec:
  accessModes:
  - "ReadWriteOnce"    
  resources:
    requests:
      storage: "100Mi"
  storageClassName: "kfsplugin"

3. 拷贝存储数据

作为替换的新的 PV 已创建，创建一个 Deployment 挂载新旧两个 PV，将旧 PV 的数据拷贝到新 PV：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: datacopy
  name: datacopy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: datacopy
  template:
    metadata:
      labels:
        app: datacopy
    spec:
      containers:
        - name: datacopy
          image: busybox
          command:
            - 'sleep'
          args:
            - infinity
          volumeMounts:
            - name: old-pvc
              readOnly: false
              mountPath: /mnt/old
            - name: new-pvc
              readOnly: false
              mountPath: /mnt/new
      volumes:
        - name: old-pvc
          persistentVolumeClaim:
            claimName: xxx-xxx  #需要替换成旧的pvc名称
        - name: new-pvc
          persistentVolumeClaim:
            claimName: data-new

① 使用以下命令进入容器后，分别检查旧PV挂载点是否包含应用数据，新PV挂载点是否为空：

kubectl exec -it <pod-name> -- sh

② 执行以下命令进行数据的复制和权限继承：

(cd /mnt/old; tar -cf - .) | (cd /mnt/new; tar -xpf -)

说明：此方法在遇到较大数据时较慢。

验证数据是否复制完成：
① 检查新的 PV 的挂载点是否包含旧的PV 的数据，在新旧pv的两个挂载路径下通过命令ls -l验证数据的所有权限是否被正确继承。
② 确认数据复制完成后，需要将 datacopy deployment 的副本缩减为0（若后续不使用可直接删除），这样两个pvc 就和它失去关联，可以执行后续操作：

kubectl scale deployment datacopy --replicas=0

4. 迁移PVC

迁移存储的理想状态是使用旧的 PVC，并将其指向新的 PV，这样工作负载的 YAML 配置清单就不需要做任何改变。但 PVC 和 PV 之间的绑定关系是不可更改的，要想让它们解绑，必须先删除旧的 PVC，再创建同名的 PVC，并将旧的 PV 与它绑定。
默认情况下 PV 的回收策略是 Delete，一旦删除 PVC，与之绑定的 PV 和 PV 里的数据都会被删除，因此需要修改回收策略，以便删除 PVC 时 PV 能够保留下来。

(1) 修改回收策略

执行命令 kubectl describe pv <pv-name>，分别查看新旧 PV 的回收策略：

修改新旧PV的回收策略为Retain，这样可以确保将新旧PVC删除时，PV不会受到影响。

kubectl patch pv <pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

(2) 删除新旧PVC

执行以下命令行，删除新旧PVC：

kubectl delete pvc <pvc-name>

(3)绑定pv

在创建最终的 PVC 之前，我们必须要确保新创建的 PVC 能够被绑定到新的 PV 上。通过命令kubectl describe pv <pv-name>可以看到新 PV 目前处于释放状态，不能被最终的 PVC 绑定：

这是因为 PV 在 spec.claimRef中仍然引用了已经被删除的 PVC，通过命令编辑PV，将spec.claimRef中的内容删除：

kubectl patch pv <pv-name> -p '{"spec":{"claimRef":null}}'

再次查看PV已处于可用状态：

创建与旧 PVC 同名的新PVC，并保证与旧 PVC 的参数相同：

• 新 PVC 的名字和旧 PVC 的名字相同；
• spec.volumeName指向新 PV；
• 新 PVC 的 metadata.annotations
  和 metadata.labels和旧 PVC 保存相同，因为这些值可能会影响到应用部署（比如 Helm chart 等）。

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: 
  namespace: 
spec:
  accessModes:
  - "ReadWriteOnce"
  resources:
    requests:
      storage: 
  storageClassName: "kfsplugin"
  volumeMode: Filesystem
  volumeName: "新PV的名字"

通过kubectl get pv与kubectl get pvc命令查看pv与pvC的信息，确保新的PVC与PV都为Bound状态。

步骤四：恢复工作负载

将工作负载副本恢复到期望数量：

kubectl scale deployment <deployment-name> --replicas=<期望数量>

在运行正常后可将旧PV删除。