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.

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

1.28 y versiones posteriores: GA

1.16: Versión preliminar

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, haz 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 la duración depende de tu infraestructura.

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

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

Migración de clústeres de usuarios

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

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 de forma manual 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 en el 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, ya que 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 servicios 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. También supongamos que el clúster tiene dos servicios de tipo LoadBalancer y las direcciones externas para esos servicios 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 usa 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 servicios 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 de trabajo, pero sí 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 servicios 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, establece 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

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

Modifica 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, ya que 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.

Modifica 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 usa 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 usuarios y los pods de metallb no se ejecutan en el clúster de usuarios, enciende manualmente las VMs de Seesaw del clúster de usuarios. Esto restablecerá el tráfico a las VIP que se usan actualmente. Sin embargo, es posible que las VMs de Seesaw no entreguen los VIPs recién creados si el pod load-balancer-seesaw no está en ejecución. 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 usuarios 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.