Descripción general del balanceador de cargas de aplicaciones

El balanceador de cargas de aplicaciones es un balanceador de cargas de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios. El balanceador de cargas de aplicaciones distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de plataformas de Google Cloud, como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage y Cloud Run, así como backends externos conectados a través de Internet o mediante la conectividad híbrida.

Los balanceadores de cargas de aplicaciones están disponibles en los siguientes modos de implementación:

  • Balanceador de cargas de aplicaciones externo: balancea las cargas del tráfico proveniente de los clientes en Internet. Para obtener más detalles sobre la arquitectura, consulta Arquitectura del balanceador de cargas de aplicaciones externo.

    Modo de implementación Nivel de servicio de red Esquema de balanceo de cargas Dirección IP Puertos de frontend
    Global externo Nivel Premium EXTERNAL_MANAGED IPv4
    IPv6

    Puede hacer referencia a un solo puerto de 1 a 65535.

    Regional y externo Nivel Premium o Estándar EXTERNAL_MANAGED IPv4
    Clásico

    Global en el nivel Premium

    Regional en el nivel Estándar

    EXTERNAL IPv4
    IPv6 (requiere el nivel Premium)
  • Balanceador de cargas de aplicaciones interno: balancea las cargas del tráfico dentro de tu red de VPC o las redes conectadas a tu red de VPC. Para obtener más detalles sobre la arquitectura, consulta Arquitectura del balanceador de cargas de aplicaciones interno.

    Modo de implementación Nivel de servicio de red Esquema de balanceo de cargas Dirección IP Puertos de frontend
    Regional interno Nivel Premium INTERNAL_MANAGED IPv4

    Puede hacer referencia a un solo puerto de 1 a 65535.

    Interna entre regiones*

    Nivel Premium INTERNAL_MANAGED IPv4

El esquema de balanceo de cargas es un atributo de la regla de reenvío y el servicio de backend de un balanceador de cargas y, luego, indica si el balanceador de cargas se puede usar para tráfico interno o externo. El término *_MANAGED en el esquema de balanceo de cargas indica que el balanceador de cargas se implementa como un servicio administrado en Google Front End (GFE) o en el código abierto Proxy de Envoy. En un esquema de balanceo de cargas que es *_MANAGED, las solicitudes se enrutan al GFE o al proxy de Envoy.

* El balanceador de cargas usa recursos globales y se puede implementar en una o varias regiones de Google Cloud que elijas.

Balanceador de cargas de aplicaciones externo

Los balanceadores de cargas de aplicaciones externos se implementan mediante Google Front End (GFE) o proxies administrados. Los balanceadores de cargas de aplicaciones externos globales y los clásicos usan GFE distribuidos globalmente y operan juntos mediante el uso del plano de control y la red global de Google Los GFEs ofrecen balanceo de cargas multirregional en el nivel Premium, lo que dirige el tráfico al backend más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de sus usuarios. Los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones externos regionales usan el software de proxy de Envoy de código abierto para habilitar las funciones avanzadas de administración del tráfico.

Estos balanceadores de cargas se pueden implementar en uno de los siguientes modos: global, regional o clásico.

Los balanceadores de cargas de aplicaciones externos admiten las siguientes funciones:

En el siguiente diagrama, se muestra una arquitectura de balanceador de cargas de aplicaciones externo de ejemplo.

Arquitectura del balanceador de cargas de aplicaciones externo.
Arquitectura del balanceador de cargas de aplicaciones externo.

Para obtener una descripción general completa, consulta Descripción general de la arquitectura para balanceadores de cargas de aplicaciones externos.

Balanceador de cargas de aplicaciones interno

Los balanceadores de cargas de aplicaciones internos son balanceadores de cargas regionales de capa 7 basados en proxy de Envoy que te permiten ejecutar y escalar el tráfico de tu aplicación HTTP detrás de una dirección IP interna. Los balanceadores de cargas de aplicaciones internos admiten backends en una región, pero se pueden configurar para que los clientes de cualquier región de Google Cloud puedan acceder de forma global.

El balanceador de cargas distribuye el tráfico a los backends alojados en Google Cloud, en entornos locales o en otros entornos de nube. Los balanceadores de cargas de aplicaciones internos también admiten las siguientes funciones:

  • Políticas de localidad. Dentro de un grupo de instancias de backend o de un grupo de extremos de red, puedes configurar cómo se distribuyen las solicitudes a instancias o extremos miembros. Para obtener detalles, consulta Administración del tráfico.
  • Acceso global. Cuando el acceso global está habilitado, los clientes de cualquier región pueden acceder al balanceador de cargas. Para obtener más información, consulta Habilita el acceso global.
  • Acceso desde redes conectadas. Puedes hacer que tu balanceador de cargas sea accesible para los clientes desde redes más allá de su propia red de nube privada virtual (VPC) de Google Cloud. Las otras redes deben conectarse a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC, Cloud VPN o Cloud Interconnect. Para obtener más información, consulta Accede a redes conectadas.
  • Compatibilidad con GKE mediante Ingress (completamente organizado) Si deseas obtener detalles, consulta Configura Ingress para balanceadores de cargas de aplicaciones internos.
  • Los balanceadores de cargas de aplicaciones internos regionales son compatibles con App Hub, que está en vista previa.
Arquitectura del balanceador de cargas de aplicaciones interno.
Arquitectura del balanceador de cargas de aplicaciones interno.

Para obtener una descripción general completa, consulta Descripción general de la arquitectura para balanceadores de cargas de aplicaciones internos.

Casos de uso

En las siguientes secciones, se describen algunos casos de uso comunes de los balanceadores de cargas de aplicaciones.

Servicios web de tres niveles

Puedes implementar una combinación de balanceadores de cargas de aplicaciones y balanceadores de cargas de red para admitir servicios web convencionales de tres niveles. En el siguiente ejemplo, se muestra cómo implementar cada nivel según el tipo de tráfico:

  • Nivel web. Un balanceador de cargas de aplicaciones externo con backends de grupo de instancias entrega el frontend de la aplicación. El tráfico ingresa desde Internet y se envía desde el balanceador de cargas a un conjunto de backends de grupos de instancias en varias regiones. Estos backends envían tráfico HTTP(S) a un conjunto de balanceadores de cargas de aplicaciones internos.
  • Nivel de la aplicación. El middleware de la aplicación se implementa y escala mediante un balanceador de cargas de aplicaciones interno y backends de grupo de instancias. Los balanceadores de cargas distribuyen el tráfico a grupos de instancias de middleware. Estos grupos de instancias de middleware envían el tráfico a los balanceadores de cargas de red de transferencia internos.
  • Nivel de base de datos. Los balanceadores de cargas de red funcionan como frontends para el nivel de la base de datos. Distribuyen el tráfico a los backends de almacenamiento de datos en varias regiones.
Enrutamiento basado en la capa 7 en una aplicación web de tres niveles.
Enrutamiento basado en la capa 7 en una aplicación web de tres niveles.

Acceso global para balanceadores de cargas de aplicaciones internos regionales

Si habilitas el acceso global para el balanceador de cargas de aplicaciones interno regional, las VMs de cliente de nivel web pueden estar en otra región.

En este ejemplo de aplicación de varios niveles, se muestra lo siguiente:

  • Un nivel web orientado a Internet disponible a nivel global que balancea las cargas del tráfico mediante un balanceador de cargas de aplicaciones externo
  • Un nivel de base de datos de backend interno con balanceo de cargas en la región us-east1 al que accede el nivel web global
  • Una VM de cliente que forma parte del nivel web en la región europe-west1 y que accede al nivel de base de datos interno con balanceo de cargas ubicado en us-east1
Aplicación web de tres niveles con un balanceador de cargas de aplicaciones externo, acceso global y un balanceador de cargas de aplicaciones interno
Aplicación web de tres niveles con un balanceador de cargas de aplicaciones externo, acceso global y un balanceador de cargas de aplicaciones interno (haz clic para ampliar).

Cargas de trabajo con cumplimiento jurisdiccional

Algunas cargas de trabajo con requisitos regulatorios o de cumplimiento requieren que los parámetros de configuración de red y la finalización del tráfico residan en una región específica. Para estas cargas de trabajo, un balanceador de cargas de aplicaciones regional externo suele ser la opción preferida a fin de proporcionar los controles jurisdiccionales que requieren estas cargas de trabajo.

Administración avanzada del tráfico

Los balanceadores de cargas de aplicaciones admiten funciones avanzadas de administración del tráfico que te brindan un control detallado sobre cómo se maneja tu tráfico. Entre estas capacidades, se incluyen las siguientes:

  • Puedes actualizar la forma en que se administra el tráfico sin necesidad de modificar el código de la aplicación.
  • Puedes enrutar el tráfico de forma inteligente según los parámetros HTTP(S), como el host, la ruta de acceso, los encabezados y otros parámetros de solicitud. Por ejemplo, puedes usar buckets de Cloud Storage para manejar cualquier contenido de video estático y puedes usar grupos de instancias o NEG a fin de manejar todas las demás solicitudes.
  • Puedes reducir riesgos cuando implementas una versión nueva de tu aplicación mediante la división de tráfico basada en el peso. Por ejemplo, puedes enviar el 95% del tráfico a la versión anterior de tu servicio y el 5% a la nueva versión de tu servicio. Después de validar que la versión nueva funciona como se espera, puedes cambiar de forma gradual los porcentajes hasta que todo el tráfico llegue a la nueva versión de tu servicio. La división del tráfico suele usarse para implementar versiones nuevas, pruebas A/B, migración de servicios, modernización de servicios heredados y procesos similares.

A continuación, se muestra un ejemplo de enrutamiento basado en rutas de acceso implementado mediante un balanceador de cargas de aplicaciones interno. Un backend diferente controla cada ruta.

Enrutamiento basado en rutas con balanceadores de cargas de aplicaciones internos.
Enrutamiento basado en rutas con balanceadores de cargas de aplicaciones internos.

Para obtener más detalles, consulta lo siguiente:

Extensibilidad con extensiones del servicio

Los textos destacados de las extensiones de servicio te permiten incorporar lógica personalizada en la ruta de acceso de los datos del balanceo de cargas. Estas extensiones te permiten indicarle a los balanceadores de cargas de aplicaciones compatibles que realicen llamadas gRPC a aplicaciones o servicios administrados por el usuario durante el procesamiento de datos.

Para obtener más información, consulta la Descripción general de las extensiones de servicio.

Migra servicios heredados a Google Cloud

La migración de un servicio existente a Google Cloud te permite liberar capacidad local y reducir el costo y la carga de mantener una infraestructura local. Puedes configurar de forma temporal una implementación híbrida que te permita enrutar el tráfico al servicio local actual y al extremo del servicio de Google Cloud correspondiente.

En el siguiente diagrama, se muestra esta configuración con un balanceador de cargas de aplicaciones interno. Si usas un balanceador de cargas interno, puedes configurar el balanceador de cargas de Google Cloud para usar la división de tráfico basada en la ponderación para dividir el tráfico en los dos servicios. La división del tráfico te permite comenzar enviando un 0% del tráfico al servicio de Google Cloud y un 100% al servicio local. Luego, puedes aumentar de forma gradual la proporción del tráfico enviado al servicio de Google Cloud. Por último, envías el 100% del tráfico al servicio de Google Cloud y puedes retirar el servicio local.

Migra servicios heredados a Google Cloud.
Migra servicios heredados a Google Cloud.

Balanceo de cargas para aplicaciones de GKE

Existen tres maneras de implementar balanceadores de cargas de aplicaciones para clústeres de GKE:

  • Controlador de Gateway de GKE. Solo son compatibles con los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos y los balanceadores de cargas de aplicaciones internos regionales. Para obtener instrucciones de configuración, consulta Implementa puertas de enlace.
  • Controlador de Ingress de GKE. Puedes usar el controlador de Ingress de GKE integrado, que implementa balanceadores de cargas de Google Cloud en nombre de los usuarios de GKE. Esto es lo mismo que la arquitectura de balanceo de cargas independiente, excepto que su ciclo de vida está completamente automatizado y controlado por GKE. Es compatible con los balanceadores de cargas de aplicaciones internos y externos. Para obtener instrucciones de configuración, consulta los siguientes vínculos:
  • NEGs zonales independientes. Los NEGs independientes se implementan y administran a través del controlador de NEG de GKE, pero todos los recursos de balanceo de cargas (reglas de reenvío, verificaciones de estado, etc.) se implementan de forma manual. Los balanceadores son compatibles con balanceadores de cargas de aplicaciones internos y externos.

Balanceo de cargas para aplicaciones de Cloud Run, funciones de Cloud Run y App Engine

Puedes usar un balanceador de cargas de aplicaciones como frontend para tus aplicaciones sin servidores de Google Cloud. Esto te permite configurar tus aplicaciones sin servidores para entregar solicitudes desde una dirección IP dedicada que no se comparte con ningún otro servicio.

A fin de configurar esto, usa un NEG sin servidores como el backend del balanceador de cargas. En los siguientes diagramas, se muestra cómo se integra una aplicación sin servidores a un balanceador de cargas de aplicaciones.

Global externo

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura del balanceador de cargas de aplicaciones externo global.

Arquitectura del balanceador de cargas de aplicaciones externo global para apps sin servidores.
Arquitectura del balanceador de cargas de aplicaciones externo global para apps sin servidores.

Regional y externo

En este diagrama, se muestra cómo un NEG sin servidores se ajusta a una arquitectura del balanceador de cargas de aplicaciones externo regional. Este balanceador de cargas solo admite backends de Cloud Run.

Arquitectura del balanceador de cargas de aplicaciones externo regional para apps sin servidores.
Arquitectura del balanceador de cargas de aplicaciones externo regional para apps sin servidores.

Regional interno

En este diagrama, se muestra cómo un NEG sin servidores se ajusta al modelo del balanceador de cargas de aplicaciones interno regional. Este balanceador de cargas solo admite backends de Cloud Run.

Arquitectura del balanceador de cargas de aplicaciones interno regional para apps sin servidores.
Arquitectura del balanceador de cargas de aplicaciones interno regional para apps sin servidores.

Interna entre regiones*

En este diagrama, se muestra cómo un NEG sin servidores se ajusta al modelo del balanceador de cargas de aplicaciones interno entre regiones. Este balanceador de cargas solo admite backends de Cloud Run.

Arquitectura del balanceador de cargas de aplicaciones interno entre regiones para apps sin servidores.
Arquitectura del balanceador de cargas de aplicaciones interno entre regiones para apps sin servidores (haz clic para ampliar).

Documentación relacionada:

Balanceo de cargas a backends fuera de Google Cloud

Los balanceadores de cargas de aplicaciones admiten el tráfico de balanceo de cargas a los extremos que se extienden más allá de Google Cloud, como centros de datos locales y otros entornos de nube. Por lo general, se puede acceder a los backends externos de una de las siguientes maneras:

  • Se puede acceder a través del Internet pública. Para estos extremos, usa un NEG de Internet como el backend del balanceador de cargas. El NEG de Internet está configurado para apuntar a un solo extremo FQDN:Puerto o IP:Puerto en el backend externo. Los NEG de Internet pueden ser globales o regionales.

    En el siguiente diagrama, se muestra cómo conectarse a backends externos a los que se puede acceder a través de la Internet pública mediante un NEG de Internet global.

    Balanceador de cargas de aplicaciones externo global con un backend externo.
    Balanceador de cargas de aplicaciones externo global con un backend externo.

    Para obtener más detalles, consulta Descripción general de los NEGs de Internet.

  • Se puede acceder mediante la conectividad híbrida (Cloud Interconnect o Cloud VPN). Para estos extremos, usas un NEG híbrido como el backend del balanceador de cargas. El NEG híbrido está configurado para apuntar a los extremos de IP:Port en el backend externo.

    En los siguientes diagramas, se demuestra cómo conectarse a backends externos a los que se puede acceder mediante Cloud Interconnect o Cloud VPN.

    Externo

    Conectividad híbrida con los balanceadores de cargas de aplicaciones externos globales.
    Conectividad híbrida con los balanceadores de cargas de aplicaciones externos globales.

    Interno

    Conectividad híbrida con los balanceadores de cargas de aplicaciones internos.
    Conectividad híbrida con los balanceadores de cargas de aplicaciones internos.

    Para obtener más información, consulta Descripción general de los NEGs híbridos.

Integración en Private Service Connect

Private Service Connect permite el consumo privado de servicios en las redes de VPC que pertenecen a distintos grupos, equipos, proyectos u organizaciones. Puedes usar Private Service Connect para acceder a los servicios y las APIs de Google o a servicios administrados en otra red de VPC.

Puedes usar un balanceador de cargas de aplicaciones global externo para acceder a los servicios administrados que se publican mediante Private Service Connect. Para obtener más información, consulta Acerca de los backends de Private Service Connect.

Puedes usar un balanceador de cargas de aplicaciones interno para enviar solicitudes a las APIs y los servicios regionales compatibles de Google. Para obtener más información, consulta Accede a las APIs de Google a través de backends.

Alta disponibilidad y conmutación por error entre regiones

La conmutación por error entre regiones solo está disponible con balanceadores de cargas de aplicaciones externos globales, balanceadores de cargas de aplicaciones clásicos y balanceadores de cargas de aplicaciones internos entre regiones. Estos balanceadores de cargas te permiten mejorar la disponibilidad del servicio cuando creas servicios de backend globales con backends en varias regiones. Si los backends en una región en particular están inactivos, el tráfico se dirige a otra región con facilidad.

Para obtener más información sobre cómo funciona la conmutación por error, consulta los siguientes temas: