Se usó la API de Cloud Translation para traducir esta página.

Migra un clúster de administrador a alta disponibilidad

En este documento, se muestra cómo migrar a un clúster de administrador de alta disponibilidad (HA) desde un clúster de administrador que no tiene 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 del plano de control y dos nodos de complementos.

Descripción general del procedimiento

Estos son los pasos principales que implica una migración:

Edita el archivo de configuración del clúster de administrador.
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 plano de control del clúster de administrador nuevo mediante la especificación de HA y una VIP del plano de control nueva.
- 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 anteriores del clúster de administrador en el plano de control de alta disponibilidad nuevo.
- 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 cierto tiempo de inactividad para el plano de control del clúster de administrador. (El tiempo de inactividad es de menos de 18 min según nuestra prueba, pero la duración real depende de entornos individuales de infraestructura).
Los requisitos de los clústeres de administrador de alta disponibilidad se mantienen para la migración que no es de alta disponibilidad a alta disponibilidad. Es decir, si usas el balanceador de cargas de Seesaw para un clúster de administrador que no tiene alta disponibilidad, primero debes migrar a MetalLB y, luego, migrar a un clúster de administrador de alta disponibilidad. Esto se debe a que un clúster de administrador de alta disponibilidad no es compatible con Seesaw.
Una vez que se realice correctamente la migración, quedarán recursos restantes (p.ej., la VM principal sin alta disponibilidad) que conservamos intencionalmente para la recuperación ante fallas. Si es necesario, puedes limpiarlos manualmente.

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 a los discos 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, 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ático, según network.ipMode.type	DHCP o estático, según 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 del plano de control nueva 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

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"

Completa la sección hostconfig. Si el clúster de administrador usa direcciones IP estáticas, esta sección ya está completada. Por ejemplo:
```
hostConfig:
 dnsServers:
 – 203.0.113.1
 – 198.51.100.1
 ntpServers:
 – 216.239.35.12
```
Reemplaza el valor de loadBalancer.vips.controlPlaneVIP por una VIP nueva. Por ejemplo:
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

Actualiza los campos de configuración adicionales

Configura adminMaster.replicas como 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Quita el campo vCenter.dataDisk. Esto se debe a que, en un clúster de administrador de alta disponibilidad, las rutas de acceso 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 del almacén de datos.
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, sigue el paso de esta sección. De lo contrario, omite esta sección.

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

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

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

Actualiza el clúster de administrador

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
El comando muestra el progreso de la migración.

Cuando se le solicite, ingrese Y para continuar.
Cuando se completa la migración, el archivo kubeconfig del clúster de administrador se actualiza de forma automática para usar la nueva VIP del plano de control. Mientras tanto, la VIP del plano de control anterior aún funciona y también se puede usar para acceder al clúster de administrador de alta disponibilidad nuevo.

Limpia manualmente 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 cambio, solo cierra la VM en lugar de borrarla de vSphere. Si deseas borrar la VM del plano de control anterior después de una migración correcta, debes borrarla de forma manual.

Para borrar de forma manual la VM del plano de control anterior y los recursos relacionados, haz lo siguiente:

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

Si se prefiere usar la CLI, estos son los comandos de govc:

  // 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