Migra un clúster de administrador a la alta disponibilidad

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 este documento, se muestra cómo migrar a un clúster de administrador de alta disponibilidad (HA) desde un clúster de administrador sin alta disponibilidad.

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

Un clúster de administrador de alta disponibilidad tiene tres nodos del plano de control y ningún nodo complementario. Un clúster de administrador sin alta disponibilidad tiene un nodo de plano de control y dos nodos de complemento.

Descripción general del procedimiento

Estos son los pasos principales involucrados en una migración:

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

2. Ejecuta gkectl update admin. Este comando realiza las siguientes acciones:

   • Abre un clúster externo (tipo) y asegúrate de que el clúster de administrador actual que no tiene alta disponibilidad esté en buen estado.

   • Crea un nuevo plano de control del clúster de administrador con la especificación de HA y una VIP nueva 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 antiguos del clúster de administrador en el nuevo plano de control de HA.

   • Conciliar 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 cierto tiempo de inactividad en el plano de control del clúster de administrador. (El tiempo de inactividad es inferior a 18 min, según nuestra prueba, pero la duración real depende de los entornos de infraestructura individuales).

• Los requisitos de los clústeres de administrador con alta disponibilidad se mantienen para la migración que no tiene alta disponibilidad a la alta disponibilidad. Es decir, si usas el balanceador de cargas de Seesaw para un clúster de administrador sin alta disponibilidad, primero debes migrar a MetalLB y, luego, migrar a un clúster de administrador con alta disponibilidad. Esto se debe a que un clúster de administrador con alta disponibilidad no es compatible con Seesaw.

• Después de que la migración se realice de forma correcta, quedarán recursos restantes (p.ej., la VM de la instancia principal de administrador sin alta disponibilidad) que conservamos de forma intencional para la recuperación de fallas. Si es necesario, puedes realizar una limpieza manual.

Antes y después de la migración

Estas son las principales diferencias en el 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	100GB * 1	25GB * 3
Ruta de acceso del disco de datos	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	Establecido por 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ático, dependiendo de 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ático, dependiendo de network.ipMode.type	DHCP o estático, dependiendo de network.ipMode.type
Archivo de punto de control	Habilitado de forma predeterminada	No utilizadas

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 VIP nueva 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.

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 con una VIP nueva. Por ejemplo:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Actualiza los campos de configuración adicionales

1. Configura adminMaster.replicas en 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Quita el campo vCenter.dataDisk. Esto se debe a que, para 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 de forma automática en el directorio raíz anthos en el almacén de datos.

3. Si loadBalancer.manualLB.controlPlaneNodePort tiene un valor distinto de cero, configúralo como 0.

Ajustar la configuración manual del balanceador de cargas

Si tu clúster de administrador usa el balanceo de cargas manual, realiza el paso de 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 esta asignación en tu balanceador de cargas:

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

Esto es para que la VIP del plano de control anterior funcione durante la migración.

Actualiza el clúster de administrador

1. Inicia la migración:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Reemplaza lo siguiente:

   • ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso 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 de forma automática para usar la VIP nueva del plano de control. Mientras tanto, 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.

Realiza una limpieza manual de los recursos restantes si es necesario.

Durante la migración, gkectl no borra la VM del plano de control del clúster de administrador. En su lugar, solo apaga la VM en lugar de borrarla de vSphere. Si deseas borrar la VM del plano de control anterior después de una migración exitosa, debes realizar la eliminación de forma manual.

Para borrar de forma manual la VM del plano de control anterior y los recursos relacionados, sigue estos pasos:

1. Asegúrate de que la VM principal de administrador sin alta disponibilidad gke-admin-master-xxx ya esté apagada.
2. Borra de vSphere la VM principal de administrador sin alta disponibilidad gke-admin-master-xxx.
3. Borra la plantilla de VM principal de administrador sin alta disponibilidad gke-admin-master-xxx-tmpl de vSphere.
4. Borra el disco de datos del administrador sin alta disponibilidad y el archivo del punto de control del administrador.
5. Limpia los archivos temporales guardados en /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Los siguientes son comandos govc si se prefiere usar cli:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml