Provisioning dei PVC nel servizio per volumi a blocchi

È possibile eseguire il provisioning dinamico di un volume a blocchi utilizzando il plugin CSI specificato dalla definizione della classe di memorizzazione oci-bv (provisioner: blockvolume.csi.oraclecloud.com). Ad esempio, se l'amministratore del cluster non ha creato alcun PV adatto corrispondente alla richiesta PVC.

È possibile definire un PVC in un file denominato csi-bvs-pvc.yaml. Ad esempio:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mynginxclaim
spec:
  storageClassName: "oci-bv"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Inserire il seguente comando per creare il PVC dal file csi-bvs-pvc.yaml:

kubectl create -f  csi-bvs-pvc.yaml

L'uscita dal comando di cui sopra conferma la creazione del PVC:

persistentvolumeclaim "mynginxclaim" created

Verificare che il PVC sia stato creato eseguendo kubectl get pvc:

kubectl get pvc

L'output del comando precedente mostra lo stato corrente del PVC:

		
NAME               STATUS   VOLUME   CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Pending                                    oci-bv         4m

Il PVC ha lo stato Pending perché la definizione della classe di memorizzazione oci-bv include volumeBindingMode: WaitForFirstConsumer.

È possibile utilizzare questo PVC quando si creano altri oggetti, come i baccelli. Ad esempio, è possibile creare un nuovo pod dalla seguente definizione di pod, che indica al sistema di utilizzare il PVC mynginxclaim come volume nginx, montato dal pod su /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: mynginxclaim

Dopo aver creato il nuovo pod, è possibile verificare che il PVC sia stato legato a un nuovo volume persistente inserendo:

kubectl get pvc

L'uscita dal comando di cui sopra conferma che il PVC è stato legato:

			
NAME               STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv         4m

È possibile verificare che il pod stia utilizzando la nuova richiesta di volume persistente immettendo:

kubectl describe pod nginx

È possibile visualizzare le statistiche di capacità per il nuovo volume persistente utilizzando uno strumento di aggregazione delle metriche, ad esempio Prometheus.

Uno snapshot di un volume Kubernetes è uno snapshot di un volume persistente in un sistema di storage. È possibile utilizzare uno snapshot del volume per eseguire il provisioning di un nuovo volume persistente. Per ulteriori informazioni sugli snapshot dei volumi Kubernetes, consulta la sezione relativa agli snapshot dei volumi nella documentazione di Kubernetes.

Quando si utilizza il plugin del volume CSI per connettere i cluster ai volumi a blocchi nel servizio per volumi a blocchi, è possibile utilizzare i backup dei volumi a blocchi per eseguire il provisioning degli snapshot dei volumi Kubernetes. Puoi usare uno snapshot del volume per creare un nuovo volume a blocchi e preinserirlo con i dati del backup del volume a blocchi. Per ulteriori informazioni sui backup dei volumi a blocchi nel servizio per volumi a blocchi, vedere Panoramica dei backup dei volumi a blocchi.

È possibile utilizzare il plugin del volume CSI per eseguire il provisioning di uno snapshot del volume in uno dei due modi riportati di seguito.

• In modo dinamico: è possibile richiedere la creazione di un backup del volume a blocchi con provisioning di un volume persistente. La richiesta di volume persistente viene specificata utilizzando l'oggetto VolumeSnapshot e vengono specificati i parametri da utilizzare per creare il backup del volume a blocchi utilizzando l'oggetto VolumeSnapshotClass. Gli snapshot del volume con provisioning dinamico vengono anche definiti snapshot del volume dinamico. Vedere Creazione di snapshot del volume con provisioning dinamico.
• Staticamente: è possibile fornire i dettagli di un backup del volume a blocchi esistente utilizzando l'oggetto VolumeSnapshotContent. Gli snapshot di volume con provisioning statico vengono anche definiti snapshot di volume statici e snapshot di volume con provisioning preliminare. Creazione di snapshot di volumi con provisioning statico

Quando crei uno snapshot del volume con provisioning dinamico, le stesse tag in formato libero e le stesse tag definite applicate al volume a blocchi di origine vengono applicate al backup del volume a blocchi. Tuttavia, puoi utilizzare i parametri per applicare tag aggiuntive al backup del volume a blocchi (vedere Applicazione di tag ai backup dei volumi a blocchi).

Prima di creare snapshot del volume da utilizzare con i cluster creati da Kubernetes Engine, è necessario soddisfare una serie di prerequisiti. Vedere Prerequisiti per la creazione di snapshot del volume.

Tenere presente quanto riportato di seguito durante la creazione e l'uso degli snapshot dei volumi.

• È possibile creare snapshot di volumi solo quando si utilizza il plugin del volume CSI, ovvero non è possibile creare snapshot di volumi quando si utilizza il plugin del volume FlexVolume.
• Nel caso dei backup dinamici dei volumi, il plugin dei volumi CSI crea un nuovo backup dei volumi a blocchi per eseguire il provisioning di uno snapshot dei volumi dinamici nello stesso compartimento del cluster. Nel caso di snapshot di volumi statici, il backup del volume a blocchi che esegue il provisioning di uno snapshot del volume statico può trovarsi in un compartimento diverso dal cluster, a condizione che esistano istruzioni criteri appropriate per consentire al cluster di accedere a tale altro compartimento (vedere Prerequisiti per la creazione di snapshot del volume).
• Non è possibile utilizzare il plugin volume CSI per ripopolare un volume esistente con i dati. In altre parole, non è possibile ripristinare (ripristinare) i dati di un volume persistente esistente in uno stato precedente modificando lo snapshot del volume specificato nel manifesto della richiesta di volume persistente. È possibile utilizzare il plugin volume CSI solo per popolare un nuovo volume con i dati.
• Quando si crea un backup del volume a blocchi (ad esempio, quando si crea uno snapshot dinamico del volume), la chiave di cifratura utilizzata durante la creazione del volume a blocchi viene utilizzata anche per creare il backup del volume a blocchi. Non è possibile specificare una nuova chiave di cifratura quando si crea il backup di un volume a blocchi. Pertanto, il backup del volume a blocchi utilizza la stessa cifratura del volume a blocchi di cui esegue il backup.
• La dimensione specificata per un volume persistente di cui è stato eseguito il provisioning da uno snapshot del volume non deve essere inferiore alla dimensione del volume originale da cui è stato creato lo snapshot.
• Quando il plugin del volume CSI crea un nuovo volume a blocchi per il backup di un volume persistente di cui è stato eseguito il provisioning da uno snapshot del volume, il posizionamento del volume a blocchi dipende dai requisiti di topologia della richiesta di creazione del volume. Ad esempio, se il plugin del volume CSI crea un volume a blocchi per un pod che utilizza una richiesta di volume persistente, il volume a blocchi viene creato nello stesso dominio di disponibilità del nodo di lavoro su cui è in esecuzione il pod.
• Gli snapshot dello spazio di nomi incrociati non sono supportati.
• Con l'aumento del numero di oggetti VolumeSnapshot e VolumeSnapshotContent in un cluster, possono consumare spazio significativo in etcd, il che potrebbe causare un funzionamento imprevisto del cluster. Per mantenere il cluster in buono stato, si consiglia di implementare un meccanismo di rimozione per eseguire regolarmente il cleanup degli oggetti VolumeSnapshot e VolumeSnapshotContent non più necessari.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

ALLOW any-user to manage volume-backups in compartment <compartment-name> where request.principal.type = 'cluster'
ALLOW any-user to use volumes in compartment <compartment-name> where request.principal.type = 'cluster'

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: "oci-bv"
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvctobackup.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: sample-pvc

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
deletionPolicy: Delete

kubectl create -f csi-mysnapshotclass.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
  namespace: default
spec:
  volumeSnapshotClassName: my-snapclass
  source:
    persistentVolumeClaimName: sample-pvc

kubectl create -f csi-mysnapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: my-static-snapshot-content
spec:
  deletionPolicy: Retain
  driver: blockvolume.csi.oraclecloud.com
  source:
    snapshotHandle: ocid1.volumebackup.oc1.iad.aaaaaa______xbd
  volumeSnapshotRef:
    name: my-static-snapshot
    namespace: default

kubectl create -f csi-mystaticsnapshotcontent.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-static-snapshot
spec:
  source:
    volumeSnapshotContentName: my-static-snapshot-content

kubectl create -f csi-mystaticsnapshot.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fromsnapshot
  namespace: default
spec:
  storageClassName: oci-bv
  dataSource:
    name: test-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvcfromsnapshot.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-restore
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-fromsnapshot

oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'

oci.oraclecloud.com/defined-tags: '{"<tag-namespace>": {"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}}'

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
  oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'
deletionPolicy: Delete

Una copia Kubernetes è un duplicato esatto di un volume persistente esistente in un sistema di storage. Puoi duplicare un volume persistente esistente per eseguire il provisioning di una nuova richiesta di volume persistente. Il nuovo volume persistente contiene una copia dei dati dal volume persistente di origine, ma è indipendente dal volume persistente di origine. Puoi utilizzare le copie dei volumi per eseguire rapidamente il test delle modifiche alla configurazione, senza alcun impatto su un ambiente di produzione. Per ulteriori informazioni sulle copie Kubernetes, consulta la sezione relativa alla copia dei volumi CSI nella documentazione di Kubernetes.

Nel servizio per volumi a blocchi, puoi duplicare un volume a blocchi per creare un nuovo volume a blocchi precompilato con i dati del volume a blocchi di origine. Per ulteriori informazioni sulla duplicazione dei volumi a blocchi nel servizio per volumi a blocchi, vedere Duplicazione di un volume a blocchi.

Quando si utilizza il plugin del volume CSI per connettere i cluster ai volumi a blocchi nel servizio per volumi a blocchi, è possibile eseguire il provisioning di un nuovo PVC con un nuovo volume a blocchi duplicato da un volume a blocchi esistente che esegue il provisioning di un altro PVC esistente. Per indicare che si desidera che il plugin del volume CSI duplichi il volume a blocchi esistente per il nuovo PVC, specificare il PVC esistente come origine dati per il nuovo PVC.

Il nuovo PVC può essere utilizzato allo stesso modo di qualsiasi altro PVC ed è completamente separato dal PVC esistente specificato come origine dati. Analogamente, il nuovo volume a blocchi e il volume a blocchi esistente da cui viene duplicato sono risorse completamente separate e possono essere aggiornati, duplicati, snapshot ed eliminati indipendentemente l'uno dall'altro.

Non appena il volume a blocchi di origine viene duplicato e viene creato un nuovo volume a blocchi (in genere entro pochi secondi), il nuovo volume a blocchi ha lo stato Disponibile. Tutti i dati presenti nel volume a blocchi di origine in quel momento vengono copiati nel nuovo volume a blocchi (non vengono copiate modifiche successive). Tuttavia, i dati vengono copiati in background, il che può richiedere fino a trenta minuti a seconda della dimensione del volume a blocchi (ad esempio, la copia di un volume a blocchi da 1 TB può richiedere fino a quindici minuti). Pertanto, per evitare la possibilità di errori o danneggiamento dei dati, il nuovo PVC ha uno stato di In sospeso fino a quando tutti i dati non sono stati copiati. Quando tutti i dati sono stati copiati, il nuovo PVC è legato al PV fornito dal nuovo volume a blocchi e il nuovo PVC ha uno stato Disponibile.

Prima di eseguire il provisioning di una nuova richiesta di volume persistente, è necessario soddisfare alcuni prerequisiti duplicando il volume a blocchi che già esegue il provisioning di una richiesta di volume persistente esistente. Vedere Prerequisiti per la duplicazione di un volume a blocchi esistente per il provisioning di un nuovo PVC.

Quando si duplica un volume a blocchi per eseguire il provisioning di un nuovo PVC, tenere presente quanto riportato di seguito.

• Il plugin del volume CSI crea il nuovo volume a blocchi nello stesso dominio di disponibilità, area e tenancy del volume a blocchi di origine.
• Il nuovo volume a blocchi creato dal plugin del volume CSI può essere duplicato non appena ha lo stato Disponibile.
• Tutti i requisiti di topologia in una richiesta di creazione del volume vengono ignorati. Ad esempio, se il plugin del volume CSI duplica un volume a blocchi per un pod che utilizza una richiesta di volume persistente, il nuovo volume a blocchi viene creato nello stesso dominio di disponibilità del nodo di lavoro su cui è in esecuzione il pod.
• Non è possibile utilizzare il plugin del volume CSI per duplicare i volumi a blocchi creati dal plugin del volume FlexVolume.
• Impossibile eliminare il PVC di origine mentre è in corso la duplicazione. Allo stesso modo, non puoi eliminare un volume a blocchi di origine mentre i dati vengono copiati in un volume a blocchi che è stato duplicato da esso.
• La duplicazione dello spazio di nomi incrociato non è supportata. Il nuovo PVC e il PVC di origine devono essere entrambi nello stesso spazio di nomi.
• Non è necessario specificare esplicitamente una classe di stoccaggio per il nuovo PVC. Se si specifica esplicitamente una classe di storage per il nuovo PVC, la classe di storage specificata può essere diversa dalla classe di storage specificata per il PVC di origine. Se non si specifica una classe di memorizzazione per il nuovo PVC, viene utilizzata la classe di memorizzazione predefinita.

Ad esempio, si definisce una richiesta di volume persistente denominata my-clone-pvc in un file denominato csi-myclonepvc.yaml. Il provisioning della richiesta di volume persistente my-clone-pvc viene eseguito da un volume a blocchi creato mediante la duplicazione del volume a blocchi in cui viene eseguito il provisioning della richiesta di volume persistente my-source-pvc:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-clone-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: custom-clone-storage-class
  resources:
    requests:
      storage: 50Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: my-source-pvc

Creare la richiesta di volume persistente:

kubectl create -f csi-myclonepvc.yaml

È possibile utilizzare la richiesta di volume persistente quando si definiscono altri oggetti, ad esempio i pod. Ad esempio, la seguente definizione pod indica al sistema di utilizzare la richiesta di volume persistente my-clone-pvc come volume nginx, che viene montato dal pod in /sample-volume.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: my-clone-pvc

Dopo aver creato il nuovo pod, la richiesta di volume persistente my-clone-pvc viene associata a un nuovo volume persistente di cui è stato eseguito il provisioning da un volume a blocchi che è stato duplicato dal volume a blocchi eseguendo il provisioning della richiesta di volume persistente my-source-pvc.

È possibile creare un PVC da un volume a blocchi esistente o da un backup del volume a blocchi per l'uso da parte del plugin volume FlexVolume. Ad esempio, se l'amministratore del cluster ha creato un backup del volume a blocchi da utilizzare durante il provisioning di una nuova richiesta di volume persistente. Un backup del volume a blocchi di questo tipo potrebbe essere fornito con dati pronti per l'uso da parte di altri oggetti, ad esempio i pod.

È possibile definire un PVC in un file denominato flex-pvcfrombackup.yaml. L'elemento annotazione volume.beta.kubernetes.io/oci-volume-source consente di specificare l'origine del volume a blocchi da utilizzare durante il provisioning di una nuova richiesta di volume persistente mediante il plugin volume FlexVolume. Puoi specificare l'OCID di un volume a blocchi o di un backup del volume a blocchi come valore dell'annotazione. In questo esempio, si specifica l'OCID del backup del volume a blocchi creato dall'amministratore del cluster. Ad esempio:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myvolume
  annotations:
    volume.beta.kubernetes.io/oci-volume-source: ocid1.volumebackup.oc1.iad.abuw...
spec:
  selector:
    matchLabels:
      topology.kubernetes.io/zone: US-ASHBURN-AD-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Si noti che il file flex-pvcfrombackup.yaml include l'elemento matchLabels, applicabile solo nel caso del plugin volume FlexVolume.

Inserire il seguente comando per creare il PVC dal file flex-pvcfrombackup.yaml:

kubectl create -f flex-pvcfrombackup.yaml

L'uscita dal comando di cui sopra conferma la creazione del PVC:

persistentvolumeclaim "myvolume" created

Verificare che il PVC sia stato creato e associato a un nuovo volume persistente creato dal backup del volume immettendo:

kubectl get pvc

L'output del comando precedente mostra lo stato corrente del PVC:

			
NAME           STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
myvolume       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci            4m

È possibile utilizzare il nuovo volume persistente creato dal backup del volume quando si definiscono altri oggetti, ad esempio i pod. Ad esempio, la seguente definizione di pod indica al sistema di utilizzare il PVC myvolume come volume nginx, montato dal pod su /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: myvolume

Dopo aver creato il nuovo pod, è possibile verificare che sia in esecuzione e utilizzare la nuova richiesta di volume persistente immettendo:

kubectl describe pod nginx

Il servizio Oracle Cloud Infrastructure Block Volume cifra sempre tutti i volumi a blocchi e i backup dei volumi in archivio utilizzando l'algoritmo Advanced Encryption Standard (AES) con la cifratura a 256 bit. Per impostazione predefinita, tutti i volumi e i relativi backup vengono cifrati utilizzando le chiavi di cifratura fornite da Oracle. Ogni volta che un volume viene duplicato o ripristinato da un backup, al volume viene assegnata una nuova chiave di cifratura univoca.

Per ulteriori informazioni, vedere Gestione delle chiavi. È possibile cifrare tutti i volumi e i relativi backup utilizzando le chiavi di cui si è proprietari e che si gestiscono utilizzando il servizio Vault. Se non si configura un volume per l'uso del servizio Vault o se in seguito si rimuove l'assegnazione di una chiave dal volume, il servizio per volumi a blocchi utilizza invece la chiave di cifratura fornita da Oracle. Ciò si applica sia alla cifratura in archivio che alla cifratura in transito pseudo-virtualizzata.

Tutti i dati che passano dall'istanza al volume a blocchi vengono trasferiti tramite una rete interna estremamente sicura. In caso di requisiti specifici correlati alla cifratura dei dati durante lo spostamento tra l'istanza e il volume a blocchi, il servizio per volumi a blocchi offre la possibilità di abilitare la cifratura in transito per i collegamenti di volumi pseudo-irtualizzati nelle istanze di virtual machine (VM). Alcune forme Bare Metal supportano la cifratura in transito per i volumi a blocchi collegati a iSCSI dell'istanza.

Per ulteriori informazioni sulla cifratura dei volumi a blocchi e sul supporto della cifratura in transito, vedere Cifratura dei volumi a blocchi.

Quando i PVC Kubernetes sono supportati dal servizio per volumi a blocchi, puoi scegliere la modalità di cifratura dei volumi a blocchi specificando:

• Chiave di cifratura master da utilizzare impostando la proprietà kms-key-id nella definizione della classe di storage Kubernetes. È possibile specificare l'OCID di una chiave di cifratura master nel servizio Vault.
• Modalità di collegamento del volume a blocchi all'istanza di computazione impostando la proprietà attachment-type nella definizione della classe di storage Kubernetes su iscsi o paravirtualized.
• Indica se la cifratura in transito è abilitata per ogni pool di nodi in un cluster impostando la proprietà isPvEncryptionInTransitEnabled del pool di nodi (utilizzando l'interfaccia CLI, l'API o l'opzione Usa cifratura in transito del pool di nodi nella console).

L'interazione delle impostazioni specificate determina la modalità di cifratura dei volumi a blocchi, come illustrato nella tabella.

Prima di poter creare un cluster per il quale si desidera gestire la chiave di cifratura master, è necessario:

• Creare una chiave di cifratura master appropriata nel vault (o ottenere l'OCID di tale chiave). Vedere Gestione delle chiavi.
• Creare un criterio che conceda l'accesso alla chiave di cifratura principale. Vedere Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

Per ulteriori informazioni sulla rotazione delle chiavi nel servizio Vault, vedere Rotating a Vault Key.

Quando viene creato un PVC utilizzando il plugin volume CSI (provisioner: blockvolume.csi.oraclecloud.com), è possibile espandere la dimensione del volume online. In questo modo, è possibile distribuire inizialmente applicazioni con una certa quantità di storage e successivamente aumentare lo storage disponibile senza tempi di inattività.

Se si desidera supportare gli aumenti della richiesta di memorizzazione, impostare allowVolumeExpansion: true nella definizione della classe di memorizzazione specificata per il PVC. Ad esempio:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-bv
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  attachment-type: "paravirtualized"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Per impostazione predefinita, la classe di memorizzazione oci-bv predefinita per il plugin del volume CSI è allowVolumeExpansion: true.

Per espandere le dimensioni di un volume, modificare il manifesto in PVC e aggiornare le dimensioni del volume, quindi applicare il manifesto. Quando il disco viene sottoposto a nuova scansione per consentire al sistema operativo di identificare la dimensione del volume espanso (che può richiedere alcuni minuti), l'aumento dello storage diventa automaticamente disponibile per i pod che utilizzano il PVC. Non è necessario riavviare i pod.

Immettere il comando seguente per confermare che il PVC è stato associato a un volume a blocchi appena ingrandito:

kubectl get pvc <pvc_name> -o yaml

Tenere presente quanto riportato di seguito.

• L'espansione dei volumi è supportata nei cluster su cui è in esecuzione Kubernetes 1.19 o versione successiva.
• La classe di storage oci-bv predefinita per il plugin del volume CSI è configurata con allowVolumeExpansion: true nei cluster su cui è in esecuzione Kubernetes 1.19 o versione successiva. Le definizioni delle classi di memorizzazione oci-bv nei cluster esistenti che eseguono Kubernetes 1.19 o versioni successive vengono modificate automaticamente per impostare allowVolumeExpansion: true.
• Non è possibile ridurre le dimensioni di un volume a blocchi. È possibile specificare solo un valore più grande della dimensione corrente del volume a blocchi. Se si aggiorna un file manifesto in PVC per richiedere meno spazio di archiviazione rispetto a quanto richiesto in precedenza, la richiesta di archiviazione non riesce.
• Per ulteriori informazioni sull'aumento delle dimensioni dei volumi a blocchi nel servizio per volumi a blocchi, vedere Ridimensionamento di un volume. In particolare, tenere presente il suggerimento di creare un backup prima di ridimensionare un volume a blocchi.

I volumi a blocchi nel servizio per volumi a blocchi possono essere configurati per diversi livelli di prestazioni, in base ai requisiti di I/O del carico di lavoro previsti. Le prestazioni del volume a blocchi sono espresse in VPU (volume performance units). Sono disponibili diversi livelli di prestazioni, tra cui:

• Costo inferiore (0 VPU)
• Bilanciato (10 VPU)
• Prestazioni più elevate (20 VPU)
• Ultra High Performance (tra 30 VPU e 120 VPU)

Per impostazione predefinita, i volumi a blocchi vengono configurati per il livello di prestazioni bilanciato (10 VPU). Per ulteriori informazioni sui diversi livelli di prestazioni dei volumi a blocchi, vedere Livelli di prestazioni dei volumi a blocchi.

Quando si definisce un PVC utilizzando il plugin volume CSI (provisioner: blockvolume.csi.oraclecloud.com), è possibile specificare un livello di prestazioni del volume a blocchi diverso nella definizione della classe di storage appropriato per il carico di lavoro previsto.

Tenere presente che non è possibile modificare successivamente il livello di prestazioni di un volume a blocchi che supporta un PVC. È invece necessario definire una nuova classe di storage, impostare il livello di prestazioni in base alle esigenze e creare un nuovo PVC fornito dalla nuova classe di storage.

I volumi a blocchi nel servizio per volumi a blocchi possono essere configurati per diversi tipi di file system. Il file system più appropriato da utilizzare dipende, tra le altre cose, dalla dimensione prevista del file e dal numero di file da elaborare. Sono disponibili diversi tipi di file system, tra cui:

• ext3: il tipo di file system ext3 include funzionalità di journaling per migliorare l'affidabilità e la disponibilità. I controlli di coerenza dopo un'interruzione dell'alimentazione o un arresto incontrollato del sistema non sono necessari.
• ext4: oltre alle funzioni ext3, il tipo di file system ext4 supporta estensioni (blocchi fisici contigui), preallocazione, allocazione ritardata, controllo più rapido del file system, journaling più affidabile e altri miglioramenti.
• XFS: il file system XFS è un tipo di file system di journaling ad alte prestazioni che garantisce un'elevata scalabilità per i thread I/O, la larghezza di banda del file system, la dimensione dei file e dei file system, anche quando il file system si estende su molti dispositivi di memorizzazione.

I file system ext3 e ext4 sono in genere considerati più adatti per le applicazioni che utilizzano un singolo thread di lettura/scrittura e file di piccole dimensioni. Mentre, il file system XFS è generalmente considerato più adatto per le applicazioni che hanno più thread di lettura/scrittura e file più grandi.

Quando un PVC viene creato utilizzando il plugin volume CSI (provisioner: blockvolume.csi.oraclecloud.com), è possibile specificare un tipo di file system per il volume a blocchi appropriato per il carico di lavoro previsto.

Per impostazione predefinita, i volumi a blocchi vengono configurati con un file system ext4. Se il file system ext4 non è il file system più appropriato per il carico di lavoro previsto, è possibile specificare un tipo di file system alternativo nella definizione della classe di storage.

Per creare un PVC supportato da un volume a blocchi con un file system ext3 o XFS, impostare il parametro fstype nella definizione della classe di memorizzazione personalizzata come indicato di seguito.

• per ext3, impostare csi.storage.k8s.io/fstype: ext3
• per XFS, impostare csi.storage.k8s.io/fstype: xfs

Ad esempio, per creare un PVC supportato da un volume a blocchi con un file system ext3:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: oci-bv-ext3
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  csi.storage.k8s.io/fstype: ext3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForConsumer

Creare un file manifesto per un PVC di cui è stato eseguito il provisioning dalla classe di memorizzazione oci-bv-ext3 e includere una richiesta di archiviazione. Ad esempio, in un file denominato csi-bvs-pvc-fstype.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: oci-bv-claim-ext3
spec:
  storageClassName: oci-bv-ext3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Immettere il comando seguente per creare il PVC dal file csi-bvs-PVC-fstype.yaml:

kubectl apply -f csi-bvs-pvc-fstype.yaml

Dopo aver creato il PVC, è possibile utilizzarlo quando si creano altri oggetti, come i baccelli. Ad esempio, è possibile creare un nuovo pod dalla seguente definizione di pod, che indica al sistema di utilizzare il PVC oci-bv-claim-ext3 come volume nginx, montato dal pod su /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: oci-bv-claim-ext3

Dopo aver creato il nuovo pod, è possibile verificare che il PVC sia stato legato a un nuovo volume persistente inserendo:

kubectl get pvc

L'uscita dal comando di cui sopra conferma che il PVC è stato legato:

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
oci-bv-claim-ext3       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv-ext3         4m

È possibile verificare che il pod stia utilizzando la nuova richiesta di volume persistente immettendo:

kubectl describe pod nginx

Tenere presente che in seguito non è possibile modificare il file system di un volume a blocchi che supporta un PVC. È invece necessario definire una nuova classe di storage, impostare il file system in base alle esigenze e creare un nuovo PVC fornito dalla nuova classe di storage.

Quando si utilizza il plugin del volume CSI ( provisioner: blockvolume.csi.oraclecloud.com ) per connettere i cluster ai volumi a blocchi nel servizio per volumi a blocchi, è possibile associare un PVC a un PV di cui viene eseguito il provisioning da un volume a blocchi configurato come volume a blocchi raw. Quando un volume a blocchi è stato configurato come volume a blocchi raw, anziché come file system di cui è stato eseguito il MOUNT, un PV di cui è stato eseguito il provisioning da tale volume a blocchi viene visualizzato come dispositivo a blocchi per i contenitori in esecuzione su un cluster. Di conseguenza, le applicazioni in esecuzione all'interno del contenitore possono accedere al volume a blocchi collegato come dispositivo a blocchi, senza il sovraccarico delle prestazioni causato dall'accesso al dispositivo tramite un file system. Tale sovraccarico può essere particolarmente significativo per le applicazioni sensibili alle prestazioni (come i database) che beneficiano dell'accesso diretto ai dispositivi a blocchi.

Per configurare il volume a blocchi che supporta un PVC come volume a blocchi raw, specificare volumeMode: Block nel file manifesto del PVC. Tenere presente che, se non specificato, si suppone che il valore volumeMode: Filesystem e i volumi a blocchi siano configurati con un file system ext4 per impostazione predefinita.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-raw-block-volume
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: oci-bv
  volumeMode: Block

Immettere il comando seguente per creare il PVC dal file csi-bvs-PVC-raw.yaml:

kubectl apply -f csi-bvs-pvc-raw.yaml

Dopo aver creato il PVC, è possibile utilizzarlo quando si creano altri oggetti, come i baccelli. Ad esempio, è possibile creare un nuovo pod dalla seguente definizione di pod, che indica al sistema di utilizzare il PVC PVC-raw-block-volume come volume di storage per il contenitore raw-volume-test, al quale il contenitore può accedere all'indirizzo /dev/block:

apiVersion: v1
kind: Pod
metadata:
  name: raw-volume-test-pod
spec:
  containers:
  - name: raw-volume-test
    image: centos
    command: ["/bin/sh"]
    volumeDevices:
    - name: raw-volume
      devicePath: /dev/block
  volumes:
  - name: raw-volume
    persistentVolumeClaim:
      claimName: pvc-raw-block-volume

Dopo aver creato il nuovo pod, è possibile verificare che il PVC sia stato legato a un nuovo volume persistente inserendo:

kubectl get pvc

L'uscita dal comando di cui sopra conferma che il PVC è stato legato:

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
pvc-raw-block-volume    Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv              4m

È possibile verificare che il pod stia utilizzando la nuova richiesta di volume persistente immettendo:

kubectl describe pod raw-volume-test-pod

Tenere presente che in seguito non è possibile modificare se il volume a blocchi che supporta un PVC è configurato come volume a blocchi raw o come file system attivato. Invece, devi creare un nuovo PVC e impostare volumeMode: in modo appropriato nel manifesto in PVC.