Questa pagina spiega i concetti di archiviazione di Google Distributed Cloud (solo software) per VMware.
Riepilogo
Google Distributed Cloud si integra con sistemi di archiviazione di file o blocchi esterni tramite:
- Il driver vSphere Container Storage Interface (CSI)
- Driver CSI di terze parti
- Plug-in dei volumi in-tree di Kubernetes
Datastore vSphere
Quando crei un cluster di amministrazione, specifichi un datastore vSphere esistente per i dati etcd del cluster.
Quando crei un cluster utente, puoi utilizzare lo stesso datastore del cluster di amministrazione oppure puoi 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 dell'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 StorageClass che fornisce informazioni su come verrà eseguito il provisioning dello spazio di archiviazione. Se non specifichi un oggetto StorageClass, viene utilizzato quello predefinito.
StorageClass del cluster di amministrazione
Nei cluster di amministrazione, esiste un oggetto StorageClass denominato standard, che è designato come StorageClass predefinito. La classe di archiviazione standard elenca il plug-in del volume in-tree di vSphere come provisioner.
Per visualizzare l'oggetto StorageClass standard:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
standard --output yaml
Nell'output, puoi vedere che standard è l'oggetto StorageClass predefinito e
il provisioner è il plug-in del volume 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
...
StorageClass del cluster utente
Nei cluster utente, esiste un oggetto StorageClass denominato standard e un altro oggetto StorageClass denominato standard-rwo.
La classe di archiviazione standard-rwo è designata come classe di archiviazione predefinita ed elenca il driver CSI vSphere come provisioner.
Per visualizzare l'oggetto StorageClass standard-rwo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
standard-rwo --output yaml
Nell'output, puoi vedere che standard-rwo è la StorageClass predefinita 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
...
Plug-in dei volumi in-tree di Kubernetes
Kubernetes viene fornito con una serie di plug-in per volumi in-tree. Tuttavia, la maggior parte di questi plug-in per volumi in-tree è deprecata (incluso il plug-in per volumi in-tree vSphere). Per ulteriori informazioni, consulta il progetto di migrazione CSI.
Migrazione CSI per il driver di archiviazione vSphere
In passato, il plug-in del volume vSphere in-tree era il provisioner per la classe di archiviazione predefinita nei cluster utente. Tuttavia, ora il plug-in di volume vSphere in-tree è deprecato e il driver CSI vSphere è l'oggetto di provisioning per la classe StorageClass predefinita nei cluster utente. Ti consigliamo di utilizzare il driver CSI vSphere anziché il plug-in del volume 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 del volume vSphere integrato. Ciò significa che se un workload utilizza un volume vSphere in-tree, tutte le chiamate interne alle operazioni di archiviazione vengono reindirizzate automaticamente al driver CSI vSphere.
Ad esempio, supponiamo che un PersistentVolumeClaim specifichi la StorageClass standard, che elenca il plug-in del volume in-tree di vSphere, kubernetes.io/vsphere-volume, come provisioner. In questo modo, le chiamate alle operazioni di archiviazione di qualsiasi workload che utilizza quel PersistentVolumeClaim verranno reindirizzate al driver CSI vSphere, csi.vsphere.vmware.com.
Controlli preflight
Quando crei un nuovo cluster o ne esegui l'upgrade, vengono eseguiti controlli preflight per assicurarsi che l'ambiente sia adatto alla migrazione 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 PersistentVolume vSphere in-tree.
- Verifica che le StorageClass vSphere non abbiano determinati parametri che vengono ignorati dopo la migrazione CSI.
- Verifica le annotazioni sui PersistentVolume e sui PersistentVolumeClaim in-tree creati staticamente richiesti per la migrazione CSI.
- Verifica che il cluster possa eseguire correttamente un workload utilizzando un volume CSI di cui è stato eseguito il provisioning dal driver CSI vSphere.
Per saperne di più, consulta Esecuzione dei controlli preflight.
Problemi noti
Esistono diversi problemi noti relativi al driver vSphere CSI. Per informazioni e soluzioni alternative, consulta la sezione Problemi noti nelle note di rilascio del driver CSI di VMWare vSphere 3.0.
Completa la migrazione a CSI
Con la funzionalità di migrazione CSI di Kubernetes abilitata per impostazione predefinita nella versione 1.15, i PersistentVolume supportati dal plug-in di volume vSphere integrato continuano a funzionare in un ambiente solo CSI, reindirizzando semplicemente le chiamate alle operazioni del plug-in integrato al plug-in CSI. Poiché la specifica PersistentVolume è immutabile,
sarà la stessa del plug-in del volume in-tree.
Per questo motivo, il set completo di funzionalità di CSI, come l'espansione e gli snapshot del volume, non è disponibile per questi volumi. Per sfruttare queste funzionalità, è necessario eseguire la migrazione completa del workload stateful a CSI ricreando la specifica della risorsa Kubernetes con i campi CSI. Abbiamo sviluppato uno strumento automatizzato per facilitare la migrazione del workload stateful a CSI senza tempi di inattività dell'applicazione, che ti consentirà di utilizzare il set di funzionalità CSI completo.
Utilizzo di driver di terze parti
Se vuoi eseguire il provisioning di volumi di archiviazione diversi dai datastore vSphere, puoi creare una nuova StorageClass in un cluster che utilizza un driver di archiviazione diverso. In seguito, puoi impostare StorageClass come predefinita del cluster o configurare i workload in modo che utilizzino StorageClass (esempio di StatefulSet).
Partner di archiviazione
Abbiamo collaborato con molti fornitori di spazio di archiviazione per qualificare 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 è utilizzato da un pod o un'espansione offline se il volume non è in uso.
Per il driver CSI vSphere, l'espansione offline è disponibile nelle versioni vSphere >= 7.0, mentre l'espansione online è disponibile nelle versioni vSphere >= 7.0 Update 2.
La classe di archiviazione 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 questa classe di archiviazione. Per un cluster di cui è stato eseguito l'upgrade, poiché le StorageClass non vengono modificate durante gli upgrade del cluster, quando viene eseguito l'upgrade di un cluster dalla versione 1.7 alla 1.8, l'impostazione allowVolumeExpansion in standard-rwo rimane non configurata, 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 le risorse VolumeSnapshot e VolumeSnapshotClass. Per utilizzare questa funzionalità su un volume CSI, il driver CSI deve supportare gli snapshot del volume e il container sidecar external-snapshotter deve essere incluso nel deployment del driver CSI.
Per saperne di più sugli snapshot dei volumi, consulta Utilizzo degli snapshot dei volumi.
I controller di snapshot CSI vengono sottoposti a deployment 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. Devi eliminare tutti i volumi, i PersistentVolumeClaim e gli StatefulSet prima di eliminare il cluster.
Risoluzione dei problemi
Consulta la sezione Risoluzione dei problemi relativi allo spazio di archiviazione.