Migra del balanceador de cargas de Seesaw a MetalLB

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

El uso de MetalLB tiene varios beneficios en comparación con otras opciones de balanceo de cargas.

1.28 y 1.29: GA
1.16: Versión preliminar

Para verificar el estado externalTrafficPolicy, ejecuta el siguiente comando:

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

Comunícate con Atención al cliente de Google para obtener ayuda con este problema.

Notas sobre el tiempo de inactividad

Hay tiempo 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 tienen alta disponibilidad (sin HA), ya que el balanceador de cargas SeeSaw no admite clústeres de administrador con HA.

  • Cuando migres un clúster de administrador, ten en cuenta lo siguiente:

    • Hay un tiempo de inactividad del plano de control para los clústeres de usuario de kubeception a medida que se migra controlPlaneVIP. El tiempo de inactividad debe ser inferior a 10 minutos, pero su duración depende de tu infraestructura.

    • Hay un tiempo de inactividad para el plano de control del clúster de administrador, ya que el nodo principal del administrador debe volver a crearse con controlPlaneVIP conectado directamente a la VM. El tiempo de inactividad debe ser inferior a 20 minutos, pero su duración depende de tu infraestructura.

  • Cuando se migra un clúster de usuario, se produce una interrupción de las VIP después de que se apaga el balanceador de cargas de Seesaw y antes de que se activen los Pods de MetalLB. Por lo general, este proceso tarda alrededor de un minuto.

Migración del clúster de usuario

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

En el archivo de configuración del clúster de usuario, elige un grupo de nodos y configura enableLoadBalancer como true:

nodePools:
- name: pool-1
  replicas: 3
  enableLoadBalancer: 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

A continuación, quita las secciones de Seesaw del archivo y agrega una sección de MetalLB.

Luego, actualiza el clúster nuevamente:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifica que los componentes de MetalLB se ejecuten correctamente:

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

El resultado muestra los Pods del 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 manualmente las VMs de Seesaw, que ya están apagadas, para el 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.

Ejemplo: Clúster de usuario, direcciones IP estáticas

Supongamos que tienes un clúster de usuario que usa direcciones IP estáticas para sus nodos. 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 usuario de la siguiente manera:

  • Conserva la sección network.hostConfig.
  • Establece loadBalancer.kind en MetalLB.
  • Quita la sección loadBalancer.seesaw.
  • Agrega 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 usará el balanceador de cargas de Seesaw, se necesita 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, para los Services existentes 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 usuario que usa DHCP para sus nodos de clúster. 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.61 y 172.16.21.65.

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

  • Quita la sección network.hostConfig.
  • Establece loadBalancer.kind en MetalLB.
  • Quita la sección loadBalancer.seesaw.
  • Agrega 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 ya no usará el balanceador de cargas de Seesaw, y no usará direcciones IP estáticas para sus nodos. Por lo tanto, no se necesita 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, para los Services existentes de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Ejemplo: Clúster de usuario de Controlplane V2, DHCP

Supongamos que tienes un clúster de usuario que tiene habilitado Controlplane V2 y usa DHCP para sus nodos trabajadores. 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.81 y 172.16.21.85.

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

  • Conserva la sección network.hostconfig.
  • Establece loadBalancer.kind en MetalLB.
  • Quita la sección loadBalancer.seesaw.
  • Agrega 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 ya no usará direcciones IP estáticas para los nodos trabajadores, sino que las usará para los nodos del plano de control. Por lo tanto, se necesita 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, para los Services existentes de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Migración del clúster de administrador

En el archivo de configuración del clúster de administrador, configura loadBalancer.kind como MetalLB y quita la sección loadBalancer.seesaw.

Actualiza el clúster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Reemplaza lo siguiente:

  • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

  • ADMIN_CLUSTER_CONFIG: la ruta de acceso del archivo de configuración de tu clúster de administrador

Verifica que los componentes de MetalLB se ejecuten correctamente: 

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

El resultado muestra los Pods del 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 manualmente las VMs de Seesaw, que ya están apagadas, para el 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 en 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.

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

  • Conserva la sección network.hostConfig.
  • Establece loadBalancer.kind en MetalLB.
  • Quita 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 usará el balanceador de cargas de Seesaw, se necesita la sección network.hostConfig porque los nodos del clúster usan direcciones IP estáticas.

Ejemplo: Clúster de administrador, 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:

  • Quita la sección network.hostConfig.
  • Establece loadBalancer.kind en MetalLB.
  • Quita 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 ya no usará el balanceador de cargas de Seesaw, y no usará direcciones IP estáticas para sus nodos. Por lo tanto, no se necesita la sección network.hostConfig.

Soluciona problemas

Si gkectl update falla durante la migración del clúster de usuario y los Pods de MetalLB no se ejecutan en el clúster de usuario, enciende manualmente las VMs de Seesaw del clúster de usuario. Esto restablecerá el tráfico a las VIP que se usan actualmente. Sin embargo, es posible que las VMs de Seesaw no entreguen las VIP creadas recientemente si el Pod load-balancer-seesaw no se está ejecutando. Si ese es el caso, crea un ticket de asistencia.

Si gkectl update falla durante la migración del clúster de administrador y los Pods de MetalLB no se ejecutan 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 a las VIP del plano de control que se usan actualmente para los clústeres de usuario vuelva a funcionar. Sin embargo, es posible que la 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 tipo de servicio kube-apiserver de ClusterIP a LoadBalancer. Si es necesario, crea un ticket de asistencia.