Ce document explique comment migrer des disques d'un Datastore vSphere vers un autre datastore vSphere à l'aide de la gestion basée sur les 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 des 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 les clusters d'utilisateur Controlplane V2
Disques de démarrage (fichiers VMDK) utilisés par tous les nœuds de cluster d'administrateur et de 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'utilisateur kubeception
Stockage pour les charges de travail que vous déployez sur des nœuds de calcul de 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, migrez-le vers la haute disponibilité avant de continuer.
Vérifiez que le cluster d'administrateur dispose d'un plan de contrôle 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, assurez-vous que vous voyez trois nœuds du plan de contrôle. 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 le résultat, si le champ
datastore
est vide et que le champstoragePolicyName
n'est pas vide, cela signifie que le cluster utilise SPBM.Le cluster ne doit pas utiliser le plug-in de volume vSphere "in-tree".
Si votre cluster a été mis à niveau à partir d'une ancienne version de Google Distributed Cloud, il est possible qu'il contienne des PV/PVC 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 toutes 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 StorageClasses et découvrez les approvisionneurs qu'elles utilisent:
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
Dans le résultat, si la colonne
PROVISIONER
indiquekubernetes.io/vsphere-volume
, les PVC créées avec cette StorageClass utilisent le plug-in de volume vSphere in-tree. Pour les StatefulSets utilisant ces PV/PVC, migrez-les vers le pilote CSI vSphere.
Effectuer la migration du stockage
Google Distributed Cloud accepte deux catégories de migration du stockage:
Stockage vMotion pour les VM, qui déplace le stockage de VM, y compris les volumes VPC vSphere associés utilisés par les pods exécutés sur un nœud, et les VMDK utilisés par ces volumes CNS de VM associés aux nœuds
La relocalisation de volume CNS, qui déplace les volumes CNS vSphere spécifiés vers un datastore compatible sans exécuter de vMotion de stockage pour les VM
Effectuer des opérations de stockage vMotion pour les 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 règle de stockage.
Dans votre environnement vSphere, migrez les VM de cluster utilisant l'ancien datastore vers le nouveau. Pour obtenir des instructions, consultez la page Migrer une machine virtuelle vers une nouvelle ressource de calcul et un nouvel espace de stockage.
Sur votre poste de travail administrateur, vérifiez que les VM ont bien été migrées vers le nouveau datastore.
Récupérez les objets Machine dans le cluster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
Dans la sortie, les disques associés aux VM s'affichent sous
status.disks
. 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 bien é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 CNS Relocation pour déplacer des volumes CNS
Si vous souhaitez uniquement déplacer des volumes CNS provisionnés par le pilote CSI vSphere, suivez les instructions de la section Migrer des volumes de conteneurs dans vSphere. Cela peut être plus simple si vous n'avez que des volumes CNS dans l'ancien datastore.
Mettre à jour vos règles de stockage si nécessaire
Dans votre environnement vSphere, mettez à jour la règle de stockage pour exclure les anciens datastores. Sinon, les nouveaux volumes et les VM recréées peuvent être attribués à un ancien datastore.