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

Der Filestore-CSI-Treiber ist die primäre Möglichkeit, Filestore zu verwenden Instanzen mit Google Kubernetes Engine (GKE) erstellen. 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 verwendet werden, um Filestore-Sicherungen zu erstellen.

  Bei einer Filestore-Sicherung wird eine differenzielle Kopie der Dateifreigabe erstellt. einschließlich aller Dateidaten und Metadaten und speichert sie 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 richtige GKE verwenden Versionsnummer für Ihre Dienststufe. 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
  • Damit Sie die Filestore-Multishare-Funktion nutzen können, müssen Ihre Cluster die GKE-Version 1.25 oder höher.

• 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 Dateisystemprotokoll NFSv3 in 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.

• Wenn Sie Filestore in einem freigegebene VPC-Netzwerk verwenden möchten, finden Sie weitere Informationen unter 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 container clusters create CLUSTER_NAME \
    --addons=GcpFilestoreCsiDriver \
    --cluster-version=VERSION

Wenn Sie Filestore in einem freigegebene VPC-Netzwerk verwenden möchten, finden Sie weitere Informationen unter Filestore-CSI-Treiber in 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 container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

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 container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

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

1. 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
   

2. 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 verfügbar für den höheren Kapazitätsbereich (10 TiB bis 100 TiB).
• enterprise-rwx mit der Filestore-Enterprise-Stufe Dabei ist jedes Kubernetes-nichtflüchtige Volume einer Filestore-Instanz zugeordnet.
• enterprise-multishare-rwx mit der Filestore-Enterprise-Stufe Dabei ist jedes Kubernetes-nichtflüchtige Volume einer Freigabe eines bestimmten Filestore-Werts zugeordnet. Instanz. Weitere Informationen finden Sie unter Filestore Multishares für Google Kubernetes Engine.
• standard-rwx mit dem Einfache HDD-Dienststufe von Filestore.
• premium-rwx mit dem Grundlegende Filestore-SSD-Dienststufe.

Jede Speicherklasse ist nur in GKE-Clustern verfügbar, die ausgeführt werden in ihre jeweiligen unterstützten GKE-Versionsnummern. Eine Liste mit der für jede Dienststufe erforderlichen 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 zu erstellen. Die automatisch installierten Speicherklassen verwenden die Standardeinstellung Netzwerk, das für GKE-Cluster erstellt wurde. Wenn Sie diese(s) gelöscht haben Netzwerk verwenden oder ein anderes Netzwerk verwenden möchten, müssen Sie eine neue Speicherklasse erstellen. wie in den folgenden Schritten beschrieben. Andernfalls wird die automatisch installierte Speicherklassen funktionieren nicht.

1. 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.
   • Alle unterstützten Filestore-Stufen kann im Parameter tier 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.

2. 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.

1. 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
   

2. 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 für ein Deployment-Manifest wird PersistentVolume verwendet Ressource mit dem Namen pvc-example.yaml.

Eine PersistentVolumeClaim-Ressource kann von mehreren Pods verwendet werden.

1. 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
   

2. 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
   

3. 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. Vorher melden Bereitstellungen keinen READY-Status. 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 Zugriffssteuerung Regeln für Bände. Dieses Feature ist für GKE-Cluster verfügbar, die ausgeführt werden Version 1.29.5 oder höher.

Mit dieser Funktion können Administratoren angeben, welche IP-Adressbereiche Sie dürfen auf eine Filestore-Instanz zugreifen, die dynamisch über GKE Dies erhöht die Sicherheit, da der Zugriff nur autorisierter Personen gewährt wird. insbesondere in Szenarien, in denen der IP-Bereich des GKE-Cluster weit gefasst, sodass die Filestore-Instanz möglicherweise nicht autorisierten Zugriff Nutzenden oder Anwendungen.

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

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 freigegebenen Dateispeichern Berechtigungen für Ihre GKE-Arbeitslasten. Wenn Sie jedoch wissen, Für die Eigentümerschaft und den Zugriff von Dateien sind einige wichtige Konzepte zu verstehen:

• NFS und Nutzerzuordnungen: NFS (Network File System) ist das von Filestore Dabei werden Nutzer auf Clientsystemen (Ihre GKE- Pods) für Nutzer auf dem Filestore-Server. Wenn eine Datei auf dem Server und ein Client mit der Nutzer-ID 1003 eine Verbindung herstellt, hinzufügen.

• Root Squashing und anonUid:

  • Root Squashing ROOT_SQUASH ist eine Sicherheitsfunktion, die verhindert, Clients nicht mit vollen Root-Berechtigungen auf die Filestore-Instanz zugreifen können. Wenn Root Squash aktiviert ist, werden Root-Nutzer auf Clientsystemen einer nicht privilegierten Nutzer, der in der Einstellung anonUid angegeben ist.

  • No Root Squashing (NO_ROOT_SQUASH) ermöglicht Clients den Zugriff auf Filestore-Instanz mit vollständigen Root-Berechtigungen. Dies ist praktisch für bei der Ersteinrichtung, aber weniger sicher für den normalen Betrieb.

• Ersteinrichtung und Berechtigungen: Standardmäßig wird eine neue Filestore-Instanz die vollständig dem Root-Nutzer gehören. Wenn Sie Root Squashing aktivieren, ohne zuvor wenn Sie Berechtigungen für andere Nutzer einrichten, verlieren Sie den Zugriff. Aus diesem Grund Sie benötigen anfangs mindestens eine NFS-Exportregel mit NO_ROOT_SQUASH Konfigurieren Sie den Zugriff für andere Nutzer und Gruppen.

Empfehlungen

• Ersteinrichtung:Beginnen Sie immer mit mindestens einer NFS-Exportregel, die gibt einen Administratorbereich mit Berechtigungen vom Typ READ_WRITE an und erlaubt NO_ROOT_SQUASH-Zugriff. Verwenden Sie diesen Zugriff, um Verzeichnisse zu erstellen, Berechtigungen erteilen und die Eigentumsrechte zuweisen.
• Sicherheit:Aktivieren Sie Root Squashing (ROOT_SQUASH), um die Sicherheit zu verbessern. Beachten Sie, dass Sie nach dem Erstellen eines Volumes nur die Zugriffsregeln ändern können über die Filestore API.
• Gemeinsamer Zugriff: Verwenden Sie fsGroup für die Pod-Sicherheit. Kontexte um die Gruppeninhaberschaft von freigegebenen Volumes zu verwalten. Achten Sie darauf, dass sich die mit dem Modus ROOT_SQUASH. Dadurch wird ein Access denied zurückgegeben. Fehlermeldung erhalten.

Filestore mit freigegebene VPC verwenden

In diesem Abschnitt wird beschrieben, wie Sie eine Filestore-Instanz auf einem Freigegebene VPC-Netzwerk aus einem Dienstprojekt.

Cluster mit freigegebener VPC einrichten

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

1. Erstellen Sie ein Host- und Dienstprojekt.
2. Aktivieren Sie die Google Kubernetes Engine API in Ihren Host- und in Ihren Dienstprojekten.
3. Erstellen Sie in Ihrem Hostprojekt ein Netzwerk und ein Subnetz.
4. Aktivieren Sie die freigegebene VPC im Hostprojekt.
5. Im Hostprojekt die Nutzerrollenbindung HostServiceAgent für die GKE-Dienstkonto des Dienstprojekts.
6. Aktivieren Sie den Zugriff auf private Dienste im freigegebenen VPC-Netzwerk.

Filestore-CSI-Treiber in einem neuen Cluster mit freigegebene VPC aktivieren

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

1. 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 │
   └──────────────────────┴───────────────┴─────────────────────────────┘
   

2. 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
   

3. Erstellen Sie Firewallregeln, um die Kommunikation zwischen Knoten, Pods und Dienste in Ihrem Cluster. Das folgende Beispiel zeigt, wie Sie ein Firewallregel mit dem Namen my-shared-net-rule-2.

   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
   

   Im Beispiel stammen die IP-Werte der Quellbereiche aus dem vorherigen Schritt in dem Sie die verwendbaren Subnetze und sekundären Bereiche überprüft haben.

Speicherklasse erstellen, wenn der Filestore-CSI-Treiber mit freigegebene VPC verwendet wird

Das folgende Beispiel zeigt, wie Sie mit der Filestore-CSI-Treiber mit freigegebene VPC:

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-Mehrfachfreigaben auf GKE-Cluster, auf denen Version 1.23 oder höher ausgeführt wird, finden Sie unter Speicher mit Filestore-Mehrfachfreigaben für GKE optimieren

Einzelne Filestore-Volumes mit einzelner Freigabe neu verbinden

Wenn Sie Filestore mit einer Basis-HDD, einer Basis-SSD oder einer Enterprise-Lösung verwenden (Einzelfreigabe) haben, können Sie diese Anleitung befolgen, um die Verbindung vorhandene Filestore-Instanz zu Ihren GKE-Arbeitslasten hinzufügen.

1. Suchen Sie die Details Ihrer vorab bereitgestellten Filestore-Instanz nach Folgen Sie der Anleitung unter Informationen zu einer bestimmten Instanz abrufen.

2. Stellen Sie die PersistentVolume-Spezifikation noch einmal bereit. Geben Sie im Feld volumeAttributes Ändern Sie die folgenden Felder so, dass sie dieselben Werte wie in Filestore verwenden. Instanz aus Schritt 1:

   • ip: Ändern Sie diesen Wert in die vorab bereitgestellte Filestore-Instanz. IP-Adresse.
   • volume: Ändern Sie diesen Wert in den vorab bereitgestellten Filestore-Wert. den Freigabenamen der Instanz.

3. Stellen Sie die PersistentVolumeClaim-Spezifikation noch einmal bereit. Im volumeName Achten Sie darauf, dass Sie auf denselben Nichtflüchtigen-Namen wie in Schritt 2 verweisen.

4. Bindungsstatus von PersistentVolumeClaim und nichtflüchtigem Speicher prüfen indem Sie kubectl get pvc ausführen.

5. Stellen Sie die Pod-Spezifikation noch einmal bereit und prüfen Sie, ob Ihr Pod auf den wieder die Filestore-Freigabe ausführen.

Nächste Schritte

• Zustandsorientierte Filestore-Arbeitslast in GKE bereitstellen.
• Weitere Informationen über die Freigabe einer Filestore-Enterprise-Instanz mit mehreren nicht flüchtigen Volumes.
• Weitere Informationen zur Verwendung der Volume-Erweiterung
• Volume-Snapshots verwenden
• Weitere Informationen zum CSI-Treiber auf GitHub