Storage

Questa pagina illustra i concetti di Google Distributed Cloud (solo software) per lo spazio di archiviazione VMware.

Riepilogo

Google Distributed Cloud si integra con sistemi di archiviazione a blocchi o di file esterni tramite:

  • Il driver Container Storage Interface (CSI) di vSphere
  • Driver CSI di terze parti
  • Plugin dei volumi in-tree di Kubernetes

Datastore vSphere

Quando crei un cluster di amministrazione, specifica un datastore vSphere esistente per i dati etcd del cluster.

Quando crei un cluster utente, puoi utilizzare lo stesso datastore del cluster di amministrazione o specificarne uno diverso. Puoi anche specificare i datastore per i singoli pool di nodi.

I datastore vSphere utilizzati dai cluster di amministrazione e utente possono essere supportati da NFS, vSAN o VMFS su un dispositivo a blocchi, ad esempio un array di archiviazione esterno. In un ambiente multi-host, ogni dispositivo a blocchi deve essere collegato a tutti gli host in questo ambiente e il datastore deve essere configurato su ogni host tramite l'opzione Monta datastore su host aggiuntivi.

StorageClasses

Quando crei un PersistentVolumeClaim, puoi specificare una classe di archiviazione che fornisce informazioni su come verrà eseguito il provisioning dello spazio di archiviazione. Se non specifichi una classe di archiviazione, viene utilizzata la classe di archiviazione predefinita.

StorageClass del cluster di amministrazione

Nei cluster di amministrazione è presente una classe di archiviazione denominata standard, che è designata come classe di archiviazione predefinita. La classe di archiviazione standard elenca il plug-in dei volumi in-tree di vSphere come provisioner.

Per visualizzare standard StorageClass:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
    standard --output yaml

Nell'output, puoi vedere che standard è il StorageClass predefinito e il provisioner è il plug-in dei volumi in-tree di vSphere, kubernetes.io/vsphere-volume. Puoi anche vedere il nome di un datastore vSphere.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  ...
  labels:
    bundle.gke.io/component-name: admin-storage-class
  name: standard
...
parameters:
  datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...

StorageClasses del cluster utente

Nei cluster utente è presente una StorageClass denominata standard e un'altra StorageClass denominata standard-rwo.

La classe di archiviazione standard-rwo è designata come predefinita e elenca il driver CSI di vSphere come provisioner.

Per visualizzare standard-rwo StorageClass:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
    standard-rwo --output yaml

Nell'output, puoi vedere che standard-rwo è il StorageClass predefinito e il provisioner è il driver CSI vSphere, csi.vsphere.vmware.com. Puoi anche visualizzare l'URL di un datastore vSphere:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
    ...
  labels:
    bundle.gke.io/component-name: user-vsphere-csi-driver-addon
    ...
  name: standard-rwo
...
parameters:
  datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...

Plugin dei volumi in-tree di Kubernetes

Kubernetes viene fornito con una serie di plug-in per i volumi in-tree. Tuttavia, la maggior parte di questi plug-in dei volumi in-tree è deprecata (incluso il plug-in dei volumi in-tree di vSphere). Per ulteriori informazioni, consulta il progetto Migrazione CSI.

Migrazione CSI per il driver di archiviazione vSphere

In passato, il plug-in dei volumi vSphere in-tree era il provisioning per la classe di archiviazione predefinita nei cluster utente. Tuttavia, ora il plug-in dei volumi vSphere in-tree è deprecato e il driver CSI vSphere è il provisioning per la classe di archiviazione predefinita nei cluster utente. Ti consigliamo di utilizzare il driver CSI vSphere anziché il plug-in dei volumi in-tree.

A partire dalla versione 1.15 di Google Distributed Cloud, la funzionalità di migrazione CSI di Kubernetes è abilitata per impostazione predefinita per il plug-in di volume vSphere in-tree. Ciò significa che se un workload utilizza un volume vSphere integrato, tutte le chiamate alle operazioni di archiviazione interna vengono reindirizzate automaticamente al driver CSI vSphere.

Ad esempio, supponiamo che un PersistentVolumeClaim specifichi la standard StorageClass, che elenca il plug-in dei volumi in-tree di vSphere, kubernetes.io/vsphere-volume, come provisioner. A questo punto, le chiamate alle operazioni di archiviazione di qualsiasi carico di lavoro che utilizza questo PersistentVolumeClaim verranno reindirizzate al driver CSI vSphere, csi.vsphere.vmware.com.

Controlli preflight

Quando crei un nuovo cluster o esegui l'upgrade di un cluster, vengono eseguiti controlli preflight che assicurano che l'ambiente sia adatto alla migrazione di CSI.

Ad esempio, i controlli preflight:

  • Verifica che le versioni di vCenter ed ESXI siano appropriate.
  • Verifica che il driver CSI vSphere sia abilitato se sono presenti vSphere PersistentVolume in-tree.
  • Verifica che le classi di archiviazione vSphere non abbiano determinati parametri che vengono ignorati dopo la migrazione del CSI.
  • Verifica le annotazioni sui volumi permanenti e sulle richieste di volumi permanenti in-tree creati in modo statico necessarie per la migrazione del CSI.
  • Verifica che il cluster possa eseguire correttamente un carico di lavoro utilizzando un volume CSI provisioning dal driver CSI vSphere.

Per ulteriori informazioni, consulta Eseguire i controlli preflight.

Problemi noti

Esistono diversi problemi noti relativi al driver CSI vSphere. Per informazioni e soluzioni alternative, consulta la sezione Problemi noti nelle note di rilascio del driver VMware vSphere CSI 3.0.

Completare la migrazione a CSI

Con la funzionalità di migrazione CSI di Kubernetes abilitata per impostazione predefinita nella versione 1.15, il PersistentVolume supportato dal plug-in di volume vSphere in-tree continua a funzionare in un ambiente solo CSI, ma reindirizza le chiamate di operazioni del plug-in in-tree al plug-in CSI. Poiché la specifica PersistentVolume è immutabile, la specifica sarà la stessa del plug-in del volume in-tree.

Di conseguenza, il set completo di funzionalità di CSI, come l'espansione dei volumi e gli snapshot dei volumi, non è disponibile per questi volumi. Per sfruttare queste funzionalità, il carico di lavoro con stato deve essere sottoposto a migrazione completa a CSI ricreando la specifica della risorsa Kubernetes con i campi CSI. Abbiamo sviluppato un strumento automatizzato per facilitare la migrazione del carico di lavoro stateful a CSI senza tempi di inattività dell'applicazione, che ti consentirà di utilizzare l'intero set di funzionalità di CSI.

Utilizzo di driver di terze parti

Se vuoi eseguire il provisioning di volumi di archiviazione diversi dai datastore vSphere, puoi creare una nuova classe di archiviazione in un cluster che utilizza un driver di archiviazione diverso. Quindi, puoi impostare StorageClass come predefinito del cluster o configurare i carichi di lavoro in modo che utilizzino StorageClass (esempio di StatefulSet).

Partner per lo spazio di archiviazione

Abbiamo collaborato con molti fornitori di soluzioni di archiviazione per certificare i loro sistemi di archiviazione con Google Distributed Cloud. Consulta l'elenco completo dei partner di archiviazione qualificati.

Espansione del volume

Puoi espandere le dimensioni di un volume permanente dopo il provisioning modificando la richiesta di capacità in PersistentVolumeClaim. Puoi eseguire un'espansione online mentre il volume è in uso da un pod o un'espansione offline quando il volume non è in uso.

Per il driver CSI vSphere, l'espansione offline è disponibile nelle versioni vSphere >= 7.0 e l'espansione online è disponibile nelle versioni vSphere >= 7.0 Update 2.

La risorsa StorageClass imposta allowVolumeExpansion su true per impostazione predefinita per i cluster appena creati in esecuzione su vSphere 7.0 e versioni successive.standard-rwo Puoi utilizzare l'espansione sia online che offline per i volumi che utilizzano questo StorageClass. Per un cluster sottoposto ad upgrade, poiché i tipi di archiviazione non vengono modificati durante gli upgrade del cluster, quando viene eseguito l'upgrade di un cluster da 1.7 a 1.8, l'impostazione allowVolumeExpansion in standard-rwo rimane non impostata, il che significa che l'espansione del volume non è consentita.

Per ulteriori informazioni sull'espansione del volume, consulta Utilizzare l'espansione del volume.

Snapshot dei volumi CSI

Puoi creare snapshot dello spazio di archiviazione permanente utilizzando le risorse VolumeSnapshot e VolumeSnapshotClass. Per utilizzare questa funzionalità su un volume CSI, il driver CSI deve supportare gli snapshot dei volumi e il contenitore sidecar external-snapshotter deve essere incluso nel deployment del driver CSI.

Per ulteriori informazioni sulle istantanee dei volumi, consulta Utilizzo delle istantanee dei volumi.

I controller degli snapshot CSI vengono dispiacchiati automaticamente quando crei un cluster.

Pulizia del volume

Quando elimini un cluster utente, i volumi di cui è stato eseguito il provisioning dal driver CSI vSphere non vengono eliminati. Prima di eliminare il cluster, devi eliminare tutti i volumi, i PersistentVolumeClaim e gli StatefulSet.

Risoluzione dei problemi

Consulta la sezione Risoluzione dei problemi di archiviazione.

Per approfondire