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:

Modo de implementación Nivel de servicio de red Esquema de balanceo de cargas Dirección IP Puertos de frontend Vínculos
Balanceador de cargas de aplicaciones externo

Balancea las cargas de tráfico proveniente de los clientes en Internet.

Global externo Nivel Premium EXTERNAL_MANAGED IPv4
IPv6

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

Detalles de la arquitectura
Regional y externo Nivel Premium o Estándar EXTERNAL_MANAGED IPv4
Clásico

Global en el nivel Premium

Regional en el nivel Estándar

EXTERNO IPv4
IPv6 requiere nivel Premium
Balanceador de cargas de aplicaciones interno

Balancea las cargas de tráfico dentro de tu red de VPC o las redes conectadas a tu red de VPC.

Regional interno Nivel Premium INTERNAL_MANAGED IPv4

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

Detalles de la arquitectura

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 balanceadores de cargas de aplicaciones clásicos usan GFE distribuidos de forma global, que funcionan en conjunto mediante la red global y el plano de control de Google. Los GFE 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 puedan acceder a ellos a nivel global desde cualquier región de Google Cloud.

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

  • 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 más detalles, consulta Administración de 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 muestran 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 entrega backends de grupo de instancias para entregar el frontend de la aplicación. El tráfico ingresa desde Internet y se envía mediante un proxy 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 aplicación. El middleware de la aplicación se implementa y escala mediante un balanceador de cargas de aplicaciones interno y los backends de grupos de instancias. Los balanceadores de cargas distribuyen el tráfico a grupos de instancias de middleware. Estos grupos de instancias de middleware luego envían el tráfico a balanceadores de cargas de red de transferencia interna.
  • Nivel de base de datos. Los balanceadores de cargas de red sirven como frontends para el nivel de la base de datos. Distribuyen tráfico a 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 VM de cliente de nivel web pueden estar en otra región.

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

  • Un nivel web orientado a Internet con disponibilidad 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. Estas capacidades incluyen las siguientes:

  • Puedes actualizar la forma en que se administra el tráfico sin tener que modificar el código de la aplicación.
  • Puedes enrutar el tráfico de forma inteligente según los parámetros de 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 mitigar 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 implementada con 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 de servicio

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

Para obtener más información, consulta 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

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

Balanceo de cargas para aplicaciones de Cloud Run, Cloud Functions 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 comparta con ningún otro servicio.

Los balanceadores de cargas de aplicaciones internos entre regiones solo admiten un servicio de Cloud Run por servicio de backend. Si se especifican varios NEG, solo se usa el primero.

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 en un balanceador de cargas de aplicaciones.

Global externo

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

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 regional del balanceador de cargas de aplicaciones externo. 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.

Documentación relacionada:

Balanceo de cargas a backends fuera de Google Cloud

Los balanceadores de cargas de aplicaciones admiten el balanceo de cargas de tráfico a 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:

  • Es accesible a través de la Internet pública. Para estos extremos, usas un NEG de Internet como 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 la Descripción general de los NEG de Internet.

  • Se puede acceder mediante la conectividad híbrida (Cloud Interconnect o Cloud VPN). Para estos extremos, usas un NEG híbrido como backend del balanceador de cargas. El NEG híbrido está configurado para apuntar a extremos de IP:Puerto 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 detalles, consulta la Descripción general de los NEG 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 externo global para acceder a los servicios 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 conmuta por error a otra región de forma correcta.

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