Storage

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

Riepilogo

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

  • Il driver Container Storage Interface (CSI) di vSphere
  • Driver CSI di terze parti
  • Plug-in di volume in-tree di Kubernetes

Datastore vSphere

Quando crei un cluster di amministrazione, devi specificare 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 dell' ambiente e il datastore deve essere configurato su ogni host tramite l' opzione Mount Datastore on Additional Hosts (Monta il datastore su host aggiuntivi).

StorageClasses

Quando crei un oggetto PersistentVolumeClaim, puoi specificare un oggetto StorageClass che fornisce informazioni su come verrà eseguito il provisioning dell'archiviazione. Se non specifichi un oggetto StorageClass, viene utilizzato quello predefinito.

Oggetto StorageClass del cluster di amministrazione

Nei cluster di amministrazione è presente un oggetto StorageClass denominato standard, che è designato come oggetto StorageClass predefinito. L'oggetto StorageClass standard elenca il plug-in di 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 di 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
...

Oggetti StorageClass del cluster utente

Nei cluster utente sono presenti un oggetto StorageClass denominato standard e un altro StorageClass denominato standard-rwo.

L'oggetto StorageClass standard-rwo è designato come oggetto StorageClass predefinito 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 è l'oggetto 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
...

Plug-in di volume in-tree di Kubernetes

Kubernetes viene fornito con una serie di plug-in di volume in-tree. Tuttavia, la maggior parte di questi plug-in di volume in-tree sono deprecati (incluso il plug-in di volume in-tree di vSphere). Per ulteriori informazioni, consulta il progetto di migrazione CSI .

Migrazione CSI per il driver di archiviazione vSphere

In passato, il plug-in di volume in-tree di vSphere era il provisioner per l'oggetto StorageClass predefinito nei cluster utente. Ora, però, il plug-in di volume in-tree di vSphere è deprecato e il driver CSI vSphere è il provisioner per l'oggetto StorageClass predefinito nei cluster utente. Ti consigliamo di utilizzare il driver CSI vSphere anziché il plug-in di 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 in-tree di vSphere. Ciò significa che se un carico di lavoro utilizza un volume in-tree di vSphere, tutte le chiamate alle operazioni di archiviazione interne vengono reindirizzate automaticamente al driver CSI vSphere.

Ad esempio, supponiamo che un oggetto PersistentVolumeClaim specifichi l'oggetto StorageClass standard, che elenca il plug-in di volume in-tree di vSphere, kubernetes.io/vsphere-volume, come provisioner. Quindi, tutte le chiamate alle operazioni di archiviazione di qualsiasi carico di lavoro che utilizza l'oggetto 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 assicurarti che il tuo ambiente sia adatto alla migrazione CSI.

Ad esempio, i controlli preflight:

  • Verificano che le versioni di vCenter ed ESXI siano appropriate.
  • Verificano che il driver CSI vSphere sia abilitato se sono presenti oggetti PersistentVolume in-tree di vSphere.
  • Verificano che gli oggetti StorageClass di vSphere non abbiano determinati parametri ignorati dopo la migrazione CSI.
  • Verificano le annotazioni sugli oggetti PersistentVolume e PersistentVolumeClaim in-tree creati staticamente richiesti per la migrazione CSI.
  • Verificano 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, consulta 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 CSI vSphere 3.0 di VMWare.

Completa la migrazione a CSI

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

Per questo motivo, l'insieme completo di funzionalità CSI, come le funzionalità di espansione del volume e snapshot del volume, non è disponibile per questi volumi. Per usufruire di queste funzionalità, il carico di lavoro con stato deve essere migrato completamente 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 con stato a CSI senza tempi di inattività dell'applicazione, che ti consentirà di utilizzare l'insieme completo di funzionalità CSI.

Utilizzo di driver di terze parti

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

Partner di archiviazione

Abbiamo collaborato con molti fornitori 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 eseguito il provisioning modificando la richiesta di capacità nell'oggetto 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 di vSphere >= 7.0 e l'espansione online è disponibile nelle versioni di vSphere >= 7.0 Update 2.

L'oggetto StorageClass standard-rwo imposta allowVolumeExpansion su true per impostazione predefinita per i cluster appena creati in esecuzione su >= vSphere 7.0. Puoi utilizzare sia l'espansione online che offline per i volumi che utilizzano questo oggetto StorageClass. Per un cluster di cui è stato eseguito l'upgrade, poiché gli oggetti StorageClass non vengono modificati 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 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 VolumeSnapshot e VolumeSnapshotClass risorse. Per utilizzare questa funzionalità su un volume CSI, il driver CSI deve supportare gli snapshot dei volumi e il container sidecar 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 degli 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. Prima di eliminare il cluster, devi eliminare tutti i volumi, gli oggetti PersistentVolumeClaim e gli oggetti StatefulSet.

Risoluzione dei problemi

Consulta Risoluzione dei problemi relativi all'archiviazione.

Per approfondire