Migra el almacén de datos a SPBM

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

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

1.30: DG
1.29: Versión preliminar
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:

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 para especificar una política de almacenamiento:

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

Antes de comenzar

  • 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 establecerás.
  • Solo se admiten clústeres de administrador con alta disponibilidad (HA). Si tu clúster de administrador no es de alta disponibilidad, primero debes migrarlo a alta disponibilidad.

Migra un clúster de usuario

Los pasos que uses para la migración dependen de si deseas migrar todo el clúster de usuario o si deseas migrar los nodos del plano de control y los grupos de nodo trabajador por separado. Esta opción te permite seleccionar diferentes políticas de almacenamiento para los nodos del plano de control y los grupos de nodo trabajador.

Para ayudarte a planificar un período de mantenimiento, ten en cuenta lo siguiente:

  • Migrar todo el clúster solo requiere una actualización del clúster.

  • La migración de los nodos del plano de control y los grupos de nodos trabajadores por separado requiere dos actualizaciones del clúster.

Clúster completo

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

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

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

    2. Quita o marca como comentario lo siguiente si se especifica:

      • Campo vCenter.datastore
      • Sección masterNode.vsphere
      • 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 usuario:

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

    Reemplaza lo siguiente:

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

    • USER_CLUSTER_CONFIG: Es la ruta de acceso al archivo de configuración del clúster de usuario.

Actualiza el StorageClass incluido

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

  1. Obtén el StorageClass predeterminado actual para el vsphere-csi-driver incluido, que se llama standard-rwo, y guárdalo en un archivo local llamado storage-class.yaml.

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

    Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

  2. Crea una copia de storage-class.yaml como medida de precaución, ya que debes realizar cambios en el archivo:

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

  3. Borra 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. Borra o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

    2. Agrega el campo parameters.storagePolicyName y configúralo con 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 usuario:

    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 usuario de Kubeception, debes actualizar StorageClass para los nodos del plano de control del clúster de usuario en el clúster de administrador. Los clústeres de Kubeception tienen el campo de configuración enableControlplaneV2 establecido en false. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el mismo clúster de usuario. Cuando Controlplane V2 no está habilitado, el plano de control del clúster de usuario se ejecuta en el clúster de administrador, 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, completa los siguientes pasos para actualizar el StorageClass predeterminado para los nodos del plano de control del clúster de usuario en el clúster de administrador:

  1. Obtén el StorageClass predeterminado actual para el vsphere-csi-driver incluido, que se llama USER_CLUSTER_NAME-csi, y guárdalo 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

    Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del kubeconfig del clúster de administrador.

  2. Crea una copia de storage-class-kubeception.yaml como medida de precaución, ya que deberás realizar cambios en el archivo:

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

  3. Borra 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. Borra o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

    2. Agrega el campo parameters.storagePolicyName y configúralo con 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 archivo 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 nuevo después de una migración, el grupo nuevo seguirá las reglas de herencia según el clúster actualizado.

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

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

Nodos por separado

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

  1. Solo para la versión 1.29: Obtén la configuración actual del clúster. Este paso no es necesario si el clúster de usuario es de la versión 1.30 o superior.

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

    Reemplaza lo siguiente:

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

    • USER_CLUSTER_NAME es el nombre del clúster de usuario.

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

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

    El archivo de configuración generado tiene el nombre datastore establecido en cada nivel: clúster, masterNode (para nodos del plano de control) y nodepools (para nodos trabajadores), 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

Migra los nodos del plano de control

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

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

    • Configura el campo masterNode.vsphere.storagePolicyName con el nombre de la política de almacenamiento.
    • Borra 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 usuario:

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

    Reemplaza lo siguiente:

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

    • USER_CLUSTER_CONFIG: Es la ruta de acceso al archivo de configuración del clúster de usuario.

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

Migra grupos de nodos

Sigue estos pasos para migrar todos los grupos de nodos:

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

    • Configura cada campo nodePools[i].vsphere.storagePolicyName con el nombre de la política de almacenamiento.
    • Borra 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 usuario:

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

De manera opcional, actualiza la política de almacenamiento a nivel del clúster

En los clústeres de usuario, los campos datastore y storagePolicyName de la sección vCenter a nivel del clúster son un valor predeterminado que usan las secciones masterNode y nodepools. Después de realizar los pasos anteriores, los componentes del clúster no usarán la configuración de vCenter datastore y storagePolicyName a nivel del clúster. Puedes dejar la sección vCenter a nivel del clúster como está o actualizarla para que sea coherente con masterNode y nodepools.

Si dejas el parámetro de configuración como está, te recomendamos que agregues un comentario sobre la sección vCenter a nivel del clúster que indique que se ignora el parámetro de configuración porque se anula con los parámetros de configuración de las secciones masterNode y nodepools.

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

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

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

  2. Actualiza el clúster de usuario:

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

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

Actualiza el StorageClass incluido

Después de actualizar los parámetros de configuración, debes actualizar el StorageClass incluido.

  1. Obtén el StorageClass predeterminado actual para el vsphere-csi-driver incluido, que se llama standard-rwo, y guárdalo en un archivo local llamado storage-class.yaml.

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

    Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

  2. Crea una copia de storage-class.yaml como medida de precaución, ya que debes realizar cambios en el archivo:

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

  3. Borra 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. Borra o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

    2. Agrega el campo parameters.storagePolicyName y configúralo con 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 usuario:

    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 usuario de Kubeception, debes actualizar StorageClass para los nodos del plano de control del clúster de usuario en el clúster de administrador. Los clústeres de Kubeception tienen el campo de configuración enableControlplaneV2 establecido en false. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el mismo clúster de usuario. Cuando Controlplane V2 no está habilitado, el plano de control del clúster de usuario se ejecuta en el clúster de administrador, 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, completa los siguientes pasos para actualizar el StorageClass predeterminado para los nodos del plano de control del clúster de usuario en el clúster de administrador:

  1. Obtén el StorageClass predeterminado actual para el vsphere-csi-driver incluido, que se llama USER_CLUSTER_NAME-csi, y guárdalo 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

    Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del kubeconfig del clúster de administrador.

  2. Crea una copia de storage-class-kubeception.yaml como medida de precaución, ya que deberás realizar cambios en el archivo:

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

  3. Borra 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. Borra o comenta los siguientes campos:

      • parameters.datastoreURL
      • resourceVersion

    2. Agrega el campo parameters.storagePolicyName y configúralo con 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 archivo StorageClass modificado al clúster de administrador:

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

Migra un clúster de administrador

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

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

    • Quita o comenta el campo vCenter.datastore.
    • Establece 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

    Reemplaza lo siguiente:

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

Migración de almacenamiento con SPBM

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

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