Configura el balanceo de cargas en paquetes con MetalLB

En esta página, se describe cómo configurar el balanceo de cargas en paquetes con MetalLB para Google Distributed Cloud. Los balanceadores de cargas de MetalLB se ejecutan en un grupo dedicado de nodos trabajadores o en los mismos nodos que el plano de control.

Consulta la descripción general de los balanceadores de cargas para ver ejemplos de topologías de balanceo de cargas disponibles en Google Distributed Cloud.

Requisitos

  • Todos los nodos del balanceador de cargas deben estar en la misma subred de capa 2.
  • Todos los VIP deben estar en la subred de nodos del balanceador de cargas y deben enrutarse a través de la puerta de enlace de la subred.
  • La puerta de enlace de la subred del balanceador de cargas debe escuchar los mensajes ARP injustificados y reenviar paquetes ARP a los nodos del balanceador de cargas.

Campos de configuración

Edita la sección cluster.spec.loadBalancer del archivo de configuración del clúster para configurar el balanceo de cargas en paquetes. Para obtener información sobre los archivos de configuración de clúster y ejemplos de configuraciones válidas, consulta una de las páginas siguientes:

loadBalancer.mode

Este valor debe ser bundled para habilitar el balanceo de cargas en paquetes.

loadBalancer.ports.controlPlaneLBPort

Este valor especifica el puerto de destino que se usará para el tráfico enviado al plano de control de Kubernetes (los servidores de la API de Kubernetes).

loadBalancer.vips.controlPlaneVIP

Este valor especifica la dirección IP de destino que se usará para el tráfico enviado al plano de control de Kubernetes (los servidores de la API de Kubernetes). Esta dirección IP debe estar en la misma subred de capa 2 que los nodos del clúster. No incluyas esta dirección en la sección address pools del archivo de configuración.

loadBalancer.vips.ingressVIP

Este valor especifica la dirección IP que se usará para los servicios detrás del balanceador de cargas para el tráfico de entrada. No se permite este campo en los archivos de configuración del clúster de administrador. Esta dirección debe aparecer en la sección de grupos de direcciones de la configuración.

loadBalancer.addressPools

Esta sección de la configuración contiene uno o más grupos de direcciones. Cada grupo de direcciones especifica una lista de rangos de direcciones IP. Cuando creas un servicio de tipo LoadBalancer, las direcciones IP externas del Service se eligen a partir de estos rangos.

Los grupos de direcciones se especifican en el siguiente formato:

- name: POOL_NAME
  avoidBuggyIPs: BOOLEAN
  manualAssign: BOOLEAN
  addresses:
  - IP_RANGE
  - IP_RANGE2
  • name: El nombre del grupo de direcciones, pool-name, para tus propios fines organizativos. Este campo es inmutable.
  • avoidBuggyIPs: (opcional) true o false. Si es true, el grupo omite las direcciones IP que terminan en .0 y .255. Algunos hardware de red descartan el tráfico hacia estas direcciones especiales. Puedes omitir este campo; su valor predeterminado es false. Este campo es mutable.
  • manualAssign: (opcional) true o false. Si es true, las direcciones en este grupo no se asignan automáticamente a los servicios de Kubernetes. Si es true, una dirección IP en este grupo se usa solo cuando un servicio lo especifica de manera explícita. Puedes omitir este campo; su valor predeterminado es false. Este campo es mutable.
  • addresses Una lista de uno o más rangos de direcciones IP que no se superponen. ip-range se puede especificar en notación CIDR (como 198.51.100.0/24) o notación de rangos (como 198.51.100.0-198.51.100.10, sin espacios alrededor del guion). Este campo es inmutable.

Los rangos de direcciones IP de la lista addresses no deben superponerse y deben estar en la misma subred que los nodos que ejecutan balanceadores de cargas.

loadBalancer.nodePoolSpec

En esta sección de la configuración, se especifica una lista de nodos para ejecutar balanceadores de carga. Los nodos del balanceador de cargas pueden ejecutar cargas de trabajo regulares de forma predeterminada. no hay un taint especial en esos nodos. Si bien los nodos del grupo de nodos del balanceador de cargas pueden ejecutar cargas de trabajo, están separados de los nodos de los grupos de nodo trabajador. No puedes incluir un nodo de clúster determinado en más de un grupo de nodos. La superposición de direcciones IP de nodos entre grupos de nodos bloquea la creación de clústeres y otras operaciones de clústeres.

Si quieres evitar que las cargas de trabajo se ejecuten en un nodo del grupo de nodos del balanceador de cargas, agrega el siguiente taint al nodo:

node-role.kubernetes.io/load-balancer:NoSchedule

Google Distributed Cloud agrega tolerancias para este taint a los Pods que se requieren para el balanceo de cargas.

En el siguiente ejemplo, se muestra un grupo de nodos de balanceo de cargas con dos nodos. El primer nodo tiene una dirección IP estándar nodePoolSpec.nodes.address (“1.2.3.4”) y una dirección IP de Kubernetes nodePoolSpec.nodes.k8sIP (10.0.0.32). Cuando especificas la dirección k8sIP opcional para un nodo, esta se dedica a controlar el tráfico de datos del nodo, como las solicitudes y las respuestas de la API de Kubernetes, kubelet y las cargas de trabajo. En este caso, la dirección IP estándar nodePoolSpec.nodes.address se usa para las conexiones SSH al nodo para las operaciones del clúster de administración. Si no especificas una dirección k8sIP, la dirección IP del nodo estándar controla todo el tráfico del nodo.

nodePoolSpec:
  nodes:
  - address: 1.2.3.4
    k8sIP: 10.0.0.32
  - address: 10.0.0.33

De forma predeterminada, todos los nodos del grupo de nodos del balanceador de cargas deben estar en la misma subred de capa 2 que las VIP del balanceador de cargas configuradas en la sección loadBalancer.addressPools del archivo de configuración. Sin embargo, si especificas una dirección IP de Kubernetes k8sIP para un nodo, solo esa dirección debe estar en la misma subred de capa 2 que los otros VIP del balanceador de cargas.

Si no se configura nodePoolSpec, los balanceadores de cargas agrupados se ejecutan en los nodos del plano de control. Te recomendamos que, cuando sea posible, ejecutes balanceadores de cargas en grupos de nodos separados.

Balanceo de cargas del plano de control

El balanceador de cargas del plano de control entrega la dirección IP virtual (VIP) del plano de control. Google Distributed Cloud ejecuta Keepalived y HAProxy como Pods estáticos de Kubernetes en los nodos del balanceador de cargas para anunciar la VIP del plano de control. Keepalived usa el protocolo de redundancia de router virtual (VRRP) en los nodos del balanceador de cargas para obtener alta disponibilidad.

Balanceo de cargas del plano de datos

El balanceador de cargas del plano de datos es para todos los servicios de Kubernetes del tipo LoadBalancer. Google Distributed Cloud usa MetalLB que se ejecuta en modo de capa 2 para el balanceo de cargas del plano de datos. El balanceo de cargas del plano de datos solo se puede configurar a través de Google Distributed Cloud. No modifiques el ConfigMap de MetalLB directamente. Puedes usar todas las funciones de MetalLB, incluido el uso compartido de direcciones IP en todos los servicios. Consulta la documentación de MetalLB para obtener información sobre las funciones.

MetalLB ejecuta un Pod de bocina en cada nodo con un daemonset, con memberlist para una alta disponibilidad. Hay un nodo de balanceador de cargas dedicado de MetalLB para cada servicio de Kubernetes, en lugar de uno para todo el clúster. De esta manera, el tráfico se distribuye entre los nodos del balanceador de cargas si hay varios servicios.

Los balanceadores de cargas del plano de datos pueden ejecutarse en los nodos del plano de control o en un subconjunto de nodos trabajadores. La creación de balanceadores de cargas de planos de datos en los nodos del plano de control aumenta el uso de los nodos del plano de control. Además, la dependencia de los nodos del plano de control también aumenta el riesgo de sobrecargar el plano de control y aumenta el perfil de riesgo de la información confidencial del plano de control, como las claves SSH.

Separación del balanceador de cargas

Antes de la versión 1.32, cuando configurabas el balanceo de cargas de capa 2 con MetalLB, los balanceadores de cargas del plano de control y los balanceadores de cargas del plano de datos se ejecutaban en los mismos nodos. Según tu configuración, todos los balanceadores de cargas se ejecutan en los nodos del plano de control o en el grupo de nodos del balanceador de cargas.

En el siguiente diagrama, se muestra la configuración predeterminada del balanceador de cargas agrupado con los balanceadores de cargas del plano de control y del plano de datos que se ejecutan en los nodos del plano de control o ambos que se ejecutan en el grupo de nodos del balanceador de cargas:

Configuración predeterminada del balanceador de cargas

Con los clústeres de la versión 1.32, puedes configurar los balanceadores de cargas del plano de control para que se ejecuten en los nodos del plano de control y los balanceadores de cargas del plano de datos para que se ejecuten en el grupo de nodos del balanceador de cargas. Puedes especificar esta separación de los balanceadores de cargas cuando crees un clúster nuevo de la versión 1.32 o puedes actualizar un clúster de la versión 1.32 para migrar los balanceadores de cargas del plano de datos de los nodos del plano de control al grupo de nodos del balanceador de cargas.

La configuración del clúster para los balanceadores de cargas separados debería ser similar al siguiente ejemplo:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.33
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    loadBalancer:
      mode: bundled
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  loadBalancer:
    mode: bundled
    ...
    nodePoolSpec:
      nodes:
      - address: 10.200.0.5
      - address: 10.200.0.6
      - address: 10.200.0.7
  clusterOperations:
  ...

Separa los balanceadores de cargas cuando crees un clúster

Si creas un clúster nuevo de la versión 1.32 o posterior, puedes configurar los balanceadores de cargas para que ejecuten los balanceadores de cargas del plano de control en los nodos del plano de control y los balanceadores de cargas del plano de datos en el grupo de nodos del balanceador de cargas.

En el siguiente diagrama, se muestran los balanceadores de cargas del plano de control y del plano de datos separados en diferentes nodos:

Balanceadores de cargas separados para el plano de control y el plano de datos

Para separar los balanceadores de cargas cuando crees un clúster, sigue estos pasos:

  1. En el archivo de configuración del clúster, especifica un grupo de nodos del balanceador de cargas con loadBalancer.nodePoolSpec, como se describe en la sección loadBalancer.nodePoolSpec de este documento.

  2. Agrega controlPlane.loadBalancer.mode al archivo de configuración del clúster y configura el valor de mode como bundled.

  3. Termina de configurar el clúster y ejecuta bmctl create cluster para crearlo.

Migra los balanceadores de cargas del plano de datos fuera del plano de control

Si tienes un clúster existente de la versión 1.32 o posterior en el que no se configuró controlPlane.loadBalancer.mode ni loadBalancer.nodePoolSpec, tanto el balanceador de cargas del plano de control como el balanceador de cargas del plano de datos se ejecutan en el grupo de nodos del plano de control. Puedes actualizar el clúster para migrar el balanceador de cargas del plano de datos a un grupo de nodos del balanceador de cargas.

En el siguiente diagrama, se muestran los balanceadores de cargas del plano de control y del plano de datos separados después de que el balanceador de cargas del plano de datos se migró de los nodos del plano de control:

El balanceador de cargas del plano de datos se migró al grupo de nodos del balanceador de cargas

Para migrar el balanceador de cargas del plano de datos a un grupo de nodos del balanceador de cargas cuando actualices un clúster, sigue estos pasos:

  1. En el archivo de configuración del clúster, especifica un grupo de nodos del balanceador de cargas con loadBalancer.nodePoolSpec, como se describe en la sección loadBalancer.nodePoolSpec de este documento.

  2. Agrega controlPlane.loadBalancer.mode al archivo de configuración del clúster y configura el valor de mode como bundled.

  3. Actualiza el clúster ejecutando el siguiente comando:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Reemplaza lo siguiente:

    • CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.

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

Preservación de la dirección IP de origen del cliente

El Service LoadBalancer que se creó con la solución de balanceo de cargas de capa 2 en paquetes usa la configuración Cluster predeterminada para la política de tráfico externo. Esta configuración, spec.externalTrafficPolicy: Cluster, enruta el tráfico externo a los extremos de todo el clúster, pero también oculta la dirección IP de origen del cliente.

Google Distributed Cloud admite dos métodos para conservar la dirección IP de origen del cliente:

  • Establece el modo de reenvío para el balanceo de cargas en Retorno directo del servidor (DSR). Para obtener más información sobre el modo de reenvío de DSR, incluidas las instrucciones para habilitarlo, consulta Configura el modo de reenvío del balanceo de cargas.

  • Establece la política de tráfico externo como local para el Service LoadBalancer y configura los Services y el Ingress relacionados según corresponda. En las siguientes secciones, se describe cómo configurar tu clúster para usar este método.

Servicios de LoadBalancer

Cuando uses externalTrafficPolicy: Local en los Services de LoadBalancer, configura los Pods de la aplicación para que se ejecuten exactamente en los nodos del balanceador de cargas. Agrega el siguiente nodeSelector a tus Pods de aplicación para realizar este cambio:

apiVersion: v1
kind: Pod
...
spec:
  nodeSelector:
      baremetal.cluster.gke.io/lbnode: "true"
...

Servicios de NodePort

Kubernetes realiza la traducción de direcciones de red (SNAT) de origen para los Services de NodePort. Para conservar las direcciones IP de origen del cliente, establece service.spec.externalTrafficPolicy como Local. Kubernetes ya no realizará SNAT de origen, pero debes asegurarte de que haya Pods que se ejecuten exactamente en la IP que seleccionaste.

Entrada

Si tus aplicaciones son servicios HTTP, puedes lograr visibilidad de la IP de cliente si configuras componentes de Ingress:

  1. Abre el Service de istio-ingress para editarlo:

    kubectl edit service -n gke-system istio-ingress

  2. Agrega externalTrafficPolicy: Local a spec, guarda y sal del editor.

    apiVersion: v1
kind: Service
...
spec:
...
  externalTrafficPolicy: Local

  3. Abre el Deployment de istio-ingress para editarlo:

    kubectl edit deployment -n gke-system istio-ingress

  4. Agrega el siguiente nodeSelector al Deployment, guarda y sal del editor.

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      nodeSelector:
          baremetal.cluster.gke.io/lbnode: "true"
...

Ahora, todos tus servicios detrás de Ingress ven un encabezado X-Forwarded-For con la IP de cliente, como el siguiente ejemplo:

X-Forwarded-For: 21.0.104.4