Question

TL; DR。我在删除PVC后失去了如何访问数据，以及删除PVC后PV不会消失的原因。

我采取的步骤：

手动在GCE中创建了一个磁盘：

gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b

RAN：

kubectl apply -f /tmp/pv-and-pvc.yaml

使用以下配置：

# /tmp/pv-and-pvc.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-for-rabbitmq
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 5Gi
  gcePersistentDisk:
    fsType: ext4
    pdName: disk-for-rabbitmq
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-for-rabbitmq
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
  volumeName: pv-for-rabbitmq

手动删除了一个PVC（在高级别：我在这里模拟灾难性场景，如意外删除或helm版本配置错误）：
```
kubectl delete pvc pvc-for-rabbitmq
```

此时我看到以下内容：

$ kubectl get pv
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                      STORAGECLASS   REASON   AGE
pv-for-rabbitmq   5Gi        RWO            Delete           Released   staging/pvc-for-rabbitmq   standard                8m
$

一个附带问题，只是提高我的理解：为什么PV仍然存在，即使它的回收政策设置为Delete？这不是{{} 3}}对Delete回收政策说什么？

现在，如果我尝试重新创建PVC以重新获得对PV中数据的访问权限：

$ kubectl apply -f /tmp/pv-and-pvc.yaml
persistentvolume "pv-for-rabbitmq" configured
persistentvolumeclaim "pvc-for-rabbitmq" created
$

我仍为pv提供此信息，例如PV陷入Released状态：

$
kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                             STORAGECLASS   REASON    AGE
pv-for-rabbitmq                            5Gi        RWO            Delete           Released   staging/pvc-for-rabbitmq          standard                 15m
$

...我为pvc s得到了这个：

$
kubectl get pvc
NAME               STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-for-rabbitmq   Pending   pv-for-rabbitmq   0                         standard       1m
$

看起来我的PV处于Released状态，并且PVC无法访问不属于Available状态的PV。

那么，为什么同样的PV和PVC再也不能成为朋友呢？ 如何让PVC重新获得对现有PV中数据的访问权限？

Answer 1

这句话说，Pods消耗节点资源而PVC消耗光伏资源可能有助于充分理解PV和PVC之间的理论和友谊。

我尝试使用提供的YAML文件完整再现所记录的行为并失败，并返回了预期的结果。因此，在提供任何进一步的细节之前，这里是我的再现的演练。

步骤1：在Europe-west1区域创建PD

sunny@dev-lab:~$ gcloud compute disks create --size 5Gi disk-for-rabbitmq --zone europe-west1-b

WARNING: You have selected a disk size of under [200GB]. This may result in poor I/O 
performance. For more information, see: 

NAME               ZONE            SIZE_GB  TYPE         STATUS
disk-for-rabbitmq  europe-west1-b  5        pd-standard  READY

步骤2：使用项目YAML文件

创建PV和PVC

sunny@dev-lab:~$  kubectl apply -f pv-and-pvc.yaml

persistentvolume "pv-for-rabbitmq" created
persistentvolumeclaim "pvc-for-rabbitmq" created

第3步：列出所有可用的PVC

sunny@dev-lab:~$ kubectl get pvc
NAME               STATUS    VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-for-rabbitmq   Bound     pv-for-rabbitmq   5Gi        RWO            standard       16s

第4步：列出所有可用的PV

sunny@dev-lab:~$ kubectl get pv
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                      STORAGECLASS   REASON    AGE
pv-for-rabbitmq   5Gi        RWO            Delete           Bound     default/pvc-for-rabbitmq   standard                 28s

步骤5：删除PVC并验证结果

sunny@dev-lab:~$  kubectl delete pvc pvc-for-rabbitmq
persistentvolumeclaim "pvc-for-rabbitmq" deleted

sunny@dev-lab:~$  kubectl get pv

找不到资源。

sunny@dev-lab:~$  kubectl get pvc

找不到资源。

sunny@dev-lab:~$  kubectl describe pvc-for-rabbitmq

服务器没有资源类型“pvc-for-rabbitmq”

根据您的问题

一个附带问题，只是提高我的理解：为什么PV仍然存在，即使它有回收政策设置为删除？这不是docs说删除回收政策？

您完全正确，根据文档，当用户完成其卷时，他们可以从API中删除允许回收资源的PVC对象。 PersistentVolume 的回收政策告诉群集在声明发布后如何处理该卷。在你的YAML中它被设置为：

Reclaim Policy:  Delete

表示应该立即删除它。目前，交易量可以保留，回收或已删除。

为什么不删除它？我唯一能想到的，就是PV可能还在某种程度上声称，这很可能是因为PVC未能成功删除其容量显示“0”并修复此问题，您需要删除POD。或者，您可以使用$ kubectl describe pvc命令查看PVC仍处于暂挂状态的原因。

对于这个问题，如何让PVC重新获得现有PV中的数据？

这是不可能的，因为回收政策的状态，即Reclaim Policy: Delete使这成为可能，您需要使用保留选项，而不是documentation

要验证您可以删除PVC并保留磁盘的理论，请执行以下操作：

将回收政策更改为保留
删除PVC
删除PV

然后验证磁盘是否保留。

Answer 2

kubectl patch pv pv-for-rabbitmq -p '{"spec":{"claimRef": null}}'

这对我有用。

Answer 3

你正在经历一种典型的错误观念，认为PV和PVC与它们相关性更高。

持续音量：在K8s中，此资源有很多选项。例如，hostPath将从运行pod的节点保留指定的大小，并将其映射到两者上的所需路径;你的吊舱和你的节点。

永久性卷声明：PVC（特别是在GKE上）将在Google Cloud Platform上创建物理永久磁盘，并将其作为辅助磁盘附加到运行该pod的节点。因此，声明更具体是云提供商。

注意：您不需要手动创建磁盘。只需创建声明，并检查发生了什么。您将不得不给它一些时间，但最终状态应为BOUND，这意味着永久磁盘已创建，附加并可供使用。

如果您执行df -h，它将显示为附加设备，并且它也会显示为kubectl get pv，因为它最终是一个持久性卷

关于删除内容。删除PV或PVC时，没有任何反应。您仍然可以进入pod并转到已映射的路径。没问题。由于它没有被删除，因此pod仍然可以访问它。现在，如果您的pod已关闭并重新创建，如果没有PV或PVC，您将收到错误。

Answer 4

官方文档有答案，希望可以帮助其他人寻找相同的内容（https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes）

保留保留回收策略允许手动回收资源。删除PersistentVolumeClaim后，PersistentVolume仍然存在，并且该卷被视为“已释放”。但是该数据尚无法用于其他索赔，因为前一个索赔人的数据仍保留在该卷上。管理员可以按照以下步骤手动回收该卷。

删除PersistentVolume。中的相关存储资产外部基础架构（例如AWS EBS，GCE PD，Azure Disk或删除PV后，煤渣体积仍然存在。
手动清理关联存储资产上的数据相应地。
手动删除关联的存储资产，或者如果要删除重复使用相同的存储资产，并创建一个新的PersistentVolume 存储资产定义。

Answer 5

Bharat 的回答也对我有用。

如果您的 PV 显示为“已发布”并且您已经通过 helm 卸载或其他方法删除了 PVC，则除非您删除声明引用，否则您无法再次使用此 PV：

kubectl patch pv PV_NAME -p '{"spec":{"claimRef": null}}'

请记住，您不能这样做，除非在 PV 绑定时，您必须首先删除 PVC，以便 PV 显示“已发布”，然后您可以运行此命令。 PV 的状态随后应显示为“可用”并且可以重复使用。

Answer 6

我编写了一个简单的自动 PV 释放器控制器，它会为新的 PVC 再次查找并制作 Released PV Available，请在此处查看 https://github.com/plumber-cd/kubernetes-dynamic-reclaimable-pvc-controllers。

但请务必阅读免责声明并确保这正是您想要的。出于某种原因，Kubernetes 不会自动执行此操作 - 工作负载不应访问来自其他工作负载的数据。因为当他们这样做时 - Kubernetes 惯用的方式是 StatefulSets，因此 Kubernetes 保证只有相同工作负载的副本才能声明旧数据。我的发布者在某些情况下肯定会很有用，比如 CI/CD 构建缓存（它是为它创建的） - 但通常 PVC 意味着“给我一个干净的准备使用的存储，我可以保存一些数据”，所以至少- 使其成为一个单独的 StorageClass。

如何处理已发布的持续卷？

6 个答案: