Migrar un clúster de usuarios a las funciones recomendadas

Información general

En esta página se explica cómo migrar clústeres de usuarios de la versión 1.30 o posterior a las siguientes funciones recomendadas:

  • Migra a Dataplane V2 como interfaz de red de contenedor (CNI).
  • Migra clústeres de usuarios mediante kubeception a Controlplane V2.

  • Migra la configuración del balanceador de carga:

    • Desde la configuración del balanceador de carga integrado F5 BIG-IP hasta ManualLB

      o

    • Del balanceador de carga de Seesaw agrupado a MetalLB.

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 información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas habituales de los usuarios de GKE.

Prácticas recomendadas

Te recomendamos que primero migres el entorno 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.

Te recomendamos que crees un clúster de usuarios con Controlplane V2 habilitado para conocer las diferencias arquitectónicas con los clústeres de kubeception. El nuevo clúster no afecta a tus cargas de trabajo. Sin embargo, en el peor de los casos, si la migración falla, tendrás un clúster listo para tus cargas de trabajo.

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

Requisitos

Para esta migración:

  • El clúster de usuarios debe tener 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 carga Seesaw, asegúrate de que no dependas de él para conservar la IP del cliente, tal como se describe en la siguiente sección.

Conservación de la IP de cliente de Seesaw

Para comprobar el externalTrafficPolicy, ejecuta el siguiente comando:

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

Si tienes este problema, ponte en contacto con el equipo de Asistencia de Google.

Estimar el tiempo necesario y planificar una ventana 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 forma secuencial. Por lo tanto, el tiempo total de actualización depende del número de nodos del grupo de nodos más grande. Para calcular una estimación aproximada de cada actualización, sigue estos pasos:

  • Si vas a migrar de Seesaw a MetalLB, calcula 15 minutos para que se actualice y elijas un grupo de nodos para el balanceador de carga de MetalLB. En esta actualización, solo se actualiza el grupo de nodos seleccionado.
  • Para cualquier otra actualización del proceso de migración, multiplica 15 minutos por el número de nodos del grupo de nodos.

Para calcular el tiempo que necesitas dedicar, cuenta el número de veces que tienes que actualizar el clúster. Los siguientes pasos generales muestran cuándo debes ejecutar gkectl update cluster para actualizar el clúster:

  1. Si el clúster de usuarios usa el cifrado de secretos siempre activo, inhabilita la función y ejecuta gkectl update cluster.
  2. Si el clúster de usuarios tiene enableDataplaneV2 sin definir o definido como false, haz los cambios de configuración y, a continuación, ejecuta gkectl update cluster para migrar a Dataplane V2.

  3. Prepara la migración del balanceador de carga y del plano de control:

    1. Si el clúster de administrador tiene la reparación automática habilitada, desactívala. A continuación, ejecuta gkectl update admin. Esta actualización se completa rápidamente porque no vuelve a crear los nodos del clúster de administrador.
    2. Si el clúster de usuario usa Seesaw, elige un grupo de nodos para que lo use el balanceador de carga de MetalLB y, a continuación, ejecuta gkectl update cluster. Esta actualización solo afecta a los nodos del grupo de nodos seleccionado.

  4. Haz todos los cambios de configuración necesarios para actualizar tu balanceador de carga y migrar a Controlplane V2. A continuación, ejecuta gkectl update cluster.

  5. Después de la migración, si has inhabilitado el cifrado de secretos siempre activo, vuelve a habilitar la función y ejecuta gkectl update cluster.

El tiempo total de la migración depende del número de veces que debas ejecutar gkectl cluster update, que a su vez depende de tu configuración. Por ejemplo, supongamos que vas a migrar a Dataplane V2, ControlPlane V2 y MetalLB. También se da por hecho 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, añade lo siguiente:

  • 150 minutos para la migración a Dataplane V2, ya que 15 minutos * 10 nodos en el pool más grande = 150 minutos.
  • 45 minutos para el grupo de nodos que usa MetalLB, ya que 15 minutos * 3 nodos en ese grupo de nodos = 45 minutos.
  • 150 minutos para la actualización de Controlplane V2 y MetalLB, ya que 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 hacer la migración por fases. Siguiendo el ejemplo anterior, puedes hacer la migración a Dataplane V2 en una ventana de mantenimiento y el resto de la migración en una o dos ventanas de mantenimiento.

Planificar el tiempo de inactividad durante la migración

Al planificar la 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 vas a migrar a Controlplane V2, habrá un tiempo de inactividad del plano de control para los clústeres de usuarios de kubeception mientras se migra loadBalancer.vips.controlPlaneVIP. El tiempo de inactividad suele ser inferior a 10 minutos, pero depende de tu infraestructura.
  • Tiempo de inactividad de la carga de trabajo: las IPs virtuales (VIPs) 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 todas las IPs virtuales del clúster de usuario para los servicios de Kubernetes de tipo LoadBalancer durante unos dos o 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:

De Para Acceso a la API de Kubernetes Cargas de trabajo de los usuarios
Clúster de Kubeception que usa Calico, que tiene enableDataplaneV2 sin definir o definido como false Clúster de Kubeception con Dataplane V2 No se ve afectado No se ve afectado
Clúster de Kubeception, que tiene enableControlplaneV2 sin definir o definido como false con MetalLB o ManualLB Clúster de Controlplane V2 con el mismo tipo de balanceador de carga A quién afecta No se ve afectado
Clúster de Kubeception con loadBalancer.kind: "F5BigIP" Clúster de Controlplane V2 con configuración manual del balanceador de carga A quién afecta No se ve afectado
Clúster de Kubeception con loadBalancer.kind: "Seesaw" Clúster de Controlplane V2 con MetalLB A quién afecta A quién afecta
  • 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

Para que la migración se lleve a cabo correctamente, sigue los pasos que se indican en las siguientes secciones.

Asignar nuevas direcciones IP

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

  • Necesitas una dirección IP para el loadBalancer.vips.controlPlaneVIP.

  • Asigna una dirección IP a cada nodo del plano de control. El número de direcciones IP que debes asignar depende de si el clúster de usuarios será de alta disponibilidad (HA) o no.

    • Sin alta disponibilidad: una dirección IP
    • Alta disponibilidad: tres direcciones IP

Actualizar reglas de cortafuegos

Si vas a migrar a Controlplane V2, actualiza las reglas de cortafuegos de tus clústeres de usuarios. Asegúrate de que las direcciones IP recién asignadas a los nodos del plano de control del clúster de usuario puedan acceder a todas las APIs y otros destinos necesarios, tal como se describe en Reglas de cortafuegos de los nodos del clúster de usuario.

Comprobar 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 1.30 o una posterior. De lo contrario, actualiza los grupos de nodos a la versión gkeOnPremVersion en el archivo de configuración del clúster de usuarios antes de continuar con la migración. Para comprobar las versiones, ejecuta el siguiente comando:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de administrador.

Comprobar el estado del clúster

Comprueba el estado del clúster y corrige los problemas que indique el comando gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

Haz los cambios siguientes:

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

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

Si vas a migrar el clúster de usuario para que use Controlplane V2 y la reparación automática esté habilitada en el clúster de administrador, inhabilita la reparación automática. Comprueba el campo autoRepair.enabled del archivo de configuración del clúster de administrador. Si ese campo no está definido o tiene el valor true, sigue estos pasos:

  1. En el archivo de configuración del clúster de administrador, asigna el valor autoRepair.enabled a false . Por ejemplo:

    autoRepair:
  enabled: false

  2. Actualiza el clúster de administrador:

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

Haz los cambios siguientes:

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

Una vez finalizada la migración, vuelve a habilitar la reparación automática en el clúster de administrador.

Comprobar si hay algún problema con el cifrado de secretos siempre activo

Si vas a migrar el clúster de usuario para que use Controlplane V2, comprueba si hay algún problema con el cifrado de secretos siempre activo.

Si el cifrado de secretos siempre activo se ha habilitado alguna vez en el clúster de usuario, debes seguir los pasos que se indican en Inhabilitar el cifrado de secretos siempre activo y descifrar secretos antes de iniciar la migración. De lo contrario, el nuevo clúster Controlplane V2 no podrá descifrar los secretos.

Antes de iniciar la migración, ejecuta el siguiente comando para ver si el cifrado de secretos siempre activo se ha habilitado 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 la salida del comando anterior está vacía, significa que el cifrado de secretos siempre activo nunca se ha habilitado. Puedes iniciar la migración.

Si la salida del comando anterior no está vacía, significa que el cifrado de secretos siempre activo se había habilitado anteriormente. Antes de migrar, debes seguir los pasos de la sección siguiente para asegurarte de que el nuevo clúster de Controlplane V2 pueda descifrar secretos.

En el siguiente ejemplo se muestra una salida no vacía:

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

Inhabilitar el encriptado de secretos siempre activo y descifrar los secretos si es necesario

Para inhabilitar el encriptado de secretos siempre activo y descifrar secretos, sigue estos pasos:

  1. En el archivo de configuración del clúster de usuarios, para inhabilitar el cifrado de secretos siempre activos, añade un campo disabled: true a la sección secretsEncryption:

    secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true

  2. Actualiza el clúster:

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

    Haz los cambios siguientes:

    • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
    • USER_CLUSTER_CONFIG: la ruta del archivo de configuración del clúster de usuarios

  3. Para hacer una actualización continua de un DaemonSet específico, sigue estos pasos:

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

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

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

  5. Para que todos los secretos se almacenen en etcd como texto sin formato, vuelve a aplicar todos los secretos del clúster de usuario:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml

    Ahora puedes iniciar la migración a Controlplane V2. Una vez completada la migración, puedes volver a habilitar el cifrado de secretos siempre activo en el clúster.

Comprobar si hay un problema con los webhooks de carga de trabajo mal configurados

Si vas a migrar el clúster de usuario para que use Controlplane V2, comprueba si hay algún problema con los webhooks de carga de trabajo mal configurados.

Si tienes webhooks que incluyen pods del sistema en el espacio de nombres kube-system, añade namespaceSelector para filtrar el espacio de nombres kube-system.

Por ejemplo, 

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Habilitar un grupo de nodos para que lo use MetalLB

Si vas a migrar del balanceador de carga de Seesaw agrupado a MetalLB, sigue 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 usuarios. Si va a migrar la configuración integrada de F5 BIG-IP, vaya a la siguiente sección, Migrar a Dataplane V2.

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

  1. En la sección nodePools del archivo de configuración del clúster de usuario, elige un grupo de nodos o añade uno nuevo y asigna el valor enableLoadBalancer a true. Por ejemplo:

    nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true

  2. Actualiza el clúster:

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

Para obtener más información sobre MetalLB, consulta el artículo sobre el balanceo de carga agrupado con MetalLB.

Migrar a Dataplane V2

Antes de migrar, compruebe si DataPlane V2 está habilitado en el clúster ejecutando el siguiente comando:

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, vaya a la siguiente sección, Preparar la migración del balanceador de carga.

Para migrar a Dataplane V2, tienes las siguientes opciones:

  • Actualiza el clúster a la versión 1.31. Para ver los pasos detallados, consulta Habilitar Dataplane V2.

  • Actualiza el clúster 1.30.

En ambos casos, debes quitar temporalmente la especificación NetworkPolicy, tal como se describe en los pasos siguientes.

Para migrar a Dataplane V2, sigue estos pasos. Si tienes alguna duda sobre la eliminación temporal de la especificación NetworkPolicy, ponte en contacto con el equipo de Asistencia de Google.

Si tu clúster usa un NetworkPolicy, quítalo temporalmente del clúster de la siguiente manera:

  1. Comprueba si hay algún NetworkPolicy no perteneciente al sistema aplicado a tu clúster:

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

  2. Si la salida del paso anterior no estaba vacía, guarda cada NetworkPolicy especificación en un archivo para poder volver a aplicarla después de actualizar el clúster.

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml

    Haz los cambios siguientes:

    • NETWORK_POLICY_NAME: el nombre del NetworkPolicy que vas a guardar.
    • NETWORK_POLICY_NAMESPACE: el espacio de nombres de NetworkPolicy.

  3. Elimina el NetworkPolicy con el siguiente comando:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Para migrar a Dataplane V2, sigue estos pasos:

  1. Asigna el valor enableDataplaneV2 a true en el archivo de configuración del clúster de usuarios.

  2. Para habilitar DataPlane V2, actualiza tu clúster:

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

  3. Si has eliminado alguna especificación que no sea del sistema NetworkPolicy en un paso anterior, una vez que se haya completado la actualización, vuelve a aplicarla con este comando:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml

Una vez completados esos pasos, Dataplane V2 estará habilitado. A continuación, prepara la migración de tu clúster al balanceador de carga y a Controlplane V2 recomendados.

Preparar la migración del balanceador de carga

Si tus clústeres de usuarios usan el balanceador de carga Seesaw o F5 BIG-IP integrado, sigue los pasos de esta sección para hacer los cambios necesarios en el archivo de configuración del clúster de usuarios. De lo contrario, vaya a la siguiente sección, Prepararse para la migración a Controlplane V2.

F5 BIG-IP

Si tus clústeres usan la configuración integrada de F5 BIG-IP, prepárate para la migración a ManualLB haciendo los siguientes cambios en el archivo de configuración del clúster de usuario:

  1. Cambia loadBalancer.kind a "ManualLB".
  2. Mantén el mismo valor en el campo loadBalancer.vips.ingressVIP.
  3. Si vas a migrar a Controlplane V2, cambia el valor del campo loadBalancer.vips.controlPlaneVIP por la dirección IP que hayas asignado. De lo contrario, puedes mantener el mismo valor.
  4. Elimina toda la sección loadBalancer.f5BigIP.

En el siguiente archivo de configuración de clúster de usuarios de ejemplo 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 usuarios usan el balanceador de carga Seesaw, prepárate para la migración a MetalLB siguiendo los pasos que se indican en las secciones siguientes.

Especificar grupos de direcciones

El controlador de MetalLB asigna direcciones IP a los servicios. Cuando un desarrollador de aplicaciones crea un servicio de tipo LoadBalancer en un clúster de usuario, el controlador MetalLB asigna automáticamente una dirección IP al servicio. El controlador de MetalLB selecciona una dirección IP de un grupo de direcciones que especifiques.

Para asegurarte de que tu clúster de usuarios tenga suficientes direcciones IP, ten en cuenta el número máximo de servicios LoadBalancer que probablemente estén activos. A continuación, especifica suficientes direcciones IP en la sección loadBalancer.metalLB.addressPools del archivo de configuración de tu clúster de usuarios.

Las direcciones del grupo deben estar en formato CIDR o de intervalo. Para especificar una dirección concreta, usa un /32 CIDR. Por ejemplo:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

Excluir direcciones IP usadas para otros fines

No incluyas las siguientes direcciones IP en ningún grupo de direcciones:

Actualizar el archivo de configuración del clúster

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

  1. Asigna el valor "MetalLB" a loadBalancer.kind.
  2. Puedes mantener el mismo valor en el campo loadBalancer.vips.ingressVIP.
  3. Añade el VIP de entrada a un grupo de direcciones de MetalLB.
  4. Si vas a migrar a Controlplane V2, cambia el valor del campo loadBalancer.vips.controlPlaneVIP por la dirección IP que hayas asignado. De lo contrario, puedes mantener el mismo valor.
  5. Elimina la sección loadBalancer.seesaw.
  6. Añade una loadBalancer.metalLB sección.

En la siguiente parte de un archivo de configuración de clúster de usuarios se muestran estos cambios y la configuración de MetalLB:

  • Un grupo de direcciones para que el controlador de MetalLB elija y asigne a los servicios de tipo LoadBalancer. La IP virtual de entrada, que en este ejemplo es 198.51.100.10, está en este grupo en formato de intervalo 198.51.100.10/32.
  • La IP virtual designada para el servidor de la API de Kubernetes del clúster de usuario.
  • El VIP de entrada que has configurado para el proxy de entrada.
  • Un grupo de nodos habilitado para usar MetalLB. La migración despliega 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"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Prepararse para la migración a Controlplane V2

Si el clúster no tiene habilitado Controlplane V2:

  • Actualiza el archivo de configuración del clúster de usuarios.
  • Si el clúster usa el balanceo de carga manual (loadBalancer.kind: "ManualLB"), también debes actualizar la configuración en el balanceador de carga.

Estos pasos se describen en las siguientes secciones.

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

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

Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:

  1. Asigna el valor true a enableControlplaneV2.
  2. Si quieres, puedes hacer que el plano de control del clúster de usuario Controlplane V2 tenga alta disponibilidad. Para cambiar de un clúster que no es de alta disponibilidad a uno que sí lo es, cambia masterNode.replicas de 1 a 3.
  3. Añade la dirección o las direcciones IP estáticas de los nodos del plano de control del clúster de usuario a la sección network.controlPlaneIPBlock.ips. La dirección o las direcciones IP de los nodos del plano de control deben estar en la misma VLAN que los nodos de trabajo. Los nombres de host son obligatorios.
  4. Rellena los campos netmask y gateway de la sección network.controlPlaneIPBlock.
  5. Si la sección network.hostConfig está vacía, rellénala.
  6. Asegúrate de que el campo loadBalancer.vips.controlPlaneVIP tenga la nueva dirección IP virtual del plano de control. La dirección IP debe estar en la misma VLAN que las IPs de los nodos del plano de control.
  7. Si el clúster de usuarios usa el balanceo de carga manual, asigna el valor 0 a loadBalancer.manualLB.controlPlaneNodePort y loadBalancer.manualLB.konnectivityServerNodePort. No son obligatorios cuando Controlplane V2 está habilitado, pero deben tener el valor 0.
  8. Si el clúster de usuarios usa el balanceo de carga manual, configura el balanceador de carga tal como se describe en la siguiente sección.

Ajustar las asignaciones del balanceador de carga si es necesario

Si tu clúster de usuario ya usa el balanceo de carga manual, debes configurar algunas asignaciones en el balanceador de carga. Si vas a migrar de la configuración integrada de F5 BIG-IP al balanceo de carga manual, no tienes que hacer ningún cambio en la configuración de tu balanceador de carga y puedes pasar a la siguiente sección, Migrar el clúster de usuarios.

Por cada dirección IP que hayas especificado en la sección network.controlPlaneIPBlock, configura las siguientes asignaciones en tu balanceador de carga 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 usuario, tanto los nodos del plano de control como los nodos de trabajador. Como los NodePorts se configuran en el clúster, Kubernetes los abre en todos los nodos del clúster, de modo que cualquier nodo del clúster puede gestionar el tráfico del plano de datos.

Una vez que hayas configurado las asignaciones, el balanceador de carga escuchará el tráfico en la dirección IP que hayas configurado para el VIP de entrada del clúster de usuarios en los puertos HTTP y HTTPS estándar. El balanceador de carga dirige las solicitudes a cualquier nodo del clúster. Una vez que se enruta una solicitud a uno de los nodos del clúster, la red interna de Kubernetes enruta la solicitud al pod de destino.

Migrar el clúster de usuarios

Primero, revisa detenidamente todos los cambios que hayas hecho en el archivo de configuración del clúster de usuarios. Todos los ajustes del balanceador de carga y de Controlplane V2 son inmutables, 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:

  1. Crea el plano de control de un nuevo clúster con ControlPlane V2 habilitado.
  2. Detiene el plano de control de Kubernetes del clúster de kubeception.
  3. Crea una instantánea de etcd del clúster de kubeception.
  4. Apaga los nodos del plano de control del clúster de usuarios del clúster de kubeception. Hasta que se complete la migración, los nodos no se eliminarán, ya que esto permite recuperar los errores volviendo a ese clúster de kubeception.
  5. Restaura los datos del clúster en el nuevo plano de control mediante la instantánea de etcd creada en un paso anterior.
  6. Conecta los nodos del grupo de nodos del clúster de kubeception al nuevo plano de control, al que se puede acceder con el nuevo controlPlaneVIP.
  7. Reconcilia el clúster de usuarios restaurado para que coincida 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 de los clústeres de usuarios durante la migración.
  • El plano de control del clúster de usuarios experimentará un tiempo de inactividad durante la migración. En concreto, 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 el momento en que se completa 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 eliminan los nodos del plano de control del clúster de usuarios de los clústeres de kubeception. Si el clúster de administrador tiene el valor "static" en network.ipMode.type, puedes reciclar algunas de las direcciones IP estáticas que no se utilicen. Puedes enumerar los objetos de nodo del clúster de administrador con kubectl get nodes -o wide para ver qué direcciones IP se están usando. Para reciclar esas direcciones IP, quítelas del archivo de configuración del clúster de administradores y ejecute gkectl update admin.
  • Al final de la migración, los nodos de trabajo se someten a una actualización gradual. Espera a que todos los nodos estén listos antes de continuar con los pasos posteriores a la migración que se indican en la siguiente sección.
  • Después de la migración, la antigua dirección VIP del plano de control sigue funcionando, pero es inestable. No te fíes de él. Actualiza lo antes posible las dependencias de la dirección VIP antigua para que usen la nueva.

Después de la migración

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

  1. Verifica que tu clúster de usuario esté en funcionamiento:

    kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

    El resultado debería ser similar al siguiente:

    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

  2. Si has migrado a Controlplane V2, actualiza las reglas de firewall de tu clúster de administrador para quitar los nodos de plano de control del clúster de usuarios de kubeception.

  3. Si has inhabilitado el cifrado de secretos siempre activo, vuelve a habilitar la función.

    1. En el archivo de configuración del clúster de usuarios, elimina el campo disabled: true.

    2. Actualiza el clúster de usuarios:

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

  4. Si has inhabilitado la reparación automática en el clúster de administración, vuelve a habilitar la función.

    1. En el archivo de configuración del clúster de administrador, asigna el valor autoRepair.enabled a true.

    2. Actualiza el clúster:

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

Migración de balanceadores de carga

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

Migración de MetalLB

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

kubectl --kubeconfig USER_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 usuarios. Puedes encontrar los nombres de las VMs de Seesaw en la sección vmnames del archivo seesaw-for-[USERCLUSTERNAME].yaml de tu directorio de configuración.

Migración de F5 BIG-IP

Después de la migración al balanceo de carga manual, el tráfico a tus 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 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