Descripción general del balanceo de cargas de HTTP(S) interno

El balanceo de cargas de HTTP(S) interno de Google Cloud es un balanceador de cargas regional de capa 7 basado en proxy que te permite ejecutar y escalar los servicios detrás de una dirección IP interna.

El balanceo de cargas HTTP(S) interno distribuye el tráfico HTTP y HTTPS a los backends alojados en Compute Engine, Google Kubernetes Engine (GKE) y Cloud Run. Solo se puede acceder al balanceador de cargas en la región elegida de tu red de nube privada virtual (VPC) en una dirección IP interna.

El balanceo de cargas de HTTP(S) interno es un servicio administrado basado en el proxy de Envoy de código abierto. Esto permite funciones completas de control de tráfico 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 un nivel alto, un balanceador de cargas de HTTP(S) interno consta de los siguientes elementos:

  • Una dirección IP interna a la que los clientes envían tráfico. Solo los clientes que se encuentran en la misma región que el balanceador de cargas pueden acceder a esta dirección IP. Las solicitudes internas de clientes permanecen dentro de la red y la región.
  • Uno o más servicios de backend a los que el balanceador de cargas reenvía el tráfico. Los backends pueden ser VMs de Compute Engine, grupos de VMs de Compute Engine (mediante grupos de instancias), aplicaciones de Cloud Run o nodos de GKE (a través de grupos de extremos de red [NEG]). Estos backends deben estar ubicados en la misma región que el balanceador de cargas.
Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)
Servicios internos con balanceo de cargas basado en la capa 7 (haz clic para ampliar)

Para conocer las limitaciones específicas del balanceo de cargas de HTTP(S) interno, consulta la sección Limitaciones.

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Casos de uso

El balanceo de cargas HTTP(S) interno aborda muchos casos prácticos. En esta sección se proporcionan algunos ejemplos de alto nivel. Para ver ejemplos adicionales, consulta Casos prácticos de la administración del tráfico.

Servicios web de tres niveles

Puedes usar el balanceo de cargas de HTTP(S) interno para admitir los servicios web tradicionales de tres niveles. En el siguiente ejemplo, se muestra cómo puedes usar tres tipos de balanceadores de cargas de Google Cloud para escalar tres niveles. En cada nivel el tipo de balanceador de cargas depende del tipo de tráfico:

En el diagrama se muestra cómo se mueve el tráfico a través de los niveles:

  1. Un balanceador de cargas de HTTP(S) externo distribuye el tráfico de Internet a un conjunto de grupos de instancias de frontend web en varias regiones.
  2. Estos frontends envían el tráfico HTTP(S) a un conjunto de balanceadores de cargas de HTTP(S) regionales internos (el tema de esta descripción general).
  3. Los balanceadores de cargas de HTTP(S) internos distribuyen el tráfico a grupos de instancias de middleware.
  4. Estos grupos de instancias de middleware envían el tráfico a balanceadores de cargas de TCP/UDP internos, que balancean la carga del tráfico a los clústeres de almacenamiento de datos.
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles (haz clic si deseas ampliar)
Enrutamiento basado en la capa 7 para niveles internos en una app de varios niveles

Balanceo de cargas mediante el enrutamiento basado en ruta de acceso

Un caso práctico común es el balanceo de cargas del tráfico entre distintos servicios. En este ejemplo un cliente interno puede solicitar contenido de video y de imagen mediante la misma URL base, mygcpservice.internal, con las rutas de acceso /video y /images.

El mapa de URL del balanceador de cargas de HTTP(S) especifica que las solicitudes a la ruta de acceso /video deben enviarse al servicio de backend de video, mientras que las solicitudes a la ruta de acceso /images deben enviarse al servicio de backend de imágenes. En el siguiente ejemplo, los servicios de backend de video y de imágenes se entregan mediante las VM de Compute Engine, pero también se pueden entregar mediante pods de GKE.

Cuando un cliente interno envía una solicitud a la dirección IP interna del balanceador de cargas, el balanceador de cargas evalúa la solicitud según esta lógica y la envía al servicio de backend correcto.

En el siguiente diagrama, se ilustra este caso práctico.

Servicios internos (micro) con balanceo de cargas basado en la capa 7 (haz clic para ampliar)
Servicios internos (micro) con balanceo de cargas basado en la capa 7

Modernización de servicios heredados

El balanceo de cargas de HTTP(S) interno puede ser una herramienta eficaz para modernizar las aplicaciones heredadas.

Un ejemplo de una aplicación heredada es una aplicación monolítica grande que no se puede actualizar con facilidad. En este caso, puedes implementar un balanceador de cargas de HTTP(S) interno frente a la aplicación heredada. Luego, puedes usar las funciones de control de tráfico del balanceador de cargas para dirigir un subconjunto de tráfico a microservicios nuevos que reemplacen la funcionalidad que proporciona la aplicación heredada.

Para comenzar, debes configurar el mapa de URL del balanceador de cargas a fin de que enrute todo el tráfico a la aplicación heredada de forma predeterminada. Esto mantiene el comportamiento existente. A medida que se desarrollen los servicios de reemplazo, deberías actualizar el mapa de URL para enrutar partes del tráfico a estos servicios.

Imagina que la aplicación heredada contiene alguna funcionalidad de procesamiento de video que se entrega cuando los clientes internos envían solicitudes a /video. Puedes dividir este servicio de video en un microservicio individual de la siguiente manera:

  1. Agrega balanceo de cargas HTTP(S) interno frente a la aplicación heredada.
  2. Crea un microservicio de procesamiento de video de reemplazo.
  3. Actualiza el mapa de URL del balanceador de cargas para que todas las solicitudes a la ruta de acceso /video se enruten al microservicio nuevo en lugar de enrutarse a la aplicación heredada.

A medida que desarrolles servicios de reemplazo adicionales, se seguirá actualizando el mapa de URL. Con el tiempo, se enviarán menos solicitudes a la aplicación heredada. Además, los servicios de reemplazo existirán para todas las funcionalidades que proporciona la aplicación heredada. En este punto, puedes retirar tu aplicación heredada.

Balanceo de cargas con conectividad híbrida

Cloud Load Balancing admite tráfico de balanceo de cargas a extremos que se extienden más allá de Google Cloud, como centros de datos locales y otras nubes públicas a las que puedes usar la conectividad híbrida para llegar.

En el siguiente diagrama, se muestra una implementación híbrida con un balanceador de cargas HTTP(S) interno.

Conectividad híbrida con el balanceo de cargas de HTTP(S) interno (haz clic para ampliar)
Conectividad híbrida con el balanceo de cargas de HTTP(S) interno (haz clic para ampliar)

Private Service Connect

Puedes usar un balanceo de cargas HTTP(S) interno para enviar solicitudes a las API y los servicios regionales compatibles de Google. Si deseas obtener más información, consulta Usa Private Service Connect para acceder a las API de Google con los controles de servicio de HTTP(S) del consumidor.

Balanceo de cargas para aplicaciones de GKE

Si compilas aplicaciones en GKE, te recomendamos que uses el controlador de Ingress de GKE integrado, que implementa balanceadores de cargas de Google Cloud por los usuarios de GKE. Esto es lo mismo que la arquitectura de balanceo de cargas independiente que se describe en esta página, excepto que su ciclo de vida está completamente automatizado y controlado por GKE.

Documentación de GKE relacionada:

Arquitectura y recursos

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios para un balanceador de cargas de HTTP(S) interno.

Componentes del balanceo de cargas HTTP(S) interno (haz clic para ampliar)
Componentes del balanceo de cargas de HTTP(S) interno

Cada balanceador de cargas de HTTP(S) interno usa estos recursos de configuración de Google Cloud:

Subred de solo proxy

En el diagrama anterior, la subred de solo proxy (proxy-only subnet) 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 HTTP(S) internos. Todos los balanceadores de cargas de HTTP(S) internos en una región y red de VPC comparten la misma subred de solo proxy porque también comparten un grupo de proxies de Envoy. Además:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • Las VM de backend o los extremos de todos los balanceadores de cargas de HTTP(S) internos en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
  • La dirección IP de un balanceador de cargas de HTTP(S) 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

Una regla de reenvío administrado interno especifica una dirección IP interna, un puerto y un proxy HTTP(S) de destino regional. 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 de HTTP(S) interno deben usar la versión 1.1 de HTTP o una versión 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 cualquier subred en la misma red y región. Ten en cuenta las siguientes condiciones:

  • La dirección IP puede (pero no es necesario) provenir de la misma subred que los grupos de instancias de backend.
  • La dirección IP no debe provenir de la subred de solo proxy reservada que tiene la marca --purpose configurada como REGIONAL_MANAGED_PROXY.
  • Si deseas compartir una dirección IP interna con varias reglas de reenvío, configura la marca --purpose de la dirección IP como SHARED_LOADBALANCER_VIP.

Cada regla de reenvío que usas en un balanceador de cargas HTTP(S) interno puede hacer referencia a exactamente un puerto TCP. Para los balanceadores de cargas HTTP, usa el puerto 80 o el 8080, en el caso de los balanceadores de cargas HTTPS, usa el puerto 443.

Proxy de destino

Un proxy HTTP(S) de destino regional 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.

Certificado SSL

La seguridad de la capa de transporte (TLS) es un protocolo de encriptación que se usa en los certificados SSL para proteger las comunicaciones de redes.

Google Cloud usa certificados SSL para proporcionar privacidad y seguridad desde un cliente hacia un balanceador de cargas. Si usas el balanceo de cargas basado en HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

Para obtener más información sobre los certificados SSL, consulta lo siguiente:

Mapa de URL

El proxy HTTP(S) usa un mapa de URL regional 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 regionales 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.

Servicio de backend

Un servicio de backend regional distribuye las solicitudes a backends en buen estado: grupos de instancias que contienen VM de Compute Engine, NEG que contienen contenedores de GKE o NEG de Private Service Connect que apuntan a los servicios y las API de Google compatibles.

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.

Uno o más backends deben estar conectados al servicio de backend. Debido a que el permiso de un balanceador de cargas HTTP(S) interno es regional en vez de global, los clientes y los extremos o VM de backend deben estar todos en la misma región. Los backends pueden ser grupos de instancias o NEG con cualquiera de las siguientes opciones de configuración:

  • Grupos de instancias administrados (zonales o regionales)
  • Grupos de instancias no administrados (zonales)
  • Grupos de extremos de red

No puedes usar grupos de instancias y NEG en el mismo servicio de backend.

Backends y redes de VPC

Todos los backends deben estar ubicados en la misma red de VPC y región. 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 Balanceo de cargas de HTTP(S) interno y redes conectadas.

Subconjuntos de backend

La subdivisión de backend es una función opcional 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 HTTP(S) interno.

Verificación de estado

Una verificación de estado regional supervisa la preparación de las backends de manera periódica. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud.

Reglas de firewall

Un balanceador de cargas de HTTP(S) interno requiere las siguientes reglas de firewall:

Arquitecturas de VPC compartida

El balanceo de cargas de HTTP(S) interno admite redes que usan VPC compartida. La VPC compartida te permite mantener una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios. Tus equipos de desarrollo pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de cargas. Además, los administradores de red pueden administrar direcciones IP internas de forma segura y eficiente. 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 dos formas de configurar el balanceo de cargas HTTP(S) 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 Regla de reenvío Proxy de destino y mapa de URL Componentes de backend
Crea la red, las subredes (incluida la subred de solo proxy) necesarias y las direcciones IP internas en el proyecto host de la VPC compartida. La regla de reenvío externa se puede definir en el proyecto host o en un proyecto de servicio. El proxy de destino y el mapa de URL deben definirse en el mismo proyecto que la regla de reenvío.

Los servicios de backend y los backends pueden crearse 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. Este caso de uso se encuentra en Vista previa.

También puedes crear todos los componentes del balanceador de cargas y sus backends en un único proyecto de servicio.

Cada servicio de backend debe definirse en el mismo proyecto que las instancias de backend a las que hace referencia. Estas instancias deben estar en grupos de instancias vinculadas al servicio de backend como backends. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Debes crear la red, las subredes y las direcciones IP necesarias en el proyecto host. Luego, para los componentes del balanceador de cargas, puedes realizar una de las siguientes acciones:

En todos estos modelos de implementación, los clientes pueden acceder al balanceador de cargas si están en la misma red de VPC compartida y en la misma región 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.

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 del servicio entre proyectos.

La referencia del servicio entre proyectos brinda a los desarrolladores y administradores de servicios autonomía sobre la exposición de sus servicios mediante el balanceador de cargas administrado de forma central. Los administradores de proyectos de servicio usan el rol de IAM compute.loadBalancerServiceUser para otorgar acceso a los servicios de backend en sus proyectos.

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

Servicio entre proyectos que hace referencia al 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

Servicio entre proyectos que hace referencia al ejemplo 2: frontend del balanceador de cargas en el proyecto host; 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

Todos los componentes y backends del balanceador de cargas en un proyecto de servicio

En este modelo, todos los componentes y backends del balanceador de cargas están en un proyecto de servicio. Este modelo de implementación es compatible con todos los balanceadores de cargas de HTTP(S).

El balanceador de cargas usa direcciones IP y subredes del proyecto host.

Balanceo de cargas de HTTP(S) interno en la red de VPC compartida
Balanceador de cargas de HTTP(S) interno en la red de VPC compartida

Balanceador de cargas y backends en un proyecto host

En este modelo, la red de VPC compartida, los componentes del balanceador de cargas y los backends están en el proyecto host. Este modelo no separa las responsabilidades de la administración de red y del desarrollo del servicio.

La configuración de este modelo es la misma que la configuración del balanceador de cargas en una red de VPC independiente.

Tiempos de espera y reintentos

El balanceo de cargas de HTTP(S) interno tiene tres tipos de tiempos de espera distintos:
  • Un tiempo de espera del servicio de backend HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera para que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos. El rango completo de valores de tiempo de espera permitidos es de 1 a 2,147,483,647 segundos.

    Por ejemplo, si el valor del tiempo de espera del servicio de backend es el valor predeterminado de 30 segundos, los backends tienen 30 segundos para responder a las solicitudes. El balanceador de cargas vuelve a intentar la solicitud HTTP GET una vez si el backend cierra la conexión o se agota el tiempo de espera antes de enviar encabezados de respuesta al balanceador de cargas. Si el backend envía encabezados de respuesta o si la solicitud enviada al backend no es una solicitud HTTP GET, el balanceador de cargas no vuelve a intentarlo. Si el backend no responde en absoluto, el balanceador de cargas muestra una respuesta HTTP 5xx. Para estos balanceadores de cargas, puedes cambiar el valor de tiempo de espera a fin de que los backends tengan más o menos tiempo de responder a las solicitudes.

    El tiempo de espera del servicio de backend debe establecerse en el tiempo máximo posible desde el primer byte de la solicitud hasta el último byte de la respuesta para la interacción entre Envoy y tu backend. Si usas WebSockets, el tiempo de espera del servicio de backend se debe establecer en la duración máxima de un WebSocket, inactivo o activo.

    Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que un backend tarde más en mostrar respuestas HTTP
    • La conexión se actualiza a un WebSocket.

    El tiempo de espera del servicio de backend que establezcas es un objetivo mejor. No garantiza que las conexiones TCP subyacentes permanezcan abiertas durante el tiempo de espera.

    Puedes establecer el tiempo de espera del servicio de backend con el valor que desees. Sin embargo, establecerlo en un valor superior a un día (86,400 segundos) no significa que el balanceador de cargas mantendrá una conexión TCP en ejecución largo. Puede hacerlo, pero no así. Google reinicia los proxies de Envoy de forma periódica para las actualizaciones de software y el mantenimiento de rutina, y el tiempo de espera del servicio de backend no lo anula. Mientras más tiempo de espera el servicio de backend, más probable es que Google finalice una conexión TCP para el mantenimiento de Envoy. Te recomendamos que implementes la lógica de reintento para reducir el impacto de esos eventos.

    Para obtener más información, consulta Configuración del servicio de backend.

    Nota: El tiempo de espera del servicio de backend no es un tiempo de espera de HTTP inactivo (keepalive). Es posible que la entrada y salida (IO) del backend se bloquee debido a un cliente lento (por ejemplo, un navegador con conexión lenta). Este tiempo de espera no se toma en cuenta en el tiempo de espera del servicio de backend.

  • Un tiempo de espera de keepalive de HTTP, cuyo valor se fija en 10 minutos (600 segundos). Este valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos a fin de evitar que el backend cierre de forma prematura las conexiones. Este tiempo de espera no se aplica a WebSockets. En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos 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;
  • Un tiempo de espera de inactividad de la transmisión, cuyo valor se fija en 5 minutos (300 segundos) Este valor no se puede configurar. Las transmisiones HTTP se vuelven inactivas después de 5 minutos sin actividad.

Reintentos

Los reintentos se pueden configurar mediante 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) y dan como resultado respuestas HTTP 502, 503 o 504 se reintentan una vez. Las solicitudes HTTP POST no se reintentan. Este comportamiento predeterminado es equivalente a cuando retryConditions=["gateway-error"].

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 balanceo de cargas de HTTP(S) interno.

Accede a redes conectadas

Puedes acceder a un balanceador de cargas de HTTP(S) 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 Balanceo de cargas de HTTP(S) interno 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 dentro de la misma región. Si todos los backends están en mal estado, el balanceador de cargas muestra una respuesta HTTP 503 Service Unavailable.

Compatible con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud tienen compatibilidad nativa 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 muestra 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.

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 mediante 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 HTTP(S) 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.

  • El balanceo de cargas HTTP(S) interno no es compatible con las siguientes características:

  • Un balanceador de cargas HTTP(S) interno admite HTTP/2 solo a través de TLS.

  • Los clientes que se conectan a un balanceador de cargas de HTTP(S) 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 HTTP(S) interno debe tener exactamente un puerto.

  • El balanceo de cargas de HTTP(S) interno no es compatible con Cloud Trace.

  • Cuando se usa el balanceo de cargas de HTTP(S) 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 proyecto de servicio dentro del mismo entorno de VPC compartida. Este es un problema conocido, y esta forma de acceso se bloqueará en el futuro.

¿Qué sigue?