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.

Migración del clúster 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

El resultado muestra los Pods para el 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

Importante: El proceso de migración detendrá las conexiones de red a todas las VIP en el clúster de usuario para los Services de Kubernetes de tipo LoadBalancer durante dos a diez minutos. Una vez 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 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 los nodos del 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 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 los nodos del clúster. Además, supongamos 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 no usará direcciones IP estáticas para los nodos del clúster. 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 servicios existentes de tipo LoadBalancer se incluyen en el grupo de direcciones de MetalLB.

Ejemplo: Clúster de usuario de plano de control 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 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, la sección network.hostConfig es necesaria.

• 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 en 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 para el 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

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. Una vez 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, del 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 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 los nodos del 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 no usará direcciones IP estáticas para los nodos del clúster. 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 las VMs de Seesaw de forma manual. Esto 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 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 las VM de Seesaw del clúster de administrador de forma manual. Esto podría permitir que el tráfico a las VIP del plano de control que se usan actualmente para que los clústeres de usuario vuelvan 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 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.