Regionale nichtflüchtige Speicher und Hyperdisk Balanced High Availability-Volumes bereitstellen

Auf dieser Seite wird erläutert, wie Sie die dynamische Bereitstellung von Hyperdisk Balanced-Volumes mit hoher Verfügbarkeit und regionalen nichtflüchtigen Speichern aktivieren und diese manuell in Google Kubernetes Engine (GKE) bereitstellen. Informationen zur Kompatibilität von Maschinentypen finden Sie unter Einschränkungen für regionale Laufwerke und Unterstützung von Maschinenserien für Hyperdisk. Im Allgemeinen sollten Sie Hyperdisk Balanced-Hochverfügbarkeitsvolumes für Maschinen-Serien der 3. Generation oder neuer und regionale nichtflüchtige Speicher für Maschinen-Serien der 2. Generation oder älter verwenden. Weitere Informationen zur Generation von Maschinenserien finden Sie unter Compute Engine-Terminologie.

Informationen zum Erstellen von End-to-End-Lösungen für Anwendungen mit hoher Verfügbarkeit mit regionalen nichtflüchtigen Speichern finden Sie unter Verfügbarkeit zustandsorientierter Anwendungen mit zustandsorientiertem HA-Operator erhöhen. Diese Funktion unterstützt keine Hyperdisk Balanced High Availability-Volumes.

Hyperdisk mit ausgeglichener Hochverfügbarkeit

In diesem Beispiel wird gezeigt, wie Hyperdisk Balanced High Availability-Volumes dynamisch nach Bedarf oder vorab manuell vom Clusteradministrator bereitgestellt werden können.

Dynamische Bereitstellung

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen balanced-ha-storage.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: balanced-ha-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
# Allow volume expansion.
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced-high-availability
  # Provisioned throughput in MiB/s.
  provisioned-throughput-on-create: "250Mi"
  # Provisioned IOPS (input/output operations per second).
  provisioned-iops-on-create: "7000"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - ZONE1
    - ZONE2

    Ersetzen Sie Folgendes:

    • ZONE1, ZONE2: die Zonen innerhalb der Region, in die das dynamisch bereitgestellte Volume repliziert wird.

  2. StorageClass erstellen:

    kubectl create -f hdb-ha-example-class.yaml

  3. Speichern Sie das folgende PersistentVolumeClaim-Manifest in einer Datei mit dem Namen pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Ersetzen Sie Folgendes:

    • ACCESS_MODE: Hyperdisk Balanced High Availability unterstützt ReadWriteOnce, ReadWriteMany und ReadWriteOncePod. Informationen zu den Unterschieden und Anwendungsfällen der einzelnen Zugriffsmodi finden Sie unter Zugriffsmodi für nichtflüchtige Volumes.
    • Wenn Sie ReadWriteMany verwenden, müssen Sie auch volumeMode: Block zu PersistentVolumeClaim hinzufügen. Diese Einstellung verhindert Datenbeschädigungen, die durch das gleichzeitige Schreiben mehrerer Pods in den Speicher auftreten können. Die Einstellung volumeMode: Block macht die Festplatte als Raw-Blockgerät verfügbar, das die Dateisystemverwaltung durch Kubernetes umgeht. Hier ein Beispiel:
      kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: podpvc
  spec:
    accessModes:
    - ReadWriteMany
    volumeMode: Block
    storageClassName: balanced-ha-storage
    resources:
      requests:
        storage: 20Gi
  ```

  4. Wenden Sie den PersistentVolumeClaim an, der auf die StorageClass verweist, die Sie zuvor erstellt haben:

    kubectl apply -f pvc-example.yaml

Manuelle Bereitstellung

  1. Folgen Sie der Compute Engine-Dokumentation, um ein Hyperdisk-Volume mit ausgeglichener Hochverfügbarkeit manuell zu erstellen.

  2. Speichern Sie das folgende PersistentVolume-Manifest in einer Datei mit dem Namen pv-example.yaml. Das Manifest verweist auf das Hyperdisk Balanced High Availability-Volume, das Sie gerade erstellt haben:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ACCESS_MODE
  # ClaimRef links this PersistentVolume to a PersistentVolumeClaim.
  claimRef:
    namespace: default
    name: podpvc
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier of the Compute Engine disk resource that backs this volume.
    volumeHandle: projects/PROJECT_ID/regions/REGION/disks/gce-disk-1
  # Node affinity to ensure the Pod is scheduled in a zone where the volume is replicated.
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
            - ZONE1
            - ZONE2

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die Projekt-ID des von Ihnen erstellten Volumes.
    • REGION: die Region des Laufwerks, das Sie erstellt haben. Informationen zur aktuellen regionalen Verfügbarkeit finden Sie in der Compute Engine-Dokumentation.
    • ZONE1, ZONE2: die Zonen innerhalb der Region, in denen das von Ihnen erstellte Volume repliziert wird.
    • ACCESS_MODE: Hyperdisk Balanced High Availability unterstützt ReadWriteOnce, ReadWriteMany und ReadWriteOncePod. Informationen zu den Unterschieden und Anwendungsfällen der einzelnen Zugriffsmodi finden Sie unter Zugriffsmodi für nichtflüchtige Volumes.

  3. Erstellen Sie das PersistentVolume, das auf das zuvor erstellte Hyperdisk Balanced-Hochverfügbarkeits-Volume verweist:

    kubectl apply -f pv-example.yaml

  4. Speichern Sie das folgende PersistentVolumeClaim-Manifest in einer Datei mit dem Namen pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Ersetzen Sie Folgendes:

    • ACCESS_MODE: Hyperdisk Balanced High Availability unterstützt ReadWriteOnce, ReadWriteMany und ReadWriteOncePod. Muss derselbe Zugriffsmodus sein, der im PersistentVolume aus dem vorherigen Schritt angegeben ist. Informationen zu den Unterschieden und Anwendungsfällen der einzelnen Zugriffsmodi finden Sie unter Zugriffsmodi für nichtflüchtige Volumes.

  5. Wenden Sie den PersistentVolumeClaim an, der auf das zuvor erstellte PersistentVolume verweist:

    kubectl apply -f pvc-example.yaml

Verwenden eines Volumes für mehrere Autoren im Blockmodus

Wenn Sie ein Volume im Blockmodus verwenden möchten, müssen Sie im nutzenden Pod volumeBlock anstelle von volumeMounts angeben. Ein Beispiel-Pod, der das zuvor eingeführte PersistenVolumeClaim verwendet, sollte so aussehen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        # Use volumeDevices instead of volumeMounts to consume the volume as a raw block device.
        volumeDevices:
        # The "mountPath" field specifies the path where the block device is accessible in the container.
        - mountPath: /dev/my-device
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
          readOnly: false

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. Wenn Sie regionale nichtflüchtige Speicher vom Typ pd-standard verwenden möchten, legen Sie das Attribut spec.resources.requests.storage des PersistentVolumeClaim auf mindestens 200 GiB fest. Wenn Sie ein kleineres Volume benötigen, sollten Sie stattdessen pd-balanced oder pd-ssd verwenden.

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
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
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
      # This Pod uses the PVC that's associated with the
      # "regionalpd-storageclass" StorageClass.
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      # The volume is mounted into the container at the "/usr/share/nginx/html" path.
      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
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
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:
  # The StorageClass that specifies regional replication.
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier for the pre-existing regional disk.
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  # Ensures that Pods are scheduled in zones where the disk is replicated.
  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