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
Hay tráfico del balanceador de cargas procedente 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 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:
- Administración avanzada de tráfico, como duplicación de tráfico, división de tráfico basada en ponderación y transformaciones de encabezados basadas en solicitudes y respuestas. Para obtener más información, consulta Descripción general de la administración del tráfico.
- Balanceo de cargas de tráfico a backends alojados en una variedad de plataformas de Google Cloud como Compute Engine, Google Kubernetes Engine (GKE), Cloud Run y más. La compatibilidad del backend depende del modo de implementación del balanceador de cargas. Para obtener más detalles, consulta la descripción general del balanceador de cargas de aplicaciones externo.
- Respuestas almacenadas en caché con Cloud CDN.
- Protección contra DDoS u otros ataques web mediante Google Cloud Armor.
- Balanceo de cargas a GKE mediante Ingress o Gateway (completamente organizado) o NEG independientes.
- Los balanceadores de cargas de aplicaciones externos regionales son compatibles con App Hub, que está en vista previa.
En el siguiente diagrama, se muestra una arquitectura de balanceador de cargas de aplicaciones externo de ejemplo.
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.
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.
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-east1al que accede el nivel web global - Una VM de cliente que forma parte del nivel web en la región
europe-west1y que accede al nivel de base de datos interno con balanceo de cargas ubicado enus-east1
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.
Para obtener más detalles, consulta lo siguiente:
- Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos globales
- Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos regionales
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.
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. Estos son compatibles con los balanceadores de cargas de aplicaciones internos y externos.
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 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.
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.
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.
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.
Documentación relacionada:
- Descripción general de NEG sin servidores
- Configura un balanceador de cargas de aplicaciones externo global con un backend de Cloud Run, Cloud Functions o App Engine
- Configura un balanceador de cargas de aplicaciones externo regional con un backend de Cloud Run
- Configura un balanceador de cargas de aplicaciones interno regional con un backend de Cloud Run
- Configura un balanceador de cargas de aplicaciones interno entre regiones con Cloud Run
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. 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. Interno
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:
- Balanceadores de cargas de aplicaciones externos globales: cómo se distribuyen las solicitudes
- Balanceadores de cargas de aplicaciones internos entre regiones: alta disponibilidad y conmutación por error entre regiones