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:
Clúster de administrador: vCenter.datastore
Clúster de usuario a nivel del clúster, que incluye nodos del plano de control y todos los grupos de nodo trabajador: vCenter.datastore
Nodos del plano de control del clúster de usuario: masterNode.vsphere.datastore
Grupos de nodo trabajador 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 deadminCluster.vCenter.datastore
.Si
userCluster.nodePools[i].vsphere.datastore
está vacío, hereda el valor deuserCluster.vCenter.datastore
.
Del mismo modo, hay cuatro lugares para especificar una política de almacenamiento:
Clúster de administrador vCenter.storagePolicyName
Clúster de usuario a nivel del clúster, que incluye nodos del plano de control y todos los grupos de nodo trabajador: vCenter.storagePolicyName
Nodos del plano de control del clúster de usuario: masterNode.vsphere.storagePolicyName
Grupos de nodo trabajador del clúster de usuario: nodePools[i].vsphere.storagePolicyName
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.
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 marca como comentario lo siguiente si se especifica:
- Campo
vCenter.datastore
- Sección
masterNode.vsphere
nodepools[i].vsphere.datastore
nodepools[i].vsphere.storagePolicyName
- Campo
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
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.
Obtén el
StorageClass
predeterminado actual para elvsphere-csi-driver
incluido, que se llamastandard-rwo
, y guárdalo en un archivo local llamadostorage-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.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
Borra el
StorageClass
predeterminado del clúster:kubectl delete storageclass standard-rwo \ --kubeconfig USER_CLUSTER_KUBECONFIG
Actualiza la configuración en
storage-class.yaml
de la siguiente manera:Borra o comenta los siguientes campos:
parameters.datastoreURL
resourceVersion
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
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:
Obtén el
StorageClass
predeterminado actual para elvsphere-csi-driver
incluido, que se llamaUSER_CLUSTER_NAME-csi
, y guárdalo en un archivo local llamadostorage-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.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
Borra el
StorageClass
predeterminado del clúster:kubectl delete storageclass USER_CLUSTER_NAME-csi \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Actualiza la configuración en
storage-class-kubeception.yaml
de la siguiente manera:Borra o comenta los siguientes campos:
parameters.datastoreURL
resourceVersion
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
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.
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
, buscauser-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) ynodepools
(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:
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
- Configura el campo
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:
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
- Configura cada campo
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:
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
.
- Establece el campo
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
yvCenter.storagePolicyName
del servidor (OnPremUserCluster
).
Actualiza el StorageClass
incluido
Después de actualizar los parámetros de configuración, debes actualizar el StorageClass
incluido.
Obtén el
StorageClass
predeterminado actual para elvsphere-csi-driver
incluido, que se llamastandard-rwo
, y guárdalo en un archivo local llamadostorage-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.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
Borra el
StorageClass
predeterminado del clúster:kubectl delete storageclass standard-rwo \ --kubeconfig USER_CLUSTER_KUBECONFIG
Actualiza la configuración en
storage-class.yaml
de la siguiente manera:Borra o comenta los siguientes campos:
parameters.datastoreURL
resourceVersion
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
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:
Obtén el
StorageClass
predeterminado actual para elvsphere-csi-driver
incluido, que se llamaUSER_CLUSTER_NAME-csi
, y guárdalo en un archivo local llamadostorage-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.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
Borra el
StorageClass
predeterminado del clúster:kubectl delete storageclass USER_CLUSTER_NAME-csi \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Actualiza la configuración en
storage-class-kubeception.yaml
de la siguiente manera:Borra o comenta los siguientes campos:
parameters.datastoreURL
resourceVersion
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
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.
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.
- Quita o comenta el campo
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.