web-dev-qa-db-de.com

Beharrlicher Volumenanspruch von Kubernetes auf unbestimmte Zeit im ausstehenden Zustand

Ich habe ein PersistentVolume aus einer persistenten Festplatte von Google Compute Engine erstellt, die ich bereits formatiert und mit Daten versehen habe. Laut Kubernetes ist das PersistentVolume verfügbar.

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

Anschließend habe ich PersistentVolumeClaim erstellt, damit ich dieses Volume an mehrere Pods über mehrere Knoten hinweg anhängen kann. Kubernetes sagt jedoch auf unbestimmte Zeit, dass es sich in einem ausstehenden Zustand befindet.

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 Einsichten? Ich habe das Gefühl, dass mit dem Selektor etwas nicht stimmt ...

Ist es überhaupt möglich, eine persistente Festplatte mit Daten vorzukonfigurieren und Pods über mehrere Knoten hinweg auszulesen?

28
Akash Krishnan

Mir wurde schnell klar, dass PersistentVolumeClaim das Feld storageClassName standardmäßig auf standard setzt, wenn nichts angegeben ist. Wenn Sie jedoch ein PersistentVolume erstellen, hat storageClassName keine Standardeinstellung, sodass der Selektor keine Übereinstimmung findet.

Folgendes hat für mich 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
40
Akash Krishnan

Bei der dynamischen Bereitstellung sollten Sie PVs und PVCs nicht separat erstellen müssen. In Kubernetes 1.6+ gibt es Standard-Provisioner für GKE und einige andere Cloud-Umgebungen, mit denen Sie einfach eine PVC erstellen und automatisch eine PV und eine zugrunde liegende persistente Festplatte für Sie bereitstellen können.

Weitere Informationen zur dynamischen Bereitstellung finden Sie unter:

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

12

Stellen Sie sicher, dass Ihr VM auch über genügend Speicherplatz verfügt.

0
William Loch

Ich hatte das gleiche Problem, bei dem der PersistentVolumeClaim auf unbestimmte Zeit in der Pending-Phase war. Ich habe versucht, den storageClassName in PersistentVolume als 'Standard' anzugeben, genau wie bei PersistentVolumeClaim, aber dieses Problem wurde nicht behoben.

Ich habe eine Änderung in meiner persistentvolume.yml vorgenommen und die PersistentVolumeClaim-Konfiguration über die Datei und dann PersistentVolume als zweite Konfiguration in der yml-Datei verschoben. Es hat dieses Problem behoben.

Wir müssen sicherstellen, dass zuerst PersistentVolumeClaim und anschließend PersistentVolume erstellt wird, um dieses Problem der ausstehenden Phase zu beheben.

Ich poste diese Antwort, nachdem ich sie einige Male getestet habe, in der Hoffnung, dass sie jemandem helfen könnte, der damit zu kämpfen hat.

0
Adnan Raza

Ich habe dieses Verhalten in microk8s 1.14.1 gesehen, wenn zwei PersistentVolumes den gleichen Wert für spec/hostPath/path Haben, z.

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"

Es scheint, dass microk8s ereignisbasiert ist (was bei einem Cluster mit einem Knoten nicht erforderlich ist) und Informationen zu fehlgeschlagenen Vorgängen wegwirft, was zu unnötigem, fürchterlichem Feedback bei fast allen Fehlern führt.

0
Karl Richter