Aggiornamento del plugin IBM Cloud Block Storage

Puoi eseguire l'upgrade del plugin IBM Cloud Block Storage esistente alla versione più recente.

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

1. Aggiorna il repository Helm per richiamare la versione più recente di tutti i grafici Helm in questo repository.

   helm repo update
   

2. Facoltativo: scarica il grafico helm più recente sulla tua macchina locale. Estrai quindi il pacchetto e riesamina il file release.md per trovare le informazioni di release più aggiornate.

   helm pull iks-charts/ibmcloud-block-storage-plugin --untar
   

3. Trova il nome della release e lo spazio dei nomi del grafico Helm dell'archiviazione blocchi che hai installato nel tuo cluster.

   helm ls -A
   

   Output di esempio

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS      CHART                                   APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed        bmcloud-block-storage-plugin-v2.1.5
   

4. Aggiorna il plugin IBM Cloud Block Storage alla versione più recente. Includi il nome della release e lo spazio dei nomi che hai richiamato in precedenza.

   helm upgrade RELEASE-NAME iks-charts/ibmcloud-block-storage-plugin -n NAMESPACE
   

5. Facoltativo; quando aggiorni il plugin, la classe di archiviazione default non è impostata. Se vuoi impostare la classe di archiviazione predefinita su una classe di archiviazione di tua scelta, esegui questo comando.

   kubectl patch storageclass STORAGECLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

Rimozione del plugin IBM Cloud Block Storage

Se non desideri configurare e utilizzare IBM Cloud Block Storage nel tuo cluster, puoi disinstallare il chart Helm.

La rimozione del plugin non rimuove PVC, PV o dati esistenti. Quando rimuovi il plugin, tutti i pod e le serie di daemon correlati vengono rimossi dal tuo cluster. Una volta rimosso il plug-in, non sarà più possibile allocare nuovo spazio di archiviazione a blocchi per il cluster né utilizzare i PVC e i PV di archiviazione a blocchi esistenti.

Prima di cominciare:

• Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.
• Assicurati che nel tuo cluster non siano presenti PVC o PV che utilizzano lo storage a blocchi.

Per rimuovere il plugin:

1. Trova il nome della release e lo spazio dei nomi del grafico Helm dell'archiviazione blocchi che hai installato nel tuo cluster.

   helm ls -A
   

   Output di esempio

   NAME            NAMESPACE   REVISION    UPDATED                             STATUS   CHART                                  APP VERSION
   block-plugin    default     1           2022-01-21 09:02:46.11622 -0500 EST deployed    ibmcloud-block-storage-plugin-v2.1.5
   

2. Elimina il plugin IBM Cloud Block Storage.

   helm uninstall NAME -n kube-system
   

3. Verifica che i pod dell'archiviazione blocchi siano stati rimossi.

   kubectl get pods -n kube-system | grep block
   

   La rimozione dei pod è riuscita se nel tuo output della CLI non vengono visualizzati pod.

4. Verifica che le classi di archiviazione blocchi vengano rimosse. La rimozione delle classi di archiviazione è riuscita se nel tuo output della CLI non vengono visualizzate classi di archiviazione.

   kubectl get sc | grep block
   

Crittografia dei dati del volume utilizzando una classe di archiviazione personalizzata

È possibile distribuire applicazioni che utilizzano volumi crittografati creando prima una propria classe di archiviazione.

La seguente procedura spiega come creare una classe di archiviazione personalizzata e crittografata che puoi utilizzare per creare più istanze di archiviazione blocchi crittografate con la stessa configurazione. Se vuoi creare una PVC crittografata utilizzando una delle classi di archiviazione fornite da IBM, puoi farlo facendo riferimento alle credenziali Key Protect direttamente nella tua PVC.

1. Decidi una configurazione di archiviazione.

2. Crea una classe di archiviazione personalizzata che configuri un'istanza di archiviazione a blocchi crittografata, utilizzando come base una delle classi di archiviazione fornite da IBM. È possibile recuperare i dettagli di una classe di archiviazione eseguendo il comando kubectl get sc <storageclass_name> -o yaml``. Il seguente esempio è basato sulla classe di archiviazione ibmc-block-retain-bronze.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: <name> # Enter the name of the storage class. Example: my_custom_storageclass
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
     encrypted: "true" # Enter "true" to enable encryption.
     encryptionKeySecret: <secret_name> # # #nter the name of the secret that you created earlier.Example: my_secret
     encryptionKeyNamespace: <namespace> # # #nter the namespace where you created your secret. Example: default
   provisioner: ibm.io/ibmc-block
   reclaimPolicy: Delete
   volumeBindingMode: Immediate
   

3. Crea la classe di archiviazione nel tuo cluster.

   kubectl apply -f storageclass.yaml
   

4. Aggiungi " Block Storage for Classic " alla tua app utilizzando una classe di archiviazione personalizzata per creare un PVC.

5. Verifica la crittografia dei tuoi volumi Block Storage for Classic.

Crea una PVC che faccia riferimento al tuo segreto Block Storage for Classic

Puoi eseguire il provisioning di Block Storage for Classic crittografato creando una PVC che specifica il segreto Kubernetes che contiene le tue credenziali Key Protect.

La seguente procedura mostra come puoi fare riferimento alle tue credenziali Key Protect nella tua PVC per creare un'istanza Block Storage for Classic crittografata. Per creare più volumi crittografati senza specificare le credenziali Key Protect in ciascuna PVC, puoi creare una classe di archiviazione personalizzata e crittografata.

1. Riesamina le classi di archiviazione Block Storage for Classic fornite per determinare qualche classe di archiviazione soddisfa meglio i requisiti della tua applicazione. Se le classi di archiviazione disponibili non soddisfano i requisiti della tua app, puoi crearne una personalizzata.

2. Crea un file di configurazione PVC denominato pvc.yaml e che faccia riferimento al segreto Kubernetes in cui hai archiviato le credenziali del servizio Key Protect. Per creare questo segreto, vedi Configurazione della crittografia per Block Storage for Classic.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: <pvc_name> # Enter a name for your PVC.
     annotations:
     volume.beta.kubernetes.io/storage-class: "<storage_class>" # Enter a storage class. To see a list of storageclasses run `kubectl get storageclasses`.
     labels:
       encrypted: "true"
       encryptionKeyNamespace: <namespace> # Enter the namespace where your secret was created.
       encryptionKeySecret: <secret_name> # Enter the name of the secret you created.
   spec:
     accessModes:
       - ReadWriteOnce
       resources:
       requests:
           storage: 20Gi
   

3. Crea la PVC nel tuo cluster.

   kubectl apply -f pvc.yaml
   

4. Controlla lo stato della tua PVC.

   kubectl get pvc
   

5. Attendi il bind della tua PVC e quindi crea una distribuzione che utilizza la tua PVC.

6. Verifica la crittografia dei tuoi volumi Block Storage for Classic.

Verifica della crittografia dei tuoi volumi Block Storage for Classic

Puoi verificare la crittografia dei tuoi volumi controllando il percorso di montaggio del volume.

1. Accedi al tuo pod dell'applicazione. Sostituisci " <pod_name> " con il nome del pod che monta il volume crittografato " Block Storage for Classic ".

   kubectl exec <pod_name> -it bash
   

2. Elenca il file system del tuo pod.

   df -h
   

3. Riesamina il percorso del file system per il tuo volume Block Storage for Classic crittografato.

   • I volumi crittografati hanno una struttura di percorsi del tipo /dev/mapper/<pvc-ID_encrypted>. In questo esempio, il volume crittografato è montato sul percorso file /test nel pod.

       Filesystem                                            Size  Used Avail Use% Mounted on
       overlay                                                98G  8.2G   85G   9% /
       tmpfs                                                  64M     0   64M   0% /dev
       tmpfs                                                 2.0G     0  2.0G   0% /sys/fs/cgroup
       /dev/mapper/pvc-a011a111-1111-1111-111a-aaa1a1111a11_encrypted   20G   45M   20G   1% /test
       ```
   * I volumi non crittografati hanno una struttura di percorsi del tipo `dev/mapper/<random_string>`.
   
   ```sh {: screen}
       Filesystem                                     Size  Used Avail Use% Mounted on
       overlay                                         98G   16G   78G  17% /
       tmpfs                                           64M     0   64M   0% /dev
       tmpfs                                          7.9G     0  7.9G   0% /sys/fs/cgroup
       /dev/mapper/3600a09803830476e733f4e477370716e   24G   45M   24G   1% /test
       ```
   

La rimozione del segreto " Kubernetes " non revoca l'accesso ai dati del volume. Se hai creato una distribuzione solo pod, devi eliminare il pod. Se hai creato una distribuzione, devi eliminare la distribuzione.

Recupero delle informazioni relative al tuo block storage esistente

1. Recupera o genera una chiave API per il tuo account dell'infrastruttura IBM Cloud.

   1. Accedi al portale dell'infrastruttura IBM Cloud.
   2. Seleziona Account, quindi Utenti e quindi Elenco utenti.
   3. Trova il tuo ID utente.
   4. Nella colonna Chiave API, fai clic su Genera per generare una chiave API oppure su Visualizza per visualizzare la tua chiave API esistente.

2. Recupera il nome utente API per il tuo account dell'infrastruttura IBM Cloud.

   1. Dal menu Elenco utenti, seleziona il tuo ID utente.
   2. Nella sezione Informazioni di accesso API, trova il tuo Nome utente API.

3. Accedi al plug-in della CLI dell'infrastruttura IBM Cloud.

   ibmcloud sl init
   

4. Scegli di eseguire l'autenticazione utilizzando il nome utente e la chiave API per il tuo account dell'infrastruttura IBM Cloud.

5. Immetti il nome utente e la chiave API che hai recuperato nei passi precedenti.

6. Elenca i dispositivi di archiviazione blocchi disponibili.

   ibmcloud sl block volume-list
   

   Output di esempio

   id          username              datacenter   storage_type                capacity_gb   bytes_used   lunId   
   11111111    IBM01AAA1111111-1     wdc07        endurance_block_storage     45            -            2      
   

7. Richiama i dettagli del volume. Sostituisci <volume_ID> con l'ID del volume di archiviazione blocchi che hai richiamato nel passo 6.

   ibmcloud sl block volume-detail <volume_ID>
   

   Output di esempio

   ID                         11111111
   User name                  IBM01AAA1111111-1   
   Type                       endurance_block_storage   
   Capacity (GB)              45   
   LUN Id                     2   
   IOPs                       100   
   Datacenter                 wdc07   
   Target IP                  10.XXX.XX.XXX  
   # of Active Transactions   0   
   Replicant Count            0
   

8. Prendi nota di ID, Capacity, LUN Id, Datacenter e Target IP del volume che vuoi montare nel tuo cluster. Nota: per montare l'archiviazione esistente in un cluster, devi disporre di un nodo di lavoro nella stessa zona della tua archiviazione. Per verificare la zona del tuo nodo di lavoro, esegui il comando ibmcloud ks worker ls --cluster <cluster_name_or_ID>``.

Creazione di un volume persistente (PV) e di una richiesta di volume persistente (PVC) corrispondente

1. Opzionale: se si dispone di uno spazio di archiviazione provisionato con una classe di archiviazione " retain ", quando si rimuove il PVC, il PV e il dispositivo di archiviazione fisico non vengono rimossi. Per riutilizzare l'archiviazione nel tuo cluster, devi prima rimuovere il PV. Elenca i PV esistenti e cerca il PV che appartiene alla tua archiviazione persistente. Il PV è in uno stato released.

   kubectl get pv
   

2. Rimuovi il PV.

   kubectl delete pv <pv_name>
   

3. Verificare che il PV sia stato rimosso.

   kubectl get pv
   

4. Crea un file di configurazione per il tuo PV. Includere i parametri richiamati in precedenza.

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: "block-storage-pv" # Enter a name for your PV. For example, my-static-pv.
     labels:
        failure-domain.beta.kubernetes.io/region: "<region>" # Example us-east.
        failure-domain.beta.kubernetes.io/zone: "<zone>" # Example: wdc04. See /docs/containers?topic=containers-regions-and-zones#zones-sz
   spec:
     capacity:
       storage: "<storage>"
     accessModes:
       - ReadWriteOnce
     flexVolume:
       driver: "ibm/ibmc-block"
       fsType: "<fs_type>" # Enter ext or xfs
       options:
         "Lun": "<Lun_ID>"
         "TargetPortal": "<TargetPortal>"
         "VolumeID": "<VolumeID>"
         "volumeName": "block-storage-pv" # Enter the same value as your PV name from metadata.name
   

   name

   Assegna un nome al tuo impianto fotovoltaico. Ad esempio, block-storage-pv. Notare che è necessario immettere questo valore anche in spec.FlexVolume.options come volumeName.

   labels

   Immetti la regione e la zona che hai richiamato in precedenza. Devi disporre di almeno un nodo di lavoro nella stessa regione e nella stessa zona della tua archiviazione persistente per montare l'archiviazione nel tuo cluster. Per richiamare i dettagli del volume, esegui ibmcloud sl block volume-list per ottenere l'ID volume, quindi esegui ibmcloud sl block volume-detail <volume_ID> per ottenere i dettagli del volume.

   region

   Inserisci la regione in cui si trova il tuo block storage. Nota che il tuo cluster e l'archiviazione blocchi devono essere nella stessa regione. Per individuare la posizione del tuo cluster, esegui il comando ibmcloud ks cluster ls``. Per ulteriori informazioni sulle regioni e zone disponibili, vedi Regioni e zone. Ad esempio, us-east.

   zone

   Immettere la zona in cui si trova il volume di storage. Per richiamare i dettagli del volume, esegui ibmcloud sl block volume-list per ottenere l'ID volume, quindi esegui ibmcloud sl block volume-detail <volume_ID> per ottenere i dettagli del volume. Nota che per collegare l'archiviazione blocchi al tuo cluster, devi avere un nodo di lavoro disponibile nella stessa zona del volume che vuoi collegare. Per individuare le zone dei tuoi nodi di lavoro, esegui ibmcloud ks worker ls -c <cluster>. Ad esempio, wdc04.

   storage

   Immetti la dimensione di archiviazione del volume di archiviazione blocchi esistente che vuoi collegare al tuo cluster. La dimensione di archiviazione deve essere scritta in gigabyte, ad esempio, 20Gi (20 GB) o 1000Gi (1 TB). Per richiamare i tuoi dati del volume, esegui ibmcloud sl block volume-list per ottenere l'ID volume e quindi esegui ibmcloud sl block volume-detail <volume_ID> per ottenere i dati del volume.

   fsType

   Immetti il tipo di file system configurato per la tua archiviazione blocchi esistente. Scegli tra ext4 o xfs. Se non si specifica questa opzione, il valore predefinito di PV è ext4. Quando viene definito il fsType non corretto, la creazione del PV ha esito positivo ma il montaggio del PV in un pod ha esito negativo. Per richiamare i dettagli del volume, esegui ibmcloud sl block volume-list per ottenere l'ID volume, quindi esegui ibmcloud sl block volume-detail <volume_ID> per ottenere i dettagli del volume.

   Lun

   Immetti l'ID LUN del tuo volume di archiviazione blocchi. Per richiamare i dettagli del volume, esegui ibmcloud sl block volume-list per ottenere l'ID volume, quindi esegui ibmcloud sl block volume-detail <volume_ID> per ottenere i dettagli del volume.

   TargetPortal

   Inserisci l'indirizzo IP del tuo sistema di archiviazione a blocchi. Per richiamare il parametro TargetPortal, esegui ibmcloud sl block volume-list per ottenere l'ID volume, quindi esegui ibmcloud sl block volume-detail <volume_ID> e prendi nota di Target IP nell'output.

   VolumeId

   Immetti l'ID della tua archiviazione blocchi. Per richiamare i dettagli del tuo volume, esegui ibmcloud sl block volume-list.

   volumeName

   Immetti lo stesso valore del tuo nome PV. Ad esempio, block-storage-pv.

5. Crea il PV nel tuo cluster.

   kubectl apply -f pv.yaml
   

6. Verifica che il PV sia stato creato.

   kubectl get pv
   

7. 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 creato automaticamente un nuovo PV.

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: block-storage-pvc
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: "20Gi"
     storageClassName: ""
   

8. Crea la tua PVC.

   kubectl apply -f static-pvc.yaml
   

9. Verifica che la tua PVC sia stata creata e collegata al PV che hai creato in precedenza. Questo processo può richiedere qualche minuto.

   kubectl describe pvc static-pvc
   

   Output di esempio

   Name:          static-pvc
   Namespace:     default
   StorageClass:  
   Status:        Bound
   

10. Facoltativo Salva la seguente configurazione pod di esempio come un file denominato pod.yaml.

    apiVersion: v1
    kind: Pod
    metadata:
      name: block-storage
      labels:
        app: block-storage
    spec:
      containers:
        - name: block-storage
          image: nginx
          command: ["/bin/sh"]
          args: ["-c", "while true; do date \"+%Y-%m-%d %H:%M:%S\"; sleep 3600; done"]
          workingDir: /home
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          volumeMounts:
            - name: block-storage-pv
              mountPath: /home
      volumes:
        - name: block-storage-pv
          persistentVolumeClaim:
            claimName: block-storage-pvc
    

11. Crea il pod nel tuo cluster.

    kubectl create -f pod.yaml
    

12. Dopo che il pod è nello stato Running, ottieni i log.

    kubectl logs
    

    Output di esempio

    2022-01-21 16:11:00
    

Hai creato correttamente un PV e lo hai collegato ad una PVC. Quindi, hai distribuito e l'applicazione che utilizza l'archiviazione blocchi. Gli utenti del cluster possono ora montare il PVC sulle proprie distribuzioni e iniziare a leggere e scrivere sul volume persistente.

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

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.

Completa la seguente procedura per verificare che tutte le serie con stato esistenti nel tuo cluster siano 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.

1. 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. Il seguente esempio mostra come distribuire NGINX come una serie con stato con tre repliche. Per ogni replica, viene eseguito il provisioning di un dispositivo di archiviazione blocchi di 20 gigabyte basato sulle specifiche che sono definite nella classe di archiviazione ibmc-block-retain-bronze. Il provisioning di tutti i dispositivi di archiviazione viene eseguito nella zona dal10. Poiché non è possibile accedere allo storage a blocchi da altre zone, tutte le repliche dello stateful set vengono distribuite anche sui nodi di lavoro situati nell' 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" # Enter the region where your cluster is located.
       zone: "dal10"
   template:
     metadata:
     labels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     spec:
     containers:
     - name: nginx
       image: nginx
       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-block-retain-bronze
   

   Il seguente esempio mostra come distribuire NGINX come una serie con stato con tre repliche. La serie con stato non specifica la regione e la zona dove viene creata l'archiviazione blocchi. 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. Definendo l' topologykey: failure-domain.beta.kubernetes.io/zone, lo scheduler Kubernetes non può pianificare un pod su un nodo di lavoro se quest'ultimo si trova nella stessa zona di un pod che presenta 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 archiviazione blocchi viene ritardata finché non viene pianificato un pod di serie con stato che utilizza l'archiviazione. Questa configurazione viene definita “schedulazione dei volumi sensibile alla topologia ”.

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-block-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     fsType: ext4
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-block
   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:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteOnce # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-block-bronze-delayed
   

   name

   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

   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.

   • OrderedReady: con questa opzione, le repliche dello stateful set vengono distribuite una dopo l'altra. Ad esempio, se hai distribuito tre 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
   • Parallelo: 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 dello stateful set non vengono riconosciute da Kubernetes. Le etichette di esempio che potresti voler includere sono:

   • regione e zona: 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, 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 dell'archiviazione blocchi 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 block``. 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-block ”, in modo che il tuo Stateful Set venga configurato con l’archiviazione a blocchi.

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 tramite l'utilizzo di PVC esistenti con uno stateful set

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 vuoi eseguire i pre-provisioning della PVC per la tua serie con stato prima di creare la serie con stato, attieniti ai passi da 1 a 3 in Aggiunta di archiviazione blocchi alle applicazioni per creare una PVC per ogni replica di 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 tre repliche della serie con stato, crea tre 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 dispositivo di archiviazione 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 dal tuo nome PVC nella specifica della serie con stato: 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 set stateful.

1. Verifica che le PVC siano utilizzate nei tuoi pod di replica della serie con stato elencando i pod nel tuo cluster. Identifica 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
   ...
   

Impostazione delle istantanee periodiche

Puoi configurare delle istantanee periodiche per la tua archiviazione blocchi, che è 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 nella tua archiviazione blocchi. 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. \n \n ** Per creare un'istantanea per il volume, completa la seguente procedura.

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. Le dimensioni e gli IOPS sono riportati nella sezione "Labels " dell'output della CLI.

   kubectl describe pv <pv_name>
   

5. Per individuare l'ID del volume, controlla l'annotazione " ibm.io/network-storage-id " nell'output della CLI.

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

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

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

   ibmcloud sl block volume-detail <volume_ID>
   

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

   ibmcloud sl block snapshot-create <volume_ID>
   

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

   ibmcloud sl block snapshot-list <volume_ID>
   

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

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

    ibmcloud sl block 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 archiviazione blocchi configurata in un'altra zona.

I dati possono essere replicati solo dall'archiviazione primaria a quella di backup. Non è possibile montare un'istanza di storage a blocchi replicata 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 archiviazione blocchi 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, configura innanzitutto le istantanee per il volume.

Backup dei dati in IBM Cloud® Object Storage

Puoi utilizzare il grafico Helm ibm-backup-restore per avviare un pod di backup e ripristino nel tuo 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.

L'archiviazione blocchi viene montata con una modalità di accesso RWO. Questo accesso consente di montare un solo pod nell'archiviazione blocchi alla volta. Per eseguire il backup dei tuoi dati, devi smontare il pod dell'applicazione dall'archiviazione, montarlo nel tuo pod di backup, eseguire il backup dei dati e rimontare l'archiviazione nel tuo pod dell'applicazione.

Per rendere i tuoi dati ancora più altamente disponibili e proteggere la tua applicazione da un errore di zona, configura una seconda istanza Object Storage e replica i dati tra le varie zone. Se hai bisogno di ripristinare i dati dalla tua istanza Object Storage, utilizza il pod 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.

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

Quando esegui il comando kubectl cp, se non specifichi un contenitore con -c, il comando utilizza il primo contenitore 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> <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

Bronze

Nome

ibmc-block-bronze

ibmc-block-retain-bronze

Immettere

Archiviazione Endurance

File system

ext4

IOPS per gigabyte

2

Intervallo di dimensioni in gigabyte

20-12000 Gi

Disco rigido

SSD

Politica di riacquisizione

ibmc-block-bronze: eliminazione

ibmc-block-retain-bronze: conserva

Silver

Nome

ibmc-block-silver

ibmc-block-retain-silver

Immettere

Archiviazione Endurance

File system

ext4

IOPS per gigabyte

4

Intervallo di dimensioni in gigabyte

20-12000 Gi

Disco rigido

SSD

Politica di riacquisizione

ibmc-block-silver: eliminazione

ibmc-block-retain-silver: conserva

Gold

Nome

ibmc-block-gold

ibmc-block-retain-gold

Immettere

Archiviazione Endurance

File system

ext4

IOPS per gigabyte

10

Intervallo di dimensioni in gigabyte

20-4000 Gi

Disco rigido

SSD

Politica di riacquisizione

ibmc-block-gold: eliminazione

ibmc-block-retain-gold: conserva

Personalizzato

Nome

ibmc-block-custom

ibmc-block-retain-custom

Immettere

File system delle prestazioni

ext4

IOPS e dimensione

Intervallo di capacità in gigabyte / Intervallo di IOPS in multipli di 100

• 20-39 Gi / 100-1000 IOPS
• 40-79 Gi / 100-2000 IOPS
• 80-99 Gi / 100-4000 IOPS
• 100-499 Gi / 100-6000 IOPS
• 500-999 Gi / 100-10000 IOPS
• 1000-1999 Gi / 100-20000 IOPS
• 2000-2999 Gi / 200-40000 IOPS
• 3000-3999 Gi / 200-48000 IOPS
• 4000-7999 Gi / 300-48000 IOPS
• 8000-9999 Gi / 500-48000 IOPS
• 10000-12000 Gi / 1000-48000 IOPS

Disco rigido

Il rapporto IOPS-gigabyte determina il tipo di disco rigido di cui viene eseguito il provisioning. Per determinare il tuo rapporto IOPS/gigabyte, dividi l'IOPS per la dimensione della tua archiviazione.

Esempio: hai scelto uno spazio di archiviazione da 500Gi con 100 IOPS. Il tuo rapporto è 0,2 (100 IOPS/500Gi).

Panoramica dei tipi di disco rigido in base al rapporto:

• Inferiore o uguale a 0,3: SATA
• Maggiore di 0,3: SSD

Politica di riacquisizione

ibmc-block-custom: eliminazione

ibmc-block-retain-custom: conserva

Creazione di un'archiviazione che rileva la topologia

Per utilizzare l'archiviazione blocchi in un cluster multizona, il tuo pod deve essere pianificato nella stessa zona della tua istanza di archiviazione blocchi 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 archiviazione blocchi quando veniva creata una PVC. Quindi, quando creavi il tuo pod, il programma di pianificazione Kubernetes provava a distribuire il pod allo stesso data center della tua istanza di archiviazione blocchi.

La creazione dell'istanza di archiviazione blocchi 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 archiviazione blocchi viene ritardata finché non viene creato il primo pod che utilizza l'archiviazione.

Per utilizzare la pianificazione dei volumi basata sulla topologia, assicurarsi di aver installato il plug-in " IBM Cloud " ( Block Storage ) versione 1.2.0 o successiva.

I seguenti esempi mostrano come creare classi di archiviazione che ritardano la creazione dell'istanza di archiviazione blocchi 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 impostato automaticamente su Immediate e l'istanza di block storage viene creata al momento della creazione del PVC.

Esempio di archiviazione a blocchi di tipo Endurance.

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

Esempio di archiviazione a blocchi ad alte prestazioni.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-performance-storageclass
  labels:
  kubernetes.io/cluster-service: "true"
  provisioner: ibm.io/ibmc-block
  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 e della regione

Se vuoi creare la tua archiviazione blocchi in una zona specifica, puoi specificare la zona e la regione in una classe di archiviazione personalizzata.

Utilizza la classe di archiviazione personalizzata se usi il plugin IBM Cloud Block Storage versione 1.0.0 o se vuoi eseguire il provisioning dell'archiviazione blocchi in modo statico in una zona specifica. In tutti gli altri casi, specifica la zona direttamente nella tua PVC.

Il seguente file .yaml personalizza una classe di archiviazione basata sulla classe di archiviazione di non conservazione ibm-block-silver: il type è "Endurance", l'iopsPerGB è 4, il sizeRange è "[20-12000]Gi" e la reclaimPolicy è impostata su "Delete". La zona viene specificata come dal12. Per utilizzare una classe di archiviazione differente come tua base, vedi il riferimento delle classi di archiviazione.

Crea la classe di archiviazione nelle stessa regione e nella stessa zona dei tuoi cluster e dei tuoi nodi di lavoro. Per individuare la regione del proprio cluster, eseguire il comando ibmcloud ks cluster get --cluster <cluster_name_or_ID> e cercare 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 archiviazione a blocchi di tipo Endurance.

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

Esempio di archiviazione a blocchi ad alte prestazioni.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-block-performance-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-block
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Performance"
  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]"
reclaimPolicy: "Delete"

Montaggio dell'archiviazione blocchi con un file system XFS

I seguenti esempi creano una classe di archiviazione che esegue il provisioning dell'archiviazione blocchi con un file system XFS.

Esempio di archiviazione a blocchi di tipo Endurance.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
labels:
  addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  fsType: "xfs"
reclaimPolicy: "Delete"

Esempio di archiviazione a blocchi ad alte prestazioni.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ibmc-block-custom-xfs
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
  classVersion: "2"
  type: "Performance"
  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]
  fsType: "xfs"
reclaimPolicy: "Delete"

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 automaticamente eliminati quando si elimina il cluster. Nel caso di storage provisionato in modo statico 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 è presente 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 block volume-list --columns id --columns notes | grep <pv_name>
    

    Output di esempio

    12345678   {"plugin":"ibmcloud-block-storage-plugin-689df949d6-4n9qg","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"block-storage-pvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-block-silver","reclaim":"Delete"}
    

    Descrizione delle informazioni del campo Note.

    "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, ovvero Endurance o Performance.

    "ns":"default"

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

    "pvc":"block-storage-pvc"

    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 block volume-cancel <classic_block_id>
    

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

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

ibmcloud sl block volume-list