Migrar del balanceador de carga de Seesaw a MetalLB

En este documento se muestra cómo migrar del balanceador de carga de Seesaw al balanceador de carga de MetalLB para las versiones de 1.16 a 1.29. Si tus clústeres tienen la versión 1.30 o una posterior, te recomendamos que sigas las instrucciones que se indican en el artículo Planificar la migración de clústeres a las funciones recomendadas.

Usar MetalLB tiene varias ventajas en comparación con otras opciones de balanceo de carga.

1.28 y 1.29: GA
1.16: Vista previa

Para comprobar el externalTrafficPolicy, ejecuta el siguiente comando:

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

Ponte en contacto con el equipo de Asistencia de Google para obtener ayuda con este problema.

Notas sobre el tiempo de inactividad

Hay un periodo de inactividad de la carga de trabajo durante la migración. Las siguientes notas solo se aplican a los clústeres de administrador que no son de alta disponibilidad (no HA), ya que el balanceador de carga SeeSaw no admite clústeres de administrador de alta disponibilidad.

  • Al migrar un clúster de administrador, haz lo siguiente:

    • El plano de control de los clústeres de usuarios de kubeception se inactiva mientras se migra controlPlaneVIP. El tiempo de inactividad debería ser inferior a 10 minutos, pero depende de tu infraestructura.

    • El plano de control del clúster de administrador se inactiva porque el nodo maestro del administrador debe recrearse con controlPlaneVIP conectado directamente a la VM. El tiempo de inactividad debería ser inferior a 20 minutos, pero depende de tu infraestructura.

  • Al migrar un clúster de usuario, se produce una interrupción de las IPs virtuales después de que se apague el balanceador de carga de Seesaw y antes de que se activen los pods de MetalLB. Este proceso suele tardar alrededor de un minuto.

Migración de clústeres de usuarios

Debes elegir un grupo de nodos y habilitarlo para usarlo con MetalLB. MetalLB se desplegará en los nodos de este grupo de nodos.

En el archivo de configuración del clúster de usuarios, elige un grupo de nodos y asigna el valor enableLoadBalancer a true:

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

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

A continuación, elimina las secciones de Seesaw del archivo y añade una sección de MetalLB.

A continuación, vuelve a actualizar el clúster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifica 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 manualmente las VMs de Seesaw, que ya están 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.

Ejemplo: clúster de usuarios, direcciones IP estáticas

Supongamos que tienes un clúster de usuarios que usa direcciones IP estáticas para sus nodos de clúster. Supongamos también que el clúster tiene dos servicios de tipo LoadBalancer y que las direcciones externas de esos servicios son 172.16.21.41 y 172.16.21.45.

Ajusta el archivo de configuración del clúster de usuarios de la siguiente manera:

  • Mantén la sección network.hostConfig.
  • Asigna el valor MetalLB a loadBalancer.kind.
  • Elimina la sección loadBalancer.seesaw.
  • Añade una sección loadBalancer.metalLB.

Ejemplo:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
    ingressVIP: "172.16.20.31"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.31/32"
      - "172.16.20.40 - 172.16.21.49"

Puntos clave del ejemplo anterior:

  • Aunque el clúster ya no utilice el balanceador de carga Seesaw, es necesaria la sección network.hostConfig porque los nodos del clúster usan direcciones IP estáticas.

  • El valor de ingressVIP aparece en el grupo de direcciones de MetalLB.

  • Las direcciones IP externas 172.16.21.41 y 172.16.21.45 de los servicios de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Ejemplo: clúster de usuario de kubeception, DHCP

Supongamos que tienes un clúster de usuarios que usa DHCP para sus nodos de clúster. Supongamos también que el clúster tiene dos servicios de tipo LoadBalancer y que las direcciones externas de esos servicios son 172.16.21.61 y 172.16.21.65.

Ajusta el archivo de configuración del clúster de usuarios de la siguiente manera:

  • Elimina la sección network.hostConfig.
  • Asigna el valor MetalLB a loadBalancer.kind.
  • Elimina la sección loadBalancer.seesaw.
  • Añade una sección loadBalancer.metalLB.

Ejemplo:

enableControlplaneV2: false
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.50"
    ingressVIP: "172.16.20.51"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.51/32"
      - "172.16.20.60 - 172.16.21.69"

Puntos clave del ejemplo anterior:

  • El clúster dejará de usar el balanceador de carga de Seesaw y no usará direcciones IP estáticas para sus nodos. Por lo tanto, no es necesario incluir la sección network.hostConfig.

  • El valor de ingressVIP aparece en el grupo de direcciones de MetalLB.

  • Las direcciones IP externas 172.16.21.61 y 172.16.21.65 de los servicios de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Ejemplo: clúster de usuarios de Controlplane V2, DHCP

Supongamos que tienes un clúster de usuario que tiene habilitado Controlplane V2 y usa DHCP para sus nodos de trabajador. Supongamos también que el clúster tiene dos Services de tipo LoadBalancer y que las direcciones externas de esos Services son 172.16.21.81 y 172.16.21.85.

Ajusta el archivo de configuración del clúster de usuarios de la siguiente manera:

  • Mantén la sección network.hostconfig.
  • Asigna el valor MetalLB a loadBalancer.kind.
  • Elimina la sección loadBalancer.seesaw.
  • Añade una sección loadBalancer.metalLB.

Ejemplo:

enableControlplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.70"
    ingressVIP: "172.16.20.71"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.71/32"
      - "172.16.20.80 - 172.16.21.89"

Puntos clave del ejemplo anterior:

  • El clúster dejará de usar direcciones IP estáticas para los nodos de trabajo, pero las usará para los nodos del plano de control. Por lo tanto, es necesaria la sección network.hostConfig.

  • El valor de ingressVIP aparece en el grupo de direcciones de MetalLB.

  • Las direcciones IP externas 172.16.21.81 y 172.16.21.85 de los servicios de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Migración de clústeres de administradores

En el archivo de configuración del clúster de administrador, asigna el valor loadBalancer.kind a MetalLB y elimina la sección loadBalancer.seesaw.

Actualiza el clúster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Haz los cambios siguientes:

  • 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

Verifica que los componentes de MetalLB se estén ejecutando correctamente: 

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 manualmente las VMs de Seesaw, que ya están 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.

Ejemplo: clúster de administrador, direcciones IP estáticas

Supongamos que tienes un clúster de administrador que usa direcciones IP estáticas para sus nodos de clúster.

Ajusta el archivo de configuración del clúster de administrador de la siguiente manera:

  • Mantén la sección network.hostConfig.
  • Asigna el valor MetalLB a loadBalancer.kind.
  • Elimina la sección loadBalancer.seesaw.

Ejemplo:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

Punto clave del ejemplo anterior:

  • Aunque el clúster ya no utilice el balanceador de carga Seesaw, es necesaria la sección network.hostConfig porque los nodos del clúster usan direcciones IP estáticas.

Ejemplo: clúster de administración, DHCP

Supongamos que tienes un clúster de administrador que usa DHCP para sus nodos de clúster.

Ajusta el archivo de configuración del clúster de administrador de la siguiente manera:

  • Elimina la sección network.hostConfig.
  • Asigna el valor MetalLB a loadBalancer.kind.
  • Elimina la sección loadBalancer.seesaw.

Ejemplo:

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072

Punto clave del ejemplo anterior:

  • El clúster dejará de usar el balanceador de carga de Seesaw y no usará direcciones IP estáticas para sus nodos. Por lo tanto, no es necesario incluir la sección network.hostConfig.

Solución de problemas

Si gkectl update falla durante la migración del clúster de usuarios y los pods de MetalLB no se están ejecutando en el clúster de usuarios, enciende manualmente las VMs de Seesaw del clúster de usuarios. De esta forma, se restablecerá el tráfico a los VIPs que se estén usando. Sin embargo, es posible que las VMs de Seesaw no sirvan las IPs virtuales creadas recientemente si el pod load-balancer-seesaw no está en ejecución. Si es así, crea una incidencia.

Si gkectl update falla durante la migración del clúster de administrador y los pods de MetalLB no se están ejecutando en el clúster de administrador, enciende manualmente las VMs de Seesaw del clúster de administrador. Esto podría permitir que el tráfico de los VIPs del plano de control que se estén usando en ese momento para los clústeres de usuarios vuelva a funcionar. Sin embargo, es posible que el VIP del plano de control del clúster de administrador no funcione. En ese caso, edita el archivo kubeconfig del clúster de administrador para usar directamente la dirección IP del nodo del plano de control del clúster de administrador.

Además, en el espacio de nombres kube-system, cambia el kube-apiserver tipo de servicio de ClusterIP a LoadBalancer. Si es necesario, crea una incidencia.