Nichtflüchtige Speicher mit mehreren Lesezugriffen verwenden

Autopilot Standard

Auf dieser Seite wird erläutert, wie Sie Ihrem Cluster im Lesemodus "ReadOnlyMany" einen nichtflüchtigen Speicher hinzufügen. In diesem Modus können mehrere Pods auf verschiedenen Knoten das Laufwerk zum Lesen bereitstellen.

Weitere Informationen zu diesem Modus finden Sie unter Zugriffsmodi für nichtflüchtige Volumes.

Voraussetzungen

Ihr Cluster muss GKE-Version 1.22 oder höher ausführen.
Der Cluster muss den CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine verwenden.

Nichtflüchtigen Quellspeicher formatieren und füllen

Um einen nichtflüchtigen Speicher im schreibgeschützten Modus zu verwenden, müssen Sie einen nichtflüchtigen Quellspeicher mit Daten füllen, dann entweder das Volume klonen oder einen Volume-Snapshot verwenden, um die Daten in ein neues ReadOnlyMany PersistentVolume zu verschieben.

Erstellen Sie ein PersistentVolume mit einem vorhandenen nichtflüchtigen Speicher oder mithilfe der dynamischen Bereitstellung.
Formatieren Sie das Laufwerk und füllen Sie es mit Daten. Verweisen Sie auf das Laufwerk als ReadWriteOnce PersistentVolume in einem Pod, um das Laufwerk zu formatieren. GKE formatiert das zugrunde liegende Laufwerk automatisch und lässt den Pod Daten auf das Laufwerk schreiben. Achten Sie beim Starten des Pods darauf, dass der Pod die gewünschten Daten auf das Laufwerk schreibt.

`ReadOnlyMany`-PersistentVolume erstellen

Sie können ein ReadOnlyMany-PersistentVolume mit einer der folgenden Methoden erstellen:

Ein Volume-Snapshot eines Quell-PersistentVolumes, das Sie mit Daten füllen.
Ein Volume-Klon eines Quell-PersistentVolume, das Sie mit Daten füllen.
Ein bereits vorhandener nichtflüchtiger Speicher, der bereits mit Daten gefüllt wurde.

VolumeSnapshot

Einen Volume-Snapshot des Quell-PersistentVolume erstellen
Speichern Sie das folgende PersistentVolumeClaim-Manifest als snapshot-pvc.yaml:
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: PVC_NAMESPACE
  name: PVC_NAME
spec:
  dataSource:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: SNAPSHOT_NAME
  accessModes:
    - ReadOnlyMany
  storageClassName: premium-rwo
  resources:
    requests:
      storage: STORAGE_SIZE
```
Ersetzen Sie dabei Folgendes:
- PVC_NAMESPACE: der Namespace des neuen PersistentVolumeClaim.
- PVC_NAME: der Name des neuen PersistentVolumeClaim.
- SNAPSHOT_NAME: der Name Ihres VolumeSnapshot-Objekts.
- STORAGE_SIZE: die Menge des anzufragenden Speichers. Dieser Wert muss mit dem im Quell-PersistentVolumeClaim angeforderten Betrag übereinstimmen.
Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f snapshot-pvc.yaml
```

Dadurch wird ein neuer PersistentVolumeClaim namens PVC_NAME in Ihrem Cluster erstellt, mit dem GKE ein neues PersistentVolume bereitstellt, das die Daten aus dem Snapshot des nichtflüchtigen Quellspeichers enthält.

Volume-Klonen

Bevor Sie ein Volume klonen, sollten Sie sich mit den Einschränkungen dieses Ansatzes vertraut machen.

Speichern Sie das folgende Manifest als cloning-pvc.yaml:
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  namespace: PVC_NAMESPACE
  name: PVC_NAME
spec:
  dataSource:
    name: SOURCE_PVC
    kind: PersistentVolumeClaim
  accessModes:
    - ReadOnlyMany
  storageClassName: STORAGE_CLASS_NAME
  resources:
    requests:
      storage: STORAGE_SIZE
```
Ersetzen Sie dabei Folgendes:
- PVC_NAMESPACE: der Namespace des neuen PersistentVolumeClaim.
- PVC_NAME: der Name des neuen PersistentVolumeClaim.
- SOURCE_PVC: der Name des Quell-PersistentVolumeClaim, der mit Daten gefüllt ist.
- STORAGE_CLASS_NAME: die Speicherklasse für den neuen PersistentVolumeClaim. Dieser muss mit der Speicherklasse des PersistentVolumeClaim der Quelle übereinstimmen.
- STORAGE_SIZE: die Speichermenge für den neuen PersistentVolumeClaim. Dies muss der gleiche Wert sein, der vom Quell-PersistentVolumeClaim angefordert wurde.
Wenden Sie das Manifest auf Ihren Cluster an:
```
kubectl apply -f cloning-pvc.yaml
```

Dadurch wird ein PersistentVolumeClaim namens PVC_NAME erstellt, mit dem GKE ein neues PersistentVolume im ReadOnlyMany-Modus mit den Daten im Quell-PersistentVolume erstellt.

Ausführliche Informationen zum Klonen von Volumes finden Sie unter Klone nichtflüchtiger Volumes erstellen.

Bereits vorhandener nichtflüchtiger Speicher

Speichern Sie das folgende Manifest als preexisting-disk-pv-pvc.yaml:
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: PV_NAME
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: DISK_SIZE
  accessModes:
    - ReadOnlyMany
  claimRef:
    namespace: PVC_NAMESPACE
    name: PVC_NAME
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: DISK_ID
    fsType: FS_TYPE
    readOnly: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  namespace: PVC_NAMESPACE
  name: PVC_NAME
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: PV_NAME
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: DISK_SIZE
```
Ersetzen Sie dabei Folgendes:
- PV_NAME ist der Name Ihres neuen PersistentVolume.
- STORAGE_CLASS_NAME ist der Name Ihrer neuen StorageClass.
- DISK_SIZE ist die Größe des vorhandenen nichtflüchtigen Speichers. Beispiel: 500G.
- PVC_NAMESPACE: der Namespace des neuen PersistentVolumeClaim.
- PVC_NAME ist der Name Ihres neuen PersistentVolumeClaim.
- DISK_ID ist die Kennung des bereits vorhandenen nichtflüchtigen Speichers. Das Format ist projects/{project_id}/zones/{zone_name}/disks/{disk_name} für zonale nichtflüchtige Speicher oder projects/{project_id}/regions/{region_name}/disks/{disk_name} für regionale nichtflüchtige Speicher.
- FS_TYPE ist der Dateisystemtyp. Sie können die Standardeinstellung (ext4) beibehalten oder xfs verwenden. Wenn Ihre Cluster einen Windows Server-Knotenpool verwenden, müssen Sie den Wert in NTFS ändern.

Wenden Sie das Manifest auf Ihren Cluster an:

kubectl apply -f preexisting-disk-pv-pvc.yaml

Dadurch werden ein PersistentVolumeClaim namens PVC_NAME und ein PersistentVolume namens PV_NAME im ReadOnlyMany-Modus erstellt.

Ausführliche Informationen zur Verwendung eines bereits vorhandenen nichtflüchtigen Speichers finden Sie unter Vorhandener nichtflüchtiger Speicher.

PersistentVolumeClaim in einem Pod verwenden

Sie können jetzt auf den neuen PersistentVolumeClaim im schreibgeschützten Modus in mehreren Pods auf mehreren Knoten gleichzeitig verweisen. Nichtflüchtiger Speicher kann im ReadWriteOnce-Modus nicht mehreren Knoten gleichzeitig hinzugefügt werden. Weitere Informationen finden Sie unter Deployments oder StatefulSets.

In der Pod-Spezifikation müssen Sie readOnly: true im Abschnitt volumeMounts und im Abschnitt volumes angeben, wie im folgenden Beispiel:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multi-read
  labels:
    app: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      containers:
      - name: web-server
        image: nginx
        volumeMounts:
        - mountPath: /test-mnt
          name: my-volume
          readOnly: true
      volumes:
      - name: my-volume
        persistentVolumeClaim:
          claimName: PVC_NAME
          readOnly: true

Hinweis: Schreibgeschützte ext3- und ext4-Dateisysteme unterstützen keine Journalwiedergabe. Wenn das Dateisystem des nichtflüchtigen Standardspeichers beim Klonen oder Erstellen eines Snapshots als fehlerhaft gekennzeichnet ist, sind die Daten auf dem schreibgeschützten nichtflüchtigen Speicher möglicherweise inkonsistent oder beschädigt. Der CSI-Treiber für den nichtflüchtigen Speicher von Compute Engine versucht, das Laufwerk normal bereitzustellen. Wenn die Unfähigkeit, das Journal wiederzugeben, dazu führt, dass das Einbinden des Volumes fehlschlägt, versucht der CSI-Treiber automatisch, das Einbinden mit der Option noload zu wiederholen, die die Abspielversuche auf ext3- und ext4-Dateisystemen deaktiviert. Wenn das Quelldateisystem tatsächlich zu dem Zeitpunkt inkonsistent war, als es geklont oder erstellt wurde, ist die schreibgeschützte Bereitstellung ebenfalls inkonsistent.