Descripción general del balanceador de cargas de aplicaciones interno

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 más detalles, consulta Descripción general del balanceador de cargas de aplicaciones: casos de usos.

Modos de operación

Puedes configurar un balanceador de cargas de aplicaciones interno en los siguientes modos:

  • 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.
  • 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. El balanceador de cargas interno de aplicaciones entre regiones se encuentra en Versión preliminar.

    En la siguiente tabla, se describen las diferencias importantes entre los modos regionales y entre regiones:

    Atributo Balanceador de cargas de aplicaciones interno regional Balanceador de cargas de aplicaciones interno entre regiones
    Dirección IP virtual (VIP) del balanceador de cargas. Asignado desde una subred en una región específica de Google Cloud. 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.

    Acceso del cliente No se puede acceder a él de forma global de forma predeterminada.
    De manera opcional, puedes habilitar el acceso global.
    Siempre accesible a nivel global. Los clientes de cualquier región de Google Cloud pueden enviar tráfico al balanceador de cargas.
    Backends con balanceo de cargas 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.
    Backends globales.
    El balanceador de cargas puede enviar tráfico a backends en cualquier región.
    Alta disponibilidad y conmutación por error Conmutación por error automática a backends en buen estado en la misma región. Conmutación por error automática a backends en buen estado en la misma región o en otras.

Identifica el modo

consola de Cloud

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. 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

  1. 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 regional INTERNAL_MANAGED Regional
    Balanceador de cargas de aplicaciones interno entre regiones INTERNAL_MANAGED Global

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:

Regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones regional interno en el nivel Premium.

Componentes del balanceador de cargas de aplicaciones interno regional.
Componentes numerados del balanceador de cargas de aplicaciones interno regional (haz clic para ampliar).

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.

Componentes del balanceador de cargas de aplicaciones interno entre regiones
Componentes del balanceador de cargas de aplicaciones interno entre regiones (haz clic para ampliar).

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 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

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.

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 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 regional

Regla de reenvío regional

Dirección IP regional

Esquema de balanceo de cargas:

INTERNAL_MANAGED

Subred de solo proxy --purpose:

REGIONAL_MANAGED_PROXY

Dirección IP --purpose:

SHARED_LOADBALANCER_VIP

Puedes habilitar el acceso global para permitir que los clientes de cualquier región accedan al balanceador de cargas. Los backends también deben estar en la misma región que el balanceador de cargas.

Balanceador de cargas de aplicaciones interno entre regiones

Regla de reenvío global

Direcciones IP regionales

Esquema de balanceo de cargas:

INTERNAL_MANAGED

Subred de solo proxy --purpose:

GLOBAL_MANAGED_PROXY

Dirección IP --purpose:

SHARED_LOADBALANCER_VIP

El acceso global está habilitado de forma predeterminada para permitir que los clientes de cualquier región accedan al balanceador de cargas. Los backends pueden estar en varias regiones.


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 regional Balanceador de cargas de aplicaciones interno entre regiones
HTTP regionTargetHttpProxies Global targetHttpProxies
HTTPS regionTargetHttpsProxies Global targetHttpsProxies

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 regional Mapas de URL de la región
Balanceador de cargas de aplicaciones interno entre regiones Mapas de URL globales

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 regional Servicios de backend regionales
Balanceador de cargas de aplicaciones interno entre regiones Servicios de backend globales

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 regional 1
Cloud Run
Balanceador de cargas de aplicaciones interno entre regiones 2
Cloud Run
(cualquier región, pero solo una por servicio de backend)

1UsaGCE_VM_IP_PORT extremos de tipo con GKE: Usa NEG zonales independientes o usa Ingress

2UsaGCE_VM_IP_PORT extremos de tipo 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 regional Regional
Balanceador de cargas de aplicaciones interno entre regiones Global

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:

Existen ciertas excepciones a los requisitos de las reglas de firewall para estos rangos:

  • No se requiere incluir en la lista de entidades permitidas los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes incluir en la lista de anunciantes permitidos los rangos de sondeo de verificación de estado de Google 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 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 accedan al balanceador de cargas.

Para los balanceadores de cargas de aplicaciones internos entre regiones, el acceso global está habilitado de forma predeterminada. Los clientes de cualquier región pueden acceder 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:
  • Crea servicios de backend y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en el mismo proyecto de servicio que los componentes del frontend.
  • Crea servicios de backends y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en tantos proyectos de servicio como sea necesario. Un solo mapa de URL puede hacer referencia a servicios de backend en diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos.

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.

Balanceador de cargas de aplicaciones interno en la red de VPC compartida
Balanceador de cargas de aplicaciones interno en la red de VPC compartida

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).

Si deseas obtener información sobre cómo configurar la VPC compartida para un balanceador de cargas de aplicaciones interno (con y sin servicio de referencia entre proyectos, consulta Configura un balanceador de cargas de aplicaciones interno con VPC compartida.

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.

Frontend y mapa de URL del balanceador de cargas en el proyecto de servicio
Frontend y backend del balanceador de cargas en diferentes proyectos de servicio

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.

Frontend del balanceador de cargas y mapa de URL en el proyecto host
Frontend del balanceador de cargas y mapa de URL en el proyecto host

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.

Para el tráfico WebSocket, la duración máxima de WebSocket, ya sea inactivo o activo.

  • Para los NEG sin servidores en un servicio de backend: 60 minutos
  • Para todos los demás tipos de backend en un servicio de backend: 30 segundos
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.

A excepción de WebSockets, 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. Para WebSockets, el tiempo de espera del servicio de backend tiene un significado diferente. Representa la duración máxima posible de un WebSocket, inactivo o activo. Debes aumentar el tiempo de espera del servicio de backend si se cumplen las siguientes condiciones:

  • El software que se ejecuta en el backend necesita más tiempo para procesar una solicitud HTTP y mostrar su respuesta completa.
  • Necesitas conexiones WebSocket para conservar durante más tiempo.

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.

Google Cloud reinicia o cambia la cantidad de tareas de software de Envoy de forma periódica. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que los reinicios o reemplazos de tareas de Envoy finalicen las conexiones TCP.

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 update para modificar el parámetro --timeout del recurso de servicio de backend.
  • API: Modifica el parámetro timeoutSec para el recurso regionBackendServices.

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; en cambio, el tiempo de espera del servicio de backend define una duración total para el WebSocket.

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 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
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

Alta disponibilidad y conmutación por error entre regiones

Los balanceadores de cargas de red de aplicaciones internos entre regiones te permiten mejorar la disponibilidad del servicio mediante la creación de 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 de manera correcta.

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 us-west1 de tu red de VPC. Tus clientes también se encuentran en la región us-west1.
  • Un servicio de backend global que hace referencia a los backends en las regiones us-west1 y us-east1 de Google Cloud.
  • Cuando los backends en la región us-west1 están inactivos, el tráfico se conmuta por error a la región us-east1.
Balanceador de cargas de aplicaciones interno entre regiones con una implementación de conmutación por error entre regiones.
Balanceador de cargas de aplicaciones interno entre regiones con una implementación de conmutación por error entre regiones (haz clic para agrandar).

Los balanceadores de cargas de red de aplicaciones internos entre regiones también pueden proteger tu aplicación contra interrupciones regionales completas mediante la entrega de tráfico a tu cliente desde proxies y backends 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 VIP de frontend en las regiones us-west1 y us-east1 en tu red de VPC. Tus clientes se encuentran en la región us-west1.
  • 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.
Balanceador de cargas de aplicaciones interno entre regiones con implementación de alta disponibilidad (haz clic para ampliar).

Compatible con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud tienen compatibilidad integrada con 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 WebSocket proporciona un canal de comunicación dúplex completo entre clientes y servidores. Una solicitud HTTP(S) inicia el canal. Para obtener información detallada sobre el protocolo, consulta RFC 6455.

Cuando el balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP(S) seguida de una respuesta Upgrade correcta de la instancia de backend, el balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual. Si la instancia de backend no devuelve una respuesta Upgrade correcta, el balanceador de cargas cierra la conexión.

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera del servicio de backend configurable del balanceador de cargas, que es de 30 segundos según la configuración predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso.

Solo para los balanceadores de cargas de aplicaciones externos globales y los clásicos, las conexiones de WebSocket se cierran de forma automática después de 24 horas. Este límite de 24 horas no se puede personalizar y ocurre sin importar si las conexiones están en uso o si el valor del tiempo de espera del servicio de backend está establecido en un valor superior a 86,400 segundos.

La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener 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:

  1. Configura un balanceador de cargas HTTPS.
  2. 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?