john

      在云套件部署的 Kubernetes 集群中，经常会碰到项目上为了方便将 NFS 持久化存储直接部署在节点上，一旦节点被回收或调整，这就会导致 PV 挂载失效，进而使依赖该存储的云套件服务异常。以往遇到这个情况的处理办法：（云套件）备份→ （持久化数据）备份/还原→新建云套件站点→（云套件）还原。其实还可以通过直接修改 PV 的方式来做，虽然操作偏多点，但不用重建整个站点。主要流程：停服务→拷数据→改PV→恢复。

一、停止云套件服务

      再停止服务之前，建议先执行云套件的备份功进行云套件备份。
      导出 deployment / statefulset 资源

# 导出云套件命名空间(icloud-native-31)的deployment资源状态，方便后续恢复的时候进行调整
kubectl get deployment -n icloud-native-31 > giscloud-deployment-status.txt
# 导出 icloud-native-31 statefulset，方便后续恢复的时候进行调整
kubectl get statefulset -n icloud-native-31 > giscloud-statefulset-status.txt

      将 deployment / statefulset 资源副本数置0

# 将云套件命名空间(icloud-native-31)的deployment 资源的副本伸缩成0
kubectl get deployment -n icloud-native-31 | awk 'NR>1{print $1}' | xargs kubectl scale deployment -n icloud-native-31 --replicas=0
# 将云套件命名空间(icloud-native-31)的statefulset 资源的副本伸缩成0 
kubectl get statefulset -n icloud-native-31 | awk 'NR>1{print $1}' | xargs kubectl scale statefulset -n icloud-native-31 --replicas=0

二、数据拷贝

新nfs服务器创建旧nfs挂载目录，并将旧nfs mount到该目录上

# nfs文件拷贝：原nfs共享mount目录：/data/nfs_data/117，新nfs共享目录：/data/nfs_data/iMananger_v1210_117
cp -rf /data/nfs_data/117/* /data/nfs_data/iMananger_v1210_117/
# 若只是对云套件的持久化数据进行迁移，本地云套件的命名空间是“icloud-native-31”，故需要拷贝nfs中icloud-native-31开头的目录
cp -rf /data/nfs_data/117/icloud-native-31-* /data/nfs_data/iMananger_v1210_117/

      拷贝之后，可以对nfs持久化数据一个777 的权限，防止数据读取不到或者写入不进去

三、云套件 pv 和 pvc 文件导出

      导出云套件的pv和pvc yaml文件主要是用于备份，任何操作前建议都需要进行备份。

3.1 导出pvc

# 云套件命名空间：icloud-native-31，存储类名称：appset-storage-class-gisappset
kubectl get pvc -n icloud-native-31 | grep appset-storage-class-gisappset | awk '{print $1}' | xargs  kubectl get pvc -n icloud-native-31 -o yaml > giscloud-pvc.yaml

3.2 导出pv

# 云套件命名空间：icloud-native-31，存储类名称：appset-storage-class-gisappset
kubectl get pv | grep appset-storage-class-gisappset | awk '{print $1}' | xargs  kubectl get pv -o yaml > giscloud-pv.yaml

四、修改 pv 内容

      对于不熟悉k8s人员，建议一个一个的对pv进行修改和删除操作，不建议进行批量操作，若遇到问题，进行处理时就容易慌神，且任何操作修改删除操作前均要进行备份操作

4.1 单个pv处理

4.1.1 导出pv

# 导出名为“pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c“的pv编排
kubectl get pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml >  pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml

4.1.2 删除 pv

kubectl delete -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml
# 如果删不到，可能就是pvc绑定的缘故，需要先清除 claimRef 解除绑定关系，在进行删除
kubectl patch pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -p '{"spec":{"claimRef":null}}'

4.1.3 修改pv

      修改前：

      修改后：

4.1.4 运行 pv

# 运行修改后的pv
kubectl apply -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml

4.15 查看pv状态

# 查看pv情况
kubectl get pv | grep  pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c
# 查看pv内容按照yaml格式输出
kubectl get pv  pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml

4.2 批量pv处理

      对于不熟悉的k8s操作人员，建议一个一个pv的进行处理，这样更加安全

4.2.1 批量解除 pv 与 pvc 绑定关系

      批量解除之前建议先对进行留痕，然后在进行清除pv 和 pvc的绑定。

# 将存储类名为“ appset-storage-class-gisappset ”的pv名称进行备份
kubectl get pv | grep appset-storage-class-gisappset | awk '{print $1}' > pv-namse.txt
# 清除存储类名为“ appset-storage-class-gisappset ”的pv与pvc 的绑定
kubectl get pv | grep appset-storage-class-gisappset | awk '{print $1}' | xargs kubectl patch pv -p '{"spec":{"claimRef":null}}' 

      解除绑定前：

      解除绑定后：

4.2.2 批量删除pv

kubectl delete -f giscloud-pvc.yaml
# 如果一直删不掉可以对处于删除状态的pv进行清除 claimRef 解除绑定关系
kubectl get pv | grep Terminating | awk '{print $1}' | xargs kubectl patch pv -p '{"spec":{"claimRef":null}}'

4.2.3 修改giscloud-pv.yaml文件

      giscloud-pv.yaml文件就是步骤导出pv的yaml文件内容，直接使用通过编辑工具进行批量修改nfs的server 和path

4.2.4 apply giscloud-pv.yaml

kubectl apply -f giscloud-pv.yaml

五、云套件服务恢复

5.1 恢复deploy资源的副本数

      根据第一步导出giscloud-deployment-status.txt进行修改指令

# x 为副本数，支持写入多个deployment
kubectl scale deployment 【deployment名称】 -n icloud-native-31 --replicas=【x】

5.2 恢复statefulset资源的副本数

根据第一步导出giscloud-statefulset-status.txt进行修改指令

# x 为副本数，支持写入多个statefulset
kubectl scale statefulset 【statefulset名称】 -n icloud-native-31 --replicas=【x】

# keycloak 和 keycloak-database 副本数均为1，合并示例如下：
kubectl scale statefulset -n icloud-native-31 --replicas=1 cloudsuite-keycloak cloudsuite-keycloak-database

六、可能遇到的问题

6.1 keycloak-database起不来，日志报错如下截图：

【问题原因】

PostgreSQL 出于安全考虑，要求数据目录必须由运行数据库的用户（Bitnami 镜像中默认是 UID/GID 1001 的 postgres 用户）拥有。如果目录属于 root 或其他用户，启动时会报此错。

【解决办法】

给keycloak-database持久化目录下的data目录的拥有者改为1001

# 需要进入到 keycloak-database的持久化目录中执行下面的操作
chown -R 1001:1001 data