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.

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

Migración de clústeres de usuario

En el archivo de configuración del clúster de usuario, elige un grupo de nodos y establece enableLoadBalancer en 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 la bocina 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

Importante: El proceso de migración detendrá las conexiones de red a todas las VIP en el clúster de usuario para los servicios de Kubernetes de tipo LoadBalancer durante dos a diez minutos. Después de que se complete la migración, las conexiones volverán a funcionar.

Después de una migración exitosa, borra de forma manual las VM de Seesaw, que ya están apagadas, para el clúster de usuario. Puedes encontrar los nombres de las VM de Seesaw en la sección vmnames del archivo seesaw-for-[USERCLUSTERNAME].yaml del 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 de clúster. Supongamos también que el clúster tiene dos Services de tipo LoadBalancer y que las direcciones externas para esos Services 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 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 utiliza 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 para 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 el clúster no usará direcciones IP estáticas para sus nodos. Por lo tanto, la sección network.hostConfig no es necesaria.

• 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 del plano de control V2, DHCP

Supongamos que tienes un clúster de usuario que tiene habilitado el plano de control V2 y usa DHCP para sus nodos trabajadores. Supongamos también que el clúster tiene dos Services de tipo LoadBalancer y que las direcciones externas para esos Services 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, pero usará direcciones IP estáticas 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

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

Importante: El proceso de migración detendrá las conexiones de red a todas las VIP en el clúster de administrador para los Services de Kubernetes de tipo LoadBalancer durante dos a diez minutos. Después de que se complete la migración, las conexiones volverán a funcionar.

Después de una migración exitosa, borra de forma manual las VM de Seesaw, que ya están apagadas, para el clúster de administrador. Puedes encontrar los nombres de las VM de Seesaw en la sección vmnames del archivo seesaw-for-gke-admin.yaml del 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:

• 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 los nodos del 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 el clúster no usará direcciones IP estáticas para sus nodos. Por lo tanto, la sección network.hostConfig no es necesaria.

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 de forma manual las VM de Seesaw del clúster de usuario. Esta acción restablecerá el tráfico a las VIP que se usan actualmente. Sin embargo, es posible que las VM de Seesaw no entreguen las VIP recién creadas 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 de forma manual las VM 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 vuelva a funcionar. Sin embargo, es posible que la VIP para el plano de control del clúster de administrador no funcione. En ese caso, edita el archivo kubeconfig del clúster de administrador para que use 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.