Kubernetes PV отказывается связываться после удаления / воссоздания - PullRequest
0 голосов
/ 30 сентября 2019

С учетом следующих ПВХ и ПВ:

  • ПВХ:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: packages-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  volumeName: packages-volume
  • ПВ:
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 pending). Почему?

1 Ответ

1 голос
/ 09 октября 2019

Обратите внимание, что после удаления PVC, PV остается в состоянии Released:

$ 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.

Почему это не Available?

Если вы отображаете текущее yaml определение PV, что вы можете легко сделать, выполнив:

kubectl get pv packages-volume -o yaml

вы можете заметить, что в разделе claimRef он содержит uid недавно удаленных PersistentVolumeClaim:

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

Вы можете легко проверить это, выполнив:

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

непосредственно перед тем, как удалить PVC и сравнить его с тем, что содержит определение PV. Вы увидите, что это точно такой же uid, на который все еще ссылается ваш PV после удаления PVC. Эта оставшаяся ссылка является действительной причиной того, что PV остается в состоянии Released.

Почему вновь созданный PVC остается в состоянии Pending?

Хотя ваш недавно созданный PVC может показаться вам точно таким же PVC, который вы только что удалили, когда вы создаете его, используя тот же файл yaml, с точки зрения Kubernetes это совершенно новый экземплярPersistentVolumeClaim объект, который имеет совершенно другой uid. По этой причине он остается в состоянии Pending и не может связываться с PV.

Решение:

Для создания PV Available снова вам просто нужно удалить упомянутую ссылку uid, например, с помощью:

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

или, альтернативно, путем удаления всего раздела claimRef, что можно сделать следующим образом:

kubectl patch pv packages-volume --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...