Migrer un datastore vers SPBM

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

Cette page s'adresse aux spécialistes du stockage qui configurent et gèrent les performances, l'utilisation et les dépenses liées au stockage. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

1.30: Disponibilité générale
1.29: Aperçu
1.16 et versions antérieures: non disponible

Contexte

Vous pouvez spécifier un datastore dans les fichiers de configuration de cluster de quatre manières différentes:

L'héritage de ces champs est le suivant:

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

Exemples :

  • Si userCluster.vCenter.datastore est vide, il hérite de la valeur de adminCluster.vCenter.datastore.

  • Si userCluster.nodePools[i].vsphere.datastore est vide, il hérite de la valeur de userCluster.vCenter.datastore.

De même, vous pouvez spécifier une stratégie de stockage dans quatre endroits:

L'héritage des champs storagePolicyName est le même que celui des champs datastore.

Avant de commencer

  • Il s'agit d'une migration à sens unique. Nous ne prenons pas en charge la migration vers l'état précédent.
  • Le datastore doit être compatible avec la nouvelle stratégie de stockage que vous allez définir.
  • Seuls les clusters d'administrateur haute disponibilité (HA) sont compatibles. Si votre cluster d'administrateur n'est pas à haute disponibilité, vous devez d'abord migrer le cluster d'administrateur vers la haute disponibilité.

Migrer un cluster d'utilisateur

La procédure de migration varie selon que vous souhaitez migrer l'ensemble du cluster d'utilisateurs ou les nœuds du plan de contrôle et les pools de nœuds de calcul séparément. Cette option vous permet de sélectionner différentes règles de stockage pour les nœuds de plan de contrôle et les pools de nœuds de calcul.

Pour vous aider à planifier un intervalle de maintenance, tenez compte des points suivants:

  • La migration de l'ensemble du cluster ne nécessite qu'une seule mise à jour du cluster.

  • La migration des nœuds du plan de contrôle et des pools de nœuds de calcul séparément nécessite deux mises à jour du cluster.

Ensemble du cluster

Suivez ces étapes si vous souhaitez migrer l'ensemble du cluster, y compris tous les nœuds du plan de contrôle et les pools de nœuds de calcul. La version de votre cluster utilisateur doit être la version 1.30 ou ultérieure.

  1. Modifiez le fichier de configuration du cluster utilisateur comme suit:

    1. Définissez le champ vCenter.storagePolicyName sur le nom de la règle de stockage.

    2. Supprimez ou mettez en commentaire les éléments suivants, le cas échéant:

      • Champ vCenter.datastore
      • Section masterNode.vsphere
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    vCenter:
  datastore: ds-1

    Après les modifications:

    vCenter:
  storagePolicyName: sp-1
  # datastore: ds-1

  2. Mettez à jour le cluster d'utilisateur :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

    • USER_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'utilisateur.

Mettre à jour le StorageClass groupé

Après avoir mis à jour les paramètres de configuration du cluster, vous devez mettre à jour le StorageClass groupé.

  1. Obtenez l'StorageClass par défaut actuel pour le vsphere-csi-driver groupé, nommé standard-rwo, et enregistrez-le dans un fichier local appelé storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

  2. Faites une copie de storage-class.yaml par précaution, car vous devez modifier le fichier:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Supprimez le StorageClass par défaut du cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Mettez à jour la configuration dans storage-class.yaml comme suit:

    1. Supprimez ou commentez les champs suivants:

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la stratégie de stockage.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Après les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Appliquez le fichier StorageClass modifié au cluster d'utilisateur:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Clusters d'utilisateurs Kubeception uniquement

Pour les clusters d'utilisateurs kubeception, vous devez mettre à jour le StorageClass pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur. Le champ de configuration enableControlplaneV2 des clusters kubeception est défini sur false. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'utilisateur lui-même. Lorsque Controlplane V2 n'est pas activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'administrateur, ce qui est appelé kubeception.

Exécutez la commande suivante pour déterminer si Controlplane V2 est activé dans le cluster:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Si la sortie est false, procédez comme suit pour mettre à jour le StorageClass par défaut des nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur:

  1. Obtenez l'StorageClass par défaut actuel pour le vsphere-csi-driver groupé, nommé USER_CLUSTER_NAME-csi, et enregistrez-le dans un fichier local appelé storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

  2. Faites une copie de storage-class-kubeception.yaml par précaution, car vous devez modifier le fichier:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Supprimez le StorageClass par défaut du cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Mettez à jour la configuration dans storage-class-kubeception.yaml comme suit:

    1. Supprimez ou commentez les champs suivants:

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la stratégie de stockage.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Après les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Appliquez le StorageClass modifié au cluster d'administrateur:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Après la migration

Si vous créez un pool de nœuds après une migration, le nouveau pool suit les règles d'héritage en fonction du cluster mis à jour.

Par exemple, supposons que vous ayez migré vCenter.datastore vers une stratégie de stockage.

Si vous créez un pool de nœuds et laissez nodePools[i].vsphere.datastore et nodePools[i].vsphere.storagePolicyName vides, le pool de nœuds hérite de la stratégie de stockage spécifiée dans vCenter.storagePolicyName.

Nœuds séparément

Suivez ces étapes si vous souhaitez migrer les nœuds du plan de contrôle et les pools de nœuds de calcul séparément.

  1. Version 1.29 uniquement: obtenez la configuration actuelle du cluster. Cette étape n'est pas nécessaire si le cluster utilisateur est en version 1.30 ou ultérieure.

    gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster-name USER_CLUSTER_NAME \
  --output-dir ./gen-files

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.

    • USER_CLUSTER_NAME : nom du cluster d'utilisateur.

    Dans ./gen-files, localisez user-cluster.yaml.

    Pour en savoir plus sur l'obtention du fichier de configuration, consultez la section Générer des fichiers de configuration à partir d'un cluster.

    Le nom datastore est défini à chaque niveau dans le fichier de configuration généré: cluster, masterNode (pour les nœuds de plan de contrôle) et nodepools (pour les nœuds de calcul), comme illustré dans l'exemple suivant:

    apiVersion: v1
kind: UserCluster
...
# VCenter config in cluster level:
vCenter:
  datastore: ds-1
...
# VCenter config in master node level:
masterNode:
  vsphere:
    datastore: ds-1
...
# VCenter config in nodepool level:
nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

Migrer les nœuds du plan de contrôle

Pour migrer les nœuds du plan de contrôle, procédez comme suit:

  1. Apportez les modifications suivantes dans le fichier de configuration du cluster utilisateur:

    • Définissez le champ masterNode.vsphere.storagePolicyName avec le nom de la règle de stockage.
    • Supprimez ou commentez le champ masterNode.vsphere.datastore.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    masterNode:
  vsphere:
    datastore: ds-1

    Après les modifications:

    masterNode:
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Mettez à jour le cluster d'utilisateur :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

    • USER_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'utilisateur.

    Attendez que la commande de mise à jour soit terminée avant de mettre à jour les pools de nœuds.

Migrer des pools de nœuds

Pour migrer tous les pools de nœuds, procédez comme suit:

  1. Apportez les modifications suivantes dans le fichier de configuration du cluster utilisateur:

    • Définissez chaque champ nodePools[i].vsphere.storagePolicyName avec le nom de la règle de stockage.
    • Supprimez ou commentez chaque champ nodePools[i].vsphere.datastore.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    nodepools:
- name: pool-1
  vsphere:
    datastore: ds-1
- name: pool-2
  vsphere:
    datastore: ds-1

    Après les modifications:

    nodepools:
- name: pool-1
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1
- name: pool-2
  vsphere:
    # datastore: ds-1
    storagePolicyName: sp-1

  2. Mettez à jour le cluster d'utilisateur :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

(Facultatif) Mettre à jour la règle de stockage au niveau du cluster

Pour les clusters d'utilisateurs, les champs datastore et storagePolicyName de la section vCenter au niveau du cluster sont une valeur par défaut utilisée par les sections masterNode et nodepools. Une fois les étapes précédentes effectuées, les paramètres vCenter, datastore et storagePolicyName au niveau du cluster ne seront plus utilisés par aucun composant du cluster. Vous pouvez laisser la section vCenter au niveau du cluster telle quelle ou la mettre à jour pour qu'elle soit cohérente avec masterNode et nodepools.

Si vous laissez le paramètre tel quel, nous vous recommandons d'ajouter un commentaire au-dessus de la section vCenter au niveau du cluster indiquant que le paramètre est ignoré, car il est remplacé par les paramètres des sections masterNode et nodepools.

Si vous préférez, vous pouvez modifier la section vCenter au niveau du cluster pour qu'elle corresponde aux sections masterNode et nodepools, puis mettre à jour le cluster en procédant comme suit:

  1. Modifiez le fichier de configuration du cluster utilisateur comme suit:

    • Définissez le champ vCenter.storagePolicyName avec le nom de la règle de stockage.
    • Supprimez ou commentez le champ vCenter.datastore.

  2. Mettez à jour le cluster d'utilisateur :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

    Cette commande de mise à jour n'apporte aucune modification au cluster, mais elle met à jour les champs vCenter.datastore et vCenter.storagePolicyName côté serveur (OnPremUserCluster).

Mettre à jour le StorageClass groupé

Après avoir mis à jour les paramètres de configuration, vous devez mettre à jour le StorageClass groupé.

  1. Obtenez l'StorageClass par défaut actuel pour le vsphere-csi-driver groupé, nommé standard-rwo, et enregistrez-le dans un fichier local appelé storage-class.yaml.

    kubectl get storageclass standard-rwo -oyaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml

    Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'utilisateur.

  2. Faites une copie de storage-class.yaml par précaution, car vous devez modifier le fichier:

    cp storage-class.yaml storage-class.yaml-backup.yaml

  3. Supprimez le StorageClass par défaut du cluster:

    kubectl delete storageclass standard-rwo \
    --kubeconfig USER_CLUSTER_KUBECONFIG

  4. Mettez à jour la configuration dans storage-class.yaml comme suit:

    1. Supprimez ou commentez les champs suivants:

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la stratégie de stockage.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Après les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Appliquez le fichier StorageClass modifié au cluster d'utilisateur:

    kubectl apply -f storage-class.yaml \
    --kubeconfig USER_CLUSTER_KUBECONFIG

Clusters d'utilisateurs Kubeception uniquement

Pour les clusters d'utilisateurs kubeception, vous devez mettre à jour le StorageClass pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur. Le champ de configuration enableControlplaneV2 des clusters kubeception est défini sur false. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'utilisateur lui-même. Lorsque Controlplane V2 n'est pas activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'administrateur, ce qui est appelé kubeception.

Exécutez la commande suivante pour déterminer si Controlplane V2 est activé dans le cluster:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Si la sortie est false, procédez comme suit pour mettre à jour le StorageClass par défaut des nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur:

  1. Obtenez l'StorageClass par défaut actuel pour le vsphere-csi-driver groupé, nommé USER_CLUSTER_NAME-csi, et enregistrez-le dans un fichier local appelé storage-class-kubeception.yaml.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml

    Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

  2. Faites une copie de storage-class-kubeception.yaml par précaution, car vous devez modifier le fichier:

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml

  3. Supprimez le StorageClass par défaut du cluster:

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  4. Mettez à jour la configuration dans storage-class-kubeception.yaml comme suit:

    1. Supprimez ou commentez les champs suivants:

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la stratégie de stockage.

    Les exemples de configurations suivants illustrent ces modifications.

    Avant les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  datastoreURL: ds//ds-1

    Après les modifications:

    apiVersion: storage.k8s.io/v1
kind: StorageClass
  name: standard-rwo
Parameters:
  ...
  storagePolicyName: sp-1

  5. Appliquez le StorageClass modifié au cluster d'administrateur:

    kubectl apply -f storage-class-kubeception.yaml \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Migrer un cluster d'administrateur

Assurez-vous que le nom de la stratégie de stockage est également mis à jour dans le cluster d'administration.

  1. Apportez les modifications suivantes dans le fichier de configuration du cluster d'administrateur:

    • Supprimez ou commentez le champ vCenter.datastore.
    • Définissez le champ vCenter.storagePolicyName sur le nom de la règle de stockage.

  2. Mettez à jour le cluster d'administrateur :

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG

    Remplacez les éléments suivants :

    • ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.
    • ADMIN_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'administrateur.

Migration de l'espace de stockage avec SPBM

Après la migration du datastore vers SPBM, vos clusters utilisent désormais SPBM. Toutefois, la migration ne déplace aucune charge de travail de stockage (telle que les disques de données de machine ou les volumes de conteneur) de l'ancien datastore.

Pour déplacer des charges de travail de stockage, consultez la section Migration de stockage avec la gestion basée sur les règles de stockage.