Migrar un clúster de administradores a alta disponibilidad

Vista previa

Esta función está sujeta a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Las funciones previas a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

En esta página se explica cómo migrar a un clúster de administradores de alta disponibilidad (HA) desde un clúster de administradores que no sea de alta disponibilidad con la versión 1.29.

Nota: Si tus clústeres tienen la versión 1.30 o una posterior, te recomendamos que utilices el enfoque optimizado que se describe en el artículo Planificar la migración de clústeres a las funciones recomendadas.

1.29: Vista previa
1.28: No disponible

Antes y después de la migración, el clúster de administrador tiene tres nodos:

• Un clúster de administrador sin alta disponibilidad tiene un nodo de plano de control y dos nodos de complementos.
• Un clúster de administrador de alta disponibilidad tiene tres nodos de plano de control y ningún nodo de complemento, y la disponibilidad mejora significativamente.

Preparar la migración

Si la versión de tu clúster de administrador es de 1.29.0 a 1.29.600 o de 1.30.0 a 1.30.100, y el cifrado de secretos siempre activo se habilitó en el clúster de administrador en la versión 1.14 o anterior, debes rotar la clave de cifrado antes de iniciar la migración. De lo contrario, el nuevo clúster de administrador de alta disponibilidad no podrá descifrar los secretos.

Para comprobar si el clúster podría estar usando una clave de cifrado antigua, sigue estos pasos:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Si el resultado muestra una clave vacía, como en el siguiente ejemplo, debes rotar la clave de cifrado.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Rotar la clave de cifrado si es necesario

Si los pasos de la sección anterior han mostrado que debes rotar la clave de cifrado, sigue estos pasos:

1. Incrementa el keyVersion en el archivo de configuración del clúster de administrador.

2. Actualiza el clúster de administrador:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   De esta forma, se crea una clave que coincide con el nuevo número de versión, se vuelve a cifrar cada secreto y se eliminan de forma segura los secretos antiguos. Todos los secretos nuevos posteriores se cifran con la nueva clave de cifrado.

Advertencia: Si has iniciado la migración sin rotar la clave de cifrado, ponte en contacto con el equipo de Asistencia de Google.

Descripción general del procedimiento

La migración implica los siguientes pasos principales:

1. Edita el archivo de configuración del clúster de administrador.

2. Ejecuta gkectl update admin. Este comando hace lo siguiente:

   • Abre un clúster externo (Kind) y comprueba que el clúster de administrador actual sin alta disponibilidad esté en buen estado.

   • Crea un nuevo plano de control de clúster de administrador con la especificación de alta disponibilidad y un nuevo VIP del plano de control.

   • Desactiva el plano de control del clúster de administrador.

   • Crea una instantánea de etcd del clúster de administración.

   • Restaura los datos del antiguo clúster de administrador en el nuevo plano de control de alta disponibilidad.

   • Reconcilia el clúster de administración restaurado para que coincida con el estado final del clúster de administración de alta disponibilidad.

Notas

• Durante la migración, no hay tiempo de inactividad para la carga de trabajo del clúster de usuario.

• Durante la migración, el plano de control del clúster de administrador estará inactivo durante un tiempo. Según nuestras pruebas, el tiempo de inactividad es inferior a 18 minutos, pero la duración real depende de los entornos de infraestructura individuales.

• Los requisitos de los clústeres de administrador de alta disponibilidad siguen siendo válidos para la migración de clústeres de administrador que no son de alta disponibilidad a clústeres de administrador de alta disponibilidad. Por ejemplo, los clústeres de administradores de alta disponibilidad no admiten Seesaw, por lo que, si utilizas el balanceador de carga de Seesaw en un clúster de administradores que no sea de alta disponibilidad, primero debes migrar a MetalLB antes de migrar a un clúster de administradores de alta disponibilidad.

• Una vez que la migración se haya completado correctamente, los recursos restantes, como la VM maestra de administrador sin alta disponibilidad, se conservarán intencionadamente para la recuperación en caso de fallo.

Antes y después de la migración

En la siguiente tabla se muestran las principales diferencias del clúster antes y después de la migración:

	Antes de la migración	Después de la migración
Réplicas de nodos del plano de control	1	3
Nodos complementarios	2	0
Réplicas de pods del plano de control (kube-apiserver, kube-etcd, etc.)	1	3
Tamaño del disco de datos	100 GB * 1	25 GB * 3
Ruta de los discos de datos	Definido por vCenter.dataDisk en el archivo de configuración del clúster de administrador	Generado automáticamente en el directorio: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Balanceador de carga de la IP virtual del plano de control	Definido por loadBalancer.kind en el archivo de configuración del clúster de administrador	keepalived + haproxy
Asignación de direcciones IP para los nodos de plano de control del clúster de administrador	DHCP o estática, según network.ipMode.type	3 direcciones IP estáticas
Asignación de direcciones IP para los nodos de plano de control de clústeres de usuarios de kubeception	DHCP o estática, según network.ipMode.type	DHCP o estática, según network.ipMode.type
Archivo de punto de control	Habilitada de forma predeterminada	No utilizado

Editar el archivo de configuración del clúster de administrador

Debes especificar cuatro direcciones IP adicionales:

• Tres direcciones IP para los nodos del plano de control del clúster de administrador
• Una nueva IP virtual de plano de control para el balanceador de carga del clúster de administrador

También debe cambiar algunos campos más en el archivo de configuración del clúster de administrador, tal como se describe en las secciones siguientes.

Especificar direcciones IP

1. En el archivo de configuración del clúster de administrador, rellena la sección network.controlPlaneIPBlock. Por ejemplo:

   controlPlaneIPBlock:
     netmask: "255.255.255.0"
     gateway: "172.16.20.1"
     ips:
     - ip: "172.16.20.50"
       hostname: "admin-cp-node-1"
     - ip: "172.16.20.51"
       hostname: "admin-cp-node-2"
     - ip: "172.16.20.52"
       hostname: "admin-cp-node-3"
   

2. Rellena la sección hostconfig. Si tu clúster de administrador usa direcciones IP estáticas, esta sección ya estará rellena. Por ejemplo:

   hostConfig:
     dnsServers:
     - 203.0.113.1
     - 198.51.100.1
     ntpServers:
     - 216.239.35.12
   

3. Sustituye el valor de loadBalancer.vips.controlPlaneVIP por una VIP nueva. Por ejemplo:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Actualizar campos de configuración adicionales

1. Asigna el valor 3 a adminMaster.replicas:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Elimina el campo vCenter.dataDisk. En un clúster de administrador de alta disponibilidad, las rutas de los tres discos de datos que usan los nodos del plano de control se generan automáticamente en el directorio raíz anthos del almacén de datos.

3. Si loadBalancer.manualLB.controlPlaneNodePort tiene un valor distinto de cero, defínelo como 0.

Ajustar la configuración manual del balanceador de carga

Si tu clúster de administrador usa el balanceo de carga manual, completa esta sección. De lo contrario, sáltate esta sección.

Para cada una de las tres direcciones IP de los nodos del plano de control que has especificado en la sección network.controlPlaneIPBlock, configura la siguiente asignación en tu balanceador de carga:

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Esta asignación asegura que el VIP del plano de control antiguo funcione durante la migración.

Actualizar el clúster de administrador

Revisa los cambios de configuración que hayas hecho, ya que los campos son inmutables. Cuando haya confirmado que los cambios son correctos, actualice el clúster.

1. Inicia la migración:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Haz los cambios siguientes:

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

   • ADMIN_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de administrador

2. El comando muestra el progreso de la migración.

   Cuando se te pida, introduce Y para continuar.

3. Cuando se complete la migración, el archivo kubeconfig del clúster de administrador se actualizará automáticamente para usar el nuevo VIP del plano de control. El VIP del plano de control anterior sigue funcionando y también se puede usar para acceder al nuevo clúster de administración de alta disponibilidad.