Migración del almacenamiento con la gestión basada en políticas de almacenamiento

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

1.29: disponible de forma general
1.28: vista previa
1.16: no disponible

Puedes migrar los siguientes tipos de almacenamiento:

  • Almacenamiento para componentes del sistema gestionados por Google Distributed Cloud, incluidos los siguientes:

    • Discos de datos (archivos VMDK) utilizados por los nodos del plano de control de los clústeres de administrador y los clústeres de usuario de Controlplane V2

    • Discos de arranque (archivos VMDK) usados por todos los nodos de clúster de administrador y de clúster de usuario

    • Volúmenes de vSphere representados por PVs o PVCs en el clúster de administración y usados por los componentes del plano de control de los clústeres de usuarios de kubeception

  • Almacenamiento para las cargas de trabajo que implementes en los nodos de trabajo del clúster de usuarios con PVs o PVCs aprovisionados por el complemento de volumen de vSphere integrado o el controlador de CSI de vSphere

Requisitos previos de un clúster de administradores

  1. El clúster de administrador debe tener un plano de control de alta disponibilidad. Si tu clúster de administrador tiene un plano de control que no es de alta disponibilidad, migra a alta disponibilidad antes de continuar.

  2. Verifica que el clúster de administrador tenga un plano de control de alta disponibilidad:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
    

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

    En la salida, asegúrate de que aparezcan tres nodos del plano de control. Por ejemplo:

    admin-cp-1   Ready    control-plane,master ...
    admin-cp-2   Ready    control-plane,master ...
    admin-cp-3   Ready    control-plane,master ...
    

Requisitos previos de todos los clústeres (de administrador y de usuarios)

  1. El clúster debe tener inhabilitada la reparación automática de nodos. Si la reparación automática de nodos está habilitada, inhabilítala.

  2. El clúster debe usar gestión basada en políticas de almacenamiento (SPBM). Si tu clúster no usa SPBM, crea una política de almacenamiento antes de continuar.

  3. Verifica que el clúster usa SPBM:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
      -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
    

    (Solo clúster de usuario) Comprueba que los grupos de nodos usen 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}'
    

    Haz los cambios siguientes:

    • CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster (administrador o usuario).

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

    • USER_CLUSTER_NAME: el nombre del clúster de usuarios

    En el resultado, si el campo datastore está vacío y el campo storagePolicyName no está vacío, el clúster está usando SPBM.

  4. El clúster no debe usar el complemento de volumen insertado de vSphere.

    Si tu clúster se actualizó desde una versión anterior de Google Distributed Cloud, es posible que tenga PVs o PVCs aprovisionados por el plugin de volumen en el árbol de vSphere. Este tipo de volumen puede estar en uso por un nodo de plano de control de un clúster de usuarios de kubeception o por una carga de trabajo que hayas creado en un nodo de trabajador.

    Lista de todos los PVCs y sus StorageClasses:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
       -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
    

    Lista todas las StorageClasses y consulta los provisionadores que utilizan:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
    

    En el resultado, si la columna PROVISIONER es kubernetes.io/vsphere-volume, las PVCs creadas con esta StorageClass usan el complemento de volumen interno de vSphere. En el caso de los StatefulSets que usen estos PVs o PVCs, migra a la controladora CSI de vSphere.

Realizar la migración del almacenamiento

Google Distributed Cloud admite dos categorías de migración de almacenamiento:

  • Storage vMotion para máquinas virtuales, que mueve el almacenamiento de las máquinas virtuales, incluidos los volúmenes de CNS de vSphere adjuntos que usan los pods que se ejecutan en un nodo, y los VMDKs que usan estos volúmenes de CNS de máquinas virtuales adjuntos a los nodos

  • Reubicación de volúmenes de CNS, que mueve los volúmenes de CNS de vSphere especificados a un almacén de datos compatible sin realizar el almacenamiento vMotion para las VMs

Realizar Storage vMotion en máquinas virtuales

La migración implica seguir una serie de pasos en su entorno de vSphere y ejecutar comandos en su estación de trabajo de administrador:

  1. En tu entorno de vSphere, añade los almacenes de datos de destino a tu política de almacenamiento.

  2. En tu entorno de vSphere, migra las máquinas virtuales del clúster del antiguo al nuevo almacén de datos. Para obtener instrucciones, consulta Migrar una máquina virtual a un nuevo recurso de cálculo y almacenamiento.

  3. En tu estación de trabajo de administrador, comprueba que las máquinas virtuales se hayan migrado correctamente al nuevo almacén de datos.

    Obtén los objetos Machine del clúster:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

    En el resultado, en status.disks, puedes ver los discos conectados a las máquinas virtuales. Por ejemplo:

    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
    

    Verifica que todos los discos de todas las máquinas del clúster se hayan migrado al almacén de datos de destino.

  4. En tu estación de trabajo de administrador, ejecuta gkectl diagnose para verificar que el clúster está en buen estado.

Llamar a las APIs de reubicación de CNS para mover volúmenes de CNS

Si solo quieres mover los volúmenes de CNS aprovisionados por el controlador de CSI para vSphere, puedes seguir las instrucciones que se indican en Migrar volúmenes de contenedores en vSphere. Esto puede ser más sencillo si solo tienes volúmenes de CNS en el antiguo almacén de datos.

Actualizar tu política de almacenamiento si es necesario

En tu entorno de vSphere, actualiza la política de almacenamiento para excluir los antiguos almacenes de datos. De lo contrario, es posible que se asignen volúmenes nuevos y VMs recreadas a un almacén de datos antiguo.