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 de un clúster de administrador. Este tipo de plano de control se conoce como kubeception. En la versión 1.13, se introdujo la versión 2 del plano de control para los clústeres de usuario nuevos. Cuando el plano de control V2 está habilitado, 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 lo siguiente:

  • Aislamiento de errores Una falla del clúster de administrador no afecta a los clústeres de usuario.

  • Separación operativa. La actualización de un clúster de administrador no genera 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, este 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 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 nueva IP virtual (VIP) 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:

  1. Establece enableControlplaneV2 como verdadero.

  2. De forma opcional, puedes hacer que el plano de control del clúster de usuario del plano de control 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.

  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. Quita las direcciones IP de los nodos del plano de control del clúster de usuario de kubeception del archivo de bloque de IP del clúster de administrador.

  4. Completa la máscara de red y la puerta de enlace en la sección network.controlPlaneIPBlock.

  5. Si la sección network.hostConfig está vacía, complétala.

  6. 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)

  7. Actualiza el campo loadBalancer.vips.controlPlaneVIP con la dirección IP nueva para la VIP del plano de control.

  8. 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.

  9. 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.

Ajusta la configuración manual del balanceador de cargas

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

De manera similar a como configurar el balanceador de cargas para un clúster de usuario de CPv2, para cada una de las tres direcciones IP de nodo del plano de control nuevas 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 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: Es la ruta de acceso del archivo de configuración del clúster de usuario.