Auf Filestore-Instanzen mit dem Filestore-CSI-Treiber zugreifen

Autopilot Standard

Der Filestore-CSI-Treiber ist die primäre Methode zur Verwendung von Filestore-Instanzen mit Google Kubernetes Engine (GKE). Der CSI-Treiber von Filestore bietet eine vollständig verwaltete Umgebung, die vom Open-Source-Filestore-CSI-Treiber von Google Cloud unterstützt wird.

Die Version des CSI-Treibers von Filestore ist an Kubernetes-Nebenversionsnummern geknüpft. In der Regel ist die Version des CSI-Treibers von Filestore der bei der Veröffentlichung der Kubernetes-Nebenversion aktuelle Treiber. Die Treiber werden automatisch aktualisiert, wenn ein Upgrade des Clusters auf den neuesten GKE-Patch durchgeführt wird.

Vorteile

Der CSI-Treiber von Filestore bietet folgende Vorteile:

Sie haben über die Kubernetes APIs (kubectl) Zugriff auf vollständig verwalteten NFS-Speicher.
Sie können den CSI-Treiber von GKE Filestore nutzen, um PersistentVolumes dynamisch bereitzustellen.
Sie können mit dem CSI-Treiber von GKE Filestore Volume-Snapshots nutzen. CSI-Volume-Snapshots können zum Erstellen von Filestore-Sicherungen verwendet werden.

Eine Filestore-Sicherung erstellt eine differenzielle Kopie der Dateifreigabe, einschließlich aller Dateidaten und Metadaten, und speichert diese getrennt von der Instanz. Sie können diese Kopie dann nur in einer neuen Filestore-Instanz wiederherstellen. Die Wiederherstellung in einer vorhandenen Filestore-Instanz wird nicht unterstützt. Sie können mit der API für CSI-Volume-Snapshots Filestore-Sicherungen auslösen. Dazu fügen Sie der VolumeSnapshotClass das Feld type:backup hinzu.
Sie können die Volume-Erweiterung mit dem CSI-Treiber von GKE Filestore verwenden. Mit der Volume-Erweiterung können Sie die Größe der Kapazität Ihres Volumes anpassen.
Um auf vorhandene Filestore-Instanzen zugreifen, können Sie bereits bereitgestellte Filestore-Instanzen in Kubernetes-Arbeitslasten verwenden. Sie können Filestore-Instanzen auch dynamisch erstellen oder löschen und in Kubernetes-Arbeitslasten mit einer StorageClass oder einem Deployment verwenden.
Unterstützt Filestore Multishares für GKE. Mit dieser Funktion können Sie eine Filestore-Instanz erstellen und ihr mehrere kleinere, über NFS gemountete nicht flüchtige Volumes gleichzeitig in einer beliebigen Anzahl von GKE-Clustern zuweisen.

Voraussetzungen

Zur Verwendung des Filestore-CSI-Treibers müssen Ihre Cluster die für Ihre Dienststufe gültige GKE-Version verwenden. Nur die folgenden Dienststufen werden unterstützt:
- Basic HDD mit GKE-Version 1.21 oder höher
- Basic SSD mit GKE-Version 1.21 oder höher
- Zonal (10 TiB bis 100 TiB) mit GKE-Version 1.27 oder höher
- Enterprise mit GKE-Version 1.25 oder höher
- Ihre Cluster müssen die GKE-Version 1.25 oder höher verwenden, um Filestore-Multishares nutzen zu können.
Der Filestore-CSI-Treiber wird nur für Cluster unterstützt, die Linux verwenden. Windows Server-Knoten werden nicht unterstützt.
Die Mindestinstanzgröße für Filestore beträgt 1 TiB. Die Mindestinstanzgröße hängt von der ausgewählten Filestore-Dienststufe ab. Weitere Informationen finden Sie unter Dienststufen.
Filestore verwendet das NFSv3-Dateisystemprotokoll auf der Filestore-Instanz und unterstützt jeden NFSv3-kompatiblen Client.

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

Aktivieren Sie die Cloud Filestore API und die Google Kubernetes Engine API.

APIs aktivieren

Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI die compute/region- und compute/zone-Attribute fest. Durch das Festlegen von Standardspeicherorten können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden.

Wenn Sie Filestore in einem freigegebenen VPC-Netzwerk verwenden möchten, lesen Sie die zusätzliche Einrichtungsanleitung unter Filestore mit freigegebener VPC verwenden.

Filestore-CSI-Treiber auf einem neuen Cluster aktivieren

Führen Sie folgende Schritte mit der Google Cloud CLI oder der Google Cloud Console aus, um den Filestore CSI-Treiber zu aktivieren, wenn Sie einen neuen Standardcluster erstellen.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --addons=GcpFilestoreCsiDriver \
    --cluster-version=VERSION

Ersetzen Sie dabei Folgendes:

CLUSTER_NAME: Der Name Ihres Clusters.
VERSION: Die GKE-Versionsnummer. Sie müssen eine unterstützte Versionsnummer auswählen, um diese Funktion nutzen zu können. Weitere Informationen finden Sie unter [#anforderungen]. Alternativ können Sie das Flag --release-channel verwenden und eine Release-Version angeben.

Console

Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

Zur Seite „Google Kubernetes Engine“
Klicken Sie auf Erstellen.
Wählen Sie den Clustermodus Standard aus und klicken Sie dann auf Konfigurieren.
Konfigurieren Sie den Cluster entsprechend Ihren Anforderungen.
Klicken Sie im Navigationsbereich unter Cluster auf Features.
Klicken Sie auf das Kästchen Filestore-CSI-Treiber aktivieren.
Klicken Sie auf Erstellen.

Informationen zum Verwenden von Filestore in einem freigegebenen VPC-Netzwerk finden Sie unter Filestore-CSI-Treiber auf einem neuen Cluster mit freigegebener VPC aktivieren.

Nachdem Sie den CSI-Treiber von Filestore aktiviert haben, können Sie den Treiber in Kubernetes-Volumes mit dem Namen des Treibers und des Bereitstellers verwenden: filestore.csi.storage.gke.io.

Filestore-CSI-Treiber auf einem vorhandenen Cluster aktivieren

Verwenden Sie die Google Cloud CLI oder die Google Cloud Console, um den CSI-Treiber von Filestore in vorhandenen Clustern zu aktivieren.

Führen Sie die folgenden Schritte aus, um den Treiber auf einem vorhandenen Cluster zu aktivieren:

gcloud

gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

Ersetzen Sie CLUSTER_NAME durch den Namen des vorhandenen Clusters.

Console

Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

Zur Seite "Google Kubernetes Engine"
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Features neben dem Feld Filestore-CSI-Treiber auf Filestore-CSI-Treiber bearbeiten.
Klicken Sie auf das Kästchen Filestore-CSI-Treiber aktivieren.
Klicken Sie auf Änderungen speichern.

Filestore-CSI-Treiber deaktivieren

Sie können den Filestore-CSI-Treiber auf einem vorhandenen Autopilot- oder Standard-Cluster über die Google Cloud CLI oder die Google Cloud Console deaktivieren.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

Ersetzen Sie die folgenden Werte:

CLUSTER_NAME: Den Namen des vorhandenen Clusters.
REGION: Die Region für Ihren Cluster, z. B. us-central1.

Console

Rufen Sie in der Google Cloud Console die das Menü „Google Kubernetes Engine“ auf.

Zur Seite "Google Kubernetes Engine"
Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.
Klicken Sie unter Features neben dem Feld Filestore-CSI-Treiber auf Filestore-CSI-Treiber bearbeiten.
Entfernen Sie das Häkchen aus dem Kästchen Filestore-CSI-Treiber aktivieren.
Klicken Sie auf Änderungen speichern.

Mit dem Filestore-CSI-Treiber auf bereits vorhandene Filestore-Instanzen zugreifen

In diesem Abschnitt wird das typische Verfahren zur Verwendung eines Kubernetes-Volumes für den Zugriff auf bereits vorhandene Filestore-Instanzen mit dem Filestore-CSI-Treiber in GKE beschrieben:

Für den Zugriff auf die Instanz ein PersistentVolume und einen PersistentVolumeClaim erstellen

Erstellen Sie eine Manifestdatei wie im folgenden Beispiel und nennen Sie sie preprov-filestore.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: PV_NAME
spec:
  storageClassName: ""
  capacity:
    storage: 1Ti
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  csi:
    driver: filestore.csi.storage.gke.io
    volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME"
    volumeAttributes:
      ip: FILESTORE_INSTANCE_IP
      volume: FILESTORE_SHARE_NAME
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  volumeName: PV_NAME
  resources:
    requests:
      storage: 1Ti

Um die Ressourcen PersistentVolumeClaim und PersistentVolume anhand der Manifestdatei preprov-filestore.yaml zu erstellen, führen Sie folgenden Befehl aus:
```
kubectl apply -f preprov-filestore.yaml
```

Erstellen Sie dann eine Bereitstellung, die das Volume verbraucht.

Mit dem Filestore-CSI-Treiber ein Volume erstellen

In den folgenden Abschnitten wird das typische Verfahren zur Verwendung eines Kubernetes-Volumes beschrieben, das von einem Filestore CSI-Treiber in GKE unterstützt wird.

StorageClass erstellen
Mit einem PersistentVolumeClaim auf das Volume zugreifen
Deployment erstellen, das das Volume nutzt

StorageClass erstellen

Nachdem Sie den CSI-Treiber von Filestore aktiviert haben, installiert GKE automatisch die folgenden StorageClasses zur Bereitstellung von Filestore-Instanzen:

zonal-rwx, mit der zonalen Filestore-Stufe. Nur für den höheren Kapazitätsbereich (10 TiB bis 100 TiB) verfügbar.
enterprise-rwx mit der Filestore-Enterprise-Stufe, wobei jedes Kubernetes-PersistentVolume einer Filestore-Instanz zugeordnet ist.
enterprise-multishare-rwx mit der Filestore-Enterprise-Stufe, wobei jedes Kubernetes-PersistentVolume der Freigabe einer bestimmten Filestore-Instanz zugeordnet ist. Weitere Informationen finden Sie unter Filestore Multishares für Google Kubernetes Engine.
standard-rwx, mit der Filestore-Dienststufe „Basic HDD“.
premium-rwx, mit der Filestore-Dienststufe „Basic SSD“.

Jede StorageClass ist nur in GKE-Clustern verfügbar, die die jeweilige unterstützte GKE-Version ausführen. Eine Liste der für jede Dienststufe erforderlichen unterstützten Versionen finden Sie unter Anforderungen.

Sie finden den Namen der installierten StorageClass mit dem folgenden Befehl:

kubectl get sc

Sie können auch eine andere StorageClass installieren, die den CSI-Treiber von Filestore verwendet. Fügen Sie dazu filestore.csi.storage.gke.io im Feld provisioner hinzu.

Filestore muss wissen, in welchem Netzwerk die neue Instanz erstellt werden soll. Die automatisch installierten StorageClasses verwenden das für GKE-Cluster erstellte Standardnetzwerk. Wenn Sie dieses Netzwerk gelöscht haben oder ein anderes Netzwerk verwenden möchten, müssen Sie eine neue StorageClass wie in den folgenden Schritten beschrieben erstellen. Andernfalls funktionieren die automatisch installierten StorageClasses nicht.

Speichern Sie das folgende Manifest als filestore-example-class.yaml:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: standard
  network: default
```
Betrachten Sie im Manifest die folgende Parameterkonfiguration:
- Wenn Sie volumeBindingMode auf Immediate setzen, kann das Volume sofort bereitgestellt werden. Dies ist möglich, da auf Filestore-Instanzen von jeder Zone aus zugegriffen werden kann. Daher muss GKE im Gegensatz zum nichtflüchtigen Compute Engine-Speicher nicht die Zone kennen, in der der Pod geplant ist. Wenn WaitForFirstConsumer festgelegt ist, beginnt GKE mit der Bereitstellung erst, nachdem der Pod geplant wurde. Weitere Informationen finden Sie unter VolumeBindingMode.
- Mit dem Parameter tier kann jede unterstützte Filestore-Stufe angegeben werden (z. B. BASIC_HDD, BASIC_SSD, ZONAL, oder ENTERPRISE).
- Der network-Parameter kann bei der Bereitstellung von Filestore-Instanzen in nicht standardmäßigen VPCs verwendet werden. Nicht standardmäßige VPCs erfordern das Einrichten spezieller Firewallregeln.
Um eine StorageClass-Ressource anhand der Manifestdatei filestore-example-class.yaml zu erstellen, führen Sie folgenden Befehl aus:
```
kubectl create -f filestore-example-class.yaml
```

Informationen zum Verwenden von Filestore in einem freigegebenen VPC-Netzwerk finden Sie unter StorageClass erstellen, wenn der CSI-Treiber von Filestore mit einem freigegebenen VPC verwendet wird.

Mit einem PersistentVolumeClaim auf das Volume zugreifen

Sie können eine PersistentVolumeClaim-Ressource erstellen, die auf die StorageClass des CSI-Treibers für Filestore verweist.

Sie können entweder eine vorinstallierte oder eine benutzerdefinierte StorageClass verwenden.

Die folgende Manifestdatei erstellt einen PersistentVolumeClaim, der auf die StorageClass mit dem Namen filestore-example verweist.

Speichern Sie die folgende Manifestdatei als pvc-example.yaml:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

Um eine PersistentVolume-Ressource anhand der Manifestdatei pvc-example.yaml zu erstellen, führen Sie folgenden Befehl aus:
```
kubectl create -f pvc-example.yaml
```

Deployment erstellen, das das Volume nutzt

Im folgenden Beispiel-Deployment-Manifest wird die PersistentVolume-Ressource mit dem Namen pvc-example.yaml verwendet.

Eine PersistentVolumeClaim-Ressource kann von mehreren Pods verwendet werden.

Speichern Sie das folgende Manifest als filestore-example-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

Führen Sie den folgenden Befehl aus, um ein Deployment anhand der Manifestdatei filestore-example-deployment.yaml zu erstellen:
```
kubectl apply -f filestore-example-deployment.yaml
```
Prüfen Sie, ob das Deployment erfolgreich erstellt wurde:
```
kubectl get deployment
```
Es kann eine Weile dauern, bis die Bereitstellung von Filestore-Instanzen abgeschlossen ist. Bis dahin melden Bereitstellungen den READY-Status nicht. Um den Fortschritt zu prüfen, können Sie den PVC-Status mit folgendem Befehl beobachten:
```
kubectl get pvc
```
Der PVC sollte den Status BOUND haben, sobald die Volume-Bereitstellung abgeschlossen ist.

Filestore-Instanzen mit Labels versehen

Mit Labels können Sie verwandte Instanzen gruppieren und Metadaten zu einer Instanz speichern. Ein Label ist ein Schlüsselwertpaar, mit dem Sie Ihre Filestore -Instanzen organisieren können. Sie können jede Ressource mit einem Label versehen und dann die Ressourcen nach ihren Labels filtern.

Sie können Labels mithilfe des Schlüssels labels in StorageClass.parameters bereitstellen. Eine Filestore-Instanz kann mit Labels versehen werden, die angeben, für welche Werte von PersistentVolumeClaim/PersistentVolume die Instanz erstellt wurde. Benutzerdefinierte Labelschlüssel und -werte müssen der Namenskonvention für Labels entsprechen. Weitere Informationen zum Anwenden benutzerdefinierter Labels auf die Filestore-Instanz finden Sie im Beispiel zu Speicherklassen von Kubernetes.

fsgroup mit Filestore-Volumes verwenden

Kubernetes verwendet fsGroup, um Berechtigungen und Eigentumsrechte des Volumes zu ändern, damit es einer vom Nutzer angeforderten fsGroup im SecurityContext des Pods entspricht. Eine fsGroup ist eine zusätzliche Gruppe, die für alle Container in einem Pod gilt. Sie können eine fsGroup auf Volumes anwenden, die vom CSI-Treiber von Filestore bereitgestellt werden.

IP-Zugriffsregeln mit Filestore-Volumes konfigurieren

Filestore unterstützt IP-basierte Zugriffssteuerungsregeln für Volumes. Diese Funktion ist in GKE-Clustern mit Version 1.29.5 oder höher verfügbar.

Mit dieser Funktion können Administratoren angeben, welche IP-Adressbereiche auf eine Filestore-Instanz zugreifen dürfen, die dynamisch über GKE bereitgestellt wird. Dadurch wird die Sicherheit erhöht, da der Zugriff auf autorisierte Clients beschränkt wird. Dies ist insbesondere in Szenarien der Fall, in denen der IP-Bereich des GKE-Clusters zu breit ist und die Filestore-Instanz potenziell für nicht autorisierte Nutzer oder Anwendungen zugänglich ist.

Diese Regeln können direkt über die Filestore API oder über den Filestore-CSI-Treiber konfiguriert werden, wenn ein Volume erstellt wird. Sie können die ausgewählte Konfiguration im JSON-Format in der StorageClass mit dem Parameter nfs-export-options-on-create bereitstellen.

Das folgende Beispielmanifest zeigt, wie die Konfiguration angegeben wird:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
  tier: "enterprise"
  nfs-export-options-on-create: '[
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/24"
      ],
      "squashMode": "ROOT_SQUASH",
      "anonUid": "1003",
      "anonGid": "1003"
    },
    {
      "accessMode": "READ_WRITE",
      "ipRanges": [
        "10.0.0.0/28"
      ],
      "squashMode": "NO_ROOT_SQUASH"
    }
  ]'

Sicherheitsoptionen

Filestore-IP-Zugriffsregeln vereinfachen die Konfiguration von Berechtigungen für freigegebenen Dateispeicher für Ihre GKE-Arbeitslasten. Um zu verstehen, wie die Dateieigentümerschaft und der Zugriff verwaltet werden, müssen Sie jedoch einige wichtige Konzepte kennen:

NFS- und Nutzerzuordnungen NFS (Network File System) ist das Protokoll, das von Filestore verwendet wird. Dabei werden Nutzer auf Clientsystemen (Ihre GKE-Pods) Nutzern auf dem Filestore-Server zugeordnet. Wenn eine Datei auf dem Server der Nutzer-ID 1003 gehört und ein Client eine Verbindung mit der Nutzer-ID 1003 herstellt, hat er Zugriff auf die Datei.
Root Squashing und anonUid:
- Root Squashing ROOT_SQUASH ist eine Sicherheitsfunktion, die verhindert, dass Clients mit vollen Root-Berechtigungen auf die Filestore-Instanz zugreifen. Wenn Root Squashing aktiviert ist, werden Root-Nutzer auf Clientsystemen einem nicht privilegierten Nutzer zugeordnet, der durch die Einstellung anonUid angegeben wird.
- Bei Kein Root Squashing (NO_ROOT_SQUASH) können Clients mit vollen Root-Berechtigungen auf die Filestore-Instanz zugreifen. Das ist für die Ersteinrichtung praktisch, aber für den regulären Betrieb weniger sicher.
Ersteinrichtung und Berechtigungen: Standardmäßig ist der Root-Nutzer alleiniger Eigentümer einer neuen Filestore-Instanz. Wenn Sie die Root-Squashing-Funktion aktivieren, ohne zuvor Berechtigungen für andere Nutzer einzurichten, verlieren Sie den Zugriff. Daher benötigen Sie mindestens eine NFS-Exportregel mit NO_ROOT_SQUASH, um den anfänglichen Zugriff für andere Nutzer und Gruppen zu konfigurieren.

Empfehlungen

Ersteinrichtung: Beginnen Sie immer mit mindestens einer NFS-Exportregel, die einen Administratorbereich mit READ_WRITE-Berechtigungen angibt und NO_ROOT_SQUASH-Zugriff zulässt. Mit diesem Zugriff können Sie Verzeichnisse erstellen, Berechtigungen festlegen und bei Bedarf die Eigentümerschaft zuweisen.
Sicherheit: Aktivieren Sie die Root-Squashing-Funktion (ROOT_SQUASH), um die Sicherheit zu erhöhen. Nachdem ein Volume erstellt wurde, können Sie die Zugriffsregeln nur noch über die Filestore API ändern.
Gemeinsam genutzter Zugriff: Verwenden Sie fsGroup in Ihren Pod-Sicherheitskontexten, um die Gruppeneigentümerschaft für freigegebene Volumes zu verwalten. Achten Sie darauf, dass sich Ihre Einstellung nicht mit dem ROOT_SQUASH-Modus überschneidet. Dies führt zu einer Fehlermeldung vom Typ Access denied.

Filestore mit freigegebener VPC verwenden

In diesem Abschnitt wird beschrieben, wie Sie eine Filestore-Instanz in einem freigegebenen VPC-Netzwerk aus einem Dienstprojekt verwenden.

Cluster mit freigegebener VPC einrichten

So richten Sie Cluster mit einem freigegebenen VPC-Netzwerk ein:

Filestore-CSI-Treiber auf einem neuen Cluster mit freigegebener VPC aktivieren

Führen Sie folgende Schritte aus, um den CSI-Treiber von Filestore auf einem neuen Cluster mit freigegebener VPC zu aktivieren:

Prüfen Sie die verwendbaren Subnetze und sekundären Bereiche. Beim Erstellen eines Clusters müssen Sie ein Subnetz und die sekundären IP-Adressbereiche angeben, die für die Pods und Dienste des Clusters verwendet werden sollen.

gcloud container subnets list-usable \
   --project=SERVICE_PROJECT_ID \
   --network-project=HOST_PROJECT_ID

Die Ausgabe sieht in etwa so aus:

PROJECT                   REGION       NETWORK     SUBNET  RANGE
HOST_PROJECT_ID  us-central1  shared-net  tier-1  10.0.4.0/22
┌──────────────────────┬───────────────┬─────────────────────────────┐
│ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
├──────────────────────┼───────────────┼─────────────────────────────┤
│ tier-1-pods          │ 10.4.0.0/14   │ usable for pods or services │
│ tier-1-services      │ 10.0.32.0/20  │ usable for pods or services │
└──────────────────────┴───────────────┴─────────────────────────────┘

einen GKE-Cluster installieren In folgenden Beispielen wird gezeigt, wie Sie mit der gcloud CLI einen Autopilot- oder Standardcluster erstellen, der für die freigegebene VPC konfiguriert ist. In folgenden Beispielen werden die Netzwerk-, Subnetz- und Bereichsnamen aus Netzwerk und zwei Subnetze erstellen verwendet.

Autopilot

gcloud container clusters create-auto tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --region=COMPUTE_REGION \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services

Standard

gcloud container clusters create tier-1-cluster \
   --project=SERVICE_PROJECT_ID \
   --zone=COMPUTE_REGION \
   --enable-ip-alias \
   --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \
   --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \
   --cluster-secondary-range-name=tier-1-pods \
   --services-secondary-range-name=tier-1-services \
   --addons=GcpFilestoreCsiDriver

Erstellen Sie Firewallregeln, um die Kommunikation zwischen Knoten, Pods und Services in Ihrem Cluster zuzulassen. Das folgende Beispiel zeigt, wie Sie eine Firewallregel mit dem Namen my-shared-net-rule-2 erstellen können.
```
gcloud compute firewall-rules create my-shared-net-rule-2 \
   --project HOST_PROJECT_ID \
   --network=NETWORK_NAME \
   --allow=tcp,udp \
   --direction=INGRESS \
   --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20
```
In diesem Beispiel stammen die IP-Werte der Quellbereiche aus dem vorherigen Schritt, in dem Sie die verwendbaren Subnetze und sekundären Bereiche geprüft haben.

StorageClass erstellen, wenn der Filestore-CSI-Treiber mit einer freigegebenen VPC verwendet wird

Das folgende Beispiel zeigt, wie Sie eine StorageClass erstellen, wenn Sie den CSI-Treiber von Filestore mit einer freigegebenen VPC verwenden:

cat <<EOF | kubectl apply -f -

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
  network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
  connect-mode: PRIVATE_SERVICE_ACCESS
  reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true

EOF

Dabei gilt:

HOST_PROJECT_ID: ID oder Name des Hostprojekts des freigegebenen VPC-Netzwerks.
SHARED_VPC_NAME: Name des freigegebenen VPC-Netzwerks, das Sie zuvor erstellt haben.
RESERVED_IP_RANGE_NAME: Name des spezifischen reservierten IP-Adressbereichs, in dem die Filestore-Instanz bereitgestellt wird. Dieses Feld ist optional. Wenn ein reservierter IP-Adressbereich angegeben ist, muss er ein benannter Adressbereich anstelle eines direkten CIDR-Werts sein.

Wenn Sie ein Volume bereitstellen möchten, das von Filestore-Multishares auf GKE-Clustern mit Version 1.23 oder höher unterstützt wird, lesen Sie die Informationen unter Speicher mit Filestore-Multishares für GKE optimieren.

Einzelne Filestore-Volumes mit einzelner Freigabe neu verbinden

Wenn Sie Filestore mit der Basis-HDD-, Basis-SSD- oder der Unternehmensstufe (einzelne Freigabe) verwenden, folgen Sie dieser Anleitung, um Ihre vorhandene Filestore-Instanz wieder mit Ihren GKE-Arbeitslasten zu verbinden.

Suchen Sie die Details Ihrer vorab bereitgestellten Filestore-Instanz. Folgen Sie dazu der Anleitung unter Informationen zu einer bestimmten Instanz abrufen.
Stellen Sie die PersistentVolume-Spezifikation noch einmal bereit. Ändern Sie im Feld volumeAttributes die folgenden Felder so, dass dieselben Werte wie in Ihrer Filestore-Instanz aus Schritt 1 verwendet werden:
- ip: Ändern Sie diesen Wert in die vorab bereitgestellte IP-Adresse der Filestore-Instanz.
- volume: Ändern Sie diesen Wert in den Freigabenamen der vorab bereitgestellten Filestore-Instanz.
Stellen Sie die PersistentVolumeClaim-Spezifikation noch einmal bereit. Achten Sie darauf, dass Sie in volumeName auf denselben PersistentVolume-Namen wie in Schritt 2 verweisen.
Prüfen Sie den Bindungsstatus von PersistentVolumeClaim und PersistentVolume mit kubectl get pvc.
Stellen Sie Ihre Pod-Spezifikation noch einmal bereit und prüfen Sie, ob der Pod wieder auf die Filestore-Freigabe zugreifen kann.

Auf Filestore-Instanzen mit dem Filestore-CSI-Treiber zugreifen

Vorteile

Voraussetzungen

Hinweise

Filestore-CSI-Treiber auf einem neuen Cluster aktivieren

gcloud

Console

Filestore-CSI-Treiber auf einem vorhandenen Cluster aktivieren

gcloud

Console

Filestore-CSI-Treiber deaktivieren

gcloud

Console

Mit dem Filestore-CSI-Treiber auf bereits vorhandene Filestore-Instanzen zugreifen

Für den Zugriff auf die Instanz ein PersistentVolume und einen PersistentVolumeClaim erstellen

Mit dem Filestore-CSI-Treiber ein Volume erstellen

StorageClass erstellen

Mit einem PersistentVolumeClaim auf das Volume zugreifen

Deployment erstellen, das das Volume nutzt

Filestore-Instanzen mit Labels versehen

fsgroup mit Filestore-Volumes verwenden

IP-Zugriffsregeln mit Filestore-Volumes konfigurieren

Sicherheitsoptionen

Empfehlungen

Filestore mit freigegebener VPC verwenden

Cluster mit freigegebener VPC einrichten

Filestore-CSI-Treiber auf einem neuen Cluster mit freigegebener VPC aktivieren

Autopilot

Standard

StorageClass erstellen, wenn der Filestore-CSI-Treiber mit einer freigegebenen VPC verwendet wird

Einzelne Filestore-Volumes mit einzelner Freigabe neu verbinden

Nächste Schritte