Question

根据官方文档https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/和“保留”政策，PV可以手动恢复。这实际意味着什么，是否有工具如何从“保留”PV中读取数据并将其写入另一个PV，或者它是否意味着您可以安装该卷手册以获取访问权限？

Answer 1

有三个回收策略定义删除绑定卷声明后持久卷发生的情况

保留
删除
回收

删除表示删除外部基础架构中的持久卷以及关联的存储资产。

回收将清理卷rm -rf / thevolume / *，之后它将可用于新的持久性卷声明。

保留会在已发布的状态中保留持久卷，但不允许新的持久卷声明回收它。整个回收过程是手动的。您需要自己删除持久卷。您可以备份存储资产中的数据，然后删除数据。然后，您可以删除存储资产或为此资产创建新的永久卷。

如果要使用Kubernetes将数据写入另一个持久卷，可以使用Job复制数据。

在这种情况下，请确保使用持久卷访问模式ROX - ReadOnlyMany或RWX - ReadWriteMany并启动运行容器的作业，该容器声明要使用选择器备份持久卷并声明另一个目标备份卷。然后通过容器复制数据。

或者，您可以在Kubernetes之外进行备份。您的方法取决于您使用的存储资产的类型。例如，如果您使用NFS，则可以安装源和目标，并通过命令行复制数据。

我构建的两个选项都或多或少都是手动备份策略。如果您的目标是为生产工作负载制定更复杂的备份策略，那么您可以查看Stash - Backup for your disks for production workloads in Kubernetes

Answer 2

您可以使用同一PV随数据一起安装到不同的Pod。

验证PV处于释放状态。

 ➜  ~ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                     STORAGECLASS   REASON   AGE
pvc-eae6acda-59c7-11e9-ab12-06151ee9837e   16Gi       RWO            Retain           Released   default/dhanvi-test-pvc   gp2                     52m

编辑PV（kubectl edit pv pvc-eae6acda-59c7-11e9-ab12-06151ee9837e）并删除spec.claimRef部分。 PV声明将无法设置，如下所示。

 ➜  ~ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pvc-eae6acda-59c7-11e9-ab12-06151ee9837e   16Gi       RWO            Retain           Available           gp2                     57m

然后使用以下PVC声明PV。

---

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dhanvi-test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 16Gi
  volumeName: "pvc-eae6acda-59c7-11e9-ab12-06151ee9837e"

可以在如下所示的吊舱中使用。

volumes:
- name: dhanvi-test-pv
  persistentVolumeClaim:
    claimName: dhanvi-test-pvc

Answer 3

就像Tummala Dhanvi的回答中所述，spec.claimRef部分必须解决。如果您只有一个PV，则删除整个spec.claimRef会很有用，但是如果要“挽救”多个PV，这将证明非常讨厌。

第一步是确保在删除之前，PV具有Retain回收策略。您可以编辑或修补PV来实现目标

kubectl edit pv pvc-73e9252b-67ed-4350-bed0-7f27c92ce826
- 找到spec.persistentVolumeReclaimPolicy键
- 输入Retain作为其值
- 保存并退出
或者在一个命令kubectl patch pv pvc-73e9252b-67ed-4350-bed0-7f27c92ce826 -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"

现在您可以删除PVC（通过使用helm或其他方式），并且PV将不会被删除。

要成功将PV重新安装到所需的容器，您必须再次编辑PV配置，这一次是spec.claimRef部分。但不要删除整个部分。而是仅删除resourceVersion和uid键。结果部分看起来像这样

...
  capacity:
    storage: 16Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: database
    namespace: staging
  nodeAffinity:
...

对所有PV重复此操作，之后它们在kubectl get pv输出中的状态将为Available。通过保持spec.claimRef.name和spec.claimRef.namespace键不变，我们确保了具有相应的spec（在我的情况下为staging/database）的新PVC将绑定到它的确切PV应该。

还要确保您的新声明未指定比PV实际更大的存储容量（尽管新声明的容量可能小于现有PV的容量）。如果新的PVC需要更大的存储空间，则会创建新的PV。最好保持不变。

要离题：如果您使用的storageClass可以调整音量大小，则可以稍后调整大小。这里说明了如何：https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/

我的经历非常压力。我有6个PV，完全处于Retain模式。由于某种原因，新的部署部署卡住了，两个Pod只是不想终止。最后，我最终删除了整个部署（使用helm），重新启动了群集节点，然后重新进行了重新部署。这导致创建了6个 new PV！

我找到了该线程，然后继续删除所有PV的spec.claimRef。再次删除和部署安装会导致PV被重用，但是PV并未安装在应有的位置，因此数据不在那。经过大量的挖掘，我发现database卷已安装到RabbitMQ吊舱，mongodb已安装到ElasticSearch等。

我花了大约十二次才弄明白这一点。幸运的是，对我来说，卷的混合安装并没有破坏任何原始数据。 Pod初始化并没有清除卷，只是在其中写了东西。

希望这可以节省一些严重的头痛！

Answer 4

我发现这个问题的原因与现有答案地址略有不同，所以我会权衡一下。

就我而言，我有一个自我管理的 Microk8s 集群，用于开发和测试目的 手动、本地存储（安装在其中一个节点上的路径），如下所示：

apiVersion: v1
kind: PersistentVolume
metadata:
    name: pv-1
    labels:
        type: local
spec:
    storageClassName: manual
    capacity:
        storage: 50Gi
    accessModes:
        - ReadWriteOnce
    hostPath:
        path: "/mnt/data-1"

还有一个 PVC 和一个使用这个 PV 的部署。然后我对这些资源偶然存在的命名空间进行了核爆。

我想要实现的是重新创建整个命名空间，并让它使用这个 PersistentVolume 和服务器上仍然存在的相同数据。

就我的本地手动存储而言，只需删除 PV 并重新创建即可。删除 PV 不会删除服务器上的实际数据（至少在 Retain 策略下）。使用挂载将 PV 重新创建到数据已经存在的路径中也可以正常工作 - 仅使用数据。

如何手动恢复PV

4 个答案: