Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Migra un clúster de usuario a las funciones recomendadas

Descripción general

En esta página, se muestra cómo migrar clústeres de usuario de la versión 1.30 o superior a las siguientes funciones recomendadas:

Migra a Dataplane V2 como la interfaz de red de contenedor (CNI).
Migra clústeres de usuario con kubeception a Controlplane V2.
Migra la configuración del balanceador de cargas:
- Desde la configuración del balanceador de cargas F5 BIG-IP integrado a ManualLB
  
  o
- Del balanceador de cargas de Seesaw empaquetado a MetalLB.

Esta página está destinada a administradores de TI y operadores que administran el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE Enterprise.

Prácticas recomendadas

Te recomendamos que primero migres el entorno menos crítico, como el de prueba. Después de verificar que la migración se realizó correctamente, repite este proceso para cada entorno y, por último, migra tu entorno de producción. Esto te permite validar el éxito de cada migración y asegurarte de que tus cargas de trabajo se ejecuten correctamente antes de pasar al siguiente entorno más crítico.

Te recomendamos que crees un clúster de usuario nuevo con ControlPlane V2 habilitado para obtener información sobre las diferencias arquitectónicas con los clústeres de kubeception. El clúster nuevo no afecta tus cargas de trabajo. Sin embargo, en el peor de los casos, si la migración falla, tienes un clúster listo para tus cargas de trabajo.

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

Requisitos

Para esta migración, haz lo siguiente:

El clúster de usuario debe estar en la versión 1.30 o una posterior.
Todos los grupos de nodos deben tener la misma versión que el clúster de usuario.
Si el clúster usa el balanceador de cargas de Seesaw, asegúrate de no depender de Seesaw para la preservación de la IP del cliente, como se describe en la siguiente sección.

Conservación de la IP del cliente de Seesaw

Para verificar el estado externalTrafficPolicy, ejecuta el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Si tienes este problema, comunícate con el equipo de Atención al cliente de Google.

Calcula el compromiso de tiempo y planifica un período de mantenimiento

Cuando actualizas el clúster, de forma predeterminada, todos los grupos de nodos se actualizan en paralelo. Sin embargo, dentro de cada grupo de nodos, los nodos se actualizan de manera secuencial. Por lo tanto, el tiempo de actualización total depende de la cantidad de nodos en el grupo de nodos más grande. Para calcular una estimación aproximada de cada actualización, haz lo siguiente:

Si migras de Seesaw a MetalLB, espera 15 minutos para que la actualización elija un grupo de nodos para el balanceador de cargas de MetalLB. En esta actualización, solo se actualiza el grupo de nodos seleccionado.
Para cualquier otra actualización en el proceso de migración, multiplica 15 minutos por la cantidad de nodos en el grupo de nodos.

Para estimar el compromiso de tiempo, cuenta la cantidad de veces que necesitas actualizar el clúster. En los siguientes pasos de alto nivel, se muestra cuándo debes ejecutar gkectl update cluster para actualizar el clúster:

Si el clúster de usuario usa encriptación de secretos siempre activa, inhabilita la función y ejecuta gkectl update cluster.
Si el clúster de usuario tiene enableDataplaneV2 sin definir o configurado como false, realiza los cambios de configuración y, luego, ejecuta gkectl update cluster para migrar a Dataplane V2.
Prepárate para la migración del balanceador de cargas y el plano de control:
1. Si el clúster de administrador tiene habilitada la reparación automática, inhabilita esta opción. Luego, ejecuta gkectl update admin. Esta actualización finaliza rápidamente porque no vuelve a crear los nodos del clúster de administración.
2. Si el clúster de usuario usa Seesaw, elige un grupo de nodos para que use el balanceador de cargas de MetalLB y, luego, ejecuta gkectl update cluster. Esta actualización solo actualiza los nodos del grupo de nodos seleccionado.
Realiza todos los cambios de configuración necesarios para actualizar tu balanceador de cargas y migrar a Controlplane V2. Luego, ejecuta gkectl update cluster
Después de la migración, si inhabilitaste la encriptación de secretos siempre activa, vuelve a habilitar la función y ejecuta gkectl update cluster.

El tiempo total de la migración depende de la cantidad de veces que debes ejecutar gkectl cluster update, que depende de tu configuración. Por ejemplo, supongamos que migras a Dataplane V2, ControlPlane V2 y MetalLB. Supongamos también que hay 10 nodos en el grupo de nodos más grande y 3 nodos en el grupo de nodos que usará MetalLB. Para calcular una estimación del tiempo de migración, agrega lo siguiente:

150 minutos para la migración a Dataplane V2 porque 15 minutos × 10 nodos en el grupo más grande = 150 minutos.
45 minutos para el grupo de nodos que usa MetalLB porque 15 minutos × 3 nodos en ese grupo de nodos = 45 minutos.
150 minutos para la actualización de Controlplane V2 y MetalLB porque 15 minutos * 10 nodos en el grupo más grande = 150 minutos.

El tiempo total de la migración es de aproximadamente 345 minutos, lo que equivale a 5 horas y 45 minutos.

Si es necesario, puedes realizar la migración en etapas. Con el ejemplo anterior, puedes realizar la migración a Dataplane V2 en un período de mantenimiento y hacer el resto de la migración en uno o dos períodos de mantenimiento.

Planifica el tiempo de inactividad durante la migración

Cuando planifiques tu migración, ten en cuenta estos tipos de tiempo de inactividad:

Tiempo de inactividad del plano de control: El acceso al servidor de la API de Kubernetes se ve afectado durante la migración. Si migras a Controlplane V2, hay un tiempo de inactividad del plano de control para los clústeres de usuario de kubeception a medida que se migra loadBalancer.vips.controlPlaneVIP. Por lo general, el tiempo de inactividad es inferior a 10 minutos, pero la duración depende de tu infraestructura.
Tiempo de inactividad de la carga de trabajo: Las direcciones IP virtuales (VIP) que usan los servicios de tipo LoadBalancer no están disponibles. Esto solo ocurre durante una migración de Seesaw a MetalLB. El proceso de migración de MetalLB detendrá las conexiones de red a todos los VIP del clúster de usuarios para los servicios de Kubernetes de tipo LoadBalancer durante aproximadamente dos a diez minutos. Una vez completada la migración, las conexiones volverán a funcionar.

En la siguiente tabla, se describe el impacto de la migración:

Desde	Para	Acceso a la API de Kubernetes	Cargas de trabajo de usuarios
Clúster de Kubeception que usa Calico, que tiene `enableDataplaneV2` sin definir o establecido en `false`	Clúster de Kubeception con Dataplane V2	No afectado	No afectado
Clúster de Kubeception, que tiene `enableControlplaneV2` desordenado o configurado como `false` con `MetalLB` o `ManualLB`	Clúster de ControlPlane V2 con el mismo tipo de balanceador de cargas	Afectado	No afectado
Clúster de Kubeception con `loadBalancer.kind: "F5BigIP"`	Clúster de ControlPlane V2 con configuración del balanceador de cargas manual	Afectado	No afectado
Clúster de Kubeception con `loadBalancer.kind: "Seesaw"`	Clúster de ControlPlane V2 con MetalLB	Afectado	Afectado

Afectado: Hay una interrupción notable del servicio durante la migración.
No afectado: No hay interrupción del servicio o es casi imperceptible.

Prepárate para la migración

Para garantizar que la migración se complete correctamente, sigue los pasos que se indican en las siguientes secciones.

Asigna direcciones IP nuevas

Si migras a Controlplane V2, asigna direcciones IP estáticas nuevas en la misma VLAN que los nodos de trabajo (los nodos en los grupos de nodos).

Necesitas una dirección IP para el loadBalancer.vips.controlPlaneVIP.
Asigna una dirección IP para cada nodo del plano de control. La cantidad de direcciones IP que debes asignar depende de si el clúster de usuario tendrá alta disponibilidad (HA) o no.
- Sin HA: Una dirección IP
- HA: Tres direcciones IP

Actualiza reglas de firewall

Si migras a Controlplane V2, actualiza las reglas de firewall en tus clústeres de usuario. Asegúrate de que las direcciones IP recién asignadas para los nodos del plano de control en el clúster de usuario puedan llegar a todas las APIs y otros destinos requeridos, como se describe en Nodos del clúster de usuario de las reglas de firewall.

Verifica las versiones del clúster y del grupo de nodos

Verifica que todos los grupos de nodos usen la misma versión que el clúster de usuario, que debe ser la versión 1.30 o una posterior. De lo contrario, actualiza los grupos de nodos a la gkeOnPremVersion en el archivo de configuración del clúster de usuario antes de continuar con la migración. Para verificar las versiones, ejecuta el siguiente comando:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Verifica el estado del clúster

Verifica el estado del clúster y corrige cualquier problema que informe el comando gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name <var>USER_CLUSTER_NAME</var>

Reemplaza lo siguiente:

ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
USER_CLUSTER_NAME es el nombre del clúster de usuario.

Inhabilita la reparación automática en el clúster de administrador

Si migras el clúster de usuario para usar Controlplane V2 y la reparación automática está habilitada en el clúster de administrador, inhabilita la reparación automática. Verifica el campo autoRepair.enabled del archivo de configuración del clúster de administrador. Si ese campo no está establecido o se establece en true, sigue estos pasos:

En el archivo de configuración del clúster de administrador, configura autoRepair.enabled como false . Por ejemplo:
```
autoRepair:
  enabled: true
```

Actualiza el clúster de administrador:

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

Reemplaza lo siguiente:

ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del clúster de administrador.
ADMIN_CLUSTER_CONFIG: es la ruta al archivo de configuración del clúster de administrador.

Una vez que se complete la migración, asegúrate de volver a habilitar la reparación automática en el clúster de administrador.

Verifica si hay un problema con la encriptación de secretos siempre activa

Si migras el clúster de usuario para usar Controlplane V2, verifica si hay un problema con la encriptación de secretos siempre activa.

Si la encriptación de secretos siempre activa se habilitó en el clúster de usuarios, debes seguir los pasos que se indican en Inhabilita la encriptación de secretos siempre activa y desencriptar secretos antes de iniciar la migración. De lo contrario, el nuevo clúster de ControlPlane V2 no podrá desencriptar los secretos.

Antes de iniciar la migración, ejecuta el siguiente comando para ver si la encriptación de secretos siempre activa se habilitó en algún momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Si el resultado del comando anterior está vacío, significa que nunca se habilitó la encriptación de secretos siempre activa. Puedes iniciar la migración.

Si el resultado del comando anterior no está vacío, significa que la encriptación de secretos siempre activa se habilitó anteriormente. Antes de migrar, debes realizar los pasos que se indican en la siguiente sección para asegurarte de que el nuevo clúster de Controlplane V2 pueda desencriptar los secretos.

En el siguiente ejemplo, se muestra un resultado no vacío:

{"generatedKeyVersions":{"keyVersions":[1]}}

Inhabilita la encriptación de secretos siempre activa y desencripta los secretos si es necesario

Para inhabilitar la encriptación de secretos siempre activa y desencriptar secretos, sigue estos pasos:

En el archivo de configuración del clúster de usuario, para inhabilitar la encriptación de secretos siempre activa, agrega un campo disabled: true a la sección secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Actualiza el clúster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Reemplaza lo siguiente:
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- USER_CLUSTER_CONFIG: la ruta del archivo de configuración de tu clúster de usuario

Realiza una actualización progresiva en un DaemonSet específico de la siguiente manera:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Obtén los manifiestos de todos los secretos del clúster de usuarios en formato YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Para que todos los secretos se almacenen en etcd como texto simple, vuelve a aplicar todos los secretos en el clúster de usuario:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ahora puedes comenzar la migración a Controlplane V2. Una vez que se complete la migración, puedes volver a habilitar la encriptación de secretos siempre activa en el clúster.

Habilita un grupo de nodos para que lo use MetalLB

Si migras del balanceador de cargas de Seesaw integrado a MetalLB, realiza los pasos de esta sección. El clúster usa Seesaw si loadBalancer.kind: Seesaw está en el archivo de configuración del clúster de usuario. Si migras la configuración integrada de F5 BIG-IP, ve a la siguiente sección, Migra a Dataplane V2.

Elige un grupo de nodos y habilítalo para usarlo con MetalLB. La migración implementa MetalLB en los nodos de ese grupo de nodos.

En la sección nodePools del archivo de configuración del clúster de usuario, elige un grupo de nodos o agrega uno nuevo, y establece enableLoadBalancer en true. Por ejemplo:
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Actualiza el clúster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Para obtener más información sobre MetalLB, consulta Balanceo de cargas en paquetes con MetalLB.

Migra a Dataplane V2

Antes de migrar, ejecuta el siguiente comando para verificar si DataPlane V2 está habilitado en el clúster:

kubectl —kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Si Dataplane V2 ya está habilitado, ve a la siguiente sección, Prepárate para la migración del balanceador de cargas.

Para migrar a Dataplane V2, sigue estos pasos. Si tienes dudas sobre la eliminación temporal de la especificación NetworkPolicy, comunícate con el equipo de Atención al cliente de Google.

Si tu clúster usa un NetworkPolicy, quita temporalmente su especificación del clúster de la siguiente manera:

Verifica si hay algún NetworkPolicy que no sea del sistema aplicado a tu clúster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Si el resultado del paso anterior no estaba vacío, guarda cada especificación de NetworkPolicy en un archivo:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Reemplaza lo siguiente:
- NETWORK_POLICY_NAME: Es el nombre del NetworkPolicy que guardas.
- NETWORK_POLICY_NAMESPACE: Es el espacio de nombres de NetworkPolicy.

Borra la NetworkPolicy con el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Sigue estos pasos para migrar a Dataplane V2:

Configura enableDataplaneV2 como true en el archivo de configuración del clúster de usuario.

Para habilitar Dataplane V2, actualiza tu clúster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG

Si quitaste alguna especificación NetworkPolicy que no sea del sistema en un paso anterior, después de que se complete la actualización, vuelve a aplicarla con este comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Después de completar esos pasos, se habilitará Dataplane V2. A continuación, prepárate para migrar tu clúster al balanceador de cargas recomendado y Controlplane V2.

Prepárate para la migración del balanceador de cargas

Si tus clústeres de usuario usan el balanceador de cargas Seesaw o el F5 BIG-IP integrado, sigue los pasos de esta sección para realizar los cambios necesarios en el archivo de configuración del clúster de usuario. De lo contrario, pasa a la siguiente sección, Prepárate para la migración a Controlplane V2.

BIG-IP de F5

Si tus clústeres usan la configuración de BIG-IP F5 integrado, realiza los siguientes cambios en el archivo de configuración del clúster de usuario para prepararte para la migración a ManualLB:

Cambia loadBalancer.kind a "ManualLB".
Mantén el mismo valor para el campo loadBalancer.vips.ingressVIP.
Si migras a Controlplane V2, cambia el valor del campo loadBalancer.vips.controlPlaneVIP a la dirección IP que asignaste. De lo contrario, puedes conservar el mismo valor.
Borra toda la sección loadBalancer.f5BigIP.

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Si tus clústeres de usuario usan el balanceador de cargas de Seesaw, realiza los pasos de las siguientes secciones para prepararte para la migración a MetalLB.

Especifica grupos de direcciones

El controlador MetalLB realiza la administración de direcciones IP para los objetos Service. Por lo tanto, cuando un desarrollador de aplicaciones crea un Service de tipo LoadBalancer en un clúster de usuario, no tiene que especificar de forma manual una dirección IP para ese objeto. En su lugar, el controlador de MetalLB elige una dirección IP de un grupo de direcciones que especificas.

Considera la cantidad máxima de servicios LoadBalancer que pueden estar activos en tu clúster de usuario. Luego, en la sección loadBalancer.metalLB.addressPools del archivo de configuración de tu clúster de usuario, especifica suficientes direcciones IP para alojar esos objetos Service.

Cuando especifiques grupos de direcciones, incluye la VIP de entrada de tu clúster de usuario en uno de los grupos. Esto se debe a que un servicio de tipo LoadBalancer expone el proxy de entrada.

Las direcciones deben estar en formato CIDR o en rango. Si deseas especificar una dirección individual, usa un CIDR /32, como 198.51.100.10/32.

Actualiza el archivo de configuración del clúster

Actualiza el archivo de configuración del clúster para quitar la sección Seesaw y agregar una sección MetalLB, como se indica a continuación:

Establece loadBalancer.kind en "MetalLB".
Puedes mantener el mismo valor para el campo loadBalancer.vips.ingressVIP.
Agrega la VIP de entrada a un grupo de direcciones de MetalLB.
Si migras a Controlplane V2, cambia el valor del campo loadBalancer.vips.controlPlaneVIP a la dirección IP que asignaste. De lo contrario, puedes conservar el mismo valor.
Quita la sección loadBalancer.seesaw.
Agrega una sección loadBalancer.metalLB .

La siguiente porción de un archivo de configuración de clúster de usuario muestra estos cambios y la configuración de MetalLB de lo siguiente:

Un grupo de direcciones para que el controlador de MetalLB elija y asigne a los servicios de tipo LoadBalancer. La VIP de entrada, que en este ejemplo es 198.51.100.10, se encuentra en este grupo en notación de formato de rango, 198.51.100.10/32.
Es la VIP designada para el servidor de la API de Kubernetes del clúster de usuario.
La VIP de entrada que configuraste para el proxy de entrada.
Un grupo de nodos habilitado para usar MetalLB. La migración implementa MetalLB en los nodos de este grupo de nodos.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
  addressPools:
    - name: "address-pool-1"
      enableLoadBalancer: true
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Prepárate para la migración a Controlplane V2

Si el clúster no tiene habilitado Controlplane V2, haz lo siguiente:

Actualiza el archivo de configuración del clúster de usuario
Si el clúster usa el balanceo de cargas manual (loadBalancer.kind: "ManualLB"), también actualiza la configuración en tu balanceador de cargas.

Estos pasos se describen en las siguientes secciones.

Si el clúster ya tiene habilitado Controlplane V2, ve a la sección Migra el clúster de usuario.

Actualiza el archivo de configuración del clúster de usuario

Realiza los siguientes cambios en el archivo de configuración del clúster de usuario existente:

Configura enableControlplaneV2 como verdadero.
De manera opcional, haz que el plano de control para el clúster de usuario de Controlplane V2 tenga alta disponibilidad (HA). Para cambiar de un clúster sin alta disponibilidad a un clúster de alta disponibilidad, cambia masterNode.replicas de 1 a 3.
Agrega las direcciones IP estáticas para los nodos del plano de control del clúster de usuarios a la sección network.controlPlaneIPBlock.ips. Las direcciones IP de los nodos del plano de control deben estar en la misma VLAN que los nodos trabajadores.
Completa netmask y gateway en la sección network.controlPlaneIPBlock.
Si la sección network.hostConfig está vacía, completala.
Asegúrate de que el campo loadBalancer.vips.controlPlaneVIP tenga la dirección IP nueva para la VIP del plano de control. La dirección IP debe estar en la misma VLAN que las IP del nodo del plano de control.
Si el clúster de usuarios usa el balanceo de cargas manual, establece loadBalancer.manualLB.controlPlaneNodePort y loadBalancer.manualLB.konnectivityServerNodePort en 0. No son obligatorios cuando se habilita Controlplane V2, pero deben tener 0 como valor.
Si el clúster de usuario usa el balanceo de cargas manual, configura el balanceador de cargas como se describe en la siguiente sección.

Si es necesario, ajusta las asignaciones en el balanceador de cargas

Si el clúster de usuario ya usa el balanceo de cargas manual, debes configurar algunas asignaciones en el balanceador de cargas. Si migras de la configuración de F5 BIG-IP integrado al balanceo de cargas manual, no es necesario que realices ningún cambio de configuración en el balanceador de cargas y puedes avanzar a la siguiente sección, Migra el clúster de usuarios.

Para cada dirección IP que especificaste en la sección network.controlPlaneIPBlock, configura las siguientes asignaciones en tu balanceador de cargas para los nodos del plano de control:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

Estas asignaciones son necesarias para todos los nodos del clúster de usuarios, tanto los del plano de control como los trabajadores. Debido a que los NodePorts se configuran en el clúster, Kubernetes abre los NodePorts en todos los nodos del clúster para que cualquier nodo del clúster pueda controlar el tráfico del plano de datos.

Después de configurar las asignaciones, el balanceador de cargas escucha el tráfico en la dirección IP que configuraste para el VIP de entrada del clúster de usuario en los puertos HTTP y HTTPS estándar. El balanceador de cargas enruta las solicitudes a cualquier nodo del clúster. Después de que una solicitud se enruta a uno de los nodos del clúster, la red interna de Kubernetes la enruta al Pod de destino.

Migra el clúster de usuario

Primero, revisa cuidadosamente todos los cambios que realizaste en el archivo de configuración del clúster de usuario. Toda la configuración del balanceador de cargas y Controlplane V2 es inmutable, excepto cuando actualizas el clúster para la migración.

Para actualizar el clúster, ejecuta este comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Migración a Controlplane V2

Durante la migración a Controlplane V2, la actualización realiza las siguientes acciones:

Crea el plano de control de un clúster nuevo con ControlPlane V2 habilitado.
Detiene el plano de control de Kubernetes del clúster de kubeception.
Toma una instantánea de etcd del clúster de kubeception.
Apaga los nodos del plano de control del clúster de usuario del clúster de kubeception. Hasta que se completa la migración, los nodos no se borran, ya que eso permite la recuperación de fallas recurriendo a ese clúster de kubeception.
Restablece los datos del clúster en el nuevo plano de control con la instantánea de etcd que se creó en un paso anterior.
Conecta los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control, al que se puede acceder con el controlPlaneVIP nuevo.
Concilia el clúster de usuario restablecido para cumplir con el estado final del clúster con ControlPlane V2 habilitado.

Ten en cuenta lo siguiente:

No hay tiempo de inactividad para las cargas 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 usuario durante la migración. Específicamente, el plano de control no está disponible entre el momento en que se detiene el plano de control de Kubernetes del clúster de kubeception y la finalización de la conexión de los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control. (En las pruebas, este tiempo de inactividad fue inferior a 7 minutos, pero la duración real depende de tu infraestructura).
Al final de la migración, se borran los nodos del plano de control del clúster de usuario de los clústeres de kubeception. Si el clúster de administrador tiene network.ipMode.type configurado como "static", puedes reciclar algunas de las direcciones IP estáticas sin usar. Puedes enumerar los objetos del nodo del clúster de administrador con kubectl get nodes -o wide para ver qué direcciones IP están en uso. Para reciclar esas direcciones IP, quítalas del archivo de configuración del clúster de administrador y ejecuta gkectl update admin.

Después de la migración

Una vez que se complete la actualización, sigue estos pasos:

Verifica que el clúster de usuario esté en ejecución:

kubectl get nodes --kubeconfig var>USER_CLUSTER_KUBECONFIG

El resultado es similar a este:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Si migraste a Controlplane V2, actualiza las reglas de firewall en tu clúster de administrador para quitar los nodos del plano de control del clúster de usuarios de kubeception.
Si inhabilitaste la encriptación de secretos siempre activa, vuelve a habilitar la función.
1. En el archivo de configuración del clúster de usuario, quita el campo disabled: true.
2. Actualiza el clúster de usuario:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Si inhabilitaste la reparación automática en el clúster de administrador, vuelve a habilitar la función.
1. En el archivo de configuración del clúster de administrador, configura autoRepair.enabled como true.
2. Actualiza el clúster:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

Migración del balanceador de cargas

Si migraste el balanceador de cargas, verifica que los componentes del balanceador de cargas se ejecuten correctamente.

Migración de MetalLB

Si migraste a MetalLB, verifica que los componentes de MetalLB se ejecuten correctamente:

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

En el resultado, se muestran los Pods para el controlador y el interlocutor 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

Después de una migración exitosa, borra las VMs de Seesaw apagadas del clúster de usuario. Puedes encontrar los nombres de las VMs de Seesaw en la sección vmnames del archivo seesaw-for-[USERCLUSTERNAME].yaml en tu directorio de configuración.

Migración de F5 BIG-IP

Después de la migración al balanceo de cargas manual, no se interrumpe el tráfico a tus clústeres. Esto se debe a que los recursos de F5 existentes aún existen, como puedes ver si ejecutas el siguiente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

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-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z