Administra balanceadores de cargas

En esta página de descripción general, se explica cómo 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 redes 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 del 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

Existen tres formas de configurar los balanceadores de cargas en GDC:

  • Usa la API del modelo de recursos de Kubernetes (KRM) de Networking. Puedes usar esta API para crear balanceadores de cargas globales o zonales.
  • Usa la CLI de gcloud. 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.
  • El traspaso 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 interno 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 por 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 los backends a los que puede hacer referencia un solo servicio de backend:

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

  • Backends: Es 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 limitado a una zona. Selecciona extremos con etiquetas. Delimita 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 específico, en la VPC específica de una zona. Las etiquetas se aplican a las cargas de trabajo de VM y Pod en varios clústeres. Cuando un servicio de backend usa un backend del 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 y 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 se encuentra 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 que se mencionaron 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 redes:

  • 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 y asegúrate de que las solicitudes de un cliente se enruten de forma 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 interconectadas y que 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 la 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 del modelo de recursos de Kubernetes (KRM) de Networking. Usa la versión de API networking.gdc.goog para crear recursos zonales.
  • Usa la CLI de gcloud. Usa la marca --zone cuando uses los comandos de la CLI de gdcloud para especificar en qué zonas se crearán los balanceadores de cargas.
  • Usa Service de Kubernetes directamente desde el clúster de Kubernetes.

Direcciones IP virtuales del servicio

Los ILB 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 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 externamente desde fuera de la organización. Por este motivo, las direcciones VIP de ELB deben ser únicas entre todas las organizaciones. Por lo general, la organización tiene menos direcciones VIP de ELB disponibles para su uso.

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 capacidad de recuperación, lo que garantiza que el tráfico se distribuya de manera uniforme y predecible, a la vez que maximiza la localidad de los datos en los servidores de backend.

Cómo funciona Maglev: el mecanismo de hashing

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

  • Entrada de hash (5 tuplas): El algoritmo usa una tupla estándar de 5 elementos 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 (p.ej., TCP y UDP)
  • Decisión de reenvío: El resultado de este hash asigna de forma determinística 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: Al usar los cinco elementos de la tupla, Maglev genera suficiente entropía para garantizar que las diferentes conexiones se distribuyan de manera uniforme en todos los servidores de backend disponibles.

Cómo controlar el estado y las fallas del backend

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

  • Falla del backend: Cuando un backend falla en sus verificaciones de estado, se quita de la lista de destinos disponibles. Se finalizan las conexiones que antes se enrutaban al backend con errores. Las conexiones nuevas se redistribuirán automáticamente entre los backends en buen estado restantes según el algoritmo de hash. Es importante destacar que las conexiones a otros backends en buen estado no se ven afectadas ni se redireccionan.
  • Recuperación del backend: Cuando el backend en mal estado vuelve a estar en buen estado y se agrega de nuevo al grupo, la naturaleza coherente del hash garantiza que este backend se agregue al grupo con la menor interrupción posible, y el LB volverá a balancear 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, que, de lo contrario, podría sobrecargar las memorias caché o el estado de la aplicación.

Comportamiento en implementaciones en varias zonas

Es fundamental comprender 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 objetivos iguales. Si tienes backends distribuidos en diferentes zonas, el tráfico se distribuirá de manera uniforme entre todos ellos. El algoritmo no prefiere los backends en una zona "local" ni tiene en cuenta la latencia de red entre las zonas.
  • Asegúrate de que la capacidad de MultiZone Interconnect sea suficiente:Como los backends pueden abarcar varias zonas, es fundamental que el administrador de red se asegure de que MultiZone Interconnect 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 pods. El HealthCheckName en la especificación de BackendService es opcional y se debe omitir cuando se configura un balanceador de cargas con Pods.

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

  • Un recurso personalizado del balanceador de cargas global, como ForwardingRuleExternal, ForwardingRuleInternal, BackendService o HealthCheck, no debe tener el mismo nombre que estos recursos personalizados del 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ándares

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 que usa un recurso Service type=LoadBalancer debe segmentar los extremos de backend que son pods ubicados exclusivamente dentro de ese único clúster estándar. No se admite una sola definición de Load Balancer 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 gcloud 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 de los clústeres estándar.

  • Los balanceadores de cargas con alcance para el proyecto ignorarán los clústeres estándar. Si se crea una configuración del balanceador de cargas con alcance para el proyecto con el comando de CLI de gcloud o la API del modelo de recursos de Kubernetes de redes, se ignorarán todos los clústeres estándar del proyecto.

  • No se admite el balanceo de cargas global. Los recursos de ILB y ELB aprovisionados para los 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 del ILB entre zonas. No se admite la conectividad desde un pod de clúster estándar a un ILB global o a un ILB zonal en una zona diferente.

¿Qué sigue?