for - Kubernetes reclamo de volumen persistente indefinidamente en estado pendiente

no persistent volumes available for this claim and no storage class is set

Question

Creé un PersistentVolume procedente de un disco persistente de Google Compute Engine que ya había formateado y aprovisioné con datos. Kubernetes dice que el 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

Luego creé un PersistentVolumeClaim para poder adjuntar este volumen a múltiples pods a través de múltiples nodos. Sin embargo, kubernetes dice indefinidamente que está en un estado pendiente.

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

¿Alguna idea? Siento que puede haber algo mal con el selector ...

¿Es incluso posible preconfigurar un disco persistente con datos y tener pods a través de múltiples nodos que todos puedan leer desde él?

Answer 1

Con el aprovisionamiento dinámico, no debería tener que crear PV y PVC por separado. En Kubernetes 1.6+, hay aprovisionadores predeterminados para GKE y algunos otros entornos de nube, que deberían permitirle crear un PVC y aprovisionar automáticamente un PV y un Disco persistente subyacente para usted.

Para más información sobre el aprovisionamiento dinámico, consulte:

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

Answer 2

Enfrenté el mismo problema en el que PersistentVolumeClaim se encontraba en la fase pendiente de forma indefinida. Intenté proporcionar el storageClassName como "predeterminado" en PersistentVolume, tal como lo hice para PersistentVolumeClaim, pero no solucionó este problema.

Hice un cambio en mi persistentvolume.yml y moví la configuración PersistentVolumeClaim en la parte superior del archivo y luego PersistentVolume como la segunda configuración en el archivo yml. Se ha solucionado ese problema.

Debemos asegurarnos de que primero se crea PersistentVolumeClaim y luego se crea el PersistentVolume para resolver este problema de fase "Pendiente".

Estoy publicando esta respuesta después de probarla varias veces, con la esperanza de que pueda ayudar a alguien que está luchando con ella.

Answer 3

Rápidamente me di cuenta de que PersistentVolumeClaim establece por defecto el campo storageClassName como standard cuando no está especificado. Sin embargo, al crear un PersistentVolume, storageClassName no tiene un valor predeterminado, por lo que el selector no encuentra una coincidencia.

Lo siguiente me funcionó:

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