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 vSphere Container Storage Interface (CSI)
  • Driver CSI di terze parti
  • Plug-in di volume 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 in un ambiente multi-host, ogni dispositivo a blocchi deve essere collegato a tutti gli host l'ambiente e il datastore deve essere configurato su ciascun host tramite Montare 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, esiste un oggetto StorageClass denominato standard e è designato come StorageClass predefinito. 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 valore predefinito di StorageClass e il provisioner è il plug-in del volume "in-tree", 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
...

StorageClass del cluster utente

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

Il valore di StorageClass standard-rwo è designato come predefinito, mentre il driver CSI vSphere viene elencato 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 valore predefinito di StorageClass e il provisioner è il driver CSI vSphere, csi.vsphere.vmware.com. Puoi vedi anche 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 include una serie plug-in del volume "in-tree". Tuttavia, la maggior parte di questi plug-in "integrati" del volume sono deprecati (inclusi il plug-in del volume in-tree vSphere), per ulteriori informazioni, consulta Migrazione CSI progetto.

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. I nostri suggerimenti è necessario utilizzare il driver CSI vSphere al posto del plug-in di volume "in-tree".

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

Ad esempio, supponiamo che un oggetto PersistentVolumeClaim specifichi standard StorageClass, che elenca il plug-in del volume "in-tree" 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, sono disponibili verifica che il tuo ambiente sia adatto alla migrazione CSI.

Ad esempio, i controlli preflight:

  • Verifica che le versioni vCenter ed ESXI siano appropriate.
  • Verifica che il driver CSI vSphere sia abilitato se sono presenti vSphere in-tree gli oggetti PersistentVolume.
  • 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 di cui è stato eseguito il provisioning dal driver CSI vSphere.

Per ulteriori informazioni, vedi Esecuzione dei 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.

Completa la migrazione a CSI

Con la funzionalità di migrazione Kubernetes CSI abilitata per impostazione predefinita nella versione 1.15, PersistentVolume supportato dal plug-in del volume vSphere integrato funzionando in un ambiente solo CSI, si limita a eseguire il reindirizzamento dei plug-in in-tree al plug-in CSI. Poiché le specifiche PersistentVolume sono immutabili, le specifiche saranno le stesse del plug-in del volume in-tree.

Di conseguenza, l'intero set di funzionalità di CSI, come l'espansione dei volumi e gli snapshot dei volumi, non è disponibile per questi volumi. Per sfruttare questi devi eseguire la migrazione completa del carico di lavoro stateful a CSI ricreando specifica della risorsa Kubernetes con campi CSI. Abbiamo sviluppato un strumenti automatizzati per facilitare la migrazione dei carichi di lavoro stateful a CSI senza tempi di inattività delle applicazioni, ti consentono di usare l'intero set di funzionalità CSI.

Utilizzo di driver di terze parti

Se vuoi eseguire il provisioning di volumi di archiviazione diversi dai datastore vSphere, puoi un nuovo oggetto StorageClass in un cluster che usa un driver di archiviazione diverso. Poi potrai imposta il valore predefinito del cluster, o configurare i carichi di lavoro per l'utilizzo di StorageClass (esempio di StatefulSet).

Partner per lo spazio di archiviazione

Abbiamo collaborato con molti fornitori di servizi di archiviazione per qualificare i loro sistemi di archiviazione con Google Distributed Cloud. Consulta l'elenco completo degli strumenti di archiviazione idonei partner.

Espansione del volume

Puoi espandere le dimensioni un volume permanente dopo che ne è stato eseguito il provisioning modificando la capacità nell'oggetto PersistentVolumeClaim. Puoi espandere online mentre il volume è utilizzato da un pod o un'espansione offline in cui il volume in uso.

Per Driver CSI vSphere, l'espansione offline è disponibile nelle versioni di vSphere >= 7.0 ed è disponibile l'espansione online è disponibile nelle versioni di vSphere >= 7.0 Update 2.

Il campo StorageClass standard-rwo imposta allowVolumeExpansion su true per impostazione predefinita per i cluster appena creati in esecuzione su >= vSphere 7.0. 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 Utilizzo dell'espansione del volume.

Snapshot dei volumi CSI

Puoi creare snapshot dell'archiviazione permanente utilizzando il metodo VolumeSnapshot e VolumeSnapshotClass Google Cloud. 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 sugli snapshot dei volumi, consulta Utilizzo delle istantanee dei volumi.

I controller degli snapshot CSI vengono dipartiti 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 i StatefulSet.

Risoluzione dei problemi

Consulta la sezione Risoluzione dei problemi di archiviazione.

Per approfondire