Administra balanceadores de cargas

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

El balanceo de cargas para GDC garantiza una distribución eficiente del tráfico en 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 detalles, consulta Algoritmo de balanceo de cargas.

Esta página está destinada a los administradores de red dentro del grupo de administradores de la plataforma o a los desarrolladores dentro del grupo de operadores de aplicaciones, que son responsables de administrar el tráfico de red de su organización. Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

Arquitectura de balanceo de cargas

GDC proporciona balanceadores de cargas que permiten que las aplicaciones expongan servicios entre sí. Los balanceadores de cargas asignan una dirección IP virtual (VIP) estable que balancea el tráfico en un conjunto de cargas de trabajo de backend. Los balanceadores de cargas en GDC realizan el balanceo de cargas 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 cargas se configuran a nivel de proyecto.

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

  • Cargas de trabajo que se ejecutan en VMs
  • Cargas de trabajo alojadas en contenedores dentro del clúster de Kubernetes

Hay tres formas de configurar balanceadores de cargas en GDC:

  • Usa la API de Networking Kubernetes Resource Model (KRM). Puedes usar esta API para crear balanceadores de cargas globales o zonales.
  • Usa la CLI de gdcloud. Puedes usar esta API para crear balanceadores de cargas globales o zonales.
  • Usa el servicio de Kubernetes directamente desde el clúster de Kubernetes. Este método solo crea balanceadores de cargas zonales.

Componentes del balanceador de cargas

Cuando usas la API de KRM o la CLI de gdcloud para configurar el balanceador de cargas, usas un balanceador de cargas de transferencia de L4:

  • L4 significa que el protocolo es TCP o UDP.
  • Transferencia significa que no hay un proxy entre la carga de trabajo y el cliente.

El balanceador de cargas 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:

    • Consta de tres tuplas, CIDR, puerto y protocolo, para que el cliente acceda.
    • Admite protocolos TCP y UDP.
    • Ofrece 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 de las cargas de trabajo que tienen definido el valor EgressNAT.
    • Las reglas de reenvío se conectan a un servicio de backend. Puedes hacer que varias reglas de reenvío apunten al mismo servicio de backend.

  • Servicios de backend: Son el centro de balanceo de cargas que vincula las reglas de reenvío, las verificaciones de 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 cargas reenvía el tráfico. Existen limitaciones sobre a qué backends 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 Esto no se puede mezclar con los backends del proyecto.

  • Backends: Un objeto zonal que especifica los extremos que actúan como backends para los servicios de backend creados. Los recursos de backend deben tener un alcance zonal. Selecciona extremos con etiquetas. Define el alcance del selector en 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 específico, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de VM y de pod en varios clústeres. Cuando un servicio de backend usa un backend de proyecto, no puedes hacer referencia a otro backend para 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 en el proyecto especificado. Puedes especificar, como máximo, un backend por zona por clúster en un solo servicio de backend.

  • Verificaciones de estado: Especifican los sondeos para determinar si un extremo de carga de trabajo determinado en el backend está en buen estado. El extremo en mal estado se quita del balanceador de cargas hasta que vuelve a estar en buen estado. Las verificaciones de estado solo se aplican a las cargas de trabajo de VM. Las cargas de trabajo de pod pueden usar el mecanismo de sondeo integrado de Kubernetes para determinar si un extremo específico está en buen estado. Consulta las verificaciones de estado para obtener más información.

Cuando usas el servicio de Kubernetes directamente desde el clúster de usuario de Kubernetes, usas el objeto Service en lugar de los componentes enumerados anteriormente. Solo puedes segmentar cargas de trabajo en el clúster en el que se crea el objeto Service.

Balanceo de cargas interno y externo

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

  • Balanceador de cargas interno (ILB): Te permite exponer un servicio a otros clústeres dentro de la organización.
  • Balanceador de cargas externo (ELB): Asigna una dirección IP virtual (VIP) desde un rango 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 ELB para garantizar que las solicitudes de un cliente se enruten de manera coherente al mismo backend.

Balanceadores de cargas globales y zonales

Puedes crear balanceadores de cargas globales o zonales. El alcance de los balanceadores de cargas globales abarca 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 verse de la siguiente manera: us-virginia1-a, us-virginia1-b, us-virginia1-c y eu-ams1-a, eu-ams1-b, eu-ams1-c.

El alcance de los balanceadores de cargas zonales se limita a las zonas especificadas en el momento de la creación. Cada zona es un dominio de desastre independiente. Una zona administra 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 en un universo de GDC, consulta Descripción general de varias zonas.

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

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

  • Usa la API de Networking Kubernetes Resource Model (KRM). Usa la versión de la API networking.gdc.goog para crear recursos zonales.
  • Usa la CLI de gdcloud. Usa la marca --zone cuando uses los comandos de la CLI de gdcloud para especificar para qué zonas crear balanceadores de cargas.
  • Usa el Service de Kubernetes directamente desde el clúster de Kubernetes.

Direcciones IP virtuales del servicio

Los ILB asignan direcciones VIP que son internas solo 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 dentro de una organización. Estas direcciones IP pueden superponerse entre organizaciones en la misma instancia.

Por otro lado, los ELB asignan direcciones VIP a las que se puede acceder de forma externa desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas entre todas las organizaciones. Por lo general, hay menos direcciones VIP de ELB disponibles para que las use la organización.

Algoritmo de balanceo de cargas

Nuestro balanceador de cargas 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 manera uniforme y predecible, al tiempo que maximiza la localidad de los datos en los backends.

Cómo funciona Maglev: el mecanismo de hash

Maglev toma decisiones de reenvío mediante el hash de las propiedades de cada paquete entrante. Esto garantiza que todos los paquetes de una conexión determinada se envíen de manera coherente al mismo backend para maximizar la localidad de los datos.

  • Entrada de hash (tupla de 5 elementos): El algoritmo usa una tupla estándar de 5 elementos de l 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 (p.ej., TCP, 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 cargas. Durante la vida útil de esa conexión, todos sus paquetes se reenviarán al mismo backend.
  • Entropía para el balanceo: Mediante el uso de los cinco elementos de la tupla, Maglev genera entropía suficiente para garantizar que las diferentes conexiones se distribuyan de manera uniforme en todos los backends disponibles.

Cómo controlar el estado y las fallas del backend

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

  • Falla del backend: Cuando un backend falla sus verificaciones de estado, se quita de la lista de destinos disponibles. Las conexiones que se enrutaron anteriormente al backend con fallas se finalizan. Las conexiones nuevas se redistribuirán automáticamente entre los backends restantes en buen estado según el 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 del backend: Cuando el backend en mal estado vuelve a estar en buen estado y se vuelve a agregar al grupo, la naturaleza coherente del hash garantiza que este backend se agregue al grupo con una interrupción mínima, y el LB volverá a balancear la carga tomando este backend recién en buen estado. Este enfoque de "interrupción mínima" evita una reorganización masiva de todas las conexiones existentes, lo que, de lo contrario, podría sobrecargar los estados o las memorias caché de las aplicaciones.

Comportamiento en implementaciones de varias zonas

Es fundamental comprender que Maglev no tiene en cuenta la topología. Distribuye el tráfico en función del resultado matemático del hash, sin considerar 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 manera uniforme entre todos ellos. El algoritmo no prefiere backends en una zona "local" ni tiene en cuenta la latencia de red entre zonas.
  • Garantiza la capacidad de interconexión de varias zonas:Como los backends pueden abarcar varias zonas, es esencial que el administrador de red se asegure de que la interconexión de varias zonas tenga suficiente capacidad de red para controlar el tráfico entre zonas entre los nodos del balanceador de cargas y los backends.

Limitaciones

  • El recurso BackendService no debe configurarse con un recurso HealthCheck para las cargas de trabajo de pod. HealthCheckName en la especificación BackendService es opcional y se debe omitir cuando se configura un balanceador de cargas con pods.

  • Una configuración de balanceador de cargas no puede segmentar cargas de trabajo mixtas que involucren pods y VMs. Por lo tanto, no se permiten backends mixtos que involucren pods y VMs en un recurso BackendService.

  • Un recurso personalizado de balanceador de cargas global, como ForwardingRuleExternal, ForwardingRuleInternal, BackendService o HealthCheck, no debe tener el mismo nombre que estos recursos personalizados de balanceador de cargas 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 incluyen en este límite para todas las zonas.

Limitaciones para clústeres estándar

Las siguientes limitaciones se aplican al balanceo de cargas para clústeres estándar:

Alcance de un solo clúster

  • Alcance de un solo clúster: Cualquier balanceador de cargas (ILB o ELB) aprovisionado para un clúster estándar con un recurso Service type=LoadBalancer debe segmentar extremos de backend que sean pods ubicados exclusivamente dentro de ese único clúster estándar. No se admite una sola definición de balanceador de cargas que intente distribuir el tráfico a 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 Networking Kubernetes Resource Model no son compatibles con los clústeres estándar. Usa el recurso Service estándar de Kubernetes con type=LoadBalancer y las anotaciones asociadas para administrar el balanceo de cargas para clústeres estándar.

  • Los balanceadores de cargas con alcance de proyecto ignorarán los clústeres estándar. Si se crea una configuración de balanceador de cargas con alcance de proyecto con el comando gdcloud CLI o la API de Networking Kubernetes Resource Model, se ignorarán todos los clústeres estándar del proyecto.

  • No se admite el balanceo de cargas global. Los recursos ILB y ELB aprovisionados para clústeres estándar son recursos zonales con alcance en una sola zona. El balanceo de cargas global no es compatible con los balanceadores de cargas 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 en una zona diferente.

¿Qué sigue?