Filestore-Multishares für Google Kubernetes Engine verwenden

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In dieser Anleitung erfahren Sie, wie Sie Filestore-Multishares für Google Kubernetes Engine mit dem GKE Filestore-CSI-Treiber verwenden.

Hinweis

  1. Führen Sie zuerst die Einrichtungsschritte aus, die für die Verwendung von Filestore erforderlich sind.

  2. Aktivieren Sie den GKE Filestore-CSI-Treiber (GKE-Version 1.23 oder höher).

Filestore-Multishares mit mehreren Anwendungen verwenden

In diesem Abschnitt wird beschrieben, wie Sie zwei Anwendungen bereitstellen: eine Bereitstellung und eine Statefulset-Instanz, die jeweils eine PPID mit mehreren Filestore-Freigaben verwenden. Außerdem sehen Sie, wie GKE Bin-Pakete (ein Prozess zum effizienten Packen von Anwendungen in Ihre GKE-Knoten) alle Volumes in derselben zugrunde liegenden Filestore Enterprise-Instanz erstellt.

  1. Verwenden Sie die von GKE bereitgestellte PPID oder erstellen Sie eine benutzerdefinierte PPID.

    Nachdem der CSI-Treiber für GKE Filestore aktiviert wurde, können Nutzer mit der folgenden Konfiguration auf die von GKE bereitgestellte Multi-Freigeben-PPID enterprise-multishare-rwx zugreifen. Der CSI-Treiber für GKE Filestore verwendet die dynamische Volume-Bereitstellung, um auf diese PPID zu verweisen und automatisch Persistent Volumes (PVs) für neue Persistent Volume Claims (PVCs) zu erstellen, je nachdem, wie viel die GKE-Arbeitslast benötigt:

    $ kubectl describe sc enterprise-multishare-rwx
    Name:                  enterprise-multishare-rwx
    IsDefaultClass:        No
    Annotations:           components.gke.io/component-name=filestorecsi,components.gke.io/component-version=0.7.2,components.gke.io/layer=addon
    Provisioner:           filestore.csi.storage.gke.io
    Parameters:            instance-storageclass-label=enterprise-multishare-rwx,multishare=true,tier=enterprise
    AllowVolumeExpansion:  True
    MountOptions:          <none>
    ReclaimPolicy:         Delete
    VolumeBindingMode:     WaitForFirstConsumer
    Events:                <none>
    

    Bei Bedarf können Nutzer anhand dieser Vorlage eine benutzerdefinierte PPID erstellen. Beachten Sie dabei die folgenden Benennungsanforderungen:

  2. Erstellen Sie ein Deployment mit mehreren Pod-Replikaten und einem einzelnen PVC.

    Erstellen Sie eine YAML-Konfigurationsdatei, die in etwa so aussieht:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-server-multishare
      labels:
        app: nginx
    spec:
      replicas: 5
      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: test-pvc-fs
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: test-pvc-fs
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: enterprise-multishare-rwx
      resources:
        requests:
          storage: 100Gi
    
    EOF
    
  3. Prüfen Sie die Pod-Replikate.

    a. Führen Sie in der Befehlszeile den folgenden Befehl aus, um den PVC-Status zu prüfen:

      $ kubectl get pvc
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
      test-pvc-fs   Bound    pvc-056d769d-a709-4bb2-b6d3-0361871b27a2   100Gi      RWX            enterprise-multishare-rwx  35m
    

    b. Führen Sie in der Befehlszeile den folgenden Befehl aus, um den Pod-Status zu prüfen:

      $ kubectl get pod
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME                                     READY   STATUS    RESTARTS   AGE
      web-server-multishare-76c9ffb4b5-2dhml   1/1     Running   0          35m
      web-server-multishare-76c9ffb4b5-7mtcb   1/1     Running   0          35m
      web-server-multishare-76c9ffb4b5-csdbd   1/1     Running   0          35m
      web-server-multishare-76c9ffb4b5-rgx82   1/1     Running   0          35m
      web-server-multishare-76c9ffb4b5-zjl27   1/1     Running   0          35m
    
  4. Replikate skalieren.

    a. Führen Sie in der Befehlszeile den folgenden Befehl aus, um das Deployment zu bearbeiten:

      $ kubectl edit deployment web-server-multishare
    

    b. Die Datei wird in der Befehlszeile geöffnet. Suchen Sie das Feld spec.replicas und aktualisieren Sie den Wert auf 10.

    c. Führen Sie in der Befehlszeile den folgenden Befehl aus, um die angewendete Änderung zu sehen:

      $ kubectl get pod
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME                                     READY   STATUS    RESTARTS   AGE
      web-server-multishare-76c9ffb4b5-2dhml   1/1     Running   0          36m
      web-server-multishare-76c9ffb4b5-5ctkf   1/1     Running   0          3s
      web-server-multishare-76c9ffb4b5-7mtcb   1/1     Running   0          36m
      web-server-multishare-76c9ffb4b5-8dwmw   1/1     Running   0          2s
      web-server-multishare-76c9ffb4b5-csdbd   1/1     Running   0          36m
      web-server-multishare-76c9ffb4b5-lndcq   1/1     Running   0          2s
      web-server-multishare-76c9ffb4b5-rgx82   1/1     Running   0          36m
      web-server-multishare-76c9ffb4b5-vtd6p   1/1     Running   0          3s
      web-server-multishare-76c9ffb4b5-xm49s   1/1     Running   0          3s
      web-server-multishare-76c9ffb4b5-zjl27   1/1     Running   0          36m
    

    Sie sehen, dass zehn Pods ausgeführt werden.

    d. Führen Sie in der Befehlszeile den folgenden Befehl aus:

      $ kubectl get deployment
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
      web-server-multishare   10/10   10           10          36m
    

    e. Führen Sie in der Befehlszeile den folgenden Befehl aus, um den PVC-gebundenen Status zu prüfen:

      $ kubectl get pvc
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
      test-pvc-fs   Bound    pvc-056d769d-a709-4bb2-b6d3-0361871b27a2   100Gi      RWX            enterprise-multishare-rwx  37m
    

    f. Führen Sie in der Befehlszeile den folgenden Befehl aus, um das Deployment zu bearbeiten:

      $ kubectl edit deployment web-server-multishare
    

    g. Die Datei wird in der Befehlszeile geöffnet. Suchen Sie das Feld spec.replicas und aktualisieren Sie den Wert auf 2.

    h. Führen Sie in der Befehlszeile den folgenden Befehl aus, um die angewendete Änderung zu sehen:

      $ kubectl get pod
    

    Die Ausgabe sollte in etwa so aussehen:

      NAME                                     READY   STATUS    RESTARTS   AGE
      web-server-multishare-76c9ffb4b5-2dhml   1/1     Running   0          38m
      web-server-multishare-76c9ffb4b5-7mtcb   1/1     Running   0          38m
    
  5. Stellen Sie ein Statefulset bereit.

    Stellen Sie eine zweite Anwendung bereit, die die zugrunde liegende Filestore-Instanz teilt.

    Stellen Sie dazu 200 GiB Speicherplatz bereit und prüfen Sie, ob die gleiche Filestore-Instanz wie in der ersten Anwendung verwendet wird.

    Anschließend skalieren Sie die Anwendung auf neun Replikate mit insgesamt 900 GiB (9 Replikate mit jeweils 100 GiB) und prüfen, ob GKE dieselbe Filestore-Instanz verwendet, indem Sie die Instanz freigeben.

    Erstellen Sie eine YAML-Konfigurationsdatei, die in etwa so aussieht:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
      name: web
    spec:
      serviceName: "nginx"
      replicas: 2
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: k8s.gcr.io/nginx-slim:0.8
            ports:
            - containerPort: 80
              name: web
            volumeMounts:
            - name: test-pvc-multishare
              mountPath: /usr/share/nginx/html
      volumeClaimTemplates:
      - metadata:
          name: test-pvc-multishare
        spec:
          accessModes: [ "ReadWriteMany" ]
          storageClassName: enterprise-multishare-rwx
          resources:
            requests:
              storage: 100Gi
    
    EOF
    
    
  6. Prüfen Sie die zustandsorientierten Replikate und Volumes.

    Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl get pod
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME                                     READY   STATUS    RESTARTS   AGE
    web-0                                    1/1     Running   0          4m48s
    web-1                                    1/1     Running   0          3m32s
    web-server-multishare-76c9ffb4b5-2dhml   1/1     Running   0          57m
    web-server-multishare-76c9ffb4b5-7mtcb   1/1     Running   0          57m
    

    Beachten Sie, dass die ersten beiden Pods mit dem Statefulset verknüpft sind. Die letzten beiden Pods sind dem Deployment zugeordnet.

    Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl get statefulset
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME   READY   AGE
    web    2/2     2m8s
    

    Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl get pvc
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
    test-pvc-fs                 Bound    pvc-056d769d-a709-4bb2-b6d3-0361871b27a2   100Gi      RWX            enterprise-multishare-rwx   54m
    test-pvc-multishare-web-0   Bound    pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7   100Gi      RWX            enterprise-multishare-rwx   114s
    test-pvc-multishare-web-1   Bound    pvc-8b37cd6e-d764-4d38-80d7-d74228536cfe   100Gi      RWX            enterprise-multishare-rwx   38s
    

    Der PVC test-pvc-fs ist dem Deployment web-server-multishare zugeordnet.

    Die PVCs test-pvc-multishare-web-0 und test-pvc-multishare-web-1 sind dem Statefulset zugeordnet.

  7. Skalieren Sie die Replikate von Statefulset.

    Erhöhen Sie die Anzahl der Replikate auf neun. Wenn die Anzahl zunimmt, werden die entsprechenden PVCs erstellt.

    a. Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl  edit statefulset web
    

    b. Die Datei wird in der Befehlszeile geöffnet. Suchen Sie das Feld spec.replicas und aktualisieren Sie den Wert auf 9.

    c. Führen Sie in der Befehlszeile den folgenden Befehl aus, um die angewendete Änderung zu sehen:

    $ kubectl get statefulset
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME   READY   AGE
    web    9/9     13m
    

    d. Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl get deployment
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
    web-server-multishare   2/2     2            2           65m
    

    e. Führen Sie in der Befehlszeile den folgenden Befehl aus:

    $ kubectl get pvc
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
    test-pvc-fs                 Bound    pvc-056d769d-a709-4bb2-b6d3-0361871b27a2   100Gi      RWX            enterprise-multishare-rwx   65m
    test-pvc-multishare-web-0   Bound    pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7   100Gi      RWX            enterprise-multishare-rwx   13m
    test-pvc-multishare-web-1   Bound    pvc-8b37cd6e-d764-4d38-80d7-d74228536cfe   100Gi      RWX            enterprise-multishare-rwx   12m
    test-pvc-multishare-web-2   Bound    pvc-3fcbd132-939f-4364-807a-7c8ac6a3e64e   100Gi      RWX            enterprise-multishare-rwx   5m12s
    test-pvc-multishare-web-3   Bound    pvc-5894afa5-2502-4ee7-9d5c-b7378cb85479   100Gi      RWX            enterprise-multishare-rwx   4m57s
    test-pvc-multishare-web-4   Bound    pvc-ebbe452b-bc8f-4624-a830-a2094cce0d67   100Gi      RWX            enterprise-multishare-rwx   4m36s
    test-pvc-multishare-web-5   Bound    pvc-5a73a698-d174-44cb-a3a1-e767966c3417   100Gi      RWX            enterprise-multishare-rwx   4m20s
    test-pvc-multishare-web-6   Bound    pvc-102da6a9-2ca6-4f9e-9896-8fe14709db7a   100Gi      RWX            enterprise-multishare-rwx   3m55s
    test-pvc-multishare-web-7   Bound    pvc-160e81cd-c5bf-4ae6-966e-518e8249e02d   100Gi      RWX            enterprise-multishare-rwx   3m38s
    test-pvc-multishare-web-8   Bound    pvc-9b52d773-2e9a-40de-881c-dc06945ba3d7   100Gi      RWX            enterprise-multishare-rwx   118s
    
  8. Prüfen Sie den Filestore-Instanzstatus.

    Sie haben jetzt ein Deployment mit zwei Replikat-Pods und einem Statefulset mit neun Replikat-Pods und insgesamt zehn PVCs mit einer Größe von jeweils 100 GiB. Alle Volumes sind in einer einzelnen Filestore-Multishare-Instanz gepackt.

    a. Führen Sie in der Befehlszeile den folgenden instances list-Befehl aus:

    $  gcloud beta filestore instances list --project=YOUR_PROJECT_ID --region=REGION
    

    wobei

    • YOUR_PROJECT_ID ist der Name des verwendeten Projekts. Beispiel: my-project

    • REGION ist der Name der verwendeten Region. Beispiel: us-central1

    Die Ausgabe sollte in etwa so aussehen:

    INSTANCE_NAME                            LOCATION     TIER        CAPACITY_GB  FILE_SHARE_NAME  IP_ADDRESS   STATE  CREATE_TIME
    fs-a767cef8-738e-4c8e-b70b-09cbb872d016  us-central1  ENTERPRISE  1024         N/A              10.192.53.2  READY  2022-06-21T21:15:30
    

    b. Führen Sie in der Befehlszeile den folgenden instances describe-Befehl aus:

    $ gcloud filestore instances describe fs-a767cef8-738e-4c8e-b70b-09cbb872d016 --project=YOUR_PROJECT_ID --region=REGION
    capacityGb: '1024'
    capacityStepSizeGb: '256'
    createTime: '2022-06-21T21:15:30.464237089Z'
    labels:
      storage_gke_io_created-by: filestore_csi_storage_gke_io
      storage_gke_io_storage-class-id: enterprise-multishare-rwx
    maxCapacityGb: '10240'
    maxShareCount: '10'
    multiShareEnabled: true
    name: projects/YOUR_PROJECT_ID/locations/REGION/instances/fs-a767cef8-738e-4c8e-b70b-09cbb872d016
    networks:
    - connectMode: DIRECT_PEERING
      ipAddresses:
      - 10.192.53.2
      modes:
      - MODE_IPV4
      network: csi-filestore-test-network
      reservedIpRange: 10.192.53.0/26
    state: READY
    tier: ENTERPRISE
    
    

    wobei

    • YOUR_PROJECT_ID ist der Name des verwendeten Projekts. Beispiel: my-project

    • REGION ist der Name der verwendeten Region. Beispiel: us-central1

PVC maximieren und Filestore-Instanz prüfen

In diesem Abschnitt erfahren Sie, wie Sie einen vorhandenen PVC erweitern und die Größe der Filestore-Instanz prüfen.

  1. PVC maximieren.

    PVCs, die durch Freigaben in einer Filestore-Multishare-Instanz gesichert werden, können auf eine maximale Größe von 1 TiB steigen. Maximieren Sie dazu eines der Volumes, die mit dem Statefulset verknüpft sind, während der Pod es verwendet.

    Führen Sie in der Befehlszeile den folgenden Befehl aus, um die aktuelle PVC-Größe des Replikats 0 zu prüfen:

    $ kubectl get pvc test-pvc-multishare-web-0 -o json
    {
        "apiVersion": "v1",
        "kind": "PersistentVolumeClaim",
        "metadata": {
            "annotations": {
                "pv.kubernetes.io/bind-completed": "yes",
                "pv.kubernetes.io/bound-by-controller": "yes",
                "volume.beta.kubernetes.io/storage-provisioner": "filestore.csi.storage.gke.io",
                "volume.kubernetes.io/storage-provisioner": "filestore.csi.storage.gke.io"
            },
            "creationTimestamp": "2022-06-21T22:07:42Z",
            "finalizers": [
                "kubernetes.io/pvc-protection"
            ],
            "labels": {
                "app": "nginx"
            },
            "name": "test-pvc-multishare-web-0",
            "namespace": "default",
            "resourceVersion": "48395",
            "uid": "7aa21b5a-5343-4547-b7d7-414c16af15a7"
        },
        "spec": {
            "accessModes": [
                "ReadWriteMany"
            ],
            "resources": {
                "requests": {
                    "storage": "100Gi"
                }
            },
            "storageClassName": "enterprise-multishare-rwx",
            "volumeMode": "Filesystem",
            "volumeName": "pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7"
        },
        "status": {
            "accessModes": [
                "ReadWriteMany"
            ],
            "capacity": {
                "storage": "100Gi"
            },
            "phase": "Bound"
        }
    }
    
    
  2. Führen Sie in der Befehlszeile den folgenden Befehl aus, um die Größe auf 500 GiB zu erhöhen:

    $ kubectl edit pvc test-pvc-multishare-web-0
    
    
  3. Die Datei wird in der Befehlszeile geöffnet. Suchen Sie das Feld spec.resources.requests.storage und aktualisieren Sie den Wert in 500Gi.

  4. Führen Sie in der Befehlszeile den folgenden Befehl aus, um die angewendete Änderung zu sehen:

    $ kubectl get pvc test-pvc-multishare-web-0
    

    Die Ausgabe sollte in etwa so aussehen:

    NAME                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS               AGE
    test-pvc-multishare-web-0   Bound    pvc-7aa21b5a-5343-4547-b7d7-414c16af15a7   500Gi      RWX            enterprise-multishare-rwx   28m
    

    Der Filestore-CSI-Treiber hat die Anfrage akzeptiert, zuerst die zugrunde liegende Filestore-Instanz erweitert und dann den Anteil, der den PVC unterstützt.

    Insbesondere hat der Filestore-CSI-Treiber die Instanz automatisch auf 1536 Gi erweitert, um die neue Freigabegröße von 500 Gi zu berücksichtigen.

  5. Führen Sie in der Befehlszeile den folgenden instances describe-Befehl aus, um die Kapazität der Filestore-Instanz zu überprüfen:

    $ gcloud filestore instances describe fs-a767cef8-738e-4c8e-b70b-09cbb872d016 --project=YOUR_PROJECT_ID --region=REGION
    capacityGb: '1536'
    capacityStepSizeGb: '256'
    createTime: '2022-06-21T21:15:30.464237089Z'
    labels:
      storage_gke_io_created-by: filestore_csi_storage_gke_io
      storage_gke_io_storage-class-id: enterprise-multishare-rwx
    maxCapacityGb: '10240'
    maxShareCount: '10'
    multiShareEnabled: true
    name: projects/YOUR_PROJECT_ID/locations/us-central1/instances/fs-a767cef8-738e-4c8e-b70b-09cbb872d016
    networks:
    - connectMode: DIRECT_PEERING
      ipAddresses:
      - 10.192.53.2
      modes:
      - MODE_IPV4
      network: csi-filestore-test-network
      reservedIpRange: 10.192.53.0/26
    state: READY
    tier: ENTERPRISE
    

    wobei

    • YOUR_PROJECT_ID ist der Name des verwendeten Projekts. Beispiel: my-project

    • REGION ist der Name der verwendeten Region. Beispiel: us-central1

Dynamische Bereitstellung in einer freigegebenen VPC

Der Filestore-CSI-Treiber für GKE unterstützt die dynamische Bereitstellung von Volumes in einem Dienstprojekt unter einer freigegebenen VPC. Im folgenden Abschnitt wird gezeigt, wie Sie mit dem Filestore-CSI-Treiber dynamisch Volumes auf Filestore-Multishare-Instanzen in einem Dienstprojekt in einem freigegebenen VPC-Netzwerk bereitstellen.

  1. Führen Sie die Einrichtungsschritte für ein freigegebenes VPC-Netzwerk und privaten Dienstzugriff aus.

  2. Erstellen Sie eine PPID zur dynamischen Bereitstellung von Volumes, die von einer Filestore-Instanz mit mehreren Freigaben in einer freigegebenen VPC unterstützt werden.

    Führen Sie den folgenden Befehl aus, um eine StorageClass-Ressource bereitzustellen:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: csi-filestore-multishare-sharedvpc
    provisioner: filestore.csi.storage.gke.io
    parameters:
      network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
      connect-mode: PRIVATE_SERVICE_ACCESS
      tier: enterprise
      multishare: "true"
    allowVolumeExpansion: true
    
    EOF
    

    wobei

    • HOST_PROJECT_ID ist die ID oder der Name des Hostprojekts des freigegebenen VPC-Netzwerks. Beispiel: my-host-project

    • SHARED_VPC_NAME ist der Name des freigegebenen VPC-Netzwerks. Beispiel: my-shared-vpc

    Wenn Sie Ihre Ressource in einem reservierten IP-Adressbereich bereitstellen möchten, fügen Sie den Parametern im Befehl die folgende Zeile hinzu:

    reserved-ip-range: RESERVED_NAME
    

    Dabei ist RESERVED_NAME der Name des reservierten IP-Adressbereichs, in dem eine Filestore-Instanz bereitgestellt werden kann. Beispiel: filestore-reserved-ip-range Wenn ein reservierter IP-Bereich angegeben ist, muss es sich um einen benannten Adressbereich anstelle eines direkten CIDR-Werts handeln.

    Weitere Informationen finden Sie unter IP-Adressbereiche zuweisen oder Einen reservierten IP-Adressbereich konfigurieren. Ein Beispiel zum Erstellen eines reservierten Namens mit der Google Cloud Console finden Sie unter IP-Zuweisung erstellen.

  3. Deployment erstellen.

    Führen Sie den folgenden Befehl aus, um eine Deployment-Ressource zu erstellen:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-server-multishare
      labels:
        app: nginx
    spec:
      replicas: 5
      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: test-pvc-fs-sharedvpc
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: test-pvc-fs-sharedvpc
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: csi-filestore-multishare-sharedvpc
      resources:
        requests:
          storage: 100Gi
    
    EOF
    
    

CMEK-fähige Filestore-Instanzen

Sie können GKE-Volumes erstellen, die auf CMEK-fähigen Filestore-Instanzen mit mehreren Dateifreigaben gehostet werden. In diesem Abschnitt wird beschrieben, wie Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel (CMEK) für Ihre Filestore-Instanz einrichten.

Details zum vom Kunden verwalteten Schlüssel können in der PPID angegeben werden. Für jede dynamisch vom Filestore-CSI-Treiber erstellte Instanz, die auf diese PPID verweist, ist CMEK aktiviert.

  1. Erstellen Sie eine CMEK-fähige PPID.

    a. Führen Sie dazu diesen Befehl aus:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: csi-filestore-multishare-cmek
    provisioner: filestore.csi.storage.gke.io
    parameters:
      tier: enterprise
      multishare: "true"
      instance-encryption-kms-key: projects/KEY_PROJECT_ID/locations/REGION/keyRings/RING_NAME/cryptoKeys/KEY_NAME
    
    allowVolumeExpansion: true
    
    EOF
    

    wobei

    • KEY_PROJECT_ID ist der Name des Projekts, in dem sich der Schlüssel befindet. Beispiel: my-key-project

    • REGION ist der Name der verwendeten Region. Beispiel: us-central1

    • RING_NAME ist der Schlüsselbundname. Beispiel: my-key-ring-name.

    • KEY_NAME ist der Schlüsselname. Beispiel: my-key-name.

  2. Deployment erstellen.

    b. Führen Sie den folgenden Befehl aus, um eine Deployment-Ressource zu erstellen:

    cat <<EOF | kubectl apply -f -
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-server-multishare
      labels:
        app: nginx
    spec:
      replicas: 5
      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: test-pvc-fs-cmek
    ---
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: test-pvc-fs-cmek
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: csi-filestore-multishare-cmek
      resources:
        requests:
          storage: 100Gi
    
    EOF
    
    

PVCs zu Filestore-Instanzen zuordnen

In diesem Abschnitt wird beschrieben, wie Sie Ihre PVCs Ihren Filestore-Instanzen zuordnen.

Bei Filestore-Multishare-Instanzen wird jeder PVC vom Filestore-CSI-Treiber auf einer Filestore-Instanz gehostet. Die Details der zugrunde liegenden Filestore-Instanz, die das Volume hostet, und die Freigabe, die das Kubernetes-Volume darstellt, werden im Feld volumeHandle der Spezifikation für nichtflüchtige Volumes erfasst. Das Format des Volume-Handles sieht so aus:

   modeMultishare/<storageclass-prefix>/<project>/<region>/<filestore-instance-name>/<filestore-share-name>

Mit dem folgenden kubectl-Befehl können Sie die Zuordnungen zwischen einer PVC, einem PV, einer Filestore-Instanz und einer Filestore-Freigabe schnell ermitteln.

Führen Sie in der Befehlszeile den folgenden Befehl aus:

   $ kubectl get pv -o jsonpath='{range .items[*]}{"pv="}{.metadata.name}{",pvc="}{.spec.claimRef.name}{",volumeHandle="}{.spec.csi.volumeHandle}{"\n"}{end}'

Die Ausgabe sollte in etwa so aussehen:

   pv=pvc-67ad9abd-f25e-4130-b7ca-64d28bd29525,pvc=test-pvc-multishare,volumeHandle=modeMultishare/csi-filestore-multishare-sharedvpc/YOUR_PROJECT_ID/us-central1/fs-2109f680-3f04-4ada-b4bc-2a1c7fc47b88/pvc_67ad9abd_f25e_4130_b7ca_64d28bd29525

   pv=pvc-c80f4de0-9916-4957-b8ae-b21206650ac0,pvc=test-pvc-fs-sharedvpc,volumeHandle=modeMultishare/csi-filestore-multishare-sharedvpc/YOUR_PROJECT_ID/us-central1/fs-2109f680-3f04-4ada-b4bc-2a1c7fc47b88/pvc_c80f4de0_9916_4957_b8ae_b21206650ac0

wobei

  • YOUR_PROJECT_ID ist der Name des verwendeten Projekts. Beispiel: my-project

Beachten Sie, dass zwei nichtflüchtige Volumes im Cluster in einer einzigen Filestore-Instanz gehostet werden.

Nächste Schritte