Migrar un clúster de administradores a las funciones recomendadas

Información general

En esta página se explica cómo migrar un clúster de administrador de la versión 1.30 o posterior a estas funciones recomendadas:

  • La configuración del balanceador de carga:

    • La configuración del balanceador de carga F5 BIG-IP integrado en ManualLB.

      o

    • El balanceador de carga de Seesaw agrupado a MetalLB.

  • Migrar a un clúster de administradores de alta disponibilidad desde un clúster de administradores que no sea de alta disponibilidad. La disponibilidad mejora significativamente con un clúster de administración de alta disponibilidad, mientras que se usa el mismo número de VMs. Un clúster de administrador sin alta disponibilidad tiene un nodo de plano de control y dos nodos de complementos. Los tres nodos de un clúster de administrador de alta disponibilidad son nodos del plano de control y no tienen nodos complementarios.

Esta página está dirigida a administradores y operadores de TI que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Para obtener más información sobre la planificación de la migración, consulta Planificar la migración de clústeres a funciones recomendadas.

Prácticas recomendadas

Si tienes varios entornos, como de prueba, desarrollo y producción, te recomendamos que primero migres el menos crítico, como el de prueba. Una vez que hayas verificado que la migración se ha completado correctamente, repite este proceso en cada entorno y migra el entorno de producción en último lugar. De esta forma, puedes validar el éxito de cada migración y asegurarte de que tus cargas de trabajo se ejecutan correctamente antes de pasar al siguiente entorno más crítico.

Requisitos

  • El clúster de administrador debe tener la versión 1.30 o una posterior.
  • Todos los clústeres de usuarios gestionados por el clúster de administrador ya deben haberse migrado a las funciones recomendadas, tal como se describe en el artículo Migrar un clúster de usuarios a las funciones recomendadas.

Planificar el tiempo de inactividad durante la migración

Para la migración, planifica un tiempo de inactividad limitado del plano de control. El acceso a la API de Kubernetes no está disponible en los clústeres de administradores que no son de alta disponibilidad durante unos 20 minutos, pero el plano de control de Kubernetes sigue disponible en los clústeres de administradores de alta disponibilidad con F5. Durante las migraciones, el plano de datos de Kubernetes sigue funcionando de forma estable.

De Para Acceso a la API de Kubernetes Cargas de trabajo de los usuarios

Clústeres de administrador de alta disponibilidad con F5 BIG-IP

Clústeres de administrador de alta disponibilidad con ManualLB

No se ve afectado

No se ve afectado

Clústeres de administrador sin alta disponibilidad con MetalLB o ManualLB

Clústeres de administrador de alta disponibilidad con el mismo tipo de balanceador de carga

A quién afecta

No se ve afectado

Clústeres de administrador sin alta disponibilidad con F5 BIG-IP

Clústeres de administrador de alta disponibilidad con ManualLB

A quién afecta

No se ve afectado

Clústeres de administrador sin alta disponibilidad con Seesaw

Clústeres de administrador de alta disponibilidad con MetalLB

A quién afecta

No se ve afectado
  • Afectado: hay una interrupción notable del servicio durante la migración.
  • Sin cambios: no se ha interrumpido el servicio o la interrupción es casi imperceptible.

Preparar la migración

Si tu clúster de administrador no es de alta disponibilidad, prepárate para migrar a un clúster de administrador de alta disponibilidad siguiendo los pasos que se indican en esta sección. Si tu clúster de administrador ya tiene alta disponibilidad, ve a la siguiente sección, Preparar la migración del balanceador de carga.

Asignar direcciones IP adicionales

Cuando migres el clúster de administrador de un estado sin alta disponibilidad a un estado con alta disponibilidad, asigna cuatro direcciones IP adicionales. Asegúrate de que estas direcciones IP estén en la misma VLAN que los nodos del clúster de administrador y que no las use ningún nodo:

  • Asigna una dirección IP a la nueva VIP del plano de control en el campo loadBalancer.vips.controlPlaneVIP del archivo de configuración del clúster de administración.
  • Asigna una nueva dirección IP a cada uno de los tres nodos del plano de control en la sección network.controlPlaneIPBlock del archivo de configuración del clúster de administración.

Actualizar reglas de cortafuegos

Cuando migres el clúster de administrador de un estado sin alta disponibilidad a un estado con alta disponibilidad, actualiza las reglas de cortafuegos en el clúster de administrador. De esta forma, se asegura de que las direcciones IP recién asignadas a los nodos del plano de control puedan acceder a todas las APIs y otros destinos necesarios, tal como se describe en Reglas de cortafuegos para clústeres de administrador.

Preparar la migración del balanceador de carga

Si tu clúster de administrador usa la configuración integrada de F5 BIG-IP o el balanceador de carga Seesaw incluido, sigue los pasos de esta sección para hacer los cambios necesarios en el archivo de configuración del clúster de administrador. De lo contrario, vaya a la siguiente sección, Preparar la migración de una configuración que no es de alta disponibilidad a una de alta disponibilidad.

F5 BIG-IP

Si tu clúster de administrador usa la configuración integrada de F5 BIG-IP, haz los siguientes cambios en el archivo de configuración del clúster de administrador:

  1. Asigna el valor "ManualLB" al campo loadBalancer.kind.
  2. Define o mantén el valor del campo loadBalancer.vips.controlPlaneVIP. Si tu clúster de administrador ya tiene alta disponibilidad, mantén el mismo valor. Si vas a migrar de un clúster de administrador que no es de alta disponibilidad a uno que sí lo es, cambia el valor del campo loadBalancer.vips.controlPlaneVIP por la dirección IP que hayas asignado.
  3. Elimina toda la sección loadBalancer.f5BigIP.

En el siguiente archivo de configuración de clúster de administrador de ejemplo se muestran estos cambios:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Si tu clúster de administrador usa el balanceador de carga Seesaw, haz los siguientes cambios en el archivo de configuración del clúster de administrador:

  1. Asigna el valor "MetalLB" al campo loadBalancer.kind.
  2. Mantén la sección network.hostConfig.
  3. Define o mantén el valor del campo loadBalancer.vips.controlPlaneVIP]5. Si tu clúster de administrador ya tiene alta disponibilidad, puedes mantener el mismo valor. Si va a migrar de un clúster de administrador sin alta disponibilidad a un clúster de administrador con alta disponibilidad, cambie el valor del campo loadBalancer.vips.controlPlaneVIP a la dirección IP que haya asignado.
  4. Elimina la sección loadBalancer.seesaw.

En el siguiente archivo de configuración de clúster de administrador de ejemplo se muestran estos cambios:

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Preparar la migración de una configuración sin alta disponibilidad a una con alta disponibilidad

Si tu clúster de administrador no es de alta disponibilidad, prepárate para migrar a la alta disponibilidad siguiendo los pasos de esta sección.

Si tu clúster de administrador ya tiene alta disponibilidad, ve a la sección siguiente, Migrar el clúster de administrador.

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 cambiar la clave de cifrado siguiendo los pasos que se indican en este problema conocido.

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

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

Haz estos cambios en el archivo de configuración del clúster de administrador:

  1. Rellena el campo network.controlPlaneIPBlock con las tres direcciones IP que has asignado a los nodos del plano de control.
  2. Asegúrate de haber rellenado la sección network.hostConfig. Esta sección contiene información sobre los servidores NTP, los servidores DNS y los dominios de búsqueda de DNS que utilizan las VMs que son los nodos de tu clúster.
  3. Asegúrate de haber sustituido el valor de loadBalancer.vips.controlPlaneVIP por la dirección IP que hayas asignado.
  4. Asigna el valor 3 a adminMaster.replicas.
  5. Quita el campo vCenter.dataDisk. En un clúster de administrador de alta disponibilidad, las rutas de los tres discos de datos que utilizan los nodos del plano de control se generan automáticamente en el directorio raíz anthos del almacén de datos.
  6. Si loadBalancer.kind tiene el valor "ManualLB", asigna el valor 0 a loadBalancer.manualLB.controlPlaneNodePort.

En el siguiente archivo de configuración de clúster de administrador de ejemplo se muestran estos cambios:

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Ajustar las asignaciones del balanceador de carga si es necesario

Si tu clúster de administrador ha estado usando el balanceo de carga manual, completa el paso de esta sección.

Si vas a migrar de un balanceo de carga manual a un balanceo de carga integrado de F5 BIG-IP o a MetalLB, ve a la sección Migrar el clúster de administrador.

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 esta asignación en tu balanceador de carga externo (como F5 BIG-IP o Citrix):

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

De esta forma, el VIP del plano de control antiguo sigue funcionando durante la migración.

Migrar el clúster de administrador

Revisa detenidamente todos los cambios que hayas hecho en el archivo de configuración del clúster de administrador. Todos los ajustes son inmutables, excepto cuando se actualiza el clúster para la migración.

Actualiza el clúster:

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

Replace the following:

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

El comando muestra el progreso de la migración.

Cuando se te pida, introduce Y para continuar.

Durante la migración de un clúster de administración sin alta disponibilidad a uno con alta disponibilidad, la VIP del plano de control anterior sigue funcionando y se puede usar para acceder al nuevo clúster de administración con alta disponibilidad. 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.

Después de la migración

Una vez que se haya completado la actualización, comprueba que el clúster de administrador se esté ejecutando:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Migración de balanceadores de carga

Si has migrado el balanceador de carga, comprueba que sus componentes se ejecutan correctamente.

MetalLB

Si has migrado a MetalLB, comprueba que los componentes de MetalLB se estén ejecutando correctamente con el siguiente comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

El resultado muestra los pods del controlador y el altavoz de MetalLB. Por ejemplo:

metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running

Una vez que se haya completado la migración, elimina las VMs de Seesaw apagadas del clúster de administrador. Puedes encontrar los nombres de las VMs de Seesaw en la sección vmnames del archivo seesaw-for-gke-admin.yaml de tu directorio de configuración.

ManualLB

Después de actualizar los clústeres para que usen el balanceo de carga manual, el tráfico a los clústeres no se interrumpe. Esto se debe a que los recursos de F5 siguen existiendo, como puedes ver si ejecutas el siguiente comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

El resultado esperado es similar al siguiente:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z