Kubernetes Persistent Volume Anspruch auf unbestimmte Zeit in den Zustand "Ausstehend"

Erstellte ich eine PersistentVolume stammen aus einer Google Compute Engine persistent disk, die ich bereits formatiert und versorgen mit Daten. Kubernetes, sagt der PersistentVolume verfügbar ist.

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

Dann habe ich einen PersistentVolumeClaim so, dass ich anbringen könnte dieses Volumen auf mehrere pods über mehrere Knoten. Jedoch, kubernetes auf unbestimmte Zeit sagt, es ist in einem wartenden Zustand.

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

Irgendwelche Erkenntnisse? Ich finde, dass es etwas falsch mit dem Selektor...

Ist es sogar möglich vorkonfigurieren eine persistente Festplatte mit Daten und Hülsen über mehrere Knoten, die alle Lesen können?

InformationsquelleAutor Akash Krishnan | 2017-07-03

  1. 29

    Merkte ich schnell, dass PersistentVolumeClaim defaults die storageClassName Feld standard wenn nicht angegeben. Jedoch bei der Erstellung eines PersistentVolume, storageClassName keinen Standard, so dass der Selektor keine übereinstimmung findet.

    Folgendes bei mir funktioniert:

    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
    führen Sie kubectl describe pvc zu bestätigen, ob dies der Fehler ist, bekommen Sie "Cannot bind to requested volume "YOUR_PV_NAME": storageClasseName does not match"
    hatte dasselbe Problem. es ist merkwürdig, dass k8 dashboard bleibt ausstehende und nicht den Fehler melden !

    InformationsquelleAutor Akash Krishnan

  2. 11

    Mit dynamic provisioning, Sie sollten nicht zu erstellen, die PVs und PVCs getrennt. In Kubernetes 1.6+ gibt es Standard-provisioners für GKE und einige andere cloud-Umgebungen, die sagen soll, erstellen Sie einfach eine PVC und haben es automatisch die Bereitstellung einer PV-und einer darunter liegenden Beständigen Datenträger für Sie.

    Mehr auf die dynamische Bereitstellung finden Sie unter:

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

    InformationsquelleAutor Anirudh Ramanathan

  3. 0

    Ich Stand vor dem gleichen Problem, in dem die PersistentVolumeClaim war im Pending-Phase auf unbestimmte Zeit, ich habe versucht, die Bereitstellung der storageClassName als 'default' in PersistentVolume genau wie ich für PersistentVolumeClaim aber es hat nicht dieses Problem lösen.

    Machte ich eine Veränderung in meinem persistentvolume.yml und zog die PersistentVolumeClaim config am Anfang der Datei und dann PersistentVolume als die zweite config in der yml-Datei. Es hat behoben das Problem.

    Müssen wir sicherstellen, dass PersistentVolumeClaim wird zunächst erstellt und die PersistentVolume erstellt, danach zum beheben dieses 'Pending' - phase Problem.

    Ich bin dieses posting eine Antwort nach der Prüfung es für ein paar mal, in der Hoffnung, dass es helfen könnte, jemand mit ihm zu kämpfen.

    InformationsquelleAutor Adnan Raza

Schreibe einen Kommentar