手动恢复卷的过程如下。
即使在PVC被删除后，您也可以使用同一个PV随数据一起挂载到不同的pod（PV必须存在，如果storageclass的回收策略为Retain，则通常会存在）
验证PV是否处于释放状态。（即目前没有PVC声称）

➜  ~ 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-volume
  persistentVolumeClaim:
    claimName: dhanvi-test-pvc

型
更新：卷克隆可能有助于https://kubernetes.io/blog/2019/06/21/introducing-volume-cloning-alpha-for-kubernetes/

有三种回收策略定义了在删除绑定卷声明后持久卷的情况

• 保留
• 删除
• 再循环
  删除表示永久卷以及外部基础架构中关联的存储资产被删除。
  回收（已弃用）将清理卷rm -rf /thevolume/*，之后将可用于新的持久卷声明。
  Retain将永久卷保留为已释放状态，不允许新的永久卷声明来回收它。整个回收过程是手动的。您需要自己删除永久卷。您可以备份存储资产中的数据，然后删除数据。然后，您可以删除存储资产或为此资产创建新的持久卷。

如果你想使用Kubernetes将数据写入另一个持久化卷，你可以使用Job来复制数据。
在这种情况下，请确保使用持久卷访问模式ROX - ReadOnlyMany或RWX - ReadWriteMany，并启动运行容器的作业，该容器使用选择器声明要备份的持久卷，并声明另一个目标备份卷。然后通过容器复制数据。
或者，您可以在Kubernetes之外进行备份。您的方法取决于您使用的存储资产的类型。例如，如果您使用NFS，则可以通过命令行装载源和目标并复制数据。
这两个选项我已经框或多或少手动备份策略。如果您的目标是为生产工作负载制定更复杂的备份策略，则可以考虑Stash - Backup for your disks for production workloads in Kubernetes

就像Tummala Dhanvi在回答中所说的那样，必须处理spec.claimRef部分。如果你只有一个PV，那么删除整个spec.claimRef是有用的，如果你有多个PV需要“拯救”，那么这将证明非常讨厌。
第一步是确保PV具有Retain回收策略**，然后再删除**PVC。您可以编辑或修补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重新安装到所需pod，必须再次编辑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，thakfully在Retain模式。由于某种原因，一个新的部署部署被卡住了，两个吊舱只是不想终止。最后，我删除了整个部署（使用helm），重新启动集群节点，然后重新部署。这导致创建6 * 新 * PV！
我找到了这个线程，然后继续删除所有PV的spec.claimRef。再次删除和部署安装会导致PV被重用，但它们没有安装到它们应该安装的位置，数据也不在那里。经过大量的挖掘，我发现database卷被挂载到RabbitMQ pod，mongodb被挂载到ElasticSearch等。
我花了十几次时间才把这个弄对。幸运的是，对我来说，混乱的卷装载并没有破坏任何原始数据。pod初始化并没有清除卷，只是在那里写了它们的东西。
希望这能节省一些严重的头痛在那里！

我发现这个问题的原因与现有的答案略有不同，所以我会权衡一下。
在我的例子中，我有一个自我管理的Microk 8 s集群，用于开发和测试目的，带有手动本地存储（其中一个节点上的挂载路径），如下所示：

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

字符串
还使用该PV进行了PVC和展开。然后我无意中删除了这些资源所在的名称空间。
我想要实现的是重新创建整个名称空间，并让它使用这个PersistentVolume，其中包含仍然存在于服务器上的相同数据。

在我的本地手动存储情况下只需删除PV并重新创建即可。删除PV不会删除服务器上的实际数据（至少对于Retain策略是这样）。在数据已经存在的路径中重新创建一个挂载PV也可以正常工作-数据只是被使用。