web-dev-qa-db-fra.com

Revendication de volume persistant de Kubernetes indéfiniment dans un état en attente

J'ai créé un PersistentVolume provenant d'un disque persistant de Google Compute Engine que j'ai déjà formaté et doté de données. Kubernetes dit que le volume persistant 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

J'ai ensuite créé une PersistentVolumeClaim afin de pouvoir attacher ce volume à plusieurs pods situés sur plusieurs nœuds. Cependant, kubernetes dit indéfiniment qu'il est en 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 sens qu'il y a peut-être un problème avec le sélecteur ...

Est-il même possible de préconfigurer un disque persistant avec des données et de pouvoir lire les pods sur plusieurs nœuds?

kubernetespersistent-volumespersistent-volume-claims
28
Akash Krishnan

J'ai vite compris que PersistentVolumeClaim utilisait le champ storageClassName sur standard lorsqu'il n'était pas spécifié. Cependant, lors de la création d'un volume persistant, storageClassName n'a pas de valeur par défaut et 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
40
Akash Krishnan

Avec le provisionnement dynamique, vous ne devriez pas avoir à créer des PV et des PVC séparément. Dans Kubernetes 1.6+, il existe des fournisseurs par défaut pour GKE et certains autres environnements de cloud, qui devraient vous permettre de créer un PVC et de le doter automatiquement d'un PV et d'un disque persistant sous-jacent.

Pour plus d'informations sur le provisionnement dynamique, voir:

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

12
Anirudh Ramanathan

Assurez-vous que votre VM dispose également d’un espace disque suffisant.

0
William Loch

J'ai rencontré le même problème que dans lequel PersistentVolumeClaim était indéfiniment dans la phase en attente. J'ai essayé de fournir storageClassName comme valeur par défaut dans PersistentVolume, comme je l'avais fait pour PersistentVolumeClaim, mais le problème n'a pas été résolu.

J'ai apporté une modification à mon fichier persistentvolume.yml et j'ai déplacé la configuration PersistentVolumeClaim au-dessus du fichier, puis PersistentVolume en tant que deuxième configuration du fichier yml. Il a résolu ce problème.

Nous devons nous assurer que PersistentVolumeClaim est créé en premier et ensuite PersistentVolume est créé pour résoudre ce problème de phase 'En attente'.

Je publie cette réponse après l'avoir testée plusieurs fois, dans l'espoir que cela puisse aider quelqu'un qui en souffre.

0
Adnan Raza

J'ai vu ce comportement dans microk8s 1.14.1 lorsque deux PersistentVolumes 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 seul nœud) et jette des informations sur les opérations en échec, ce qui entraîne des retours inutiles et horribles pour la quasi-totalité des échecs.

0
Karl Richter