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 superior con kubeception a Controlplane V2.

1.29: Versión preliminar
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 de 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 usuarios nuevos. Cuando Controlplane V2 está habilitado, el plano de control del clúster de usuario se ejecuta en el mismo clúster de usuario.

Los beneficios de Controlplane V2 incluyen lo siguiente:

Aislamiento de fallas. Una falla del clúster de administrador no afecta a los clústeres de usuario.
Separación operativa. Una actualización de un clúster de administrador no genera tiempo de inactividad para los clústeres de usuario.
Separación de la implementación. 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 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 ser de la versión 1.29 o superior. El clúster de administrador y los grupos de nodos pueden ser de una o dos versiones secundarias anteriores 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 debe configurarse 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:

Configura enableControlplaneV2 como verdadero.
De manera opcional, haz que el plano de control para el clúster de usuario de Controlplane V2 tenga alta disponibilidad (HA). Para cambiar de un clúster sin alta disponibilidad a un clúster de alta disponibilidad, cambia masterNode.replicas de 1 a 3.
Agrega las direcciones IP estáticas para los nodos del plano de control del clúster de usuarios 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, completala.
Si el clúster de usuario usa el balanceo de cargas manual, configura el balanceador de cargas a fin de incluir las IP del 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 verificar toda la configuración.
Ejecuta gkectl diagnose cluster y soluciona cualquier problema que encuentre el comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador.
- CLUSTER_NAME es el nombre del clúster de usuario.

Ajusta la configuración manual del balanceador de cargas

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

De manera similar a configurar tu 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 network.controlPlaneIPBlock, configura las asignaciones en tu 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 a Controlplane 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: la ruta del archivo de configuración de tu 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 se 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 anterior.
Conecta los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control, al que se puede acceder con el controlPlaneVIP nuevo.
Concilia 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 del clúster de usuario.
Durante la migración, hay un tiempo de inactividad para el plano de control del clúster de usuario. En particular, el plano de control no está disponible entre el paso 2 y la finalización del paso 6. (El tiempo de inactividad es inferior a 7 minutos según nuestras pruebas, 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 “static”, puedes reciclar algunas de las IP estáticas sin usar si las quitas del archivo de configuración del clúster de administrador y ejecutas 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.