Creazione di una memorizzazione persistente del file system mediante il plugin volume CSI

In Compute Cloud@Customer, puoi eseguire il provisioning di un PVC su un nuovo file system utilizzando il plugin del volume CSI. Utilizzare il comando kubectl per creare la classe di storage e la richiesta di volume persistente. Il plugin volume CSI esegue il provisioning del PVC su un nuovo file system.

Puoi avere una sola destinazione di accesso e un solo file system per ogni VCN. Puoi avere più classi di storage, volumi persistenti e richieste di volume persistenti per cluster. Tutte le classi di storage, i volumi persistenti e le richieste di volume persistenti in un cluster condividono un NFS.

1. Creare una nuova classe di storage che utilizzi il provisioning fss.csi.oraclecloud.com.

   $ kubectl create -f sc.yaml

   Di seguito è riportato il contenuto del file manifesto sc.yaml:

   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"

   • Il nome della nuova classe di storage è fss-dyn-storage.

   • È necessario specificare mountTargetSubnetOcid o mountTargetOcid. Il valore mountTargetSubnetOcid è l'OCID della subnet in cui si desidera che il plugin CSI crei una destinazione di accesso. Il valore mountTargetOcid è l'OCID di una destinazione di accesso esistente. Se si specificano sia mountTargetSubnetOcid che mountTargetOcid, viene utilizzato mountTargetOcid e mountTargetSubnetOcid viene ignorato.

     Per assicurarsi che la destinazione di accesso possa essere raggiunta dai nodi di lavoro, specificare la subnet con configurazione simile a quella della subnet "worker" descritta in Creazione di una subnet di worker (overlay del canale) o Creazione di una subnet di worker (VCN-Native Pod) o creare la destinazione di accesso nella subnet con configurazione simile alla subnet di lavoro. Assicurarsi che la porta TCP 2049 sul server NFS sia aperta in tale sottorete.

   • compartmentOcid è facoltativo. Questo valore è l'OCID del compartimento in cui verrà creato il nuovo file system (e la nuova destinazione di accesso, se si specifica mountTargetSubnetOcid). Il valore predefinito è lo stesso compartimento del cluster.

   • È necessario specificare AUTOSELECT come valore per exportPath.

   • Il valore exportOptions è la voce delle opzioni di esportazione NFS all'interno dell'esportazione del file system che definisce l'accesso concesso ai client NFS quando si connettono a una destinazione di accesso. source può essere un singolo indirizzo IP o un intervallo di blocchi CIDR. Questo valore è un set di parametri in formato JSON.

   • Il valore encryptInTransit specifica se cifrare i dati in transito.

2. Creare un PVC di cui eseguire il provisioning dal nuovo file system nel servizio di storage di file.

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

   Di seguito è riportato il contenuto del file manifesto fss-dyn-claim.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: fss-dynamic-claim
   spec:
     accessModes:
     - ReadWriteMany
     storageClassName: "fss-dyn-storage"
     resources:
       requests:
         storage: 50Gi

3. Verificare che il PVC sia stato associato al nuovo volume persistente.

   $ 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. Utilizzare il nuovo PVC quando si creano oggetti come i pod.

   Di seguito è riportato un esempio di creazione di oggetti.

   $ kubectl create nginx.yaml

   Di seguito è riportato il contenuto del file nginx.yaml. Vedere il claimName sull'ultima riga:

   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

   Verificare che l'oggetto sia stato creato e distribuito:

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