Persistenten Dateisystemspeicher mit dem CSI-Volume-Plug-in erstellen

Auf Compute Cloud@Customer können Sie mit dem CSI-Volume-Plug-in ein PVC auf einem neuen Dateisystem bereitstellen. Verwenden Sie den Befehl kubectl, um die Speicherklasse und den Persistent Volume Claim zu erstellen. Das CSI-Volume-Plug-in stellt das PVC auf einem neuen Dateisystem bereit.

Sie können nur ein Mountziel und ein Dateisystem pro VCN verwenden. Pro Cluster können mehrere Speicherklassen, persistente Volumes und Persistent Volume Claims vorhanden sein. Alle Speicherklassen, persistenten Volumes und Persistent Volume Claims in einem Cluster verwenden ein NFS gemeinsam.

  1. Erstellen Sie eine neue Speicherklasse, die den Provisioning-Vorgang fss.csi.oraclecloud.com verwendet.

    $ kubectl create -f sc.yaml

    Der Inhalt der Manifestdatei sc.yaml lautet wie folgt:

    kind: StorageClass
    apiVersion: storage.k8s.io/v1
    metadata:
      name: fss-dyn-storage
    provisioner: fss.csi.oraclecloud.com
    parameters:
      availabilityDomain: AD-1
      compartmentOcid: ocid1.compartment.unique_ID
      mountTargetSubnetOcid: ocid1.subnet.unique_ID
      exportPath: AUTOSELECT
      exportOptions: "[{\"source\":\"0.0.0.0/0\",\"requirePrivilegedSourcePort\":false,\"access\":\"READ_WRITE\",\"identitySquash\":\"NONE\"}]"
      encryptInTransit: "false"
    • Der Name für die neue Speicherklasse lautet fss-dyn-storage.

    • Entweder mountTargetSubnetOcid oder mountTargetOcid ist erforderlich. Der Wert von mountTargetSubnetOcid ist die OCID des Subnetzes, in dem das CSI-Plug-in ein Mountziel erstellen soll. Der Wert von mountTargetOcid ist die OCID eines vorhandenen Mountziels. Wenn Sie sowohl mountTargetSubnetOcid als auch mountTargetOcid angeben, wird mountTargetOcid verwendet, und mountTargetSubnetOcid wird ignoriert.

      Um sicherzustellen, dass das Mountziel von Worker-Knoten aus erreicht werden kann, geben Sie das Subnetz an, das eine Konfiguration wie das unter OKE-Netzwerkressourcen erstellen beschriebene Subnetz "Worker" aufweist, oder erstellen Sie das Mountziel in dem Subnetz, das eine Konfiguration wie das Worker-Subnetz aufweist. Stellen Sie sicher, dass der TCP-Port 2049 für den NFS-Server in diesem Subnetz geöffnet ist.

    • Die Angabe von compartmentOcid ist optional. Dieser Wert ist die OCID des Compartments, in dem das neue Dateisystem (und das neue Mountziel, wenn mountTargetSubnetOcid angegeben ist) erstellt wird. Der Standardwert ist dasselbe Compartment wie das Cluster.

    • Sie müssen AUTOSELECT als Wert für exportPath angeben.

    • Der Wert exportOptions ist der Eintrag für NFS-Exportoptionen im Dateisystemexport, der den Zugriff definiert, der NFS-Clients bei der Verbindung mit einem Mountziel erteilt wird. Bei source kann es sich um eine einzelne IP-Adresse oder einen CIDR-Blockbereich handeln. Dieser Wert ist eine Gruppe von Parametern im JSON-Format.

    • Der Wert von encryptInTransit gibt an, ob Daten während der Übertragung verschlüsselt werden sollen.

  2. Erstellen Sie einen PVC, der vom neuen Dateisystem im File Storage-Service bereitgestellt werden soll.

    $ kubectl create -f fss-dyn-claim.yaml

    Der Inhalt der Manifestdatei fss-dyn-claim.yaml lautet wie folgt:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: fss-dynamic-claim
    spec:
      accessModes:
      - ReadWriteMany
      storageClassName: "fss-dyn-storage"
      resources:
        requests:
          storage: 50Gi
  3. Prüfen Sie, ob der PVC an das neue Persistent Volume gebunden wurde.

    $ kubectl get pvc
    NAME              STATUS VOLUME                                       CAPACITY ACCESS MODES STORAGECLASS    AGE
    fss-dynamic-claim Bound  csi-fss-f6823a66-8b6f-4c42-9d1f-d25723e69257 50Gi     RWX          fss-dyn-storage 6m47s
  4. Verwenden Sie das neue PVC, wenn Sie Objekte wie Pods erstellen.

    Im Folgenden finden Sie ein Beispiel für die Objekterstellung:

    $ kubectl create nginx.yaml

    Im Folgenden finden Sie den Inhalt der Datei nginx.yaml. Siehe claimName in der letzten Zeile:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx_image_url
            ports:
            - name: http
              containerPort: 80
            volumeMounts:
            - name: persistent-storage
              mountPath: /usr/share/nginx/html
          volumes:
          - name: persistent-storage
            persistentVolumeClaim:
              claimName: fss-dynamic-claim

    Prüfen Sie, ob das Objekt erstellt und bereitgestellt wurde:

    $ kubectl get deploy
    NAME             READY UP-TO-DATE AVAILABLE AGE
    nginx-deployment 3/3   3          0         104s