Migrer un datastore vers SPBM

Ce document explique comment migrer un datastore vSphere vers Storage Policy Based Management (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 Rôles utilisateur et tâches courantes de GKE.

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 du cluster à quatre endroits :

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 règle de stockage à quatre endroits :

L'héritage des champs storagePolicyName est identique à celui des champs datastore.

Avant de commencer

  • Ce processus est 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 règle de stockage que vous allez définir.
  • Seuls les clusters d'administrateur haute disponibilité (HD) sont acceptés. 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

Les étapes à suivre pour la migration dépendent de si vous souhaitez migrer l'intégralité du cluster d'utilisateur ou si vous souhaitez migrer 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 du 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 séparée des pools de nœuds de plan de contrôle et de nœuds de calcul nécessite deux mises à jour du cluster.

Ensemble du cluster

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

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

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

    2. Supprimez ou mettez en commentaire les éléments suivants s'ils sont spécifiés :

      • 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 fourni

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

  1. Obtenez le StorageClass par défaut actuel pour le vsphere-csi-driver fourni, qui est 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 du fichier kubeconfig de votre cluster d'utilisateur.

  2. Par précaution, faites une copie de storage-class.yaml, car vous devez apporter des modifications au 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 mettez en commentaire les champs suivants :

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la règle 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'utilisateur Kubeception uniquement

Pour les clusters d'utilisateur Kubeception, vous devez mettre à jour StorageClass pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur. Les clusters Kubeception ont le champ de configuration enableControlplaneV2 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 le résultat est false, procédez comme suit pour mettre à jour le StorageClass par défaut pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur :

  1. Obtenez le StorageClass par défaut actuel pour le vsphere-csi-driver fourni, qui est 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. Par précaution, faites une copie de storage-class-kubeception.yaml, 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 mettez en commentaire les champs suivants :

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la règle 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'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 règle de stockage.

Désormais, si vous créez un pool de nœuds et que vous laissez nodePools[i].vsphere.datastore et nodePools[i].vsphere.storagePolicyName vides, le nouveau pool de nœuds hérite de la règle 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 d'utilisateur est à la 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 pour le cluster d'administrateur.

    • USER_CLUSTER_NAME : nom du cluster d'utilisateur.

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

    Pour savoir comment obtenir le fichier de configuration, consultez Générer des fichiers de configuration à partir d'un cluster.

    Le fichier de configuration généré comporte le nom datastore défini à chaque niveau : cluster, masterNode (pour les nœuds du plan de contrôle) et nodepools (pour les nœuds de calcul), comme indiqué 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. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

    • Définissez le champ masterNode.vsphere.storagePolicyName avec le nom de la règle de stockage.
    • Supprimez ou mettez en commentaire 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. Effectuez les modifications suivantes dans le fichier de configuration du cluster d'utilisateur :

    • Définissez chaque champ nodePools[i].vsphere.storagePolicyName avec le nom de la règle de stockage.
    • Supprimez ou mettez en commentaire 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

Vous pouvez également mettre à jour la règle de stockage au niveau du cluster.

Pour les clusters d'utilisateur, les champs datastore et storagePolicyName de la section vCenter au niveau du cluster sont des valeurs par défaut utilisées 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 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 ne modifiez pas le paramètre, 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 mettez en commentaire 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 fourni

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

  1. Obtenez le StorageClass par défaut actuel pour le vsphere-csi-driver fourni, qui est 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 du fichier kubeconfig de votre cluster d'utilisateur.

  2. Par précaution, faites une copie de storage-class.yaml, car vous devez apporter des modifications au 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 mettez en commentaire les champs suivants :

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la règle 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'utilisateur Kubeception uniquement

Pour les clusters d'utilisateur Kubeception, vous devez mettre à jour StorageClass pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur. Les clusters Kubeception ont le champ de configuration enableControlplaneV2 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 le résultat est false, procédez comme suit pour mettre à jour le StorageClass par défaut pour les nœuds du plan de contrôle du cluster d'utilisateur dans le cluster d'administrateur :

  1. Obtenez le StorageClass par défaut actuel pour le vsphere-csi-driver fourni, qui est 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. Par précaution, faites une copie de storage-class-kubeception.yaml, 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 mettez en commentaire les champs suivants :

      • parameters.datastoreURL
      • resourceVersion

    2. Ajoutez le champ parameters.storagePolicyName et définissez-le sur le nom de la règle 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'administrateur :

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

Migrer un cluster d'administrateur

Assurez-vous que le nom de la règle de stockage est également mis à jour dans le cluster d'administrateur.

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

    • Supprimez ou mettez en commentaire le champ vCenter.datastore.
    • Définissez le champ vCenter.storagePolicyName avec 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 du 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 (telles que les disques de données de la machine ou les volumes de conteneurs) depuis l'ancien datastore.

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