Questa pagina descrive i concetti di Google Distributed Cloud (solo software) per l'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
- Plug-in di 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 fornisca 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 una risorsa StorageClass denominata standard, che
è designata come StorageClass predefinita. standard StorageClass 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 è StorageClass predefinita e
il provisioner è il plug-in del volume in-tree di vSphere,
kubernetes.io/vsphere-volume. Puoi anche visualizzare 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 utenti, esiste una StorageClass denominata standard e un'altra
StorageClass denominata standard-rwo.
La risorsa StorageClass standard-rwo è designata come StorageClass predefinita e
elenca il driver CSI di 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 è 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 di volumi in-tree di Kubernetes
Kubernetes viene fornito con una serie di plugin di volumi in-tree. Tuttavia, la maggior parte di questi plug-in di volumi in-tree sono ritirati (incluso il plug-in di volumi in-tree vSphere). Per ulteriori informazioni, consulta il progetto Migrazione CSI.
Migrazione CSI per il driver di archiviazione vSphere
In passato, il plugin del volume vSphere in-tree era il provisioner per la classe di archiviazione predefinita nei cluster utente. Tuttavia, ora il plug-in del volume vSphere in-tree è ritirato e il driver CSI vSphere è il provisioner 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 di volume vSphere integrato. Ciò significa che se un workload utilizza un volume vSphere in-tree, tutte le chiamate alle operazioni di archiviazione interne 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. Quindi, tutte le operazioni di archiviazione di qualsiasi workload che utilizza
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 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 di vSphere non abbiano determinati parametri che vengono ignorati dopo la migrazione CSI.
- Verifica le annotazioni su PersistentVolume e 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 la sezione 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 delle note di rilascio del driver VMware vSphere CSI 3.0.
Completa 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 integrato continua
a funzionare in un ambiente solo CSI, reindirizza solo le chiamate di operazione del plug-in integrato
al plug-in CSI. Poiché la specifica PersistentVolume è immutabile,
la specifica sarà la stessa del plug-in del volume in-tree.
Per questo motivo, l'insieme completo di funzionalità CSI come l'espansione del volume e gli snapshot del volume non sono disponibili per questi volumi. Per sfruttare queste funzionalità, il workload stateful deve essere completamente migrato a CSI ricreando la specifica della risorsa Kubernetes con i campi CSI. Abbiamo sviluppato uno 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à CSI.
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. Poi, puoi impostare StorageClass come predefinita del cluster o configurare i carichi di lavoro 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 che è stato sottoposto a provisioning modificando la richiesta di capacità in PersistentVolumeClaim. Puoi eseguire un'espansione online mentre il volume è in uso da un pod oppure un'espansione offline in cui il volume non è in uso.
Per il driver CSI vSphere, l'espansione offline è disponibile nelle versioni di vSphere >= 7.0, mentre l'espansione online è disponibile nelle versioni di vSphere >= 7.0 Update 2.
La risorsa StorageClass standard-rwo imposta allowVolumeExpansion su true per impostazione predefinita
per i cluster appena creati che vengono eseguiti su vSphere 7.0 o versioni successive. Puoi utilizzare l'espansione sia online che offline per i volumi che utilizzano questa StorageClass. Per un cluster di cui è stato eseguito l'upgrade, poiché le StorageClass non vengono modificate durante gli upgrade del cluster, quando un cluster viene aggiornato dalla versione 1.7 alla 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 volume 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 dei volumi e il contenitore secondario external-snapshotter deve essere
incluso nel deployment del driver CSI.
Per ulteriori informazioni sugli snapshot dei volumi, consulta Utilizzo degli snapshot dei volumi.
I controller snapshot CSI vengono implementati 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, PersistentVolumeClaims e StatefulSet.
Risoluzione dei problemi
Consulta la sezione Risoluzione dei problemi di archiviazione.