Migra un clúster de administrador a HA

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En esta página, se muestra cómo migrar a un clúster de administrador con alta disponibilidad (HA) desde un clúster de administrador sin HA en la versión 1.29.

Nota: Si tus clústeres están en la versión 1.30 o una posterior, te recomendamos que, en su lugar, uses un enfoque optimizado que se describe en Planifica la migración de clústeres a las funciones recomendadas.

1.29: Versión preliminar
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 del plano de control y dos nodos de complementos.
• Un clúster de administrador de alta disponibilidad tiene tres nodos del plano de control y no tiene nodos de complementos, y la disponibilidad mejora significativamente.

Prepárate para la migración

Si la versión de tu clúster de administrador es 1.29.0-1.29.600 o 1.30.0-1.30.100, y si la encriptación de secretos siempre activa se habilitó en el clúster de administrador en la versión 1.14 o anterior, debes rotar la clave de encriptación antes de iniciar la migración. De lo contrario, el nuevo clúster de administrador de HA no podrá desencriptar los secretos.

Para verificar si el clúster podría estar usando una clave de encriptación anterior, haz lo siguiente:

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 encriptación.

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

Rota la clave de encriptación si es necesario

Si los pasos de la sección anterior mostraron que debes rotar la clave de encriptación, 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
   

   Esto crea una clave nueva que coincide con el número de versión nuevo, vuelve a encriptar cada secreto y borra el anterior de forma segura los secretos antiguos. Todos los secretos nuevos posteriores se encriptan con la clave de encriptación nueva.

Advertencia: Si iniciaste la migración sin rotar la clave de encriptación, comunícate con el equipo de asistencia al cliente 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 realiza las siguientes acciones:

   • Muestra un clúster externo (Kind) y se asegura de que el clúster de administrador actual sin HA esté en buen estado.

   • Crea un nuevo plano de control de clúster de administrador con las especificaciones de HA y un nuevo VIP del plano de control.

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

   • Toma una instantánea de etcd del clúster de administrador existente.

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

   • Concilia el clúster de administrador restablecido para cumplir con el estado final del clúster de administrador 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, hay un tiempo de inactividad para el plano de control del clúster de administrador. (El tiempo de inactividad es inferior a 18 minutos según nuestras pruebas, pero la duración real depende de los entornos de infraestructura individuales).

• Los requisitos para los clústeres de administrador de alta disponibilidad siguen vigentes para la migración de no HA a HA. Por ejemplo, los clústeres de administrador de alta disponibilidad no admiten Seesaw, por lo que, si usas el balanceador de cargas de Seesaw para un clúster de administrador que no es de alta disponibilidad, primero debes migrar a MetalLB antes de migrar a un clúster de administrador de alta disponibilidad.

• Una vez que se completa la migración de forma correcta, los recursos restantes, como la VM principal de administrador no HA, se conservan de forma intencional para la recuperación de fallas.

Antes y después de la migración

En la siguiente tabla, se muestran las diferencias principales 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 de complementos	2	0
Réplicas de Pods del plano de control (kube-apiserver, kube-etcd, etcétera)	1	3
Tamaño del disco de datos	100 GB * 1	25 GB * 3
Ruta de acceso a los discos de datos	Es establecido por vCenter.dataDisk en el archivo de configuración del clúster de administrador.	Se genera automáticamente en el directorio: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Balanceador de cargas para la VIP del plano de control	Se establece con loadBalancer.kind en el archivo de configuración del clúster de administrador.	keepalived + haproxy
Asignación de direcciones IP para los nodos del 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 del plano de control del clúster de usuario 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	Habilitado de forma predeterminada	No utilizado

Edita 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 VIP del plano de control para el balanceador de cargas del clúster de administrador

También debes cambiar algunos otros campos en el archivo de configuración del clúster de administrador, como se describe en las siguientes secciones.

Especifica direcciones IP

1. En el archivo de configuración del clúster de administrador, completa 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. Completa la sección hostconfig. Si tu clúster de administrador usa direcciones IP estáticas, esta sección ya está completa. Por ejemplo:

   hostConfig:
    dnsServers:
    – 203.0.113.1
    – 198.51.100.1
    ntpServers:
    – 216.239.35.12
   

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

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Actualiza campos de configuración adicionales

1. Establece adminMaster.replicas en 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Quita el campo vCenter.dataDisk. En el caso de un clúster de administrador de HA, las rutas de acceso 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, configúralo como 0.

Ajusta la configuración manual del balanceador de cargas

Si el clúster de administrador usa el balanceo de cargas manual, completa esta sección. De lo contrario, omite esta sección.

Para cada una de las tres direcciones IP nuevas del nodo del plano de control que especificaste en la sección network.controlPlaneIPBlock, configura la siguiente asignación en tu balanceador de cargas:

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

Esta asignación garantiza que la VIP del plano de control anterior funcione durante la migración.

Actualiza el clúster de administrador

Revisa los cambios de configuración que hiciste porque los campos son inmutables. Cuando hayas confirmado que los cambios son correctos, actualiza el clúster.

1. Inicia la migración:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Reemplaza lo siguiente:

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

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

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

   Cuando se le solicite, ingrese Y para continuar.

3. Cuando se completa la migración, el archivo kubeconfig del clúster de administrador se actualiza automáticamente para usar la nueva VIP del plano de control. La VIP del plano de control anterior sigue funcionando y también se puede usar para acceder al nuevo clúster de administrador de HA.