Los clústeres de Anthos alojados en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Se usó la API de Cloud Translation para traducir esta página.

Migra un clúster de usuario a Controlplane V2

En este documento, se muestra cómo migrar un clúster de usuario de la versión 1.29 o posterior con kubeception a Controlplane V2.

1.29: Vista previa
1.28: No disponible
1.16: No disponible

Acerca de los planos de control del clúster de usuario

Antes de la versión 1.13 de Google Distributed Cloud, el plano de control de un clúster de usuario se ejecutaba en uno o más nodos en un clúster de administrador. Este tipo de plano de control se conoce como kubeception. En la versión 1.13, Controlplane V2 se introdujo para los clústeres de usuario nuevos. Cuando se habilita Controlplane V2, el plano de control del clúster de usuario se ejecuta en el clúster de usuario.

Los beneficios del plano de control V2 incluyen los siguientes:

Aislamiento de fallas Una falla en el clúster de administrador no afecta a los clústeres de usuario.
Separación operativa. Una actualización del clúster de administrador no causa tiempo de inactividad para los clústeres de usuario.
Separación de la Deployment. Puedes colocar los clústeres de administrador y de usuario en diferentes dominios con fallas o sitios geográficos. Por ejemplo, un clúster de usuario en una ubicación perimetral podría estar en un sitio geográfico diferente al del clúster de administrador.

Requisitos

Para migrar un clúster de usuario a Controlplane V2, el clúster de usuario debe cumplir con los siguientes requisitos:

El clúster de usuario debe tener la versión 1.29 o superior. El clúster de administrador y los grupos de nodos pueden ser una o dos versiones secundarias inferiores al clúster de usuario. Si es necesario, actualiza el clúster.
El clúster de usuario debe tener habilitado Dataplane V2. Este campo es inmutable, por lo que, si Dataplane V2 no está habilitado en el clúster, no puedes migrarlo a Controlplane V2.
El clúster de usuario se debe configurar para usar MetalLB o un balanceador de cargas manual. Si el clúster de usuario usa el balanceador de cargas de SeeSaw, puedes migrarlo a MetalLB.
Revisa el documento de planificación de direcciones IP y asegúrate de tener suficientes direcciones IP disponibles para los nodos del plano de control del clúster de usuario. Los nodos del plano de control requieren direcciones IP estáticas, y necesitarás una dirección IP adicional para una IP virtual (VIP) nueva del plano de control.

Actualiza el archivo de configuración del clúster de usuario

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

Establece enableControlplaneV2 como verdadero.
De manera opcional, haz que el plano de control del clúster de usuario de Controlplane V2 tenga alta disponibilidad (HA). Para cambiar de un clúster sin alta disponibilidad a uno con alta disponibilidad, cambia masterNode.replicas de 1 a 3.
Agrega las direcciones IP estáticas de los nodos del plano de control del clúster de usuario a la sección network.controlPlaneIPBlock.ips.
Completa la máscara de red y la puerta de enlace en la sección network.controlPlaneIPBlock.
Si la sección network.hostConfig está vacía, complétala.
Si el clúster de usuario usa el balanceo de cargas manual, configura el balanceador de cargas a fin de que incluya las IP de nodo del plano de control para el tráfico del plano de datos:
- (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
- (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)
Actualiza el campo loadBalancer.vips.controlPlaneVIP con la dirección IP nueva para la VIP del plano de control. Ten en cuenta que debe estar en la misma VLAN que las IP del nodo del plano de control.
Todos los campos anteriores son inmutables, excepto cuando se actualiza el clúster para la migración. Asegúrate de volver a revisar todos los parámetros de configuración.
Ejecuta gkectl diagnose cluster y corrige cualquier problema que encuentre el comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.
- CLUSTER_NAME es el nombre del clúster de usuario.

Ajustar la configuración manual del balanceador de cargas

Si tu clúster de usuario usa el balanceo de cargas manual, realiza el paso de esta sección. De lo contrario, omite esta sección.

Del mismo modo que configuras el balanceador de cargas para un clúster de usuario de CPv2, para cada una de las tres direcciones IP nuevas del nodo del plano de control que especificaste en la sección network.controlPlaneIPBlock, configura las asignaciones en el balanceador de cargas:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Actualiza el clúster

Ejecuta el siguiente comando para migrar el clúster al plano de control V2:

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 del archivo de configuración del clúster de usuario.

El comando realiza lo siguiente:

Crea el plano de control de un clúster nuevo con ControlPlane V2 habilitado.
Detén el plano de control de Kubernetes del clúster de kubeception.
Toma una instantánea de etcd del clúster de kubeception.
Apaga los nodos del plano de control del clúster de usuario del clúster de kubeception. Ten en cuenta que, para la recuperación de fallas, es decir, si recurre al clúster de kubeception, los nodos no se borran hasta que se completa la migración.
Restablece los datos del clúster en el nuevo plano de control con la instantánea de etcd antes mencionada.
Conecta los nodos del grupo de nodos del clúster de kubeception al plano de control nuevo, al que se puede acceder con el controlPlaneVIP nuevo.
Conciliar el clúster de usuario restablecido para cumplir con el estado final del clúster con ControlPlane V2 habilitado

Notas

Durante la migración, no hay tiempo de inactividad para las cargas de trabajo de los clústeres de usuario.
Durante la migración, hay cierto tiempo de inactividad en el plano de control del clúster de usuario. Más concretamente, el plano de control no está disponible entre el paso 2 y la finalización del paso 6. (Según nuestras pruebas, el tiempo de inactividad es inferior a 7 minutos, pero la duración real depende de tu infraestructura).
Al final de la migración, se borran los nodos del plano de control del clúster de usuario de los clústeres de kubeception. Si el clúster de administrador tiene network.ipMode.type configurado como “estático”, puedes reciclar algunas de las direcciones IP estáticas sin usar quitándolas del archivo de configuración del clúster de administrador y ejecutando gkectl update admin. Puedes enumerar los objetos del nodo del clúster de administrador con kubectl get nodes -o wide para ver qué IP están en uso.