Migrar un almacén de datos a SPBM

En este documento se muestra cómo migrar un almacén de datos de vSphere a la gestión basada en políticas de almacenamiento (SPBM).

Esta página está dirigida a especialistas en almacenamiento que configuran y gestionan el rendimiento, el uso y los gastos del almacenamiento. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas de usuario habituales de GKE.

1.30: GA
1.29: Vista previa
1.16 y versiones anteriores: no disponible

Contexto

Hay cuatro lugares en los que puedes especificar un almacén de datos en los archivos de configuración del clúster:

• Clúster de administración: vCenter.datastore

• Clúster de usuario a nivel de clúster, que incluye nodos del plano de control y todos los grupos de nodos de trabajador: vCenter.datastore

• Nodos del plano de control del clúster de usuarios: masterNode.vsphere.datastore

• Grupos de nodos de trabajo del clúster de usuario: nodePools[i].vsphere.datastore

La herencia de estos campos es la siguiente:

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

Ejemplos:

• Si userCluster.vCenter.datastore está vacío, hereda el valor de adminCluster.vCenter.datastore.

• Si userCluster.nodePools[i].vsphere.datastore está vacío, hereda el valor de userCluster.vCenter.datastore.

Del mismo modo, hay cuatro lugares en los que se puede especificar una política de almacenamiento:

• Clúster de administrador vCenter.storagePolicyName

• Clúster de usuarios a nivel de clúster, que incluye nodos del plano de control y todos los grupos de nodos de trabajador: vCenter.storagePolicyName

• Nodos del plano de control del clúster de usuarios: masterNode.vsphere.storagePolicyName

• Grupos de nodos de trabajador del clúster de usuarios: nodePools[i].vsphere.storagePolicyName

La herencia de los campos storagePolicyName es la misma que la de los campos datastore.

Antes de empezar

• Este proceso es una migración unidireccional. No se admite la migración al estado anterior.
• El almacén de datos debe ser compatible con la nueva política de almacenamiento que vas a definir.
• Solo se admiten clústeres de administrador de alta disponibilidad. Si tu clúster de administración no es de alta disponibilidad, primero debes migrar el clúster de administración a alta disponibilidad.

Migrar un clúster de usuarios

Los pasos que sigas para la migración dependerán de si quieres migrar todo el clúster de usuarios o si quieres migrar los nodos del plano de control y los grupos de nodos de trabajo por separado. Esta opción te permite seleccionar diferentes políticas de almacenamiento para los nodos del plano de control y los grupos de nodos de trabajo.

Para ayudarte a planificar una ventana de mantenimiento, ten en cuenta lo siguiente:

• Para migrar todo el clúster, solo es necesario actualizarlo una vez.

• Para migrar los nodos del plano de control y los grupos de nodos de trabajador por separado, se necesitan dos actualizaciones del clúster.

Todo el clúster

Sigue estos pasos si quieres migrar todo el clúster, incluidos todos los nodos del plano de control y los grupos de nodos de trabajador. La versión de tu clúster de usuarios debe ser 1.30 o posterior.

1. Modifica el archivo de configuración del clúster de usuarios de la siguiente manera:

   1. Define el campo vCenter.storagePolicyName con el nombre de la política de almacenamiento.

   2. Elimina o comenta lo siguiente si se ha especificado:

      • Campo vCenter.datastore
      • masterNode.vsphere sección
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

   vCenter:
     datastore: ds-1
   

   Después de los cambios:

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

2. Actualiza el clúster de usuarios:

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

   Haz los cambios siguientes:

   • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

   • USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios.

Actualizar el StorageClass incluido

Después de actualizar los ajustes de configuración del clúster, debes actualizar el StorageClass incluido.

1. Obtiene el StorageClass predeterminado actual del paquete vsphere-csi-driver, que se llama standard-rwo, y lo guarda en un archivo local llamado storage-class.yaml.

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

   Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

2. Haz una copia de storage-class.yaml como medida de precaución, ya que tienes que hacer cambios en el archivo:

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

3. Elimina el StorageClass predeterminado del clúster:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. Actualiza la configuración en storage-class.yaml de la siguiente manera:

   1. Elimina o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Añade el campo parameters.storagePolicyName y asígnale el nombre de la política de almacenamiento.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

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

   Después de los cambios:

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

5. Aplica el StorageClass modificado al clúster de usuarios:

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

Solo clústeres de usuarios de Kubeception

En el caso de los clústeres de usuarios de Kubeception, debes actualizar el StorageClass de los nodos del plano de control del clúster de usuarios en el clúster de administradores. Los clústeres de Kubeception tienen el campo de configuración enableControlplaneV2 definido como false. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el propio clúster de usuario. Si Controlplane V2 no está habilitado, el plano de control del clúster de usuarios se ejecuta en el clúster de administradores, lo que se conoce como kubeception.

Ejecuta el siguiente comando para determinar si el clúster tiene habilitado Controlplane V2:

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

Si el resultado es false, sigue estos pasos para actualizar el valor predeterminado de StorageClass para los nodos del plano de control del clúster de usuarios en el clúster de administrador:

1. Obtiene el StorageClass predeterminado actual del paquete vsphere-csi-driver, que se llama USER_CLUSTER_NAME-csi, y lo guarda en un archivo local llamado storage-class-kubeception.yaml.

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

   Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.

2. Haz una copia de storage-class-kubeception.yaml como medida de precaución, ya que tienes que hacer cambios en el archivo:

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

3. Elimina el StorageClass predeterminado del clúster:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. Actualiza la configuración en storage-class-kubeception.yaml de la siguiente manera:

   1. Elimina o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Añade el campo parameters.storagePolicyName y asígnale el nombre de la política de almacenamiento.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

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

   Después de los cambios:

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

5. Aplica el StorageClass modificado al clúster de administrador:

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

Después de la migración

Si creas un grupo de nodos después de una migración, el nuevo grupo seguirá las reglas de herencia según el clúster actualizado.

Por ejemplo, supongamos que has migrado vCenter.datastore a una política de almacenamiento.

Ahora, si creas un grupo de nodos y dejas en blanco tanto nodePools[i].vsphere.datastore como nodePools[i].vsphere.storagePolicyName, el nuevo grupo de nodos heredará la política de almacenamiento especificada en vCenter.storagePolicyName.

Nodos por separado

Sigue estos pasos si quieres migrar los nodos del plano de control y los grupos de nodos de trabajo por separado.

1. Solo versión 1.29: obtiene la configuración del clúster actual. Este paso no es necesario si el clúster de usuarios tiene la versión 1.30 o una posterior.

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

   Haz los cambios siguientes:

   • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

   • USER_CLUSTER_NAME: el nombre del clúster de usuarios.

   En ./gen-files, busca user-cluster.yaml.

   Para obtener más información sobre cómo obtener el archivo de configuración, consulta Generar archivos de configuración a partir de un clúster.

   El archivo de configuración generado tiene el nombre datastore definido en cada nivel: clúster, masterNode (para los nodos del plano de control) y nodepools (para los nodos de trabajador), como se muestra en el siguiente ejemplo:

   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
   

Migrar nodos del plano de control

Sigue estos pasos para migrar los nodos del plano de control:

1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:

   • Define el campo masterNode.vsphere.storagePolicyName con el nombre de la política de almacenamiento.
   • Elimina o comenta el campo masterNode.vsphere.datastore.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

   masterNode:
     vsphere:
       datastore: ds-1
   

   Después de los cambios:

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

2. Actualiza el clúster de usuarios:

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

   Haz los cambios siguientes:

   • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.

   • USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios.

   Espera a que se complete el comando de actualización antes de actualizar los grupos de nodos.

Migrar grupos de nodos

Sigue estos pasos para migrar todos los grupos de nodos:

1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:

   • Define el campo nodePools[i].vsphere.storagePolicyName con el nombre de la política de almacenamiento.
   • Elimina o comenta cada campo nodePools[i].vsphere.datastore.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

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

   Después de los cambios:

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

2. Actualiza el clúster de usuarios:

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

Opcionalmente, actualiza la política de almacenamiento a nivel de clúster

En el caso de los clústeres de usuarios, los campos datastore y storagePolicyName de la sección vCenter a nivel de clúster son valores predeterminados que usan las secciones masterNode y nodepools. Después de completar los pasos anteriores, los componentes del clúster no usarán los ajustes vCenter datastore y storagePolicyName a nivel de clúster. Puedes dejar la sección vCenter a nivel de clúster como está o actualizarla para que sea coherente con masterNode y nodepools.

Si no cambia el ajuste, le recomendamos que añada un comentario encima de la sección vCenter a nivel de clúster para indicar que el ajuste se ignora porque se anula con los ajustes de las secciones masterNode y nodepools.

Si lo prefieres, puedes cambiar la sección vCenter del nivel de clúster para que coincida con las secciones masterNode y nodepools, y actualizar el clúster siguiendo estos pasos:

1. Modifica el archivo de configuración del clúster de usuarios de la siguiente manera:

   • Define el campo vCenter.storagePolicyName con el nombre de la política de almacenamiento.
   • Elimina o comenta el campo vCenter.datastore.

2. Actualiza el clúster de usuarios:

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

   Este comando de actualización no hará ningún cambio en el clúster, pero actualizará los campos OnPremUserCluster vCenter.datastore y vCenter.storagePolicyName del lado del servidor.

Actualizar el StorageClass incluido

Después de actualizar los ajustes de configuración, debes actualizar el StorageClass incluido.

1. Obtiene el StorageClass predeterminado actual del paquete vsphere-csi-driver, que se llama standard-rwo, y lo guarda en un archivo local llamado storage-class.yaml.

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

   Sustituye USER_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de usuario.

2. Haz una copia de storage-class.yaml como medida de precaución, ya que tienes que hacer cambios en el archivo:

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

3. Elimina el StorageClass predeterminado del clúster:

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. Actualiza la configuración en storage-class.yaml de la siguiente manera:

   1. Elimina o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Añade el campo parameters.storagePolicyName y asígnale el nombre de la política de almacenamiento.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

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

   Después de los cambios:

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

5. Aplica el StorageClass modificado al clúster de usuarios:

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

Solo clústeres de usuarios de Kubeception

En el caso de los clústeres de usuarios de Kubeception, debes actualizar el StorageClass de los nodos del plano de control del clúster de usuarios en el clúster de administradores. Los clústeres de Kubeception tienen el campo de configuración enableControlplaneV2 definido como false. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el propio clúster de usuario. Si Controlplane V2 no está habilitado, el plano de control del clúster de usuarios se ejecuta en el clúster de administradores, lo que se conoce como kubeception.

Ejecuta el siguiente comando para determinar si el clúster tiene habilitado Controlplane V2:

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

Si el resultado es false, sigue estos pasos para actualizar el valor predeterminado de StorageClass para los nodos del plano de control del clúster de usuarios en el clúster de administrador:

1. Obtiene el StorageClass predeterminado actual del paquete vsphere-csi-driver, que se llama USER_CLUSTER_NAME-csi, y lo guarda en un archivo local llamado storage-class-kubeception.yaml.

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

   Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta del archivo kubeconfig del clúster de administrador.

2. Haz una copia de storage-class-kubeception.yaml como medida de precaución, ya que tienes que hacer cambios en el archivo:

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

3. Elimina el StorageClass predeterminado del clúster:

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. Actualiza la configuración en storage-class-kubeception.yaml de la siguiente manera:

   1. Elimina o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

   2. Añade el campo parameters.storagePolicyName y asígnale el nombre de la política de almacenamiento.

   En los siguientes ejemplos de configuración se muestran estos cambios.

   Antes de los cambios:

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

   Después de los cambios:

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

5. Aplica el StorageClass modificado al clúster de administrador:

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

Migrar un clúster de administradores

Asegúrate de que el clúster de administrador también se actualice con el nombre de la política de almacenamiento.

1. Haz los siguientes cambios en el archivo de configuración del clúster de administrador:

   • Elimina o comenta el campo vCenter.datastore.
   • Define el campo vCenter.storagePolicyName con el nombre de la política de almacenamiento.

2. Actualiza el clúster de administrador:

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

   Haz los cambios siguientes:

   • ADMIN_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.
   • ADMIN_CLUSTER_CONFIG: la ruta al archivo de configuración del clúster de administrador.

Migración del almacenamiento con SPBM

Después de la migración del almacén de datos a SPBM, tus clústeres ya usan SPBM. Sin embargo, la migración no mueve ninguna carga de trabajo de almacenamiento (como discos de datos de máquinas o volúmenes de contenedores) del antiguo almacén de datos.

Para mover cargas de trabajo de almacenamiento, consulta Migración de almacenamiento con gestión basada en políticas de almacenamiento.