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) con air gap para configuraciones de red zonales y globales.

El balanceo de carga de GDC asegura una distribución eficiente del tráfico entre las cargas de trabajo del 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 Algoritmo de balanceo de carga.

Esta página está dirigida a los administradores de redes que pertenecen al grupo de administradores de la plataforma o a los desarrolladores que pertenecen al grupo de operadores de aplicaciones, que son los 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 con aislamiento físico.

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 balancea el tráfico entre 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 balanceadores de carga en GDC:

  • Usa la API del modelo de recursos de Kubernetes (KRM) de redes. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usa la CLI de gdcloud. Puedes usar esta API para crear balanceadores de carga globales o zonales.
  • Usa el servicio de Kubernetes directamente desde el clúster de Kubernetes. Este método solo crea balanceadores de carga zonales.

Componentes del balanceador de carga

Cuando usas la API KRM o la CLI gdcloud para configurar el balanceador de carga, usas un balanceador de carga de transferencia de nivel 4:

  • L4 significa que el protocolo es TCP o UDP.
  • Passthrough 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:

    • Consta de tres tuplas: CIDR, puerto y protocolo, para que el cliente pueda acceder.
    • Admite los 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 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. Puede hacer que varias reglas de reenvío apunten al mismo servicio de backend.

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

    • Un recurso de backend de zona por zona.
    • Un recurso de backend de clúster por clúster. No se puede mezclar con los back-ends del proyecto.

  • Backends: un objeto zonal que especifica los endpoints que actúan como backends de los servicios de backend creados. Los recursos de backend deben limitarse 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 VMs 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 el nombre indicado en el proyecto especificado. Puedes especificar como máximo un backend por zona y por clúster en un solo servicio de backend.

  • Comprobaciones del estado: especifica 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 de 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 más información sobre las comprobaciones del estado.

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

Balanceo de carga interno y externo

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 para asegurarte de que las solicitudes de un cliente se enruten de forma coherente al mismo backend.

Balanceadores de carga globales y de zona

Puedes crear balanceadores de carga globales o zonales. El ámbito de los balanceadores de carga globales abarca un universo de GDC. Cada universo de GDC puede constar de varias zonas de GDC organizadas en regiones interconectadas que comparten un plano de control. Por ejemplo, un universo formado por dos regiones con tres zonas cada una podría tener este 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 desastre 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 de zona en un universo de GDC, consulta la descripción general de multizona.

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

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

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

Direcciones IP virtuales de servicio

Los balanceadores de carga internos asignan direcciones VIP que son internas a la organización. No se puede acceder a estas direcciones VIP desde fuera de la organización, por lo que solo se pueden usar para exponer servicios a otras aplicaciones de la organización. Estas direcciones IP pueden superponerse entre organizaciones de la misma instancia.

Por otro lado, los ELBs asignan direcciones VIP a las que se puede acceder 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.

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 se ha diseñado para ofrecer un alto rendimiento y una gran resiliencia, lo que garantiza que el tráfico se distribuya de forma uniforme y predecible, al tiempo que se maximiza la localidad de los datos en los back-ends.

Cómo funciona Maglev: el mecanismo de hashing

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 cifrado con hash (5 tuplas): el algoritmo usa una 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 y 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 pool 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 entropía suficiente para asegurarse de que las diferentes conexiones se distribuyan de forma uniforme entre todos los back-ends disponibles.

Gestionar el estado y los fallos de los backends

Maglev se ha diseñado para ser resiliente y minimizar las interrupciones cuando cambia el conjunto de back-ends disponibles.

  • Fallo del backend: cuando un backend no supera las comprobaciones de estado, se elimina de la lista de destinos disponibles. Las conexiones que se dirigían al backend que ha fallado se terminan. Las nuevas conexiones se redistribuirán automáticamente entre los back-ends correctos restantes según el algoritmo de hashing. Es importante destacar que las conexiones a otros back-ends en buen estado no se ven afectadas ni se redirigen.
  • Recuperación del backend: cuando el backend en mal estado vuelve a estar en buen estado y se añade de nuevo al grupo, la naturaleza coherente del hash asegura que este backend se añada al grupo con las mínimas interrupciones, y el balanceador de carga 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, que de otro modo podría sobrecargar las cachés o el estado de las aplicaciones.

Comportamiento en despliegues multizona

Es fundamental entender 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 back-ends.

  • Distribución equitativa independientemente de la ubicación: Maglev trata todos los back-ends de su grupo como objetivos iguales. Si tienes backends distribuidos en diferentes zonas, el tráfico se distribuirá de forma uniforme entre todos ellos. El algoritmo no prefiere los back-ends de una zona "local" ni tiene en cuenta la latencia de red entre zonas.
  • Asegurar la capacidad de la interconexión multizona: como los back-ends pueden abarcar varias zonas, es fundamental que el administrador de la 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 back-ends.

Limitaciones

  • El recurso BackendService no debe configurarse con un recurso HealthCheck para cargas de trabajo de pods. El 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 dirigirse a cargas de trabajo mixtas que incluyan pods y VMs. Por lo tanto, no se permiten back-ends mixtos que incluyan pods y VMs en un recurso BackendService.

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

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

Limitaciones de los clústeres estándar

Se aplican las siguientes limitaciones al balanceo de carga de los clústeres estándar:

Á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 que use un recurso Service type=LoadBalancer debe dirigirse a los endpoints de backend que sean pods ubicados exclusivamente en ese clúster estándar. No se admite una sola definición de Load Balancer 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 compartidos.

  • La CLI de gdcloud y la API del modelo de recursos de redes de Kubernetes no se admiten en clústeres estándar. Usa el recurso estándar de Kubernetes Service con type=LoadBalancer y las anotaciones asociadas para gestionar el equilibrio 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 gdcloud CLI o la API Networking Kubernetes Resource Model, 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 clústeres estándar son recursos zonales cuyo ámbito es una sola zona. El balanceo de carga global no se admite en los balanceadores de carga de clúster 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