Revendication de volume persistante de Kubernetes indéfiniment en attente

Question

J'ai créé un PersistentVolume provenant de Google Compute Engine persistante disque que j'ai déjà mis en forme et disposition des données. Kubernetes dit le PersistentVolume est disponible.

kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true

Ensuite, j'ai créé un PersistentVolumeClaim pour que je puisse joindre le présent volume à plusieurs gousses sur plusieurs nœuds. Cependant, kubernetes indéfiniment dit qu'il est dans un état d'attente.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0

Des idées? Je pense que cela peut être quelque chose de mal avec le sélecteur...

Est-il même possible de préconfigurer un disque permanent avec les données et les gousses sur plusieurs nœuds tous être en mesure de lire?

Answer 1

J'ai rapidement réalisé que PersistentVolumeClaim définit par défaut le champ storageClassName sur standard lorsqu'il n'est pas spécifié. Cependant, lors de la création d'un volume persistant, storageClassName n'a pas de valeur par défaut, donc le sélecteur ne trouve pas de correspondance.

Ce qui suit a fonctionné pour moi:

 kind: PersistentVolume
apiVersion: v1
metadata:
  name: models-1-0-0
  labels:
    name: models-1-0-0
spec:
  capacity:
    storage: 200Gi
  storageClassName: standard
  accessModes:
    - ReadOnlyMany
  gcePersistentDisk:
    pdName: models-1-0-0
    fsType: ext4
    readOnly: true
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: models-1-0-0-claim
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  selector:
    matchLabels:
      name: models-1-0-0
 

Answer 2

Avec le provisionnement dynamique, vous ne devriez pas avoir à créer des PVs et Pvc séparément. Dans Kubernetes 1.6+, il y a défaut de ravitailleurs pour GKE et quelques autres environnements de cloud, ce qui devrait vous permettre de créer simplement une PVC et avoir automatiquement la disposition d'un PV et un sous-jacent Disque permanent pour vous.

Pour en savoir plus sur le provisionnement dynamique, voir:

https://kubernetes.io/blog/2017/03/dynamic-provisioning-and-storage-classes-kubernetes/

Answer 3

J'ai vu ce comportement dans microk8s 1.14.1 lorsque deux PersistentVolume s ont la même valeur pour spec/hostPath/path , par exemple

 kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-name
  labels:
    type: local
    app: app
spec:
  storageClassName: standard
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/k8s-app-data"
 

Il semble que microk8s soit basé sur des événements (ce qui n'est pas nécessaire sur un cluster à un nœud) et jette des informations sur toutes les opérations ayant échoué, ce qui entraîne des commentaires horribles inutiles pour presque toutes les défaillances.

Answer 4

J'ai connu le même problème dans lequel la PersistentVolumeClaim était dans l'Attente de la Phase indéfiniment, j'ai essayé de fournir le storageClassName "par défaut" dans PersistentVolume comme je l'ai fait pour PersistentVolumeClaim mais il n'a pas de résoudre le problème.

J'ai fait un changement dans ma persistentvolume.yml et déplacé le PersistentVolumeClaim config sur le haut du fichier, puis PersistentVolume que la deuxième config dans le fichier yml. Il a résolu le problème.

Nous devons nous assurer que PersistentVolumeClaim est créé en premier et les PersistentVolume est créé par la suite pour résoudre ce "en Attente" de la phase de problème.

Je suis de poster cette réponse après le tester pendant quelques temps, en espérant que cela pourrait aider quelqu'un aux prises avec elle.

Answer 5

Assurez-vous que votre machine virtuelle dispose également d'assez d'espace disque.