Regionalen nichtflüchtigen Speicher bereitstellen

Auf dieser Seite wird erläutert, wie Sie die dynamische Bereitstellung regionaler nichtflüchtiger Speicher aktivieren und diese manuell in Google Kubernetes Engine (GKE) bereitstellen.

Informationen zum Erstellen von End-to-End-Lösungen für Hochverfügbarkeitsanwendungen mit regionalen nichtflüchtigen Speichern finden Sie unter Verfügbarkeit zustandsorientierter Anwendungen mit zustandsorientiertem HA-Operator erhöhen.

Regionale nichtflüchtige Speicher

Ebenso wie zonaler nichtflüchtiger Speicher kann auch regionaler nichtflüchtiger Speicher dynamisch nach Bedarf oder vorab manuell vom Clusteradministrator bereitgestellt werden, obwohl die dynamische Bereitstellung empfohlen wird.

Dynamische Bereitstellung

Um die dynamische Bereitstellung regionaler nichtflüchtiger Speicher zu aktivieren, erstellen Sie eine StorageClass mit dem Parameter replication-type und geben Sie Zoneneinschränkungen in allowedTopologies an.

Das folgende Manifest beschreibt beispielsweise eine StorageClass namens regionalpd-storageclass, die nichtflüchtige Standardspeicher verwendet und Daten in die Zonen europe-west1-b und europe-west1-c repliziert:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Bei Verwendung eines regionalen Clusters können Sie allowedTopologies nicht angeben. In diesem Fall wird beim Erstellen eines Pods, der einen PersistentVolumeClaim verwendet, welcher diese StorageClass nutzt, ein regionaler nichtflüchtiger Speicher mit zwei Zonen bereitgestellt. Eine Zone entspricht der Zone, in der der Pod geplant ist. Die andere Zone wird zufällig aus den für den Cluster verfügbaren Zonen ausgewählt.

Bei Verwendung eines zonalen Clusters muss allowedTopologies festgelegt werden.

Nachdem Sie das Objekt StorageClass erstellt haben, erstellen Sie als Nächstes ein Objekt PersistentVolumeClaim und verweisen Sie mit dem Feld storageClassName auf das Objekt StorageClass. Das folgende Manifest erstellt beispielsweise ein PersistentVolumeClaim namens regional-pvc und verweist auf regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: regional-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
  storageClassName: regionalpd-storageclass

Da die StorageClass mit volumeBindingMode: WaitForFirstConsumer konfiguriert ist, wird das PersistentVolume erst bereitgestellt, wenn ein Pod erstellt wurde, der den PersistentVolumeClaim verwendet.

Das folgende Manifest ist ein Beispiel-Pod mit dem zuvor erstellten PersistentVolumeClaim:

kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Manuelle Bereitstellung

Erstellen Sie zuerst einen regionalen nichtflüchtigen Speicher mit dem Befehl gcloud compute disks create. Im folgenden Beispiel wird ein Speicher namens gce-disk-1 erstellt, der in die Zonen europe-west1-b und europe-west1-c repliziert wird:

gcloud compute disks create gce-disk-1 \
   --size 500Gi \
   --region europe-west1 \
   --replica-zones europe-west1-b,europe-west1-c

Sie können dann ein PersistentVolume erstellen, das auf den gerade erstellten regionalen nichtflüchtigen Speicher verweist. Zusätzlich zu den Objekten in Vorhandenen nichtflüchtigen Speicher als PersistentVolumes verwenden sollte das PersistentVolume für einen regionalen nichtflüchtigen Speicher auch eine node-affinity angeben. Wenn Sie einen StorageClass verwenden, sollte der CSI-Treiber für den nichtflüchtigen Speicher angegeben werden.

Hier ein Beispiel für ein StorageClass-Manifest, das nichtflüchtige Standardspeicher verwendet und Daten in die Zonen europe-west1-b und europe-west1-c repliziert:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Hier ist ein Beispielmanifest, das einen PersistentVolume namens pv-demo erstellt und auf regionalpd-storageclass verweist:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
               - europe-west1-b
               - europe-west1-c

Beachten Sie für das Beispiel PersistentVolume Folgendes:

  • Das Feld volumeHandle enthält Details zum Aufruf gcloud compute disks create, einschließlich deines PROJECT_ID.
  • Das Feld claimRef.namespace muss auch angegeben werden, wenn es auf default gesetzt ist.

Nichtflüchtige Speicher benennen

Kubernetes kann nicht zwischen zonalen und regionalen nichtflüchtigen Speichern mit demselben Namen unterscheiden. Geben Sie daher allen nichtflüchtigen Speichern eindeutige Namen. Bei der Verwendung von dynamisch bereitgestellten nichtflüchtigen Speichern tritt dieses Problem nicht auf.

Nächste Schritte