Gestionar balanceadores de carga

En esta página de descripción general se explica cómo configurar balanceadores de carga internos y externos en Google Distributed Cloud (GDC) air-gapped para configuraciones de red zonales y globales.

El balanceo de carga de GDC garantiza una distribución eficiente del tráfico entre las cargas de trabajo de backend, lo que mejora la disponibilidad y el rendimiento de las aplicaciones. El algoritmo que se usa para distribuir el tráfico es Maglev. Para obtener más información, consulta el artículo Algoritmo de balanceo de carga.

Esta página está dirigida a los administradores de red que forman parte del grupo de administradores de la plataforma o a los desarrolladores que forman parte del grupo de operadores de aplicaciones y que son responsables de gestionar el tráfico de red de su organización. Para obtener más información, consulta el artículo Audiencias para la documentación de GDC air-gapped .

Arquitectura de balanceo de carga

GDC proporciona balanceadores de carga que permiten que las aplicaciones expongan servicios entre sí. Los balanceadores de carga asignan una dirección IP virtual (VIP) estable que equilibra el tráfico en un conjunto de cargas de trabajo de backend. Los balanceadores de carga de GDC realizan el balanceo de carga de capa cuatro (L4), lo que significa que asignan un conjunto de puertos TCP o UDP de frontend configurados a los puertos de backend correspondientes. Los balanceadores de carga se configuran a nivel de proyecto.

Los balanceadores de carga se configuran para los siguientes tipos de cargas de trabajo:

  • Cargas de trabajo que se ejecutan en máquinas virtuales.
  • Cargas de trabajo en contenedores dentro del clúster de Kubernetes.

Hay tres formas de configurar los balanceadores de carga en GDC:

  • Usar la API de modelo de recursos de Kubernetes (KRM) de redes. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usar la CLI de gdcloud. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usar el servicio de Kubernetes directamente desde el clúster de Kubernetes. Con este método solo se crean balanceadores de carga zonales.

Componentes del balanceador de carga

Cuando usas la API de KRM o la CLI de gdcloud para configurar el balanceador de carga, utilizas un balanceador de carga de paso directo de L4:

  • L4 significa que el protocolo es TCP o UDP.
  • Paso directo significa que no hay ningún proxy entre la carga de trabajo y el cliente.

El balanceador de carga consta de los siguientes componentes configurables:

  • Reglas de reenvío: especifican qué tráfico se reenvía y a qué servicio de backend. Las reglas de reenvío tienen las siguientes especificaciones:

    • Constan de tres tuplas (CIDR, puerto y protocolo) para que el cliente pueda acceder.
    • Admiten los protocolos TCP y UDP.
    • Ofrecen reglas de reenvío internas y externas. Los clientes pueden acceder a las reglas de reenvío internas desde la nube privada virtual (VPC). Los clientes pueden acceder a las reglas de reenvío externas desde fuera de la plataforma de GDC o desde dentro mediante cargas de trabajo que tengan definido el valor EgressNAT.
    • Las reglas de reenvío se conectan a un servicio de backend. Puedes dirigir varias reglas de reenvío al mismo servicio de backend.

  • Servicios de backend: son el centro de balanceo de carga que vincula las reglas de reenvío, las comprobaciones del estado y los backends. Un servicio de backend hace referencia a un objeto de backend que identifica las cargas de trabajo a las que el balanceador de carga reenvía el tráfico. Hay limitaciones en cuanto a los backends a los que puede hacer referencia un solo servicio de backend:

    • Un recurso de backend zonal por zona.
    • Un recurso de backend de clúster por clúster. No se puede combinar con los backends del proyecto.

  • Backends: objeto zonal que especifica los endpoints que sirven como backends para los servicios de backend creados. Los recursos de backend deben estar limitados a una zona. Selecciona endpoints mediante etiquetas. Limita el selector a un proyecto o clúster:

    • Un backend de proyecto es un backend que no tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del proyecto concreto, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de máquinas virtuales y pods en varios clústeres. Cuando un servicio de backend usa un backend de proyecto, no puedes hacer referencia a otro backend de esa zona en ese servicio de backend.

    • Un backend de clúster es un backend que tiene especificado el campo ClusterName. En este caso, las etiquetas especificadas se aplican a todas las cargas de trabajo del clúster con nombre del proyecto especificado. Puedes especificar, como máximo, un backend por zona y por clúster en un solo servicio de backend.

  • Comprobaciones del estado: especifican las sondas para determinar si un endpoint de carga de trabajo determinado del backend está en buen estado. El endpoint en mal estado se retira del balanceador de carga hasta que vuelve a estar en buen estado. Las comprobaciones del estado solo se aplican a las cargas de trabajo de máquinas virtuales. Las cargas de trabajo de pods pueden usar el mecanismo de comprobación de Kubernetes integrado para determinar si un endpoint específico está en buen estado. Consulta el artículo Comprobaciones del estado para obtener más información.

Cuando usas el servicio de Kubernetes directamente desde el clúster de usuario de Kubernetes, utilizas el objeto Service en lugar de los componentes que se han indicado anteriormente. Solo puedes orientar las cargas de trabajo en el clúster donde se crea el objeto Service.

Balanceo de carga externo e interno

Las aplicaciones de GDC tienen acceso a los siguientes tipos de servicios de red:

  • Balanceador de carga interno (ILB): te permite exponer un servicio a otros clústeres de la organización.
  • Balanceador de carga externo (ELB): asigna una dirección IP virtual (VIP) de un intervalo que se puede enrutar desde cargas de trabajo externas y expone servicios fuera de la organización de GDC, como otras organizaciones dentro o fuera de la instancia de GDC. Usa la afinidad de sesión para los ELBs a fin de asegurarte de que las solicitudes de un cliente se enruten de forma coherente al mismo backend.

Balanceadores de carga globales y zonales

Puedes crear balanceadores de carga globales o zonales. El ámbito de los balanceadores de carga globales abarca todo un universo de GDC. Cada universo de GDC puede constar de varias zonas de GDC organizadas en regiones que están interconectadas y comparten un plano de control. Por ejemplo, un universo que consta de dos regiones con tres zonas cada una podría tener el siguiente aspecto: us-virginia1-a, us-virginia1-b, us-virginia1-c y eu-ams1-a, eu-ams1-b, eu-ams1-c.

El ámbito de los balanceadores de carga zonales se limita a las zonas especificadas en el momento de la creación. Cada zona es un dominio de recuperación ante desastres independiente. Una zona gestiona la infraestructura, los servicios, las APIs y las herramientas que usan un plano de control local.

Para obtener más información sobre los recursos globales y zonales de un universo de GDC, consulta el artículo Descripción general de varias zonas.

Puedes crear balanceadores de carga globales con los siguientes métodos:

Puedes crear balanceadores de carga zonales con los siguientes métodos:

  • Usar la API de modelo de recursos de Kubernetes (KRM) de redes. Usa la versión de la API networking.gdc.goog para crear recursos zonales.
  • Usar la CLI de gdcloud. Usa la marca --zone al usar los comandos de la CLI gdcloud para especificar las zonas en las que se deben crear los balanceadores de carga.
  • Usar el objeto Service de Kubernetes directamente desde el clúster de Kubernetes.

Direcciones IP virtuales de servicio

Los ILBs asignan direcciones VIP que son solo internas para la organización. No se puede acceder a estas direcciones VIP desde fuera de la organización. Por lo tanto, solo puedes usarlas para exponer servicios a otras aplicaciones de una organización. Estas direcciones IP pueden solaparse entre organizaciones de la misma instancia.

Por otro lado, los ELBs asignan direcciones VIP a las que se puede acceder externamente desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas en todas las organizaciones. Normalmente, la organización tiene menos direcciones VIP de ELB disponibles para usar.

Algoritmo de balanceo de carga

Nuestro balanceador de carga usa Maglev, un algoritmo de hash coherente, para distribuir el tráfico entrante a los destinos de backend. Este algoritmo está diseñado para ofrecer un alto rendimiento y resiliencia, lo que garantiza que el tráfico se distribuya de forma uniforme y predecible, a la vez que se maximiza la localidad de los datos en los backends.

Cómo funciona Maglev: el mecanismo de hash

Maglev toma decisiones de reenvío aplicando un hash a las propiedades de cada paquete entrante. De esta forma, todos los paquetes de una conexión determinada se envían de forma coherente al mismo backend para maximizar la localidad de los datos.

  • Entrada de hash (5 tuplas): el algoritmo usa 5 tuplas estándar del encabezado del paquete para generar un hash. Esta tupla consta de lo siguiente:
    1. Dirección IP de origen
    2. Puerto de origen
    3. Dirección IP de destino
    4. Puerto de destino
    5. Protocolo (por ejemplo, TCP o UDP)
  • Decisión de reenvío: el resultado de este hash asigna de forma determinista la conexión a uno de los backends en buen estado del grupo de balanceo de carga. Durante la vida útil de esa conexión, todos sus paquetes se reenviarán al mismo backend.
  • Entropía para el balanceo: al usar los cinco elementos de la tupla, Maglev genera la entropía suficiente para garantizar que las diferentes conexiones se distribuyan de forma uniforme entre todos los backends disponibles.

Gestionar el estado y los fallos de los backends

Maglev está diseñado para ser resiliente y minimizar las interrupciones cuando cambia el conjunto de backends disponibles.

  • Fallo de backend: cuando un backend no supera las comprobaciones del estado, se retira de la lista de destinos disponibles. Las conexiones que se habían enrutado anteriormente al backend con fallos se terminan. Las nuevas conexiones se redistribuirán automáticamente entre los backends en buen estado restantes en función del algoritmo de hash. Es importante destacar que las conexiones a otros backends en buen estado no se ven afectadas ni se vuelven a enrutar.
  • Recuperación de backend: cuando el backend en mal estado vuelve a estar en buen estado y se vuelve a añadir al grupo, la naturaleza coherente del hash garantiza que este backend se añada al grupo con la mínima interrupción, y el LB volverá a equilibrar la carga teniendo en cuenta este backend que ahora está en buen estado. Este enfoque de "interrupción mínima" evita una reorganización masiva de todas las conexiones existentes, lo que podría sobrecargar las cachés o el estado de las aplicaciones.

Comportamiento en despliegues multizona

Es fundamental tener en cuenta que Maglev no tiene en cuenta la topología. Distribuye el tráfico basándose únicamente en el resultado matemático del hash, sin tener en cuenta la ubicación física ni la ruta de red a los backends.

  • Distribución equitativa independientemente de la ubicación: Maglev trata todos los backends de su grupo como destinos iguales. Si tienes backends distribuidos en diferentes zonas, el tráfico se distribuirá de forma uniforme entre todos ellos. El algoritmo no da preferencia a los backends de una zona "local" ni tiene en cuenta la latencia de red entre zonas.
  • Asegurarse de que la interconexión multizona tenga capacidad:como los backends pueden abarcar varias zonas, es fundamental que el administrador de red se asegure de que la interconexión multizona tenga suficiente capacidad de red para gestionar el tráfico entre zonas entre los nodos del balanceador de carga y los backends.

Limitaciones

  • El recurso BackendService no debe configurarse con un recurso HealthCheck para las cargas de trabajo de pods. El campo HealthCheckName de la especificación BackendService es opcional y debe omitirse al configurar un balanceador de carga con pods.

  • Una configuración de balanceador de carga no puede orientar cargas de trabajo mixtas que incluyan pods y máquinas virtuales. Por lo tanto, no se permiten backends mixtos que incluyan pods y máquinas virtuales en un recurso BackendService.

  • Un recurso personalizado de balanceador de carga mundial, como ForwardingRuleExternal, ForwardingRuleInternal, BackendService o HealthCheck, no debe tener el mismo nombre que estos recursos personalizados de balanceador de carga zonal.

  • Una organización puede definir un máximo de 500 reglas de reenvío por zona en la que reside. Las reglas de reenvío globales se tienen en cuenta en este límite para todas las zonas.

Limitaciones de los clústeres estándar

El balanceo de carga de los clústeres estándar está sujeto a las siguientes limitaciones:

Ámbito de un solo clúster

  • Ámbito de un solo clúster: cualquier balanceador de carga (ILB o ELB) aprovisionado para un clúster estándar mediante un recurso Service type=LoadBalancer debe orientar los endpoints de backend que sean pods ubicados exclusivamente dentro de ese clúster estándar. No se admite una sola definición de balanceador de carga que intente distribuir el tráfico a los pods que se ejecutan en varios clústeres estándar diferentes o en una combinación de clústeres estándar y clústeres compartidos.

  • La CLI de gdcloud y la API de modelo de recursos de Kubernetes de redes no se admiten en los clústeres estándar. Usa el recurso Service estándar de Kubernetes con type=LoadBalancer y las anotaciones asociadas para gestionar el balanceo de carga de los clústeres estándar.

  • Los balanceadores de carga con ámbito de proyecto ignorarán los clústeres estándar. Si se crea una configuración de balanceador de carga con ámbito de proyecto mediante el comando CLI gdcloud o la API de modelo de recursos de Kubernetes de redes, se ignorarán los clústeres estándar del proyecto.

  • No se admite el balanceo de carga global. Los recursos de ILB y ELB aprovisionados para los clústeres estándar son recursos zonales limitados a una sola zona. El balanceo de carga global no se admite en los balanceadores de carga de clústeres estándar.

  • No se admite la conectividad ILB entre zonas. No se admite la conectividad de un pod de clúster estándar a un ILB global o a un ILB zonal de otra zona.

Siguientes pasos