web-dev-qa-db-fra.com

Kubernetes: impossible de supprimer PersistentVolumeClaim (pvc)

J'ai créé le volume persistant suivant en appelant

kubectl create -f nameOfTheFileContainingTheFollowingContent.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-monitoring-static-content
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/some/path"

---

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-monitoring-static-content-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 100Mi

Après cela, j'ai essayé de supprimer le pvc. Mais cette commande est bloquée . En appelant kubectl describe pvc pv-monitoring-static-content-claim, le résultat suivant est obtenu. 

Name:          pv-monitoring-static-content-claim
Namespace:     default
StorageClass:
Status:        Terminating (lasts 5m)
Volume:        pv-monitoring-static-content
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed=yes
               pv.kubernetes.io/bound-by-controller=yes
Finalizers:    [foregroundDeletion]
Capacity:      100Mi
Access Modes:  RWO
Events:        <none>

Et pour kubectl describe pv pv-monitoring-static-content

Name:            pv-monitoring-static-content
Labels:          <none>
Annotations:     pv.kubernetes.io/bound-by-controller=yes
Finalizers:      [kubernetes.io/pv-protection foregroundDeletion]
StorageClass:
Status:          Terminating (lasts 16m)
Claim:           default/pv-monitoring-static-content-claim
Reclaim Policy:  Retain
Access Modes:    RWO
Capacity:        100Mi
Node Affinity:   <none>
Message:
Source:
    Type:          HostPath (bare Host directory volume)
    Path:          /some/path
    HostPathType:
Events:            <none>

Aucun pod en cours d'exécution n'utilise le volume persistant. Quelqu'un pourrait-il me dire pourquoi le pvc et le pv ne sont pas supprimés?

kubernetespersistent-volumespersistent-volume-claims
9
Yannic Klem

Je ne sais pas pourquoi cela est arrivé, mais après avoir supprimé les finaliseurs du pv et du pvc via le tableau de bord de Kubernetes, les deux ont été supprimés . un bug.

9
Yannic Klem

Si PV existe toujours, il est possible que ReclaimPolicy soit défini sur Conserver, auquel cas il ne sera pas supprimé même si le PVC est parti. De la docs:

PersistentVolumes peut avoir diverses stratégies de récupération, notamment “Conserver”, “Recycler” et “Supprimer”. Pour provisionné dynamiquement PersistentVolumes, la politique de récupération par défaut est «Supprimer». Ça signifie qu'un volume provisionné dynamiquement est automatiquement supprimé lorsqu’un fichier l'utilisateur supprime le PersistentVolumeClaim correspondant. Cette automatique Ce comportement peut être inapproprié si le volume contient des données précieuses. Dans ce cas, il est plus approprié d’utiliser la stratégie «Conserver». Avec la stratégie «Conserver», si un utilisateur supprime un PersistentVolumeClaim, le le volume persistant correspondant ne doit pas être supprimé. Au lieu de cela, il est déplacé à la phase relâchée, où toutes ses données peuvent être récupérées manuellement

2
Anna Slastnikova

Le PV est protégé. Supprimez le PV avant de supprimer le PVC. Supprimez également les pods/déploiements revendiquant l'un des PVC référencés. Pour plus d'informations, consultez Protection des objets de stockage utilisés

1
georgekuruvillak

Je viens de rencontrer ce problème il y a quelques heures.

J'ai supprimé les déploiements utilisant cette référence et les PV/PVC sont automatiquement terminés.

0
akai