Tipi di archiviazione file

Scegli il tipo di File Storage for Classic che desideri configurare.

Classi di stoccaggio di bronzo, argento e oro

Queste classi di memoria eseguono il provisioning dell'archiviazione Endurance. L'archiviazione Endurance ti consente di scegliere la dimensione dell'archiviazione in gigabyte in livelli IOPS predefiniti.

Classe di archiviazione personalizzata

Questa classe di archiviazione fornisce l'archiviazione delle prestazioni. Con l'archiviazione Performance, hai più controllo sulla dimensione dell'archiviazione e sull'IOPS.

IOPS

Scegli la dimensione e l'IOPS per File Storage for Classic. La dimensione e il numero di IOPS definiscono il numero totale di IOPS (operazioni di input/ output al secondo) che funge da indicatore della rapidità della tua archiviazione. Più IOPS totale ha la tua archiviazione e più rapidamente elabora le operazioni di lettura e scrittura.

Classi di stoccaggio di bronzo, argento e oro

Queste classi di archiviazione offrono un numero fisso di IOPS per gigabyte e vengono fornite su dischi SSD. Il numero totale di IOPS dipende dalla dimensione dell'archiviazione che scegli. Puoi selezionare qualsiasi numero intero di gigabyte all'interno dell'intervallo di dimensioni consentite, come ad esempio 20 Gi, 256 Gi o 11854 Gi. Per determinare il numero totale di IOPS, devi moltiplicare l'IOPS con la dimensione selezionata. Ad esempio, se selezioni una dimensione di File Storage for Classic di 1000 Gi nella classe di archiviazione silver che viene fornita con 4 IOPS per GB, la tua archiviazione ha un totale di 4000 IOPS.

Classe di archiviazione personalizzata

Scegliendo questa classe di archiviazione, avrai un maggiore controllo sulle dimensioni e sugli IOPS desiderati. Per la dimensione, puoi selezionare qualsiasi numero intero di gigabyte all'interno dell'intervallo di dimensioni consentito. La dimensione da te scelta determina l'intervallo IOPS a tua disposizione. Puoi scegliere un IOPS che è un multiplo di 100 che è compreso nell'intervallo specificato. L'IOPS che scegli è statico e non ridimensiona l'archiviazione. Ad esempio, se scegli 40Gi con 100 IOPS, l'IOPS totale rimane 100.

Anche il rapporto IOPS-gigabyte determina il tipo di disco rigido di cui viene eseguito il provisioning per tuo conto. Ad esempio, se hai 500Gi a 100 IOPS, il tuo rapporto IOPS-gigabyte è 0,2. Il provisioning dell'archiviazione con un rapporto inferiore o uguale a 0,3 viene eseguito sui dischi rigidi SATA. Se il tuo rapporto è superiore a 0,3, il provisioning della tua archiviazione viene eseguito su dischi rigidi SSD.

Politica di riacquisizione

Scegli se vuoi mantenere i tuoi dati dopo l'eliminazione del cluster o dell'attestazione del volume persistente (PVC, persistent volume claim).

• Se vuoi conservare i tuoi dati, scegli una classe di archiviazione retain. Quando elimini la PVC, viene eliminata solo la PVC. Il PV, il dispositivo di archiviazione fisico nel tuo account dell'infrastruttura IBM Cloud e i tuoi dati permangono. Per reclamare l'archiviazione e utilizzarla nuovamente nel tuo cluster, devi rimuovere il PV e attenerti alla procedura per l'utilizzo del File Storage for Classic esistente.
• Se vuoi che il PV, i dati e il tuo dispositivo File Storage for Classic fisico vengano eliminati quando elimini la PVC, scegli una classe di archiviazione senza retain.

Tipo di fatturazione

Scegli oraria o mensile. Controlla i prezzi per ulteriori informazioni.

Per impostazione predefinita, il provisioning di tutti i dispositivi di File Storage for Classic viene eseguito con un tipo di fatturazione oraria.

Se scegli un tipo di fatturazione mensile, quando rimuovi l'archiviazione persistente pagherai comunque l'addebito mensile, anche se l'hai utilizzata solo per un breve periodo di tempo.

Preparazione della memoria esistente

Prima di poter iniziare a montare la tua archiviazione esistente in un'applicazione, devi richiamare tutte le informazioni necessarie per il tuo PV e preparare l'archiviazione in modo che sia accessibile nel tuo cluster.

Per lo spazio di archiviazione provisionato con una classe di archiviazione “ retain ”.

Se hai eseguito il provisioning con una classe di archiviazione retain e rimuovi la PVC, il PV e il dispositivo di archiviazione fisico non vengono rimossi automaticamente. Per riutilizzare l'archiviazione nel tuo cluster, devi rimuovere prima il PV rimanente.

Per utilizzare l'archiviazione esistente in un cluster diverso da quello dove ne hai eseguito il provisioning, attieniti alla procedura per l'archiviazione che era stata creata esternamente al cluster per aggiungere l'archiviazione alla sottorete del tuo nodo di lavoro.

1. Elenca i PV esistenti.

   kubectl get pv
   

   Cerca il PV che appartiene alla tua archiviazione persistente. Il PV è in uno stato released.

2. Ottieni i dettagli del PV.

   kubectl describe pv <pv_name>
   

3. Prendi nota di CapacityGb, storageClass, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, server e path.

4. Rimuovi il PV.

   kubectl delete pv <pv_name>
   

5. Verifica che il PV venga rimosso.

   kubectl get pv
   

Per lo storage persistente provisionato al di fuori del cluster

Se vuoi utilizzare l'archiviazione esistente di cui avevi eseguito il provisioning in precedenza ma che non hai mai usato nel tuo cluster in precedenza, devi renderla disponibile nella stessa sottorete dei tuoi nodi di lavoro.

1. Dal portale dell'infrastruttura IBM Cloud, fare clic su “Storage ”.
2. Fai clic su File Storage for Classic e, dal menu Actions, seleziona Authorize Host.
3. Seleziona Subnets.
4. Dall'elenco a discesa, seleziona la sottorete VLAN privata a cui è connesso il nodo di lavoro. Per individuare la sottorete del tuo nodo di lavoro, esegui il comando ibmcloud ks worker ls --cluster <cluster_name> e confronta l'indirizzo Private IP del tuo nodo di lavoro con la sottorete che hai individuato nell'elenco a discesa.
5. Fai clic su Submit.
6. Fai clic sul nome del File Storage for Classic.
7. Prendi nota dei campi Mount Point, size e Location. Il campo " Mount Point " viene visualizzato come " <nfs_server>:<file_storage_path>".

Creazione di un volume persistente e di un'attestazione del volume persistente

1. Crea un file di configurazione dell'archiviazione per il tuo PV. Includi i valori che hai richiamato in precedenza.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   Immetti il nome dell'oggetto del PV da creare.

   labels

   Immetti la regione e la zona che hai richiamato in precedenza. Devi avere almeno un nodo di lavoro nella stessa regione e zona.

   storage

   Immetti la dimensione di archiviazione della condivisione file NFS esistente che hai richiamato in precedenza. La dimensione di archiviazione deve essere scritta in gigabyte, ad esempio, 20Gi (20 GB) o 1000Gi (1 TB) e deve corrispondere alla dimensione della condivisione file esistente.

   accessMode

   Specificare una delle seguenti opzioni.

   • ReadWriteMany: Il PVC può essere montato su più moduli. Tutti i pod possono leggere dal e scrivere nel volume.
   • ReadOnlyMany: Il PVC può essere montato su più moduli. Tutti i pod hanno un accesso di sola lettura.
   • ReadWriteOnce: Il PVC può essere montato solo su un pod. Questo pod può leggere dal e scrivere nel volume.

   server

   Immetti l'ID server della condivisione file NFS che hai richiamato in precedenza.

   path

   Immetti il percorso alla condivisione file NFS che hai richiamato in precedenza.

2. Crea il PV nel tuo cluster.

   kubectl apply -f mypv.yaml
   

3. Verifica che il PV sia stato creato.

   kubectl get pv
   

4. Crea un altro file di configurazione per creare la tua PVC. Affinché la PVC corrisponda al PV che hai creato in precedenza, devi scegliere lo stesso valore per storage e accessMode. Il campo storage-class deve essere una stringa vuota. Se uno qualsiasi di questi campi non corrisponde al PV, viene provisionato dinamicamente un nuovo PV e una nuova istanza di archiviazione fisica.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. Crea la tua PVC.

   kubectl apply -f mypvc.yaml
   

6. Verifica che la tua PVC sia stata creata e associata al PV.

   kubectl describe pvc mypvc
   

   Output di esempio

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

Hai creato correttamente un PV e lo hai collegato ad una PVC. Gli utenti del cluster possono ora montare la PVC nelle proprie distribuzioni e iniziare a leggere e a scrivere sull'oggetto del PV.

Creazione della PVC quando crei una serie con stato utilizzando il provisioning dinamico

Utilizza questa opzione se vuoi creare automaticamente la PVC quando crei la serie con stato.

Prima di iniziare: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

1. Verifica che tutte le serie con stato esistenti nel tuo cluster siano state completamente distribuite. Se un set con stato è ancora in fase di distribuzione, non è possibile iniziare a creare il proprio set con stato. Devi attendere che tutte le serie con stato nel tuo cluster vengano distribuite completamente per evitare risultati imprevisti. Elenca le serie con stato esistenti nel tuo cluster.

   kubectl get statefulset --all-namespaces
   

   Output di esempio

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. Visualizza la sezione Pods Status di ogni serie con stato per assicurarti che la distribuzione della serie con stato sia terminata.

   kubectl describe statefulset <statefulset_name>
   

   Output di esempio

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   

   Una serie con stato è completamente distribuita quando il numero di repliche che trovi nella sezione Replicas dell'output della CLI è uguale al numero di pod in stato Running nella sezione Pods Status. Se una serie con stato non è ancora completamente distribuita, attendi fino al termine della distribuzione prima di procedere.

3. Crea un file di configurazione per la tua serie con stato e il servizio che utilizzi per esporre la serie con stato.

   Esempio di insieme con stato che specifica una zona. Il seguente esempio mostra come distribuire NGINX come una serie con stato con 3 repliche. Per ogni replica, viene eseguito il provisioning di un dispositivo File Storage for Classic da 20 gigabyte in base alle specifiche nella classe di archiviazione ibmc-file-retain-bronze. Il provisioning di tutti i dispositivi di archiviazione viene eseguito nella zona dal10. Poiché non è possibile accedere a File Storage for Classic da altre zone, tutte le repliche dello stateful set vengono distribuite anche sui nodi di lavoro situati in dal10.

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
    name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol
             mountPath: /usr/share/nginx/html
       volumeClaimTemplates:
       - metadata:
          name: myvol
         spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 20Gi
              iops: "300" #required only for performance storage
          storageClassName: ibmc-file-retain-bronze
   

   Esempio di “stateful set” con regola di anti-affinità e creazione ritardata dell’ File Storage for Classic. Il seguente esempio mostra come distribuire NGINX come una serie con stato con 3 repliche. La serie con stato non specifica la regione e la zona in cui viene creato File Storage for Classic. La serie con stato utilizza invece una regola anti-affinità per garantire che i pod vengano distribuiti tra i nodi di lavoro e le zone. L'anti-affinità dei nodi di lavoro si ottiene definendo l'etichetta app: nginx. Questa etichetta indica al programma di pianificazione Kubernetes di non pianificare un pod su un nodo di lavoro se un pod con la stessa etichetta viene già eseguito su questo nodo di lavoro. L'etichetta topologykey: failure-domain.beta.kubernetes.io/zone limita ancora di più questa regola di anti-affinità e impedisce che il pod venga pianificato su un nodo di lavoro che si trova nella stessa zona di un nodo di lavoro che già esegue un pod con l'etichetta app: nginx. Per ogni pod di serie con stato, vengono create due PVC, come definito nella sezione volumeClaimTemplates, ma la creazione delle istanze di File Storage for Classic viene ritardata finché non viene pianificato un pod di serie con stato che utilizza l'archiviazione. Questa configurazione è nota come " schedulazione dei volumi sensibile alla topologia ".

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: registry.k8s.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   Nei metadati, immetti un nome per la tua serie con stato. Il nome che inserisci viene utilizzato per creare il nome del tuo PVC nel formato: <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   Nella sezione spec, immetti il nome del servizio che vuoi utilizzare per esporre la tua serie con stato.

   replicas

   Immetti il numero di repliche per la tua serie con stato.

   podManagementPolicy

   Immetti la politica di gestione pod che vuoi utilizzare per la tua serie con stato. Scegli tra le seguenti opzioni.

   • OrderedReady: Con questa opzione, le repliche dello stateful set vengono distribuite una dopo l'altra. Ad esempio, se hai distribuito 3 repliche, Kubernetes crea la PVC per la prima replica, attende che la PVC venga collegata, distribuisce la replica della serie con stato e monta la PVC sulla replica. Al termine della distribuzione, viene distribuita la seconda replica. Per ulteriori informazioni su questa opzione, consultare la sezione “Gestione dei pod” all’indirizzo OrderedReady.
   • Parallel: Con questa opzione, l'implementazione di tutte le repliche dello stateful set viene avviata contemporaneamente. Se la tua applicazione supporta la distribuzione parallela di repliche, utilizza questa opzione per risparmiare tempo di distribuzione per le tue PVC e repliche della serie con stato.

   matchLabels

   Nella sezione spec selector, immetti tutte le etichette (label) che vuoi includere nella tua serie con stato e nella tua PVC. Le etichette incluse nell' volumeClaimTemplates e del proprio stateful set non vengono riconosciute da Kubernetes. Esaminare le seguenti etichette di esempio.

   • region e zone: se desideri che tutte le repliche degli stateful set e i PVC vengano creati in una zona specifica, aggiungi entrambe le etichette. Puoi anche specificare la zona e la regione nella classe di archiviazione che utilizzi. Se non si specificano né la zona né la regione e si dispone di un cluster multizona, la zona in cui viene allocato lo spazio di archiviazione viene selezionata secondo il principio del round-robin, al fine di bilanciare equamente le richieste di volume tra tutte le zone.
   • billingType: Inserisci il tipo di fatturazione che desideri utilizzare per i tuoi PVC. Scegli tra hourly o monthly. Se non si specifica questa etichetta, tutti i PVC vengono creati con una fatturazione oraria.

   labels

   Nella sezione dei metadati del modello di specifica, inserisci le stesse etichette che hai aggiunto alla sezione " spec.selector.matchLabels ".

   affinity

   Nella sezione spec template spec affinity, specifica la tua regola di anti-affinità per garantire che i tuoi pod di serie con stato siano distribuiti tra i nodi di lavoro e le zone. L'esempio mostra una regola di anti-affinità in cui il pod di serie con stato preferisce non essere pianificato su un nodo di lavoro dove viene eseguito un pod che ha l'etichetta app: nginx. topologykey: failure-domain.beta.kubernetes.io/zone limita ancora di più questa regole di anti-affinità e impedisce al pod di essere pianificato su un nodo di lavoro se il nodo di lavoro si trova nella stessa zona di un pod che ha l'etichetta app: nginx. Utilizzando questa regola di anti-affinità, puoi ottenere l'anti-affinità tra i nodi di lavoro e le zone.

   name

   Nella sezione spec volume claim templates metadata, immetti un nome per il tuo volume. Utilizza lo stesso nome che hai definito nella sezione " spec.containers.volumeMount.name ". Il nome che inserisci qui viene utilizzato per creare il nome del tuo PVC nel formato: <volume_name>-<statefulset_name>-<replica_number>.

   storage

   Nella sezione spec volume claim templates spec resources requests, immetti la dimensione di File Storage for Classic in gigabyte (Gi).

   iops

   Nella sezione spec volume claim templates spec resources requests, se vuoi eseguire il provisioning dell'archiviazione Performance, immetti il numero di IOPS. Se utilizzi una classe di archiviazione Endurance e specifichi un numero di IOPS, il numero di IOPS viene ignorato. Invece, viene utilizzato l'IOPS specificato nella tua classe di archiviazione.

   storageClassName

   Nella sezione spec volume claim templates spec, immetti la classe di archiviazione che vuoi utilizzare. Per visualizzare l'elenco delle classi di archiviazione esistenti, eseguire il comando kubectl get sc | grep file``. Se non si specifica una classe di archiviazione, il PVC viene creato con la classe di archiviazione predefinita impostata nel cluster. Assicurati che la classe di archiviazione predefinita utilizzi il provisioner “ ibm.io/ibmc-file ”, in modo che il tuo “stateful set” venga configurato con “ File Storage for Classic ”.

4. Crea la tua serie con stato.

   kubectl apply -f statefulset.yaml
   

5. Attendi che la serie con stato venga distribuita.

   kubectl describe statefulset <statefulset_name>
   

Per visualizzare lo stato corrente delle tue PVC, esegui kubectl get pvc. Il nome del tuo file PVC è nel formato <volume_name>-<statefulset_name>-<replica_number>.

Provisioning statico: utilizzo di una PVC esistente con la tua serie con stato

Puoi eseguire il pre-provisioning delle tue PVC prima di creare la serie con stato oppure utilizzare PVC esistenti con la tua serie con stato.

Quando esegui dinamicamente il provisioning delle tue PVC quando crei la serie con stato, il nome della PVC viene assegnato in base ai valori che hai usato nel file YAML della serie con stato. Affinché la serie con stato utilizzi le PVC esistenti, il nome delle tue PVC deve corrispondere al nome che viene automaticamente creato quando si utilizza il provisioning dinamico.

Prima di iniziare: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

1. Se desideri eseguire il pre-provisioning della tua PVC prima di creare la serie con stato, esegui i passi da 1 a 3 in Aggiunta di File Storage for Classic alle applicazioni per creare una PVC per ogni replica della serie con stato. Assicurati di creare il tuo PVC con un nome che rispetti il seguente formato: <volume_name>-<statefulset_name>-<replica_number>.

<volume_name>

Utilizza il nome che desideri specificare nella sezione " spec.volumeClaimTemplates.metadata.name " del tuo stateful set, ad esempio nginxvol.

<statefulset_name>

Utilizza il nome che desideri specificare nella sezione " metadata.name " del tuo stateful set, ad esempio nginx_statefulset.

<replica_number>

Inserisci il numero della tua replica, a partire da 0.

Ad esempio, se devi creare 3 repliche della serie con stato, crea 3 PVC con i seguenti nomi: nginxvol-nginx_statefulset-0, nginxvol-nginx_statefulset-1 e nginxvol-nginx_statefulset-2.

Intendi creare una PVC e un PV per un'istanza File Storage for Classic esistente? Crea la tua PVC e il tuo PV utilizzando il provisioning statico.

1. Attieniti alla procedura in Provisioning dinamico: creazione della PVC quando crei una serie con stato per creare la tua serie con stato. Il nome del tuo PVC segue il formato <volume_name>-<statefulset_name>-<replica_number>. Assicurati di utilizzare i seguenti valori, ricavati dal nome del tuo PVC, nella specifica dello stateful set.

spec.volumeClaimTemplates.metadata.name

Inserisci l' <volume_name> e del tuo nome in PVC.

metadata.name

Inserisci l' <statefulset_name> e del tuo nome in PVC.

spec.replicas

Inserisci il numero di repliche che desideri creare per il tuo set con stato. Il numero di repliche deve essere uguale al numero di PVC create in precedenza.

Se i tuoi PVC si trovano in zone diverse, non includere un'etichetta di regione o zona nel tuo stateful set.

1. Verifica che le PVC siano utilizzate nei tuoi pod di replica della serie con stato elencando i pod nel tuo cluster e identificando i pod che appartengono alla tua serie con stato.

   kubectl get pods
   

2. Verifica che la PVC esistente sia montata nella replica della serie con stato. Esamina il ClaimName nella sezione Volumes del tuo output della CLI.

   kubectl describe pod <pod_name>
   

   Output di esempio

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  myvol-nginx-0
   ...
   

Creazione di una classe di archiviazione personalizzata con una versione specifica di NFS

1. Crea una classe di archiviazione personalizzata con la versione NFS di cui desideri eseguire il provisioning.

2. Crea la classe di archiviazione nel tuo cluster.

   kubectl apply -f nfsversion_storageclass.yaml
   

3. Verifica che la classe di archiviazione personalizzata sia stata creata.

   kubectl get sc
   

4. Esegui il provisioning di File Storage for Classic con la tua classe di archiviazione personalizzata.

Modifica dell'impianto fotovoltaico esistente per utilizzare una versione diversa di NFS

1. Ottieni il PV del File Storage for Classic di cui vuoi modificare la versione NFS e prendi nota del nome del PV.

   kubectl get pv
   

2. Aggiungi un'annotazione al tuo PV. Sostituisci <version_number> con la versione di NFS che desideri utilizzare. Ad esempio per modificare la versione NFS con la 3.0, immetti 3.

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. Elimina il pod che utilizza il File Storage for Classic e ricrealo.

   1. Salva lo YAML del pod sulla tua macchina locale.

       kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
       ```
   2. Elimina il pod.
   
   ```sh {: pre}
       kubectl deleted pod <pod_name>
       ```
   3. Ricrea il pod.
   
   ```sh {: pre}
       kubectl apply -f pod.yaml
       ```
   

4. Attendi che il pod venga distribuito. Il pod è completamente distribuito quando lo stato viene modificato con Running.

   kubectl get pods
   

5. Accedi al tuo pod.

   kubectl exec -it <pod_name> sh
   

6. Verifica che il File Storage for Classic sia stato montato con la versione NFS che hai specificato precedentemente.

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   Output di esempio

   nfs vers=3.0
   

Impostazione delle istantanee periodiche

Puoi configurare delle istantanee periodiche per File Storage for Classic, ossia un'immagine di sola lettura che acquisisce lo stato dell'istanza in un punto nel tempo. Per archiviare l'istantanea, devi richiedere lo spazio per l'istantanea nel tuo File Storage for Classic. Le istantanee vengono archiviate nell'istanza di archiviazione esistente all'interno della stessa zona. Puoi ripristinare i dati da un'istantanea se un utente rimuove accidentalmente dati importanti dal volume.

Completa la seguente procedura per creare un'istantanea per il volume.

1. Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

2. Accedi alla CLI ibmcloud sl.

   ibmcloud sl init
   

3. Elenca i PV esistenti nel tuo cluster.

   kubectl get pv
   

4. Ottieni i dettagli del PV per cui vuoi creare uno spazio per l'istantanea e prendi nota dell'ID volume, della dimensione e dell'IOPS. L'ID del volume, la dimensione e gli IOPS sono riportati nella sezione "Labels" dell'output della CLI.

   kubectl describe pv <pv_name>
   

5. Crea la dimensione dell'istantanea per il tuo volume esistente con i parametri che hai richiamato nel passo precedente.

   ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. Attendi che la dimensione dell'istantanea venga creata. La dimensione dello snapshot è stata configurata correttamente quando il valore Dimensione dello snapshot (GB) nell'output della CLI passa da 0 alla dimensione richiesta.

   ibmcloud sl file volume-detail <volume_ID>
   

7. Crea l'istantanea per il tuo volume e prendi nota dell'ID dell'istantanea che ti viene creata.

   ibmcloud sl file snapshot-create <volume_ID>
   

8. Verifica che l'istantanea sia stata creata correttamente.

   ibmcloud sl file snapshot-list <volume_ID>
   

9. Impostare la pianificazione dell'istantanea. Per ulteriori informazioni sulle opzioni disponibili per la pianificazione dell'istantanea, fai riferimento alla documentazione della CLI.

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

10. Per ripristinare i dati da un'istantanea a un volume esistente, immetti il seguente comando.

    ibmcloud sl file snapshot-restore <volume_ID> <snapshot_ID>
    

Replica degli snapshot in un’altra zona

Per proteggere i tuoi dati da un malfunzionamento dell'ubicazione, puoi replicare le istantanee in un'istanza di File Storage for Classic configurata in un'altra zona.

I dati possono essere replicati solo dall'archiviazione primaria a quella di backup. Non è possibile montare un'istanza replicata di File Storage for Classic su un cluster. Quando la tua archiviazione primaria non funziona più, puoi impostare manualmente la tua archiviazione di backup replicata in modo che sia quella primaria. Quindi, puoi montarla nel tuo cluster. Una volta ripristinata la tua archiviazione primaria, puoi ripristinare i dati dall'archiviazione di backup.

Duplicazione dell'archiviazione

Puoi duplicare la tua istanza di File Storage for Classic nella stessa zona dell'istanza di archiviazione originale.

Un duplicato contiene gli stessi dati dell'istanza di archiviazione originale nel momento in cui è stato creato il duplicato. A differenza delle repliche, puoi utilizzare il duplicato come un'istanza di archiviazione indipendente dall'originale. Per eseguire la duplicazione, per prima cosa configura le istantanee per il volume.

Backup dei dati in IBM Cloud® Object Storage

È possibile utilizzare il grafico disponibile all'indirizzo ibm-backup-restore Helm per avviare un pod di backup e ripristino nel proprio cluster.

Questo pod contiene uno script per eseguire un backup una tantum o periodico per qualsiasi attestazione del volume persistente (PVC) nel tuo cluster. I dati vengono archiviati nella tua istanza IBM Cloud® Object Storage che hai configurato in una zona.

Per rendere i tuoi dati ancora più altamente disponibili e proteggere la tua applicazione da un errore di zona, configura una seconda istanza IBM Cloud® Object Storage e replica i dati tra le varie zone. Se devi ripristinare i dati dalla tua istanza IBM Cloud® Object Storage, utilizza lo script di ripristino fornito con il grafico Helm.

Copia dei dati da e verso pod e container

È possibile utilizzare il comando kubectl cp per copiare file e directory da e verso i pod o container specifici presenti nel proprio cluster.

Prima di iniziare: Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster. Se non si specifica un container con -c``, il comando utilizza il primo container disponibile nel pod.

Copia i dati dal tuo computer locale a un pod nel tuo cluster.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

Copia i dati da un pod del tuo cluster sul tuo computer locale.

kubectl cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

Copia i dati dal tuo computer locale in un container specifico in esecuzione in un pod all’interno del tuo cluster.

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

Creazione di un'archiviazione che rileva la topologia

Per utilizzare File Storage for Classic in un cluster multizona, il tuo pod deve essere pianificato nella stessa zona della tua istanza di File Storage for Classic in modo che tu possa leggere e scrivere sul volume. Prima che la pianificazione dei volumi che rileva la topologia fosse introdotta da Kubernetes, il provisioning dinamico della tua archiviazione creava automaticamente l'istanza di File Storage for Classic quando veniva creata una PVC. Quindi, quando creavi il tuo pod, il programma di pianificazione Kubernetes provava a distribuire il pod a un nodo di lavoro nello stesso data center della tua istanza di File Storage for Classic.

La creazione dell'istanza di File Storage for Classic senza conoscere i vincoli del pod può portare a risultati indesiderati. Ad esempio, potrebbe non essere possibile pianificare il tuo pod sullo stesso nodo di lavoro della tua archiviazione perché il nodo di lavoro ha risorse insufficienti oppure perché al nodo di lavoro è stato applicato un taint e non consente la pianificazione del pod. Con la pianificazione dei volumi che rileva la topologia, l'istanza di File Storage for Classic viene ritardata finché non viene creato il primo pod che utilizza l'archiviazione.

I seguenti esempi mostrano come creare classi di archiviazione che ritardano la creazione dell'istanza di File Storage for Classic finché il primo pod che utilizza questa archiviazione non è pronto per essere pianificato. Per ritardare la creazione, devi includere l'opzione volumeBindingMode: WaitForFirstConsumer. Se non si include questa opzione, l' volumeBindingMode viene automaticamente impostato su Immediate e l'istanza File Storage for Classic viene creata al momento della creazione del PVC.

Esempio di resistenza File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-bronze-delayed
parameters:
  billingType: hourly
  classVersion: "2"
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
  provisioner: ibm.io/ibmc-file
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

Esempio di prestazioni File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
 billingType: "hourly"
 classVersion: "2"
 sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
 type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Specifica della zona per i cluster a multizona

Se vuoi creare la tua File Storage for Classic in una zona specifica, puoi specificare la zona e la regione in una classe di archiviazione personalizzata.

Utilizza la classe di archiviazione personalizzata se desideri eseguire il provisioning di File Storage for Classic in modo statico in una zona specifica. In tutti gli altri casi, specifica la zona direttamente nella tua PVC.

Quando crei la classe di archiviazione personalizzata, specifica la stessa regione e la stessa zona dove si trovano il tuo cluster e i tuoi nodi di lavoro. Per individuare la regione del tuo cluster, esegui il comando ibmcloud ks cluster get --cluster <cluster_name_or_ID> e cerca il prefisso della regione nel Master URL, ad esempio eu-de in https://c2.eu-de.containers.cloud.ibm.com:11111. Per conoscere la zona del tuo nodo di lavoro, esegui il comando ibmcloud ks worker ls --cluster <cluster_name_or_ID>``.

Esempio di resistenza File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-silver-mycustom-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
reclaimPolicy: Delete
volumeBindingMode: Immediate

Esempio di prestazioni File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  billingType: "hourly"
  classVersion: "2"
  sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
  type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: Immediate

Modifica della versione NFS predefinita

La seguente classe di archiviazione personalizzata ti consente di definire la versione NFS di cui desideri eseguire il provisioning. Ad esempio, per configurare una versione di NFS 3.0, sostituire <nfs_version> con 3.0.

Esempio di resistenza File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

Esempio di prestazioni File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  classVersion: "2"
  sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
  mountOptions: nfsvers=<nfs_version>

Descrizione delle tue opzioni di rimozione dell'archiviazione

La rimozione dell'archiviazione persistente dal tuo account IBM Cloud varia a seconda di come hai eseguito il provisioning dell'archiviazione e di quali componenti hai già rimosso.

Quando elimino il mio cluster, anche il mio storage persistente viene eliminato?

Durante l'eliminazione del cluster, hai l'opzione di rimuovere la tua archiviazione persistente. Tuttavia, a seconda di come è stato eseguito il provisioning della tua archiviazione, la rimozione della tua archiviazione potrebbe non includere tutti i componenti di archiviazione. Se lo storage è stato provisionato dinamicamente con una classe di storage che imposta l'opzione " reclaimPolicy: Delete", il PVC, il PV e l'istanza di storage vengono eliminati automaticamente quando si elimina il cluster. Nel caso di storage provisionato staticamente o di storage provisionato con una classe di storage che imposta l'opzione " reclaimPolicy: Retain", il PVC e il PV vengono rimossi quando si elimina il cluster, ma l'istanza di storage e i dati rimangono. Ti vengono ancora addebitati dei costi per la tua istanza di archiviazione. Tuttavia, se hai eliminato il tuo cluster in uno stato non integro, l'archiviazione potrebbe permanere anche se hai scelto di rimuoverla.

Come faccio a eliminare lo spazio di archiviazione se voglio mantenere il mio cluster?

Quando hai eseguito il provisioning in modo dinamico dell'archiviazione con una classe di archiviazione che imposta reclaimPolicy: Delete, puoi rimuovere la PVC per avviare il processo di eliminazione della tua archiviazione persistente. La PVC, il PV e l'istanza di archiviazione vengono automaticamente rimossi. Per lo spazio di archiviazione provisionato in modo statico o per quello provisionato con una classe di archiviazione che imposta l'opzione " reclaimPolicy: Retain", è necessario rimuovere manualmente il PVC, il PV e l'istanza di archiviazione per evitare ulteriori addebiti.

Come viene interrotta la fatturazione dopo aver eliminato il mio spazio di archiviazione?

A seconda di quali componenti di archiviazione elimini e quando, il ciclo di fatturazione potrebbe non arrestarsi immediatamente. Se elimini la PVC e il PV ma non l'istanza di archiviazione nel tuo account IBM Cloud, tale istanza permane e incorri in addebiti per essa.

Se elimini la PVC, il PV e l'istanza di archiviazione, il ciclo di fatturazione si arresta in base al tipo di fatturazione (billingType) che hai scelto quando hai eseguito il provisioning della tua archiviazione e di come scegli di eliminare l'archiviazione.

• Quando si annulla manualmente l'istanza di archiviazione persistente dalla console IBM Cloud o dalla CLI, la fatturazione viene interrotta come segue:

  • Archiviazione oraria: la fatturazione si arresta immediatamente. Dopo che la tua archiviazione è stata annullata, potresti ancora vedere la tua istanza di archiviazione nella console per un massimo di 72 ore.
  • Archiviazione mensile: puoi scegliere tra l'annullamento immediato o l'annullamento alla data di anniversario. In entrambi i casi, ti vengono addebitati dei costi fino al termine del ciclo di fatturazione corrente e la fatturazione si arresta per il successivo ciclo di fatturazione. Dopo che la tua archiviazione è stata annullata, potresti ancora vedere la tua istanza di archiviazione nella console o nella CLI per un massimo di 72 ore.
  • Annullamento immediato: scegli questa opzione per rimuovere immediatamente la tua archiviazione. Né tu né i tuoi utenti potete più utilizzare l'archiviazione o ripristinare i dati.
  • Data di anniversario: scegli questa opzione per annullare la tua archiviazione alla prossima data di anniversario. Le tue istanze dell'archiviazione rimangono attive fino alla successiva data di anniversario e puoi continuare a utilizzarle fino a questa data, ad esempio per dare ai tuoi team il tempo di effettuare dei backup dei tuoi dati.

• Quando hai eseguito il provisioning in modo dinamico dell'archiviazione con una classe di archiviazione che imposta reclaimPolicy: Delete e scegli di rimuovere la PVC, il PV e l'istanza di archiviazione vengono automaticamente rimossi. Per l'archiviazione fatturata su base oraria, la fatturazione di arresta immediatamente. Per l'archiviazione fatturata su base mensile, incorri ancora in degli addebiti per il periodo rimanente del mese. Dopo che la tua archiviazione è stata rimossa e la fatturazione si è arrestata, potresti ancora vedere la tua istanza di archiviazione nella console o nella CLI per un massimo di 72 ore.

Cosa devo tenere presente prima di eliminare la memoria persistente?

Quando ripulisci l'archiviazione persistente, elimini tutti i dati in essa archiviati. Se hai bisogno di una copia dei dati, esegui un backup.

Ho eliminato la mia istanza di archiviazione. Perché riesco ancora a vedere la mia istanza?

Dopo che hai rimosso l'archiviazione persistente, ci possono volere 72 ore perché la rimozione venga elaborata completamente e perché l'archiviazione scompaia dalla CLI o dalla console IBM Cloud.

Ripulitura dell'archiviazione persistente

Rimuovi la PVC, il PV e l'istanza di archiviazione dal tuo account IBM Cloud per evitare ulteriori addebiti per la tua archiviazione persistente.

Prima di cominciare:

• Assicurati di aver eseguito il backup di tutti i dati che vuoi conservare.
• Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

Per ripulire i dati persistenti:

1. Elenca le PVC nel tuo cluster e prendi nota del NAME della PVC, della STORAGECLASS e del nome del PV associato alla PVC e visualizzato come VOLUME.

   kubectl get pvc
   

   Output di esempio

   NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
   claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
   claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
   claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d
   

2. Esamina ReclaimPolicy e billingType per la classe di archiviazione.

   kubectl describe storageclass <storageclass_name>
   

   Se la politica di riacquisizione indica Delete, il tuo PV e l'archiviazione fisica vengono rimossi quando rimuovi la PVC. Se la politica di riacquisizione indica Retain, o se hai eseguito il provisioning della tua archiviazione senza una classe di archiviazione, il tuo PV e l'archiviazione fisica non vengono rimossi quando rimuovi la PVC. Devi rimuovere la PVC, il PV e l'archiviazione fisica separatamente.

   Se la tua archiviazione viene addebitata mensilmente, ti viene comunque addebitato l'importo per l'intero mese, anche se rimuovi l'archiviazione prima della fine del ciclo di fatturazione.

3. Rimuovi gli eventuali pod che montano la PVC. Elenca i pod che montano la PVC. Se nell'output della CLI non viene restituito alcun pod, significa che non esiste alcun pod che utilizzi il PVC.

   kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   Output di esempio

   depl-12345-prz7b:    claim1
   

4. Rimuovi il pod che utilizza la PVC. Se il pod fa parte di una distribuzione, rimuovi la distribuzione.

   kubectl delete pod <pod_name>
   

5. Verifica che il pod venga rimosso.

   kubectl get pods
   

6. Rimuovi la PVC.

   kubectl delete pvc <pvc_name>
   

7. Esamina lo stato del tuo PV. Utilizza il nome del PV che hai richiamato in precedenza come VOLUME. Quando rimuovi la PVC, il PV ad essa associato viene rilasciato. A seconda di come hai eseguito il provisioning della tua archiviazione, il tuo PV passa a uno stato di Deleting, se il PV viene eliminato automaticamente, oppure a uno stato di Released, se devi eliminarlo manualmente. Nota:: per i PV eliminati automaticamente, lo stato potrebbe brevemente indicare Released prima che venga eliminato. Riesegui il comando dopo qualche minuto per appurare se il PV viene rimosso.

   kubectl get pv <pv_name>
   

8. Se il tuo PV non viene eliminato, rimuovilo manualmente.

   kubectl delete pv <pv_name>
   

9. Verifica che il PV venga rimosso.

   kubectl get pv
   

10. Elenca l'istanza di archiviazione fisica a cui puntava il tuo PV e prendi nota dell'id dell'istanza di archiviazione fisica.

    ibmcloud sl file volume-list --columns id  --columns notes | grep <pv_name>
    

    Esempio di output per File Storage for Classic.

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    Il plug-in di archiviazione utilizzato dal cluster.

    "region":"us-south"

    La regione in cui si trova il tuo cluster.

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    L'ID del cluster associato all'istanza di archiviazione.

    "type":"Endurance"

    Il tipo di archiviazione a file o a blocchi: Endurance oppure Performance.

    "ns":"default"

    Lo spazio dei nomi in cui è distribuita l'istanza di archiviazione.

    "pvc":"mypvc"

    Il nome del PVC associato all'istanza di archiviazione.

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    Il PV associato all'istanza di archiviazione.

    "storageclass":"ibmc-file-gold"

    Il tipo di classe di archiviazione: bronzo, argento, oro o personalizzata.

11. Rimuovi l'istanza di archiviazione fisica.

    ibmcloud sl file volume-cancel <classic_file_id>
    

12. Verifica che l'istanza di archiviazione fisica venga rimossa.

    ibmcloud sl file volume-list
    

Il completamento del processo di eliminazione potrebbe impiegare fino a 72 ore.