Versión 1.6. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, y ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos en equipos físicos. Para obtener más detalles, consulta las notas de la versión 1.6. Esta no es la versión más reciente. Para obtener una lista completa de cada versión secundaria y de parche en orden cronológico, consulta las notas de la versión combinadas.

Versiones disponibles:  1.7  |  1.6

Configurar el balanceo de cargas en conjunto

En esta página, se describe cómo configurar el balanceo de cargas en paquetes para clústeres de Anthos alojados en equipos físicos. Clústeres de Anthos alojados en equipos físicos implementa balanceadores de cargas L4 que 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 clústeres de Anthos alojados en equipos físicos.

Configurar el balanceo de cargas en conjunto

Requisitos

  • Todos los nodos del balanceador de cargas deben estar en la misma subred L2.
  • 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 los 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 utilizará 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 L2 que los nodos que ejecutan balanceadores de cargas. No incluyas esta dirección en la sección [address pools](#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 de clúster de administrador. Esta dirección debe aparecer en la sección de grupos de direcciones de la configuración.

loadBalancer.addressPools

En esta sección de la configuración, se incluyen uno o más grupos de direcciones especificados en este formato:

- name: pool-name
  avoidBuggyIPs: boolean
  manualAssign: boolean
  addresses:
  - ip-range
  - ip-range
  • name: El nombre del grupo de direcciones, pool-name, para tus propios fines organizativos.
  • avoidBuggIPs: (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.
  • manualAsignar: (opcional). Es 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 falso.
  • 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).

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. En el siguiente ejemplo, se muestra un grupo de nodos con dos nodos. El primer nodo, 1.2.3.4, usa el campo k8sIP para especificar la dirección IP del nodo en el clúster. La dirección 1.2.3.4 solo se usa para el acceso SSH.

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

Todos los nodos del grupo de nodos del balanceador de cargas deben estar en la misma subred L2 que las VIP del balanceador de cargas configuradas en la sección loadBalancer.addressPools del archivo de configuración. Si un nodo tiene un k8sIP configurado, solo esa dirección debe estar en la misma subred L2 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. Clústeres de Anthos alojados en equipos físicos ejecutan Keepalived y HAProxy en los contenedores de Docker como un servicio de sistema 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.

Accede a los registros de Keepalived y HAProxy en los nodos del balanceador de cargas con lo siguiente:

journalctl -u docker.keepalived.service
journalctl -u docker.haproxy.service

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. Clústeres de Anthos alojados en equipos físicos usa MetalLB que se ejecuta en modo L2 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 clústeres de Anthos alojados en equipos físicos. No modifiques el ConfigMap de MeceBN directamente. Puedes usar todas las características 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 altavoz en cada nodo con un daemonset, con memberlist para alta disponibilidad. Hay un nodo de balanceador de cargas dedicado de MetalBB 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. Sin embargo, 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.