En este documento, se presentan los conceptos que debes comprender para configurar balanceadores de cargas de aplicaciones internos.
Un balanceador de cargas de aplicaciones interno de Google Cloud es un balanceador de cargas de capa 7 basado en proxy que te permite ejecutar y escalar los servicios detrás de una dirección IP interna. El balanceador de cargas de aplicaciones interno 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) y Cloud Run. Para obtener detalles, consulta Casos de uso.
Modos de operación
Puedes configurar un balanceador de cargas de aplicaciones interno en los siguientes modos:
- Balanceador de cargas de aplicaciones interno entre regiones. Este es un balanceador de cargas multirregional se implementa como un servicio administrado basado en el proxy de código abierto de Envoy. El modo entre regiones te permite balancear la carga del tráfico a los servicios de backend distribuidos de forma global, incluida la administración del tráfico que garantiza que el tráfico se dirija al backend más cercano. Este balanceador de cargas también permite la alta disponibilidad. Colocar backends en varias regiones ayuda a evitar fallas en una sola región. Si los backends de una región están inactivos, el tráfico puede conmutarse por error a otra región.
Balanceador de cargas de aplicaciones interno regional. Este es un balanceador de cargas regional se implementa como un servicio administrado basado en el proxy de código abierto de Envoy. El modo regional garantiza que todos los clientes y backends provengan de una región específica, lo que ayuda cuando necesitas cumplimiento regional. Este balanceador de cargas está habilitado con funciones de control de tráfico enriquecidas basadas en parámetros HTTP(S). Después de configurar el balanceador de cargas, este asigna los proxies de Envoy de forma automática para satisfacer las necesidades de tráfico.
En la siguiente tabla, se describen las diferencias importantes entre los modos regionales y entre regiones:
Atributo Balanceador de cargas de aplicaciones interno entre regiones Balanceador de cargas de aplicaciones interno regional Dirección IP virtual (VIP) del balanceador de cargas. Asignado desde una subred en una región específica de Google Cloud. Las direcciones VIP multirregión pueden compartir el mismo servicio de backend global. Puedes configurar el balanceo de cargas global basado en DNS con las políticas de enrutamiento de DNS para enrutar las solicitudes de los clientes a la dirección VIP más cercana.
Asignado desde una subred en una región específica de Google Cloud. Acceso del cliente Siempre accesible a nivel global. Los clientes de cualquier región de Google Cloud en una VPC pueden enviar tráfico al balanceador de cargas. No se puede acceder a él de forma global de forma predeterminada.
De manera opcional, puedes habilitar el acceso global.Backends con balanceo de cargas Backends globales.
El balanceador de cargas puede enviar tráfico a backends en cualquier región.Backends regionales.
El balanceador de cargas solo puede enviar tráfico a los backends que se encuentren en la misma región que el proxy del balanceador de cargas.Alta disponibilidad y conmutación por error Conmutación por error automática a backends en buen estado en la misma región o en otras. Conmutación por error automática a backends en buen estado en la misma región.
Identifica el modo
consola de Cloud
En la consola de Google Cloud, ve a la página Balanceo de cargas.
En la pestaña Balanceadores de cargas, puedes ver el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas está en modo entre regiones. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
Modo de balanceador de cargas Tipo de balanceador de cargas Tipo de acceso Región Balanceador de cargas de aplicaciones interno regional Aplicación Interno Especifica una región Balanceador de cargas de aplicaciones interno entre regiones Aplicación Interno
gcloud
Para determinar el modo de un balanceador de cargas, ejecuta el siguiente comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
>Modo de balanceador de cargas Esquema de balanceo de cargas Regla de reenvío Balanceador de cargas de aplicaciones interno entre regiones INTERNAL_MANAGED Global Balanceador de cargas de aplicaciones interno regional INTERNAL_MANAGED Regional
Arquitectura y recursos
En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para los balanceadores de cargas de aplicaciones internos en cada modo:
Interregión
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de red de aplicaciones interno entre regiones en el nivel Premium dentro de la misma red de VPC. Cada regla de reenvío global usa una dirección IP regional que los clientes usan para conectarse.
Regional
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones regional interno en el nivel Premium.
Cada balanceador de cargas de aplicaciones interno usa los siguientes recursos de configuración de Google Cloud.
Subred de solo proxy
En el diagrama anterior, la subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones internos.
En la siguiente tabla, se describen las diferencias entre las subredes de solo proxy en los modos regional y entre regiones:
| Modo de balanceador de cargas | Valor de la marca --purpose de la subred de solo proxy |
|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones |
GLOBAL_MANAGED_PROXY Los balanceadores de cargas entre regiones y regionales no pueden compartir las mismas subredes El balanceador de cargas entre regiones basado en Envoy debe tener una subred de solo proxy en cada región en la que se haya configurado el balanceador de cargas. Los proxies del balanceador de cargas entre regiones en la misma región y red comparten la misma subred de solo proxy. |
| Balanceador de cargas de aplicaciones interno regional |
REGIONAL_MANAGED_PROXY Los balanceadores de cargas entre regiones y regionales no pueden compartir las mismas subredes Todos los balanceadores de cargas regionales basados en Envoy en una región y red de VPC comparten la misma subred de solo proxy |
Además:
- Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
- Las VMs de backend o los extremos de todos los balanceadores de cargas de aplicaciones internos en una región y red de VPC reciben conexiones desde la subred de solo proxy.
- La dirección IP virtual de un balanceador de cargas de aplicaciones interno no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada interna, que se describe a continuación.
Regla de reenvío y dirección IP
Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino y un servicio de backend.
Cada regla de reenvío proporciona una sola dirección IP regional que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática; de lo contrario, deberás actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.
Los clientes usan la dirección IP y el puerto para conectarse a los proxies de Envoy del balanceador de cargas; la dirección IP de la regla de reenvío es la dirección IP del balanceador de cargas (a veces denominada dirección IP virtual o VIP). Los clientes que se conectan a un balanceador de cargas deben usar la versión 1.1 de HTTP o una posterior. Para obtener una lista completa de los protocolos compatibles, consulta Funciones del balanceador de cargas.
La dirección IP interna asociada con la regla de reenvío puede provenir de una subred en la misma red y región que los backends.
Cada regla de reenvío para un balanceador de cargas de aplicaciones puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para usar la misma dirección IP interna (VIP) y hacer referencia al mismo proxy HTTP(S) de destino siempre que la combinación general de la dirección IP, el puerto y el protocolo son únicos para cada regla de reenvío. De esta manera, puedes usar un solo balanceador de cargas con un mapa de URL compartido como proxy para varias aplicaciones.
En la siguiente tabla, se muestran las diferencias entre las reglas de reenvío en los modos regional y entre regiones:
| Modo de balanceador de cargas | Regla de reenvío, dirección IP y subred de solo proxy--purpose |
Enrutamiento del cliente al frontend del balanceador de cargas |
|---|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones |
Esquema de balanceo de cargas:
Subred de solo proxy
Dirección IP
|
El acceso global está habilitado de forma predeterminada para permitir que los clientes de cualquier región de una VPC accedan al balanceador de cargas. Los backends pueden estar en varias regiones. |
| Balanceador de cargas de aplicaciones interno regional |
Esquema de balanceo de cargas:
Subred de solo proxy
Dirección IP
|
Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan al balanceador de cargas. Los backends también deben estar en la misma región que el balanceador de cargas. |
Proxy de destino
Un proxy HTTP(S) de destino finaliza las conexiones HTTP(S) de los clientes. El proxy HTTP(S) consulta el mapa de URL para determinar el enrutamiento del tráfico a los backends. Un proxy HTTPS de destino usa un certificado SSL para autenticarse en los clientes.
El balanceador de cargas conserva el encabezado del host de la solicitud original del cliente. El balanceador de cargas también agrega dos direcciones IP al encabezado X-Forwarded-For:
- La dirección IP del cliente que se conecta al balanceador de cargas
- La dirección IP de la regla de reenvío del balanceador de cargas
Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado. Si la solicitud tiene un encabezado X-Forwarded-For, otra información, como las direcciones IP registradas por los proxies en el camino hacia el balanceador de cargas, se conserva antes de las dos direcciones IP. El balanceador de cargas no verifica ninguna dirección IP que preceda a las últimas dos direcciones IP en este encabezado.
Si ejecutas un proxy como servidor de backend, este suele agregar más información al encabezado X-Forwarded-For, y es posible que tu software deba tener esto en cuenta. Las solicitudes que se envían a través de un proxy desde el balanceador de cargas provienen de una dirección IP en la subred de solo proxy, y el proxy en tu instancia de backend podría registrar esta dirección, así como la dirección IP de la instancia de backend.
Según el tipo de tráfico que necesite controlar tu aplicación, puedes configurar un balanceador de cargas con un proxy HTTP de destino o un proxy HTTPS de destino.
En la siguiente tabla, se muestran las APIs de proxy de destino que requieren los balanceadores de cargas de aplicaciones internos en cada modo:
| Proxy de destino | Balanceador de cargas de aplicaciones interno entre regiones | Balanceador de cargas de aplicaciones interno regional |
|---|---|---|
| HTTP | Global targetHttpProxies |
regionTargetHttpProxies |
| HTTPS | Global targetHttpsProxies |
regionTargetHttpsProxies |
Certificados SSL
Los balanceadores de cargas de aplicaciones internos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas.
En la siguiente tabla, se especifica el tipo de certificados SSL que requieren los balanceadores de cargas de aplicaciones internos en cada modo.
| Modo de balanceador de cargas | Tipo de certificado SSL |
|---|---|
| Balanceador de cargas de aplicaciones interno regional | Certificados SSL regionales de Compute Engine Certificados autoadministrados regionales del Administrador de certificados y certificados administrados por Google. Los siguientes tipos de certificados administrados por Google son compatibles con el Administrador de certificados:
Los certificados administrados por Google con autorización de balanceador de cargas no son compatibles. |
| Balanceador de cargas de aplicaciones interno entre regiones | Certificados autoadministrados del Administrador de certificados y certificados administrados por Google. Los siguientes tipos de certificados administrados por Google son compatibles con el Administrador de certificados:
Los certificados administrados por Google con autorización de balanceador de cargas no son compatibles. Los certificados SSL de Compute Engine no son compatibles. |
Mapas de URL
El proxy HTTP(S) de destino usa mapas de URL para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy desvía las solicitudes de los clientes a servicios de backend específicos. En el mapa de URL se pueden especificar acciones adicionales, como volver a escribir encabezados, enviar redireccionamientos a clientes y configurar políticas de tiempo de espera, entre otras.
En la siguiente tabla, se especifica el tipo de mapa de URL que requieren los balanceadores de cargas de aplicaciones externos en cada modo.
| Modo de balanceador de cargas | Tipo de mapa de URL |
|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones | Mapas de URL globales |
| Balanceador de cargas de aplicaciones interno regional | Mapas de URL de la región |
Servicio de backend
Un servicio de backend distribuye las solicitudes a backends en buen estado: grupos de instancias que contienen VMs de Compute Engine, Cloud Run o NEG que contienen contenedores de GKE.
Los servicios de backend admiten los protocolos HTTP, HTTPS o HTTP/2. HTTP/2 solo es compatible con TLS. Los clientes y los backends no necesitan usar el mismo protocolo de solicitud. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas mediante HTTP/2, y el balanceador de cargas puede reenviar estas solicitudes a backends mediante HTTP/1.1.
En la siguiente tabla, se especifica el tipo de servicio de backend que requieren los balanceadores de cargas de aplicaciones internos en cada modo.
| Modo de balanceador de cargas | Tipo de servicio de backend |
|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones | Servicios de backend globales |
| Balanceador de cargas de aplicaciones interno regional | Servicios de backend regionales |
En la siguiente tabla, se especifican los atributos de backend compatibles con los balanceadores de cargas de aplicaciones internos en cada modo.
|
Modo de balanceador de cargas |
Backends compatibles en un servicio de backend | Compatible con buckets de backend | Compatible con Google Cloud Armor | Admite Cloud CDN | Compatible con IAP | Admite extensiones de servicio | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Grupos de instancias | NEG zonales | NEG de Internet | NEG sin servidores | NEG híbridos | NEGs de Private Service Connect | ||||||
| Balanceador de cargas de aplicaciones interno entre regiones | 2 | Cloud Run |
|||||||||
| Balanceador de cargas de aplicaciones interno regional | 1 | Cloud Run |
|||||||||
1 Usa GCE_VM_IP_PORT extremos de tipo con GKE:
Usa NEG zonales independientes o usa Ingress
2Usa extremos de tipo GCE_VM_IP_PORT con GKE: Usa NEG zonales independientes
Para obtener más información, consulta Descripción general de los servicios de backend.
Backends y redes de VPC
Todos los backends deben estar ubicados en la misma red de VPC. No se admite la ubicación de backends en diferentes redes de VPC, incluso aquellos conectados mediante el intercambio de tráfico entre redes de VPC. Para obtener detalles sobre cómo los sistemas cliente en las redes de VPC con intercambio de tráfico pueden acceder a los balanceadores de cargas, consulta Balanceadores de cargas de aplicaciones internos y redes conectadas.
Subconjuntos de backend
La subdivisión de backends es una función opcional compatible con el balanceador de cargas de aplicaciones interno regional que mejora el rendimiento y la escalabilidad mediante la asignación de un subconjunto de backends a cada una de las instancias de proxy.
De forma predeterminada, la subdivisión del backend está inhabilitada. Si deseas obtener información sobre cómo habilitar esta función, consulta Subconjunto del backend para el balanceador de cargas de aplicaciones interno.
Verificaciones de estado
Cada servicio de backend especifica una verificación de estado que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.
Si quieres que los sondeos de verificación de estado sean exitosos, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend. Por lo general, los sondeos de verificación de estado se originan a partir del mecanismo centralizado de verificación de estado de Google. Sin embargo, para los NEGs híbridos, las verificaciones de estado se originan a partir de la subred de solo proxy. Para obtener más detalles, consulta las verificaciones de estado de Envoy distribuidas en la descripción general de NEGs híbridos.
Protocolo de verificación de estado
Aunque no es obligatorio y no siempre es posible, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends. Por el contrario, los balanceadores de cargas de aplicaciones internos que usan backends de NEGs híbridos no admiten verificaciones de estado de gRPC. Para obtener la lista de protocolos de verificación de estado compatibles, consulta Funciones del balanceo de cargas.
En la siguiente tabla, se especifica el alcance de las verificaciones de estado que admiten los balanceadores de cargas de aplicaciones internos en cada modo.
| Modo de balanceador de cargas | Tipo de verificación de estado |
|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones | Global |
| Balanceador de cargas de aplicaciones interno regional | Regional |
Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:
Reglas de firewall
Un balanceador de cargas de aplicaciones interno requiere las siguientes reglas de firewall:
- Una regla de permiso de entrada que permita el tráfico de los rangos de verificación de estado central de Google.
35.191.0.0/16130.211.0.0/22
- Una regla de permiso de entrada que permita el tráfico de la subred de solo proxy.
Existen ciertas excepciones a los requisitos de las reglas de firewall para estos rangos:
- No es necesario agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas para NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes agregar los rangos de sondeo de verificación de estado de Google a una lista de entidades permitidas para los NEG zonales.
- Para los NEG de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEG de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (a través de Cloud NAT) a cualquiera de las direcciones IP de NAT asignadas de forma manual o automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa Cloud NAT para la salida.
Acceso del cliente
Los clientes pueden estar en la misma red o en una red de VPC conectada mediante el intercambio de tráfico entre redes de VPC.
Para los balanceadores de cargas de aplicaciones internos entre regiones, el acceso global está habilitado de forma predeterminada. Los clientes de cualquier región de una VPC pueden acceder al balanceador de cargas.
Para los balanceadores de cargas de red de aplicaciones interno regional, los clientes deben estar en la misma región que el balanceador de cargas de forma predeterminada. Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan al balanceador de cargas.
En la siguiente tabla, se resume el acceso del cliente para los balanceadores de cargas de aplicaciones internos regionales:
| Acceso global inhabilitado | Acceso global habilitado |
|---|---|
| Los clientes deben estar en la misma región que el balanceador de cargas. También deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC. | Los clientes pueden estar en cualquier región. Aún deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC. |
| Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de cargas. | Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos pueden estar en cualquier región. |
Arquitecturas de VPC compartida
Los balanceadores de cargas de aplicaciones internos admiten redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común a fin de que puedan comunicarse entre ellas de forma segura y eficiente mediante las IP internas de esa red. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.
Hay muchas formas de configurar un balanceador de cargas de aplicaciones interno dentro de una red de VPC compartida. Sin importar el tipo de implementación, todos los componentes del balanceador de cargas deben estar en la misma organización.
| Subredes y dirección IP | Componentes de frontend | Componentes de backend |
|---|---|---|
Crea la red y las subredes requeridas (incluida la subred de solo proxy) en el proyecto host de la VPC compartida. La dirección IP interna del balanceador de cargas se puede definir en el proyecto host o en un proyecto de servicio, pero debe usar una subred en la red de VPC compartida deseada del host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia. |
La dirección IP interna regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio. | Puedes realizar una de las siguientes acciones:
Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend. |
Si bien puedes crear todos los componentes y backends del balanceo de cargas en el proyecto host de la VPC compartida, este tipo de implementación no separa las responsabilidades de administración de red y de desarrollo de servicios.
Todos los componentes y backends del balanceador de cargas en un proyecto de servicio
En el siguiente diagrama de arquitectura, se muestra una implementación de VPC compartida estándar en la que todos los componentes y backends del balanceador de cargas se encuentran en un proyecto de servicio. Este tipo de implementación es compatible con todos los balanceadores de cargas de aplicaciones.
El balanceador de cargas usa direcciones IP y subredes del proyecto host. Los clientes pueden acceder a un balanceador de cargas de aplicaciones interno si están en la misma región y red de VPC compartida que el balanceador de cargas. Los clientes pueden estar ubicados en el proyecto host o en un proyecto de servicio adjunto, o en cualquier red conectada.
Backends sin servidores en un entorno de VPC compartida
Para un balanceador de cargas de aplicaciones interno que usa un backend de NEG sin servidores, el servicio de copia de seguridad de Cloud Run debe estar en el mismo proyecto de servicio que el servicio de backend y el NEG sin servidores. Los componentes de frontend del balanceador de cargas (regla de reenvío, proxy de destino, mapa de URL) se pueden crear en el proyecto host, en el mismo proyecto de servicio que los componentes de backend o en cualquier otro proyecto de servicio en el mismo Entorno de VPC compartida
Referencia del servicio entre proyectos
En este modelo, el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto host o de servicio. Los servicios de backend y los backends del balanceador de cargas se pueden distribuir en todos los proyectos del entorno de VPC compartida. Se puede hacer referencia a los servicios de backend entre proyectos en un solo mapa de URL. Esto se conoce como referencia a servicios entre proyectos.
La referencia a servicios entre proyectos permite a las organizaciones configurar un balanceador de cargas central y enrutar el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puedes administrar de forma centralizada todas las reglas y las políticas de enrutamiento de tráfico en un mapa de URL. También puedes asociar el balanceador de cargas con un solo conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar la cantidad de balanceadores de cargas necesarios para implementar tu aplicación y reducir la administración, los costos operativos y los requisitos de cuota.
Si tienes proyectos diferentes para cada uno de los equipos funcionales, también puedes lograr la separación de los roles dentro de la organización. Los propietarios del servicio pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de red pueden aprovisionar y mantener balanceadores de cargas en otro proyecto, y ambos se pueden conectar a través de referencias de servicios entre proyectos.
Los propietarios del servicio pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a sus servicios a través de el balanceador de cargas. Esto se logra mediante un rol especial de IAM llamado rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser).
Limitaciones conocidas con la referencia del servicio entre proyectos
- No puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales. El resto de los tipos de backend son compatibles.
- Google Cloud no distingue entre recursos (por ejemplo, servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.
Ejemplo 1: frontend y backend del balanceador de cargas en diferentes proyectos de servicio
Este es un ejemplo de una implementación en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto de servicio A, y el mapa de URL hace referencia a un servicio de backend en el proyecto de servicio B.
En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requerirán acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol de IAM compute.loadBalancerServiceUser a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.
Ejemplo 2: frontend del balanceador de cargas en el proyecto host y backends en proyectos de servicio
En este tipo de implementación, el frontend y el mapa de URL del balanceador de cargas se crean en el proyecto host y los servicios de backend (y los backends) se crean en los proyectos de servicio.
En este caso, los administradores de red o del balanceador de cargas en el proyecto host requerirán acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol compute.loadBalancerServiceUser de IAM a los administradores del balanceador de cargas en el proyecto host A que desean hacer referencia al servicio de backend en el proyecto de servicio.
Tiempos de espera y reintentos
Los balanceadores de cargas de aplicaciones internos admiten los siguientes tipos de tiempos de espera:| Tipo de tiempo de espera y descripción | Valores predeterminados | Admite valores personalizados | ||
|---|---|---|---|---|
| Tiempo de espera del servicio de backend
Un tiempo de espera de solicitud y respuesta Representa el tiempo máximo que puede transcurrir desde que el balanceador de cargas envía el primer byte de la solicitud HTTP hasta el backend hasta que el backend devuelve el último byte de la respuesta HTTP. Si la respuesta HTTP completa no se devuelve al balanceador de cargas en el tiempo de espera de solicitud o respuesta, se descartan los datos de respuesta restantes. |
|
|||
| Tiempo de espera de keepalive del HTTP del cliente
La cantidad máxima de tiempo en que la conexión TCP entre un cliente y el proxy de Envoy administrado por el balanceador de cargas puede estar inactivo. (se puede usar la misma conexión TCP para varias solicitudes HTTP). |
10 minutos (600 segundos) | |||
| Tiempo de espera de keepalive del HTTP de backend
La cantidad máxima de tiempo en que la conexión TCP entre el proxy de Envoy administrado por el balanceador de cargas y un backend pueden estar inactivos. (se puede usar la misma conexión TCP para varias solicitudes HTTP). |
10 minutos (600 segundos) | |||
Tiempo de espera del servicio de backend
El tiempo de espera del servicio de backend configurable representa la cantidad máxima de tiempo que el balanceador de cargas espera que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto por los NEG sin servidores, el valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos.
Por ejemplo, si quieres descargar un archivo de 500 MB y el valor del tiempo de espera del servicio de backend es de 90 segundos, el balanceador de cargas espera que el backend entregue todo el archivo de 500 MB en 90 segundos. Es posible configurar el tiempo de espera del servicio de backend para que no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de cargas al menos recibió encabezados de respuesta HTTP, el balanceador de cargas devuelve los encabezados de respuesta completos y todo el cuerpo de respuesta que pudo obtener dentro del tiempo de espera del servicio de backend.
Debes establecer el tiempo de espera del servicio de backend en el tiempo más largo que esperas que tu backend necesite para procesar una respuesta HTTP. Debes aumentar el tiempo de espera del servicio de backend si el software que se ejecuta en el backend necesita más tiempo para procesar una solicitud HTTP y mostrar su respuesta completa.
El tiempo de espera del servicio de backend acepta valores entre 1 y 2,147,483,647 segundos; sin embargo, los valores más grandes no son opciones de configuración prácticas.
Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.
Para configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:
- Consola de Google Cloud: Modifica el campo Tiempo de espera del servicio de backend del balanceador de cargas.
- Google Cloud CLI: Usa el comando
gcloud compute backend-services updatepara modificar el parámetro--timeoutdel recurso de servicio de backend. - API: Modifica el parámetro
timeoutSecpara el recursoregionBackendServices.
Tiempo de espera de keepalive de HTTP del cliente
El tiempo de espera de keepalive de HTTP del cliente representa la cantidad máxima de tiempo que una conexión TCP puede estar inactiva entre el cliente (en sentido descendente) y un proxy de Envoy. El valor de tiempo de espera de keepalive del cliente HTTP se fija en 600 segundos.
El tiempo de espera de keepalive de HTTP también se denomina tiempo de espera de TCP inactivo.
El tiempo de espera de keepalive del cliente HTTP del balanceador de cargas debe ser mayor que el tiempo de espera de keepalive de HTTP (TCP inactivo) que usan los clientes o proxies descendentes. Si un cliente descendente tiene un tiempo de espera de keepalive de HTTP (TCP inactivo) mayor que el del cliente HTTP del balanceador de cargas, es posible que se produzca una condición de carrera. Desde la perspectiva de un cliente descendente, una conexión TCP establecida puede estar inactiva durante más tiempo del que permite el balanceador de cargas. Esto significa que el cliente descendente puede enviar paquetes después de que el balanceador de cargas considera que la conexión TCP está cerrada. Cuando eso sucede, el balanceador de cargas responde con un paquete de restablecimiento de TCP (RST).
Tiempo de espera de keepalive de HTTP del backend
Los balanceadores de cargas de aplicaciones internos son proxies que usan una primera conexión TCP entre el cliente (descendiente) y un proxy de Envoy, y una segunda conexión TCP entre el proxy de Envoy y los backends.
Es posible que las conexiones TCP secundarias del balanceador de cargas no se cierren después de cada solicitud; pueden permanecer abiertos para manejar varias solicitudes y respuestas HTTP. El tiempo de espera del keepalive de HTTP de backend define el tiempo de espera de inactividad de TCP entre el balanceador de cargas y los backends. El tiempo de espera de keepalive de HTTP de backend no se aplica a websockets.
El tiempo de espera de keepalive del backend se fija en 10 minutos (600 segundos) y no se puede cambiar. El tiempo de espera del keepalive del backend del balanceador de cargas debe ser menor que el que usa el software que se ejecuta en los backends. Esto evita una condición de carrera en la que el sistema operativo de los backends puede cerrar las conexiones TCP con un restablecimiento TCP (RST). Debido a que no se puede configurar el tiempo de espera de keepalive del backend para el balanceador de cargas, debes configurar el software de backend para que el valor de tiempo de espera de keepalive de HTTP (TCP inactivo) sea superior a 600 segundos.
En la siguiente tabla, se enumeran los cambios necesarios para modificar los valores de tiempo de espera de keepalive para el software del servidor web común.
| Software de servidor web | Parámetro | Parámetro de configuración predeterminado | Configuración recomendada |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Reintentos
Para configurar los reintentos, puedes usar una política de reintentos en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1.
El tiempo de espera predeterminado para cada intento (perTryTimeout) es de 30 segundos con un perTryTimeout máximo configurable de 24 horas.
Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) que dan como resultado respuestas HTTP 502, 503 o 504 se reintentan una vez.
Las solicitudes HTTP POST no se reintentan.
Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.
Para obtener más información, consulta Registro y supervisión del balanceador de cargas de aplicaciones interno.
Accede a redes conectadas
Puedes acceder a un balanceador de cargas de aplicaciones interno en tu red de VPC desde una red conectada mediante el siguiente procedimiento:
- Intercambio de tráfico entre redes de VPC
- Cloud VPN y Cloud Interconnect
Para ver ejemplos detallados, consulta Balanceadores de cargas de aplicaciones internos y redes conectadas.
Conmutación por error
Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado.
En la siguiente tabla, se describe el comportamiento de la conmutación por error en cada modo:
| Modo de balanceador de cargas | Comportamiento de la conmutación por error | Comportamiento cuando todos los backends están en mal estado |
|---|---|---|
| Balanceador de cargas de aplicaciones interno entre regiones | Conmutación por error automática a backends en buen estado en la misma región o en otras regiones. El tráfico se distribuye entre backends en buen estado que abarcan varias regiones según la distribución del tráfico configurada. |
Muestra HTTP 503 |
| Balanceador de cargas de aplicaciones interno regional | Conmutación por error automática a backends en buen estado en la misma región. El proxy de Envoy envía tráfico a backends en buen estado en una región según la distribución de tráfico configurada. |
Muestra HTTP 503 |
Alta disponibilidad y conmutación por error entre regiones
Puedes configurar un balanceador de cargas de aplicaciones interno entre regiones en varias regiones para obtener los siguientes beneficios:
Si el balanceador de cargas de aplicaciones interno entre regiones en una región falla, las políticas de enrutamiento de DNS enrutan el tráfico a un balanceador de cargas de aplicaciones interno entre regiones en otra región.
En el ejemplo de la implementación de alta disponibilidad, se muestra lo siguiente:
- Un balanceador de cargas de aplicaciones interno entre regiones con dirección IP virtual (VIP) de frontend en las regiones
RegionAyRegionBen tu red de VPC. Tus clientes se encuentran en la regiónRegionA. - Puedes hacer que el balanceador de cargas sea accesible mediante las VIP de frontend de dos regiones y usar políticas de enrutamiento de DNS para mostrar la VIP óptima a los clientes. Usa las políticas de enrutamiento de ubicación geográfica si deseas que tus clientes usen la VIP más cercana a nivel geográfico.
- Las políticas de enrutamiento de DNS pueden detectar si una VIP no responde durante una interrupción regional y mostrar la siguiente VIP más óptima para los clientes, lo que garantiza que la aplicación se mantenga activa incluso durante una interrupción regional.
Balanceador de cargas de aplicaciones interno entre regiones con implementación de alta disponibilidad (haz clic para ampliar). - Un balanceador de cargas de aplicaciones interno entre regiones con dirección IP virtual (VIP) de frontend en las regiones
Si los backends en una región en particular están inactivos, el tráfico del balanceador de cargas de aplicaciones interno entre regiones se conmuta por error a los backends en otra región con facilidad.
En el ejemplo de implementación de conmutación por error entre regiones, se muestra lo siguiente:
- Un balanceador de cargas de red de aplicaciones interno entre regiones con una dirección VIP de frontend en la región
RegionAde tu red de VPC. Tus clientes también se encuentran en la regiónRegionA. - Un servicio de backend global que hace referencia a los backends en las regiones
RegionAyRegionBde Google Cloud. - Cuando los backends en la región
RegionAestán inactivos, el tráfico se conmuta por error a la regiónRegionB.
Balanceador de cargas de aplicaciones interno entre regiones con una implementación de conmutación por error entre regiones (haz clic para agrandar). - Un balanceador de cargas de red de aplicaciones interno entre regiones con una dirección VIP de frontend en la región
Compatible con WebSocket
Los balanceadores de cargas basados en HTTP(S) de Google Cloud admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.
El protocolo de WebSocket proporciona un canal de comunicación dúplex completo entre los clientes y el balanceador de cargas. Para obtener más información, consulta RFC 6455.
El protocolo WebSocket funciona de la siguiente manera:
- El balanceador de cargas reconoce una solicitud
Upgradede WebSocket de un cliente HTTP(S). La solicitud contiene los encabezadosConnection: UpgradeyUpgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con el WebSocket. - El backend envía una respuesta
Upgradede WebSocket. La instancia de backend envía una respuesta101 switching protocolcon encabezadosConnection: Upgrade,Upgrade: websockety otros encabezados de respuesta relacionados con WebSocket. - El balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual.
Si la instancia de backend muestra una respuesta de error con
el código de respuesta 426 o 502, el balanceador de cargas cierra la conexión.
La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener más información, consulta afinidad de sesión.
Compatibilidad con gRPC
gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:
- Sistemas distribuidos altamente escalables y de baja latencia
- Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
- Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
- Diseño en capas para habilitar extensiones, autenticación y registros
Para usar gRPC con tus aplicaciones de Google Cloud, debes usar las solicitudes del proxy de extremo a extremo en HTTP/2. Para ello, haz lo siguiente:
- Configura un balanceador de cargas HTTPS.
- Habilita HTTP/2 como protocolo desde el balanceador de cargas hasta los backends.
El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.
El balanceador de cargas aún puede negociar HTTPS con algunos clientes o aceptar solicitudes HTTP no seguras en un balanceador de cargas configurado para usar HTTP/2 entre las instancias de backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.
Debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
Compatibilidad con TLS
De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente.
Cuando el balanceador de cargas de aplicaciones interno usa HTTPS como un protocolo de servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 para el backend.
Limitaciones
No hay garantía de que la solicitud de un cliente en una zona de la región se envíe a un backend que se encuentre en la misma zona que el cliente. La afinidad de sesión no reduce la comunicación entre zonas.
Los balanceadores de cargas de aplicaciones internos no son compatibles con las siguientes funciones:
Un balanceador de cargas de aplicaciones interno admite HTTP/2 solo a través de TLS.
Los clientes que se conectan a un balanceador de cargas de aplicaciones interno deben usar la versión 1.1 de HTTP o una versión posterior. HTTP 1.0 no es compatible.
Google Cloud no te advierte si tu subred de solo proxy se queda sin direcciones IP.
La regla de reenvío interno que usa el balanceador de cargas de aplicaciones interno debe tener exactamente un puerto.
Los balanceadores de cargas de aplicaciones internos no son compatibles con Cloud Trace.
Cuando se usa un balanceador de cargas de aplicaciones interno con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes en proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyectos de servicio dentro del mismo entorno de VPC compartida. Este es un problema conocido, y esta forma de acceso se bloqueará en el futuro.
Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.
¿Qué sigue?
- Para configurar el balanceo de cargas en una configuración de VPC compartida, consulta Configura un balanceador de cargas de aplicaciones interno para una VPC compartida.
- Si deseas configurar el balanceo de cargas de los servicios que se ejecutan en Pods de GKE, consulta Implementa puertas de enlace de GKE, balanceo de cargas nativo del contenedor con NEGs independientes y la sección Vincula un balanceador de cargas de aplicaciones interno a NEG independientes.
- Para configurar un balanceador de cargas de aplicaciones regional interno con Private Service Connect, consulta Configura Private Service Connect con los controles de servicio HTTP(S) de consumidor.
- Para administrar el recurso de subred de solo proxy, consulta Subredes de solo proxy.
- Para configurar la subdivisión de backend en balanceadores de cargas de aplicaciones regionales internos, consulta Subdivisión de backend.
- Para incorporar lógica personalizada en la ruta de acceso de los datos del balanceo de cargas, configura los textos destacados de las extensiones de servicio.