Cette page a été traduite par l'API Cloud Translation.

Migration du stockage avec la gestion basée sur des règles de stockage

Ce document explique comment migrer des disques d'un datastore vSphere vers un autre datastore vSphere avec la gestion des règles de stockage (SPBM).

1.29: Disponibilité générale
1.28: Aperçu
1.16: Non disponible

Vous pouvez migrer les types de stockage suivants:

Stockage pour les composants système gérés par Google Distributed Cloud, y compris:
- Disques de données (fichiers VMDK) utilisés par les nœuds du plan de contrôle des clusters d'administrateur et des clusters d'utilisateurs Controlplane V2
- Disques de démarrage (fichiers VMDK) utilisés par tous les nœuds du cluster d'administrateur et du cluster d'utilisateur
- Volumes vSphere représentés par des PV/PVC dans le cluster d'administrateur et utilisés par les composants du plan de contrôle des clusters d'utilisateurs kubeception
Stockage pour les charges de travail que vous déployez sur les nœuds de calcul du cluster d'utilisateur avec des PV/PVC provisionnés par le plug-in de volume vSphere "in-tree" ou le pilote CSI vSphere

Conditions préalables pour un cluster d'administrateur

Le cluster d'administrateur doit disposer d'un plan de contrôle à haute disponibilité. Si votre cluster d'administrateur dispose d'un plan de contrôle standard, effectuez une migration vers la haute disponibilité avant de continuer.
Vérifiez que le cluster d'administrateur dispose d'un plan de contrôle en haute disponibilité :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
```
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Dans le résultat, vérifiez que trois nœuds de plan de contrôle s'affichent. Par exemple :
```
admin-cp-1   Ready    control-plane,master ...
admin-cp-2   Ready    control-plane,master ...
admin-cp-3   Ready    control-plane,master ...
```

Conditions préalables pour tous les clusters (administrateur et utilisateur)

La réparation automatique des nœuds doit être désactivée sur le cluster. Si la réparation automatique des nœuds est activée, désactivez-la.
Le cluster doit utiliser la gestion basée sur les règles de stockage (SPBM). Si votre cluster n'utilise pas SPBM, créez une règle de stockage avant de continuer.
Vérifiez que le cluster utilise SPBM:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
  -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
```
(Cluster d'utilisateur uniquement) Vérifiez que les pools de nœuds utilisent SPBM :
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \
  -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'
```
Remplacez les éléments suivants :
- CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster (administrateur ou utilisateur).
- ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- USER_CLUSTER_NAME : nom du cluster d'utilisateur.
Dans la sortie, si le champ datastore est vide et que le champ storagePolicyName n'est pas vide, le cluster utilise SPBM.
Le cluster ne doit pas utiliser le plug-in de volume "in-tree" vSphere.

Si votre cluster a été mis à niveau à partir d'une version antérieure de Google Distributed Cloud, il est possible que des PV/PVC aient été provisionnés par le plug-in de volume vSphere "in-tree". Ce type de volume peut être utilisé par un nœud de plan de contrôle d'un cluster d'utilisateur kubeception ou par une charge de travail que vous avez créée sur un nœud de calcul.

Liste de tous les PVC et de leurs StorageClass:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
   -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
```
Répertoriez toutes les classes de stockage et identifiez les provisionneurs qu'elles utilisent:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
```
Dans la sortie, si la colonne PROVISIONER est kubernetes.io/vsphere-volume, les PVC créés avec cette StorageClass utilisent le plug-in de volume dans l'arborescence vSphere. Pour les StatefulSets qui utilisent ces PV/PVC, migrez-les vers le pilote CSI vSphere.

Effectuer la migration de stockage

Google Distributed Cloud prend en charge deux catégories de migration de stockage:

Storage vMotion pour les VM, qui déplace le stockage des VM, y compris les volumes CNS vSphere associés utilisés par les pods exécutés sur un nœud et les VMDK utilisés par ces volumes CNS VM associés aux nœuds
Relocalisation de volume CNS, qui déplace les volumes CNS vSphere spécifiés vers un datastore compatible sans effectuer de vMotion de stockage pour les VM

Effectuer une migration vMotion de stockage pour des VM

La migration implique des étapes que vous effectuez dans votre environnement vSphere et des commandes que vous exécutez sur votre poste de travail administrateur:

Dans votre environnement vSphere, ajoutez vos datastores cibles à votre stratégie de stockage.
Dans votre environnement vSphere, migrez les VM de cluster utilisant l'ancien datastore vers le nouveau datastore. Pour obtenir des instructions, consultez la section Migrer une machine virtuelle vers une nouvelle ressource de calcul et de stockage.

Sur votre poste de travail administrateur, vérifiez que les VM ont bien été migrées vers le nouveau datastore.

Obtenez les objets Machine du cluster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

Dans la sortie, sous status.disks, vous pouvez voir les disques associés aux VM. Par exemple :

status:
addresses:
– address: 172.16.20.2
  type: ExternalIP
disks:
– bootdisk: true
  datastore: pf-ds06
  filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk
  uuid: 6000C29d-8edb-e742-babc-9c124013ba54
– datastore: pf-ds06
  filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk
  uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9

Vérifiez que tous les disques de toutes les machines du cluster ont été migrés vers le datastore cible.

Sur votre poste de travail administrateur, exécutez gkectl diagnose pour vérifier que le cluster est opérationnel.

Appeler les API de relocalisation CNS pour déplacer des volumes CNS

Si vous ne souhaitez déplacer que les volumes CNS provisionnés par le pilote CSI vSphere, vous pouvez suivre les instructions de la section Migrer des volumes de conteneur dans vSphere. Cette méthode peut être plus simple si vous ne disposez de volumes CNS que dans l'ancien datastore.

Mettre à jour vos règles de stockage si nécessaire

Dans votre environnement vSphere, mettez à jour la stratégie de stockage pour exclure les anciens datastores. Sinon, les nouveaux volumes et les VM recréées peuvent être attribués à un ancien datastore.

Migration du stockage avec la gestion basée sur des règles de stockage Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.