Kubernetes PV删除/重新创建后拒绝绑定 [英] Kubernetes PV refuses to bind after delete/re-create

问题描述

给出以下PVC和PV:

Given the following PVC and PV:

• PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: packages-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  volumeName: packages-volume

• PV:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: packages-volume
  namespace: test
spec:
  claimRef:
    name: packages-pvc
    namespace: test
  accessModes:
    - ReadWriteMany
  nfs:
    path: {{NFS_PATH}}
    server: {{NFS_SERVER}}
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain

如果我创建PV，然后创建PVC，则它们会绑定在一起.但是，如果删除PVC，然后重新创建，则它们不会绑定(pvc待处理).为什么?

if I create the PV, then the PVC, they bind together. However if I delete the PVC then re-create it, they do not bind (pvc pending). Why?

推荐答案

请注意，删除PVC后，PV仍保持Released状态:

Note that after deleting PVC, PV remains in Released status:

$ kubectl get pv packages-volume
NAME              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                  STORAGECLASS   REASON   AGE
packages-volume   1007Gi     RWX            Retain           Released   default/packages-pvc                           10m

它的状态应该为Available，以便可以由另一个PersistentVolumeClaim实例重用.

It should have status Available so it can be reused by another PersistentVolumeClaim instance.

为什么不是Available?

Why it isn't Available ?

如果显示PV的当前yaml定义，则可以通过执行以下操作轻松地完成此操作:

If you display current yaml definition of the PV, which you can easily do by executing:

kubectl get pv packages-volume -o yaml

您可能会注意到，在claimRef部分中，它包含了最近删除的PersistentVolumeClaim的uid:

you may notice that in claimRef section it contains the uid of the recently deleted PersistentVolumeClaim:

  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: packages-pvc
    namespace: default
    resourceVersion: "10218121"
    uid: 1aede3e6-eaa1-11e9-a594-42010a9c0005

您可以通过发出以下命令轻松进行验证:

You can easily verify it by issuing:

kubectl get pvc packages-pvc -o yaml | grep uid

就在删除PVC并将其与PV定义所包含的内容进行比较之前.您会看到，与uid完全相同，该uid在删除PVC之后仍由您的PV引用.剩下的引用是PV保持Released状态的实际原因.

just before you delete your PVC and compare it with what PV definition contains. You'll see that this is exactly the same uid that is still referred by your PV after PVC is deleted. This remaining reference is the actual reason that PV remains in Released status.

为什么新创建的PVC保持为Pending状态?

Why newly created PVC remains in a Pending state ?

尽管您新创建的PVC在您看来似乎与使用相同的yaml文件创建它时刚刚删除的PVC完全相同，但从Kubernetes的角度来看，这是一个具有完全不同的uid的PersistentVolumeClaim对象的全新实例.这就是为什么它保持Pending状态并且无法绑定到PV的原因.

Although your newly created PVC may seem to you exactly the same PVC that you've just deleted as you're creating it using the very same yaml file, from the perspective of Kubernetes it's a completely new instance of PersistentVolumeClaim object which has completely different uid. This is the reason why it remains in Pending status and is unable to bind to the PV.

解决方案:

要再次制作PV Available，您只需删除提及的uid参考，例如通过发出:

To make the PV Available again you just need to remove the mentioned uid reference e.g. by issuing:

kubectl patch pv packages-volume --type json -p '[{"op": "remove", "path": "/spec/claimRef/uid"}]'

或通过删除整个claimRef部分来完成此操作，如下所示:

or alternatively by removing the whole claimRef section which can be done as follows:

kubectl patch pv packages-volume --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

这篇关于Kubernetes PV删除/重新创建后拒绝绑定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！