Información general sobre el balanceador de carga de aplicación interno

En este documento se presentan los conceptos que debes conocer para configurar balanceadores de carga de aplicaciones internos.

Un Google Cloud balanceador de carga de aplicaciones interno es un balanceador de carga de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios mediante una única dirección IP interna. El balanceador de carga de aplicaciones interno distribuye el tráfico HTTP y HTTPS a los backends alojados en varias plataformas, como Compute Engine, Google Kubernetes Engine (GKE) y Cloud Run. Google Cloud Para obtener más información, consulta los casos prácticos.

Modos de funcionamiento

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

• Balanceador de carga de aplicación interno entre regiones. Se trata de un balanceador de carga multirregional que se implementa como un servicio gestionado basado en el proxy Envoy de código abierto. El modo interregional te permite balancear la carga del tráfico a servicios de backend distribuidos en todo el mundo, así como gestionar el tráfico para que se dirija al backend más cercano. Este balanceador de carga también permite la alta disponibilidad. Colocar backends en varias regiones ayuda a evitar fallos en una sola región. Si los back-ends de una región no funcionan, el tráfico puede redirigirse a otra región.

• Balanceador de carga de aplicación interno regional. Se trata de un balanceador de carga regional que se implementa como un servicio gestionado basado en el proxy Envoy de código abierto. En el modo regional, los backends deben estar en una única región Google Cloud . Los clientes pueden estar limitados a esa región o pueden estar en cualquier región, en función de si el acceso global está inhabilitado o habilitado en la regla de reenvío. Este balanceador de carga tiene habilitadas funciones de control de tráfico avanzadas basadas en parámetros HTTP o HTTPS. Una vez configurado el balanceador de carga, asigna automáticamente proxies de Envoy para satisfacer tus necesidades de tráfico.

  En la siguiente tabla se describen las diferencias importantes entre los modos multirregión y regional:

  Modo del balanceador de carga	Función
  	Dirección IP virtual (VIP) del balanceador de carga	Acceso de cliente	Backends con balanceo de carga	Alta disponibilidad y conmutación por error
  Balanceador de carga de aplicación interno entre regiones	Asignada desde una subred de una región Google Cloud específica. Las direcciones IP virtuales de varias regiones pueden compartir el mismo servicio de backend global. Puedes configurar el balanceo de carga global basado en DNS mediante políticas de enrutamiento de DNS para dirigir las solicitudes de los clientes a la dirección VIP más cercana.	Siempre accesible a nivel mundial. Los clientes de cualquier Google Cloud región de una VPC pueden enviar tráfico al balanceador de carga.	Backends globales: el balanceador de carga puede enviar tráfico a backends de cualquier región.	Conmutación automática por error a backends en buen estado de la misma región o de otra.
  Balanceador de carga de aplicación interno regional	Asignada desde una subred de una región Google Cloud específica.	No se puede acceder a ellos de forma predeterminada en todo el mundo. También puedes habilitar el acceso global.	Backends regionales: el balanceador de carga solo puede enviar tráfico a backends que estén en la misma región que el proxy del balanceador de carga.	Conmutación automática por error a backends en buen estado de la misma región.

Identificar el modo

Consola

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

   Ir a Balanceo de carga

2. En la pestaña Balanceadores de carga, puedes ver el tipo de balanceador de carga, el protocolo y la región. Si el campo de la región está en blanco, el balanceador de carga está en modo interregional. En la siguiente tabla se resume cómo identificar el modo del balanceador de carga.

   Modo del balanceador de carga	Tipo de balanceador de carga	Tipo de acceso	Región
   Balanceador de carga de aplicación interno entre regiones	Aplicación	Interno
   Balanceador de carga de aplicación interno regional	Aplicación	Interno	Especifica una región.

gcloud

1. Para determinar el modo de un balanceador de carga, ejecuta el siguiente comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

   En el resultado del comando, comprueba el esquema de balanceo de carga, la región y el nivel de red. En la siguiente tabla se resume cómo identificar el modo del balanceador de carga.

   Modo del balanceador de carga	Esquema de balanceo de carga	Regla de reenvío
   Balanceador de carga de aplicación interno entre regiones	INTERNAL_MANAGED	Global
   Balanceador de carga de aplicación interno regional	INTERNAL_MANAGED	Regional

Importante: Una vez que hayas creado un balanceador de carga, no podrás editar su modo. En su lugar, debe eliminar el balanceador de carga y crear uno nuevo.

Arquitectura y recursos

En el siguiente diagrama se muestran los recursos de Google Cloud necesarios para los balanceadores de carga de aplicaciones internos:

Balanceador de carga de aplicación interno entre regiones

En este diagrama se muestran los componentes de una implementación de balanceador de carga de aplicaciones interno entre regiones en el nivel Premium dentro de la misma red VPC. Cada regla de reenvío global usa una dirección IP regional que los clientes utilizan para conectarse.

Componentes de un balanceador de carga de aplicación interno entre regiones (haz clic para ampliar).

Balanceador de carga de aplicación interno regional

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

Componentes del balanceador de carga de aplicación interno regional (haz clic para ampliar).

Para desplegar un balanceador de carga de aplicaciones interno, se necesitan los siguientes recursos:

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 carga de aplicaciones internos.

En la siguiente tabla se describen las diferencias entre las subredes solo proxy en los modos multirregión y regional. Los balanceadores de carga regionales y entre regiones no pueden compartir las mismas subredes.

Modo del balanceador de carga	Valor de la marca --purpose de la subred de solo proxy
Balanceador de carga de aplicación interno entre regiones	GLOBAL_MANAGED_PROXY El balanceador de carga basado en Envoy entre regiones debe tener una subred solo proxy en cada región en la que esté configurado. Los proxies de balanceadores de carga entre regiones de la misma región y red comparten la misma subred de solo proxy.
Balanceador de carga de aplicación interno regional	REGIONAL_MANAGED_PROXY Todos los balanceadores de carga regionales basados en Envoy de una región y una red de VPC comparten la misma subred de solo proxy.

Además:

• Las subredes de solo proxy se usan únicamente para los proxies de Envoy, no para tus back-ends.
• Las máquinas virtuales o los endpoints de backend de todos los balanceadores de carga de aplicaciones internos de una región y una red de VPC reciben conexiones de la subred de solo proxy.
• La dirección IP virtual de un balanceador de carga de aplicaciones interno no se encuentra en la subred de solo proxy. La dirección IP del balanceador de carga se define mediante su regla de reenvío interna gestionada, que se describe más abajo.

Regla de reenvío y dirección IP

Las reglas de reenvío dirigen el tráfico a una configuración de balanceo de carga según la dirección IP, el puerto y el protocolo. Esta configuración consta de un proxy de destino y un servicio de backend.

Especificación de la dirección IP. Cada regla de reenvío hace referencia a 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 que quieras usar o dejar que Cloud Load Balancing te asigne una. Te recomendamos que reserves una dirección IP estática. De lo contrario, tendrás que actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que elimines 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 carga. La dirección IP de la regla de reenvío es la dirección IP del balanceador de carga (a veces se denomina dirección IP virtual o VIP). Los clientes que se conecten a un balanceador de carga deben usar la versión 1.1 de HTTP o una posterior. Para ver la lista completa de protocolos admitidos, consulta Comparativa de funciones de los balanceadores de carga.

La dirección IP interna asociada a la regla de reenvío puede proceder de una subred de la misma red y región que tus backends.

Especificación de puerto. Cada regla de reenvío de un balanceador de carga de aplicaciones puede hacer referencia a un único puerto del intervalo 1-65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para que usen la misma dirección IP interna (VIP) y hagan referencia al mismo proxy HTTP o HTTPS de destino, siempre que la combinación general de dirección IP, puerto y protocolo sea única para cada regla de reenvío. De esta forma, puedes usar un único balanceador de carga con un mapa de URLs compartido como proxy de varias aplicaciones.

El tipo de regla de reenvío, dirección IP y esquema de balanceo de carga que utilizan los balanceadores de carga de aplicaciones internos depende del modo del balanceador de carga.

Balanceador de carga de aplicación interno entre regiones
	Regla de reenvío	Método globalForwardingRules.insert
	Dirección IP regional	addresses.insert method
	Esquema de balanceo de carga	INTERNAL_MANAGED
	Dirección IP (opcional)	SHARED_LOADBALANCER_VIP
	Enrutamiento del cliente al frontend del balanceador de carga	El acceso global está habilitado de forma predeterminada para permitir que los clientes de cualquier región de una VPC accedan a tu balanceador de carga. Los back-ends pueden estar en varias regiones.
Balanceador de carga de aplicación interno regional
	Regla de reenvío	forwardingRules.insert method
	Dirección IP regional	addresses.insert method
	Esquema de balanceo de carga	INTERNAL_MANAGED
	Dirección IP (opcional)	SHARED_LOADBALANCER_VIP
	Enrutamiento del cliente al frontend del balanceador de carga	Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan a tu balanceador de carga. Los backends también deben estar en la misma región que el balanceador de carga.

Reglas de reenvío y redes de VPC

En esta sección se describe cómo se asocian las reglas de reenvío que usan los balanceadores de carga de aplicaciones internos con las redes de VPC.

Modo del balanceador de carga	Asociación de redes VPC
Balanceador de carga de aplicación interno entre regiones Balanceador de carga de aplicación interno regional	Las direcciones IPv4 internas regionales siempre se encuentran en redes de VPC. Cuando creas la regla de reenvío, debes especificar la subred de la que se toma la dirección IP interna. Esta subred debe estar en la misma región y red VPC en la que se haya creado una subred de solo proxy. Por lo tanto, hay una asociación de red implícita.

Proxy de destino

Un proxy HTTP o HTTPS de destino finaliza las conexiones HTTP(S) de los clientes. El proxy HTTP(S) consulta el mapa de URLs para determinar cómo enrutar el tráfico a los backends. Un proxy HTTPS de destino usa un certificado SSL para autenticarse ante los clientes.

El balanceador de carga conserva el encabezado Host de la solicitud del cliente original. El balanceador de carga también añade dos direcciones IP al encabezado X-Forwarded-For:

• La dirección IP del cliente que se conecta al balanceador de carga.
• La dirección IP de la regla de reenvío del balanceador de carga

Si no hay ningún 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, se conserva otra información, como las direcciones IP registradas por los proxies de camino al balanceador de carga, antes de las dos direcciones IP. El balanceador de carga no verifica ninguna dirección IP que preceda a las dos últimas direcciones IP de esta cabecera.

Si usas un proxy como servidor backend, este suele añadir más información al encabezado X-Forwarded-For, por lo que es posible que tu software tenga que tenerlo en cuenta. Las solicitudes proxy del balanceador de carga proceden de una dirección IP de la subred de solo proxy, y tu proxy de la instancia de backend puede registrar esta dirección, así como la dirección IP de la instancia de backend.

En función del tipo de tráfico que deba gestionar tu aplicación, puedes configurar un balanceador de carga con un proxy HTTP de destino o un proxy HTTPS de destino.

En la siguiente tabla se muestran las APIs de proxy de destino necesarias para los balanceadores de carga de aplicaciones internos:

Modo del balanceador de carga	Proxy de destino
Balanceador de carga de aplicación interno entre regiones	targetHttpProxies targetHttpsProxies
Balanceador de carga de aplicación interno regional	regionTargetHttpProxies regionTargetHttpsProxies

Certificados SSL

Los balanceadores de carga de aplicaciones internos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de carga.

En la siguiente tabla se especifica el tipo de certificados SSL que requieren los balanceadores de carga de aplicaciones internos en cada modo:

Modo del balanceador de carga	Tipo de certificado SSL
Balanceador de carga de aplicación interno entre regiones	Certificate Manager certificados autogestionados y certificados gestionados por Google. Certificate Manager admite los siguientes tipos de certificados gestionados por Google: Autorización de DNS con DNS público. Para obtener más información, consulta Implementar un certificado global gestionado por Google con autorización de DNS. Servicio de Autoridades de Certificación privadas. Para obtener más información, consulta Crear un certificado gestionado por Google emitido por tu instancia de servicio de CA. No se admiten los certificados gestionados por Google con autorización de balanceador de carga. No se admiten certificados SSL de Compute Engine.
Balanceador de carga de aplicación interno regional	Certificados SSL regionales de Compute Engine Certificate Manager certificados autogestionados regionales y certificados gestionados por Google. Certificate Manager admite los siguientes tipos de certificados gestionados por Google: Certificados regionales gestionados por Google con autorización de DNS por proyecto. Para obtener más información, consulta Implementar un certificado regional gestionado por Google. Certificados regionales gestionados por Google con el Servicio de Autoridades de Certificación privadas. Para obtener más información, consulta Implementar un certificado regional gestionado por Google con el servicio de CA. No se admiten los certificados gestionados por Google con autorización de balanceador de carga.

Mapas de URL

El proxy HTTP(S) de destino usa mapas de URLs para determinar la ruta en función de los atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend específicos. El mapa de URLs puede especificar acciones adicionales, como reescribir encabezados, enviar redirecciones a los clientes y configurar políticas de tiempo de espera (entre otras).

En la siguiente tabla se especifica el tipo de mapa de URLs que requieren los balanceadores de carga de aplicaciones internos en cada modo:

Modo del balanceador de carga	Tipo de mapa de URLs
Balanceador de carga de aplicación interno entre regiones	urlMaps
Balanceador de carga de aplicación interno regional	regionUrlMaps

Servicio de backend

Un servicio de backend proporciona información de configuración al balanceador de carga para que pueda dirigir las solicitudes a sus backends, como grupos de instancias de Compute Engine o grupos de puntos finales de red (NEGs). Para obtener más información sobre los servicios de backend, consulta el resumen de los servicios de backend.

Ámbito del servicio de backend

En la siguiente tabla se indica qué recurso y ámbito de servicio de backend utilizan los balanceadores de carga de aplicaciones internos:

Modo del balanceador de carga	Recurso de servicio de backend
Balanceador de carga de aplicación interno entre regiones	backendServices
Balanceador de carga de aplicación interno regional	regionBackendServices

Protocolo a los backends

Los servicios de backend de los balanceadores de carga de aplicaciones deben usar uno de los siguientes protocolos para enviar solicitudes a los backends:

• HTTP, que usa HTTP/1.1 y no usa TLS
• HTTPS, que usa HTTP/1.1 y TLS
• HTTP/2, que usa HTTP/2 y TLS (no se admite HTTP/2 sin cifrado).
• H2C, que usa HTTP/2 a través de TCP. No se requiere TLS. H2C no es compatible con los balanceadores de carga de aplicación clásicos.

El balanceador de carga solo usa el protocolo de servicio de backend que especifiques para comunicarse con sus backends. El balanceador de carga no recurre a otro protocolo si no puede comunicarse con los backends mediante el protocolo del servicio de backend especificado.

No es necesario que el protocolo del servicio de backend coincida con el protocolo que usan los clientes para comunicarse con el balanceador de carga. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de carga mediante HTTP/2, pero el balanceador de carga puede comunicarse con los backends mediante HTTP/1.1 (HTTP o HTTPS).

Backends

En la siguiente tabla se especifican las funciones de backend admitidas por los balanceadores de carga de aplicaciones internos en cada modo.

Modo del balanceador de carga	Backends admitidos en un servicio de backend^1						Admite segmentos de backend	Admite Cloud Armor	Compatible con Cloud CDN	Compatible con IAP	Admite Service Extensions
	Grupos de instancias^2	NEGs zonales^3	NEGs de Internet	NEGs sin servidor	NEGs híbridas	NEGs de Private Service Connect
Balanceador de carga de aplicación interno entre regiones				Cloud Run
Balanceador de carga de aplicación interno regional				Cloud Run

¹ Los backends de un servicio de backend deben ser del mismo tipo: todos grupos de instancias o todos NEGs del mismo tipo. Una excepción a esta regla es que se pueden usar tanto NEGs zonales como NEGs híbridos en el mismo servicio de backend para admitir una arquitectura híbrida.GCE_VM_IP_PORT

² Se admiten combinaciones de grupos de instancias sin gestionar por zonas, gestionados por zonas y gestionados regionales en el mismo servicio de backend. Cuando uses el autoescalado en un grupo de instancias gestionado que sea un backend de dos o más servicios de backend, configura la política de autoescalado del grupo de instancias para que use varias señales.

Los NEGs por zonas ³ deben usar endpoints GCE_VM_IP_PORT.

Back-ends y redes de VPC

Nota: En esta sección se describe la asociación de redes de VPC para las implementaciones en las que el servicio de backend y los backends del balanceador de carga se encuentran en el mismo proyecto que la regla de reenvío. Si también quieres que el servicio de backend esté en un proyecto diferente al de la regla de reenvío, debes configurar el balanceador de carga en un entorno de VPC compartida con referencia de servicios entre proyectos

.

Las restricciones sobre la ubicación de los back-ends dependen del tipo de back-end.

• En el caso de los grupos de instancias, los NEGs zonales y los NEGs de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y en la misma región que el servicio de backend. Sin embargo, un balanceador de carga puede hacer referencia a un backend que utilice una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de carga y la red de VPC de backend se puede configurar mediante el emparejamiento entre redes de VPC, los túneles de Cloud VPN, las vinculaciones de VLAN de Cloud Interconnect o un marco de Network Connectivity Center.

  Definición de la red de backend

  • En el caso de los NEG zonales y los NEG híbridos, debes especificar explícitamente la red de VPC al crear el NEG.
  • En el caso de los grupos de instancias gestionados, la red VPC se define en la plantilla de instancia.
  • En los grupos de instancias no gestionados, la red VPC del grupo de instancias se configura para que coincida con la red VPC de la interfaz nic0 de la primera VM que se añade al grupo de instancias.

  Requisitos de red del backend

  La red de tu backend debe cumplir uno de los siguientes requisitos de red:

  • La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.

  • La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el emparejamiento entre redes de VPC. Debes configurar los intercambios de rutas de subred para permitir la comunicación entre la subred solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints de backend.

• Tanto la red de VPC del backend como la red de VPC de la regla de reenvío deben ser radios de VPC conectados al mismo hub de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy de la red de VPC de la regla de reenvío y las subredes que usan las instancias o los endpoints de backend.

• En el resto de los tipos de backend, todos los backends deben estar ubicados en la misma red VPC y región.

Backends e interfaces de red

Si usas backends de grupos de instancias, los paquetes siempre se envían a nic0. Si quieres enviar paquetes a interfaces que no sean nic0 (ya sean NICs virtuales o interfaces de red dinámicas), usa back-ends de NEG.

Si usas backends de NEG por zonas, los paquetes se envían a la interfaz de red que represente el endpoint en el NEG. Los endpoints del NEG deben estar en la misma red VPC que la red VPC definida explícitamente del NEG.

Subconjunto de backend

Vista previa

Este producto o función está sujeto a los "Términos de las Ofertas de Acceso Previo a la Disponibilidad General" de la sección Términos Generales de los Servicios de los Términos Específicos de los Servicios. Los productos y las funciones previos a la disponibilidad general están disponibles tal cual y pueden tener una compatibilidad y asistencia limitadas. Para obtener más información, consulta las descripciones de las fases de lanzamiento.

Subconjunto de backend es una función opcional compatible con los balanceadores de carga de aplicaciones internos regionales que mejora el rendimiento y la escalabilidad asignando un subconjunto de backends a cada una de las instancias proxy.

De forma predeterminada, el subconjunto de backend está inhabilitado. Para obtener información sobre cómo habilitar esta función, consulta Subconjuntos de backend para balanceadores de carga de aplicación internos regionales.

Comprobaciones del estado

Cada servicio de backend especifica una comprobación del estado que monitoriza periódicamente la disponibilidad de los backends para recibir una conexión del balanceador de carga. De esta forma, se reduce el riesgo de que las solicitudes se envíen a backends que no puedan atenderlas. Las comprobaciones de estado no comprueban si la aplicación funciona.

Para que las comprobaciones del estado se realicen correctamente, debes crear una regla de cortafuegos de entrada que permita que las comprobaciones del estado lleguen a tus instancias de backend. Normalmente, las sondas de comprobación del estado proceden del mecanismo de comprobación del estado centralizado de Google. Sin embargo, en el caso de los NEGs híbridos, las comprobaciones de estado se originan en la subred de solo proxy. Para obtener más información, consulta Comprobaciones de estado de Envoy distribuidas.

Protocolo de comprobación del estado

Aunque no es obligatorio y no siempre es posible, es recomendable usar una comprobación de estado cuyo protocolo coincida con el protocolo del servicio backend. Por ejemplo, una comprobación del estado de HTTP/2 prueba con mayor precisión la conectividad HTTP/2 con los back-ends. Por el contrario, los balanceadores de carga de aplicaciones internos que usan backends de NEG híbridos no admiten comprobaciones de estado de gRPC. Para consultar la lista de protocolos de comprobación del estado admitidos, consulta las funciones de balanceo de carga en la sección Comprobaciones del estado.

En la siguiente tabla se especifica el ámbito de las comprobaciones de estado admitidas por los balanceadores de carga de aplicaciones internos:

Modo del balanceador de carga	Tipo de comprobación del estado
Balanceador de carga de aplicación interno entre regiones	healthChecks
Balanceador de carga de aplicación interno regional	regionHealthChecks

Para obtener más información sobre las comprobaciones del estado, consulta lo siguiente:

• Información general sobre las comprobaciones del estado
• Crear comprobaciones del estado

Reglas de cortafuegos

Un balanceador de carga de aplicaciones interno requiere las siguientes reglas de cortafuegos:

• Una regla de permiso de entrada que permite el tráfico de los intervalos centrales de comprobación de estado de Google. Para obtener más información sobre los intervalos de direcciones IP de las sondas de comprobación de estado específicas y por qué es necesario permitir el tráfico procedente de ellas, consulta Intervalos de IP de las sondas y reglas de firewall.
• Una regla de entrada que permita el tráfico de la subred de solo proxy.

Hay ciertas excepciones a los requisitos de las reglas de cortafuegos para estos intervalos:

• No es necesario permitir el tráfico de los intervalos de sondeo de comprobación del estado de Google para los NEGs híbridos. Sin embargo, si utilizas una combinación de NEGs híbridos y zonales en un mismo servicio de backend, debes permitir el tráfico de los intervalos de sondeo de comprobación de estado de Google para los NEGs zonales.
• En el caso de los NEGs de Internet regionales, las comprobaciones del estado son opcionales. El tráfico de los balanceadores de carga que usan NEGs de Internet regionales procede de la subred solo de proxy y, a continuación, se traduce mediante NAT (con Cloud NAT) a direcciones IP de NAT asignadas de forma manual o automática. Este tráfico incluye tanto las comprobaciones del estado como las solicitudes de los usuarios del balanceador de carga a los backends. Para obtener más información, consulta NEGs regionales: usar una pasarela de Cloud NAT.

Acceso de cliente

Los clientes pueden estar en la misma red o en una red de VPC conectada mediante el emparejamiento entre redes de VPC.

En el caso de los balanceadores de carga de aplicaciones internos entre regiones, el acceso global está habilitado de forma predeterminada. Los clientes de cualquier región de una VPC pueden acceder a tu balanceador de carga.

En el caso de los balanceadores de carga de aplicaciones internos regionales, los clientes deben estar en la misma región que el balanceador de carga de forma predeterminada. Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan a tu balanceador de carga.

En la siguiente tabla se resume el acceso de los clientes a los balanceadores de carga de aplicaciones internos regionales:

Acceso global inhabilitado	Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de carga. También deben estar en la misma red de VPC que el balanceador de carga o en una red de VPC conectada a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC.	Los clientes pueden estar en cualquier región. Sin embargo, deben estar en la misma red de VPC que el balanceador de carga o en una red de VPC conectada a la red de VPC del balanceador de carga mediante el emparejamiento entre redes de VPC.
Los clientes on‐premise pueden acceder al balanceador de carga a través de túneles de Cloud VPN o vinculaciones de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de carga.	Los clientes locales pueden acceder al balanceador de carga a través de túneles de Cloud VPN o vinculaciones de VLAN. Estos túneles o archivos adjuntos pueden estar en cualquier región.

Asistencia de GKE

GKE usa balanceadores de carga de aplicaciones internos de las siguientes formas:

• Las pasarelas internas creadas con el controlador de pasarela de GKE pueden usar cualquier modo de un balanceador de carga de aplicaciones interno. Puedes controlar el modo del balanceador de carga eligiendo un GatewayClass. El controlador de pasarela de GKE siempre usa back-ends de NEG zonales GCE_VM_IP_PORT.

• Los objetos Ingress internos creados con el controlador Ingress de GKE siempre son balanceadores de carga de aplicación internos regionales. El controlador de Ingress de GKE siempre usa backends de NEG zonales GCE_VM_IP_PORT.

• Puedes usar GCE_VM_IP_PORT NEG zonales creados y gestionados por Servicios de GKE como backends de cualquier balanceador de carga de aplicaciones o balanceador de carga de red proxy. Para obtener más información, consulta Balanceo de carga nativo de contenedores mediante NEG de zona independientes.

Arquitecturas de VPC compartida

Los balanceadores de carga de aplicaciones internos admiten redes que usan VPC compartida. La VPC compartida permite a las organizaciones conectar recursos de varios proyectos a una red de VPC común para que puedan comunicarse entre sí de forma segura y eficiente mediante IPs internas de esa red. Si no conoces las VPC compartidas, consulta la documentación general sobre las VPC compartidas.

Hay muchas formas de configurar un balanceador de carga de aplicaciones interno en una red de VPC compartida. Independientemente del tipo de implementación, todos los componentes del balanceador de carga deben estar en la misma organización.

Subredes y direcciones IP	Componentes de frontend	Componentes de backend
Crea la red y las subredes necesarias (incluida la subred de solo proxy) en el proyecto host de la VPC compartida. La dirección IP interna del balanceador de carga se puede definir en el proyecto host o en un proyecto de servicio, pero debe usar una subred de la red de VPC compartida que quieras en el proyecto host. La dirección en sí procede del intervalo 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 URLs asociado deben definirse en el mismo proyecto. Este proyecto puede ser el proyecto del host o un proyecto de servicio.	Puedes hacer una de las siguientes acciones: Crea servicios de backend y backends (grupos de instancias, NEGs sin servidor o cualquier otro tipo de backend admitido) en el mismo proyecto de servicio que los componentes de frontend. Crea servicios de backend y backends (grupos de instancias, grupos de endpoints de red sin servidor u otros tipos de backend admitidos) en tantos proyectos de servicio como necesites. Un solo mapa de URLs puede hacer referencia a servicios de backend de 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 comprobaciones de estado asociadas a los servicios de backend también deben definirse en el mismo proyecto que el servicio de backend.

Aunque puedes crear todos los componentes de balanceo de carga y los backends en el proyecto host de VPC compartida, este tipo de implementación no separa las responsabilidades de administración de la red y de desarrollo de servicios.

Todos los componentes y backends del balanceador de carga de un proyecto de servicio

En el siguiente diagrama de arquitectura se muestra una implementación estándar de VPC compartida en la que todos los componentes y backends del balanceador de carga se encuentran en un proyecto de servicio. Todos los balanceadores de carga de aplicaciones admiten este tipo de implementación.

El balanceador de carga usa direcciones IP y subredes del proyecto host. Los clientes pueden acceder a un balanceador de carga de aplicaciones interno si están en la misma red de VPC compartida y región que el balanceador de carga. Los clientes pueden estar ubicados en el proyecto host, en un proyecto de servicio vinculado o en cualquier red conectada.

Balanceador de carga de aplicaciones interno en una red de VPC compartida (haz clic en la imagen para ampliarla).

Back-ends sin servidor en un entorno de VPC compartida

En el caso de un balanceador de carga de aplicaciones interno que utilice un backend de NEG sin servidor, el servicio de Cloud Run de respaldo debe estar en el mismo proyecto de servicio que el servicio de backend y el NEG sin servidor. Los componentes de frontend del balanceador de carga (regla de reenvío, proxy de destino y mapa de URLs) se pueden crear en el proyecto del host, en el mismo proyecto de servicio que los componentes de backend o en cualquier otro proyecto de servicio del mismo entorno de VPC compartida.

Referencia de servicios entre proyectos

La referencia de servicios entre proyectos es un modelo de implementación en el que el frontend y el mapa de URLs del balanceador de carga se encuentran en un proyecto, mientras que el servicio de backend y los backends del balanceador de carga están en otro proyecto.

La referencia de servicios entre proyectos permite a las organizaciones configurar un balanceador de carga central y dirigir el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puede gestionar de forma centralizada todas las reglas y políticas de enrutamiento del tráfico en un solo mapa de URLs. También puedes asociar el balanceador de carga a un único conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar el número de balanceadores de carga necesarios para desplegar tu aplicación y reducir los costes operativos, los requisitos de cuota y la capacidad de gestión.

Si asignas un proyecto diferente a cada uno de tus equipos funcionales, también puedes separar los roles dentro de tu organización. Los propietarios de los servicios pueden centrarse en crear servicios en proyectos de servicios, mientras que los equipos de redes pueden aprovisionar y mantener balanceadores de carga en otro proyecto. Ambos pueden conectarse mediante la referencia de servicios entre proyectos.

Los propietarios de los servicios pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a ellos mediante el balanceador de carga. Esto se consigue mediante un rol de gestión de identidades y accesos especial llamado rol de usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser).

En el caso de los balanceadores de carga de aplicaciones internos, la referencia de servicios entre proyectos solo se admite en entornos de VPC compartida.

Para saber cómo configurar una VPC compartida para un balanceador de carga de aplicaciones interno (con y sin referencia de servicios entre proyectos), consulta Configurar un balanceador de carga de aplicaciones interno con una VPC compartida.

Notas de uso de la referencia de servicios 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. Se admiten todos los demás tipos de backend.
• Google Cloud No diferencia entre recursos (por ejemplo, servicios backend) que tengan el mismo nombre en varios proyectos. Por lo tanto, cuando utilices referencias de servicios entre proyectos, te recomendamos que uses nombres de servicios backend únicos en todos los proyectos de tu organización.

Ejemplo 1: Frontend y backend del balanceador de carga en diferentes proyectos de servicio

A continuación, se muestra un ejemplo de una implementación de VPC compartida en la que el frontend y el mapa de URLs del balanceador de carga se crean en el proyecto de servicio A, y el mapa de URLs hace referencia a un servicio de backend en el proyecto de servicio B.

En este caso, los administradores de red o los administradores de balanceadores de carga del proyecto de servicio A necesitan acceder a los servicios backend del proyecto de servicio B. Los administradores del proyecto de servicio B conceden el rol Usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de carga del proyecto de servicio A que quieran hacer referencia al servicio de backend del proyecto de servicio B.

Componentes frontend y backend del balanceador de carga en diferentes proyectos de servicio (haz clic para ampliar).

Ejemplo 2: Frontend del balanceador de carga en el proyecto host y backends en proyectos de servicio

A continuación, se muestra un ejemplo de una implementación de VPC compartida en la que el frontend y el mapa de URLs del balanceador de carga se crean en el proyecto del host, y los servicios de backend (y los backends) se crean en proyectos de servicio.

En este caso, los administradores de red o los administradores de balanceadores de carga del proyecto host necesitan acceder a los servicios backend del proyecto de servicio. Los administradores del proyecto de servicio conceden el rol Usuario de servicios de balanceador de carga de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de carga del proyecto host A que quieran hacer referencia al servicio de backend del proyecto de servicio.

Frontend del balanceador de carga y mapa de URLs en el proyecto host (haga clic para ampliar).

Tiempos de espera y reintentos

Los balanceadores de carga de aplicaciones internos admiten los siguientes tipos de tiempos de espera:

Tipo y descripción del tiempo de espera	Valores predeterminados	Admite valores personalizados
		Interregional	Regional
Tiempo de espera del servicio de backend Tiempo de espera de la solicitud y la respuesta. Representa el tiempo máximo permitido entre que el balanceador de carga envía el primer byte de una solicitud al backend y que el backend devuelve el último byte de la respuesta HTTP al balanceador de carga. Si el backend no ha devuelto toda la respuesta HTTP al balanceador de carga en este plazo, se descartarán los datos de respuesta restantes.	En el caso de los NEGs sin servidor de un servicio de backend, el tiempo es de 60 minutos. Para todos los demás tipos de backend de un servicio de backend: 30 segundos
Tiempo de espera de keep-alive HTTP del cliente Es el tiempo máximo que puede estar inactiva la conexión TCP entre un cliente y el proxy Envoy gestionado del balanceador de carga. Se puede usar la misma conexión TCP para varias solicitudes HTTP.	610 segundos
Tiempo de espera de keep-alive HTTP del backend Cantidad máxima de tiempo que puede estar inactiva la conexión TCP entre el proxy Envoy gestionado del balanceador de carga y un backend. 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 el tiempo máximo que espera el balanceador de carga a que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto en los NEGs sin servidor, el valor predeterminado del tiempo de espera del servicio de backend es de 30 segundos.

Por ejemplo, si quiere descargar un archivo de 500 MB y el valor del tiempo de espera del servicio backend es de 90 segundos, el balanceador de carga espera que el backend entregue el archivo completo de 500 MB en 90 segundos. Es posible que el tiempo de espera del servicio de backend no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de carga ha recibido al menos los encabezados de respuesta HTTP del backend, devuelve los encabezados de respuesta completos y la mayor parte posible del cuerpo de la respuesta que haya podido obtener durante el tiempo de espera del servicio de backend.

Te recomendamos que definas el tiempo de espera del servicio de backend como el periodo más largo que creas que tu backend necesitará para procesar una respuesta HTTP. Si el software que se ejecuta en tu backend necesita más tiempo para procesar una solicitud HTTP y devolver toda la respuesta, te recomendamos que aumentes el tiempo de espera del servicio de backend.

El tiempo de espera del servicio backend acepta valores entre 1 y 2,147,483,647 segundos. Sin embargo, los valores más altos no son opciones de configuración prácticas. Google Cloud tampoco garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el tiempo de espera del servicio backend. Los sistemas cliente deben implementar una lógica de reintento en lugar de depender de que una conexión TCP esté abierta durante largos periodos.

En el caso de las conexiones WebSocket que se usan con balanceadores de carga de aplicaciones internos, las conexiones WebSocket activas no siguen el tiempo de espera del servicio de backend. Las conexiones websockets inactivas se cierran después del tiempo de espera del servicio backend.

Google Cloud reinicia periódicamente o cambia el número de tareas de software de Envoy. Cuanto mayor sea el valor del tiempo de espera del servicio backend, más probable será que los reinicios o las sustituciones de tareas de Envoy finalicen las conexiones TCP.

Para configurar el tiempo de espera del servicio backend, utiliza uno de los siguientes métodos:

Consola

Modifica el campo Tiempo de espera del servicio de backend del balanceador de carga.

gcloud

Usa el comando gcloud compute backend-services update para modificar el parámetro --timeout del recurso del servicio de backend.

API

Modifica el parámetro timeoutSec del recurso regionBackendServices.

Tiempo de espera de keep-alive HTTP del cliente

El tiempo de espera de keep-alive HTTP del cliente representa el tiempo máximo que puede estar inactiva una conexión TCP entre el cliente (descendente) y un proxy de Envoy. El valor predeterminado del tiempo de espera de keep-alive HTTP del cliente es de 610 segundos. Puedes configurar el tiempo de espera con un valor entre 5 y 1200 segundos.

El tiempo de espera de keep-alive de HTTP también se denomina tiempo de espera de inactividad de TCP.

El tiempo de espera de keep-alive de HTTP del cliente del balanceador de carga debe ser superior al tiempo de espera de keep-alive de HTTP (inactividad de TCP) que usan los clientes o proxies de nivel inferior. Si un cliente de nivel inferior tiene un tiempo de espera de keep-alive de HTTP (inactividad de TCP) mayor que el tiempo de espera de keep-alive de HTTP del cliente del balanceador de carga, es posible que se produzca una condición de carrera. Desde el punto de vista de un cliente de nivel inferior, se permite que una conexión TCP establecida esté inactiva durante más tiempo del permitido por el balanceador de carga. Esto significa que el cliente de nivel inferior puede enviar paquetes después de que el balanceador de carga considere que la conexión TCP está cerrada. Cuando esto ocurre, el balanceador de carga responde con un paquete de restablecimiento (RST) de TCP.

Cuando vence el tiempo de espera de keep-alive HTTP del cliente, el GFE o el proxy Envoy envían un FIN TCP al cliente para cerrar la conexión correctamente.

Tiempo de espera de keep-alive HTTP del backend

Los balanceadores de carga de aplicaciones internos son proxies que usan una primera conexión TCP entre el cliente (descendente) y un proxy Envoy, y una segunda conexión TCP entre el proxy Envoy y tus backends.

Es posible que las conexiones TCP secundarias del balanceador de carga no se cierren después de cada solicitud, sino que permanezcan abiertas para gestionar varias solicitudes y respuestas HTTP. El tiempo de espera de keep-alive HTTP del backend define el tiempo de espera de inactividad de TCP entre el balanceador de carga y tus backends. El tiempo de espera de keep-alive HTTP del backend no se aplica a los websockets.

El tiempo de espera de mantenimiento activo del backend es de 10 minutos (600 segundos) y no se puede cambiar. De esta forma, se asegura de que el balanceador de carga mantenga las conexiones inactivas durante al menos 10 minutos. Después de este periodo, el balanceador de carga puede enviar paquetes de finalización al backend en cualquier momento.

El tiempo de espera de keepalive del backend del balanceador de carga debe ser inferior al tiempo de espera de keepalive que usa el software que se ejecuta en tus backends. De esta forma, se evita una condición de carrera en la que el sistema operativo de tus back-ends podría cerrar las conexiones TCP con un restablecimiento de TCP (RST). Como el tiempo de espera de keepalive del backend del balanceador de carga no se puede configurar, debes configurar el software de backend para que su valor de tiempo de espera de keepalive HTTP (inactividad de TCP) sea superior a 600 segundos.

Cuando caduca el tiempo de espera de keep-alive HTTP del backend, el GFE o el proxy Envoy envían un FIN TCP a la VM del backend para cerrar la conexión correctamente.

En la siguiente tabla se indican los cambios necesarios para modificar los valores de tiempo de espera de keep-alive en el software de servidor web habitual.

Software de servidor web	Parámetro	Ajuste 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 URLs. El número predeterminado de reintentos (numRetries) es 1. El perTryTimeout máximo configurable es de 24 horas.

Si no hay una política de reintentos, las solicitudes incorrectas que no tengan un cuerpo HTTP (por ejemplo, las solicitudes GET) que den como resultado respuestas HTTP 502, 503 o 504 se reintentarán una vez.

Las solicitudes HTTP POST no se vuelven a intentar.

Las solicitudes reintentadas solo generan una entrada de registro para la respuesta final.

Para obtener más información, consulta Registros y monitorización de balanceadores de carga de aplicación internos.

Acceder a redes conectadas

Tus clientes pueden acceder a un balanceador de carga de aplicaciones interno de tu red de VPC desde una red conectada mediante lo siguiente:

• Emparejamiento entre redes VPC
• Cloud VPN y Cloud Interconnect

Para ver ejemplos detallados, consulta Balanceadores de carga de aplicación internos y redes conectadas.

Afinidad de sesión

La afinidad de sesión, configurada en el servicio de backend de los balanceadores de carga de aplicaciones, intenta enviar las solicitudes de un cliente concreto al mismo backend siempre que el número de instancias o endpoints de backend en buen estado se mantenga constante y que la instancia o el endpoint de backend seleccionado anteriormente no haya alcanzado su capacidad. La capacidad objetivo del modo de balanceo determina cuándo el backend alcanza su capacidad.

En la siguiente tabla se describen los diferentes tipos de opciones de afinidad de sesión que se admiten en los distintos balanceadores de carga de aplicaciones. En la sección Tipos de afinidad de sesión, se explica con más detalle cada tipo de afinidad de sesión.

Tabla: ajustes de afinidad de sesión admitidos

Producto

Opciones de afinidad de sesión

Balanceador de carga de aplicación interno entre regiones Balanceador de carga de aplicación interno regional

Ninguno (NONE) IP de cliente (CLIENT_IP) Cookie generada (GENERATED_COOKIE) Campo de encabezado (HEADER_FIELD) Cookie HTTP (HTTP_COOKIE) Afinidad basada en cookies con estado (STRONG_COOKIE_AFFINITY) Nota: El valor predeterminado efectivo de la política de localidad de balanceo de carga (localityLbPolicy) cambia en función de los ajustes de afinidad de sesión. Si no se configura la afinidad de sesión (es decir, si la afinidad de sesión mantiene el valor predeterminado NONE), el valor predeterminado de localityLbPolicy es ROUND_ROBIN. Si la afinidad de sesión tiene un valor distinto de NONE, el valor predeterminado de localityLbPolicy es MAGLEV. En el caso del balanceador de carga de aplicación interno, no configures la afinidad de sesión si usas la división del tráfico ponderada. Si lo haces, tendrá prioridad la configuración de división del tráfico ponderada.

Tenga en cuenta lo siguiente al configurar la afinidad de sesión:

• No confíes en la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión, excepto la afinidad de sesión basada en cookies con estado, puede dejar de funcionar cuando cambia el número de back-ends activos y correctos. Para obtener más información, consulta Pérdida de la afinidad de sesión.

• Los valores predeterminados de las marcas --session-affinity y --subsetting-policy son NONE, y solo se puede asignar un valor diferente a una de ellas a la vez.

Tipos de afinidad de sesión

La afinidad de sesión de los balanceadores de carga de aplicaciones internos se puede clasificar en una de las siguientes categorías:

• Afinidad de sesión basada en hash (NONE, CLIENT_IP)
• Afinidad de sesión basada en encabezados HTTP (HEADER_FIELD)
• Afinidad de sesión basada en cookies (GENERATED_COOKIE, HTTP_COOKIE y STRONG_COOKIE_AFFINITY)

Afinidad de sesión basada en hash

En el caso de la afinidad de sesión basada en hash, el balanceador de carga usa el algoritmo de hash coherente para seleccionar un backend apto. El ajuste de afinidad de sesión determina qué campos del encabezado IP se usan para calcular el hash.

La afinidad de sesión basada en hash puede ser de los siguientes tipos:

• Ninguno
• Afinidad de IP de cliente

Ninguno

Si el ajuste de afinidad de sesión es NONE, no significa que no haya afinidad de sesión. Esto significa que no se ha configurado explícitamente ninguna opción de afinidad de sesión.

El hashing siempre se realiza para seleccionar un backend. Si la afinidad de sesión es NONE, el balanceador de carga usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas está formado por la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino.

El valor predeterminado de la afinidad de sesión es NONE.

Afinidad de IP de cliente

La afinidad de sesión por IP de cliente (CLIENT_IP) es un hash de dos tuplas creado a partir de las direcciones IP de origen y de destino del paquete. La afinidad de IP de cliente reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend, siempre que este tenga capacidad y se mantenga en buen estado.

Cuando uses la afinidad de IP de cliente, ten en cuenta lo siguiente:

• La dirección IP de destino del paquete solo es la misma que la dirección IP de la regla de reenvío del balanceador de carga si el paquete se envía directamente al balanceador de carga.
• Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si el paquete se procesa mediante un sistema NAT o proxy intermedio antes de enviarse a un balanceador de carga. Google Cloud En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs backend pueden recibir más conexiones o solicitudes que otras.

Afinidad de sesión basada en encabezados HTTP

Con la afinidad de campo de encabezado (HEADER_FIELD), las solicitudes se enrutan a los backends en función del valor del encabezado HTTP del campo consistentHash.httpHeaderName del servicio de backend. Para distribuir las solicitudes entre todos los back-ends disponibles, cada cliente debe usar un valor de encabezado HTTP diferente.

La afinidad de campo de encabezado se admite cuando se cumplen las siguientes condiciones:

• La política de localidad de balanceo de carga es RING_HASH o MAGLEV.
• El consistentHash del servicio de backend especifica el nombre del encabezado HTTP (httpHeaderName).

Afinidad de sesión basada en cookies

La afinidad de sesión basada en cookies puede ser de los siguientes tipos:

• Afinidad de cookie generada
• Afinidad de cookies HTTP
• Afinidad de sesión basada en cookies con estado

Afinidad de cookie generada

Cuando usas la afinidad basada en cookies generadas (GENERATED_COOKIE), el balanceador de carga incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial.

El nombre de la cookie generada varía en función del tipo de balanceador de carga.

Producto	Nombre de la cookie
Balanceadores de carga de aplicación internos entre regiones	GCILB
Balanceadores de carga de aplicación internos regionales	GCILB

El atributo de ruta de la cookie generada siempre es una barra inclinada (/), por lo que se aplica a todos los servicios backend del mismo mapa de URLs, siempre que los demás servicios backend también usen la afinidad de cookie generada.

Puedes configurar el valor del tiempo de vida (TTL) de la cookie entre 0 y 1,209,600 segundos (ambos incluidos) mediante el parámetro de servicio backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor predeterminado de TTL es 0.

Cuando el cliente incluye la cookie de afinidad de sesión generada en el encabezado de solicitud Cookie de las solicitudes HTTP, el balanceador de carga dirige esas solicitudes a la misma instancia o endpoint backend, siempre que la cookie de afinidad de sesión siga siendo válida. Para ello, se asigna el valor de la cookie a un índice que hace referencia a una instancia de backend o a un endpoint específicos, y se asegura de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookies generada, configura los siguientes ajustes de localityLbPolicy y de modo de balanceo:

• En el caso de los grupos de instancias de backend, usa el modo de balanceo RATE.
• Para el localityLbPolicy del servicio de backend, usa RING_HASH o MAGLEV. Si no defines explícitamente localityLbPolicy, el balanceador de carga usará MAGLEV como valor predeterminado implícito.

Para obtener más información, consulta Pérdida de la afinidad de sesión.

Afinidad de cookies HTTP

Cuando usas la afinidad basada en cookies HTTP (HTTP_COOKIE), el balanceador de carga incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial. Usted especifica el nombre, la ruta y el tiempo de vida (TTL) de la cookie.

Todos los balanceadores de carga de aplicaciones admiten la afinidad basada en cookies HTTP.

Puedes configurar los valores de TTL de la cookie mediante segundos, fracciones de segundo (en nanosegundos) o ambos (segundos y fracciones de segundo en nanosegundos) con los siguientes parámetros de servicio backend y valores válidos:

• consistentHash.httpCookie.ttl.seconds puede tener un valor entre 0 y 315576000000 (ambos incluidos).
• consistentHash.httpCookie.ttl.nanos puede tener un valor entre 0 y 999999999 (ambos incluidos). Como las unidades son nanosegundos, 999999999 significa .999999999 segundos.

Si no se especifican consistentHash.httpCookie.ttl.seconds ni consistentHash.httpCookie.ttl.nanos, se usará el valor del parámetro de servicio backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor predeterminado de TTL es 0.

Cuando el cliente incluye la cookie de afinidad de sesión HTTP en el encabezado de solicitud Cookie de las solicitudes HTTP, el balanceador de carga dirige esas solicitudes a la misma instancia o endpoint backend, siempre que la cookie de afinidad de sesión siga siendo válida. Para ello, se asigna el valor de la cookie a un índice que hace referencia a una instancia de backend o a un endpoint específicos, y se asegura de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookies HTTP, configura los siguientes ajustes de localityLbPolicy y de modo de balanceo:

• En el caso de los grupos de instancias de backend, usa el modo de balanceo RATE.
• Para el localityLbPolicy del servicio de backend, usa RING_HASH o MAGLEV. Si no defines explícitamente localityLbPolicy, el balanceador de carga usará MAGLEV como valor predeterminado implícito.

Para obtener más información, consulta Pérdida de la afinidad de sesión.

Afinidad de sesión basada en cookies con estado

Cuando usas la afinidad basada en cookies con estado (STRONG_COOKIE_AFFINITY), el balanceador de carga incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial. Usted especifica el nombre, la ruta y el tiempo de vida (TTL) de la cookie.

Todos los balanceadores de carga de aplicaciones, excepto los clásicos, admiten la afinidad basada en cookies con estado.

Puedes configurar los valores de TTL de las cookies usando segundos, fracciones de segundo (en nanosegundos) o ambos (segundos y fracciones de segundo en nanosegundos). La duración representada por strongSessionAffinityCookie.ttl no puede ser superior a dos semanas (1.209.600 segundos).

El valor de la cookie identifica una instancia o un endpoint de backend seleccionados codificando la instancia o el endpoint seleccionados en el propio valor. Mientras la cookie sea válida, si el cliente incluye la cookie de afinidad de sesión en el encabezado de solicitud Cookie de las solicitudes HTTP posteriores, el balanceador de carga dirigirá esas solicitudes a la instancia o el endpoint de backend seleccionados.

A diferencia de otros métodos de afinidad de sesión:

• La afinidad basada en cookies con estado no tiene requisitos específicos para el modo de balanceo ni para la política de localidad de balanceo de carga (localityLbPolicy).

• La afinidad basada en cookies con estado no se ve afectada cuando el autoescalado añade una instancia nueva a un grupo de instancias gestionado.

• La afinidad basada en cookies con estado no se ve afectada cuando el autoescalado elimina una instancia de un grupo de instancias gestionado a menos que se elimine la instancia seleccionada.

• La afinidad basada en cookies con estado no se ve afectada cuando la reparación automática elimina una instancia de un grupo de instancias gestionado, a menos que se elimine la instancia seleccionada.

Para obtener más información, consulta Pérdida de la afinidad de sesión.

Significado de TTL cero para las afinidades basadas en cookies

Todas las afinidades de sesión basadas en cookies, como la afinidad de cookie generada, la afinidad de cookie HTTP y la afinidad basada en cookies con estado, tienen un atributo TTL.

Un TTL de cero segundos significa que el balanceador de carga no asigna un atributo Expires a la cookie. En este caso, el cliente trata la cookie como una cookie de sesión. La definición de sesión varía en función del cliente:

• Algunos clientes, como los navegadores web, conservan la cookie durante toda la sesión de navegación. Esto significa que la cookie persiste en varias solicitudes hasta que se cierra la aplicación.

• Otros clientes tratan una sesión como una única solicitud HTTP y descartan la cookie inmediatamente después.

Pérdida de la afinidad de sesión

Todas las opciones de afinidad de sesión requieren lo siguiente:

• La instancia o el endpoint de backend seleccionados deben seguir configurados como backend. La afinidad de sesión puede dejar de funcionar cuando se produce uno de los siguientes eventos:
  • Se elimina la instancia seleccionada de su grupo de instancias.
  • La función de autoescalado o de reparación automática de grupos de instancias gestionados elimina la instancia seleccionada de su grupo de instancias gestionado.
  • Eliminas el endpoint seleccionado de su NEG.
  • Elimina del servicio de backend el grupo de instancias o el NEG que contenga la instancia o el endpoint seleccionados.
• La instancia o el endpoint de backend seleccionados deben mantener su buen estado. La afinidad de sesión puede dejar de funcionar cuando la instancia o el endpoint seleccionados no superan las comprobaciones de estado.

A excepción de la afinidad de sesión basada en cookies con estado, todas las opciones de afinidad de sesión tienen los siguientes requisitos adicionales:

• El grupo de instancias o NEG que contiene la instancia o el endpoint seleccionados no debe estar lleno, tal como se define en su capacidad objetivo. En el caso de los grupos de instancias gestionados regionales, el componente de zona del grupo de instancias que contiene la instancia seleccionada no debe estar lleno. La afinidad de sesión puede dejar de funcionar cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEGs no. Como la capacidad puede cambiar de forma impredecible al usar el modo de balanceo UTILIZATION, debes usar el modo de balanceo RATE o CONNECTION para minimizar las situaciones en las que la afinidad de sesión pueda fallar.

• El número total de instancias o endpoints de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend configurados y se puede interrumpir la afinidad de sesión:

  • Añadir nuevas instancias o endpoints:

    • Añade instancias a un grupo de instancias que ya tengas en el servicio de backend.
    • El autoescalado de grupos de instancias gestionados añade instancias a un grupo de instancias gestionado en el servicio de backend.
    • Añade puntos finales a un NEG que ya esté en el servicio backend.
    • Añade grupos de instancias o NEGs no vacíos al servicio de backend.

  • Para quitar cualquier instancia o endpoint, no solo la instancia o el endpoint seleccionados:

    • Elimina cualquier instancia de un backend de grupo de instancias.
    • El autoescalado o la reparación automática de grupos de instancias gestionados elimina cualquier instancia de un backend de grupo de instancias gestionado.
    • Puedes quitar cualquier endpoint de un backend de NEG.
    • Elimina cualquier grupo de instancias de backend o NEG no vacío del servicio de backend.

• El número total de instancias o endpoints de backend en buen estado debe mantenerse constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend correctos y se puede interrumpir la afinidad de sesión:

  • Cualquier instancia o endpoint supera su comprobación de estado y pasa de estar en mal estado a estar en buen estado.
  • Si alguna instancia o endpoint no supera la comprobación del estado, pasa de estar en buen estado a no estarlo o a agotar el tiempo de espera.

Conmutación por error

Si un backend deja de estar en buen estado, el tráfico se redirige automáticamente a los backends que sí lo están.

En la siguiente tabla se describe el comportamiento de la conmutación por error en cada modo:

Modo del balanceador de carga	Comportamiento de conmutación por error	Comportamiento cuando todos los backends están en mal estado
Balanceador de carga de aplicación interno entre regiones	Conmutación automática por error a backends en buen estado de la misma región u otras regiones. El tráfico se distribuye entre los backends en buen estado de varias regiones en función de la distribución del tráfico configurada.	Devuelve el código HTTP 503
Balanceador de carga de aplicación interno regional	Conmutación automática por error a backends en buen estado de la misma región. El proxy Envoy envía tráfico a los backends en buen estado de una región en función de la distribución del tráfico configurada.	Devuelve el código HTTP 503

Alta disponibilidad y conmutación por error entre regiones

Balanceadores de carga de aplicación internos regionales

Para conseguir una alta disponibilidad, despliega varios balanceadores de carga de aplicación internos regionales en las regiones que mejor se adapten al tráfico de tu aplicación. A continuación, usa una política de enrutamiento por geolocalización de Cloud DNS para detectar si un balanceador de carga responde durante una interrupción regional. Una política de geolocalización dirige el tráfico a la región disponible más cercana en función del origen de la solicitud del cliente. La comprobación del estado está disponible de forma predeterminada para los balanceadores de carga de aplicaciones internos.

Balanceadores de carga de aplicación internos entre regiones

Puedes configurar un balanceador de carga de aplicaciones interno entre regiones en varias regiones para obtener las siguientes ventajas:

1. Si el balanceador de carga de aplicaciones interno entre regiones de una región falla, las políticas de enrutamiento de DNS dirigen el tráfico a un balanceador de carga de aplicaciones interno entre regiones de otra región.

   En el ejemplo de implementación de alta disponibilidad se muestra lo siguiente:

   • Un balanceador de carga de aplicaciones interno entre regiones con una dirección IP virtual (VIP) de frontend en las regiones RegionA y RegionB de tu red de VPC. Tus clientes se encuentran en la región RegionA.
   • Puedes hacer que el balanceador de carga sea accesible mediante VIPs de frontend de dos regiones y usar políticas de enrutamiento de DNS para devolver el VIP óptimo a tus clientes. Usa políticas de enrutamiento por geolocalización si quieres que tus clientes usen la VIP que esté más cerca geográficamente.
   • Las políticas de enrutamiento de DNS pueden detectar si un VIP no responde durante una interrupción regional y devolver el siguiente VIP más óptimo a tus clientes, lo que asegura que tu aplicación siga funcionando incluso durante las interrupciones regionales.

   

   Balanceador de carga de aplicación interno entre regiones con una implementación de alta disponibilidad (haz clic en la imagen para ampliarla).

2. Si los backends de una región concreta no funcionan, el tráfico del balanceador de carga de aplicación interno entre regiones se transfiere correctamente a los backends de otra región.

   En el ejemplo de implementación de conmutación por error entre regiones se muestra lo siguiente:

   • Un balanceador de carga de aplicaciones interno entre regiones con una dirección IP virtual de frontend en la RegionAregión de tu red de VPC. Tus clientes también se encuentran en la región RegionA.
   • Un servicio de backend global que hace referencia a los backends de las regiones RegionA y RegionB Google Cloud .
   • Cuando los back-ends de la región RegionA no funcionan, el tráfico se redirige a la región RegionB.

   

   Balanceador de carga de aplicación interno entre regiones con una implementación de conmutación por error entre regiones (haz clic en la imagen para ampliarla).

Compatibilidad con WebSocket

Google Cloud Los balanceadores de carga basados en HTTP(S) admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como protocolo del backend. El balanceador de carga no requiere ninguna configuración para proxy las conexiones WebSocket.

El protocolo WebSocket proporciona un canal de comunicación bidireccional entre los clientes y el balanceador de carga. Para obtener más información, consulta el RFC 6455.

El protocolo WebSocket funciona de la siguiente manera:

1. El balanceador de carga reconoce una solicitud Upgrade de websocket de un cliente HTTP o HTTPS. La solicitud contiene los encabezados Connection: Upgrade y Upgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con websockets.
2. El backend envía una respuesta Upgrade de WebSocket. La instancia de backend envía una respuesta 101 switching protocol con los encabezados Connection: Upgrade y Upgrade: websocket, así como otros encabezados de respuesta relacionados con websockets.
3. El balanceador de carga proxyiza el tráfico bidireccional durante la conexión actual.

Si la instancia de backend devuelve un código de estado 426 o 502, el balanceador de carga cierra la conexión.

La afinidad de sesión para websockets funciona igual que para cualquier otra solicitud. Para obtener más información, consulta Afinidad de sesión.

Compatibilidad con HTTP/2

HTTP/2 es una revisión importante del protocolo HTTP/1. Hay dos modos de compatibilidad con HTTP/2:

• HTTP/2 sobre TLS
• HTTP/2 en texto sin cifrar a través de TCP

HTTP/2 sobre TLS

Se admite HTTP/2 a través de TLS para las conexiones entre los clientes y el balanceador de carga de aplicaciones externo, así como para las conexiones entre el balanceador de carga y sus backends.

El balanceador de carga negocia automáticamente HTTP/2 con los clientes como parte del handshake TLS mediante la extensión TLS ALPN. Aunque un balanceador de carga esté configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de carga.

Si un cliente no admite HTTP/2 y el balanceador de carga está configurado para usar HTTP/2 entre el balanceador de carga y las instancias de backend, el balanceador de carga puede negociar una conexión HTTPS o aceptar solicitudes HTTP no seguras. A continuación, el balanceador de carga transforma esas solicitudes HTTPS o HTTP para proxy las solicitudes a través de HTTP/2 a las instancias de backend.

Para usar HTTP/2 sobre TLS, debes habilitar TLS en tus backends y definir el protocolo del servicio de backend comoHTTP2. Para obtener más información, consulta Cifrado desde el balanceador de carga hasta los back-ends.

Número máximo de transmisiones simultáneas de HTTP/2

El ajuste HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de flujos que acepta un endpoint, iniciados por el peer. El valor que anuncia un cliente HTTP/2 a un balanceador de carga no tiene ningún sentido, ya que el balanceador de carga no inicia flujos al cliente.Google Cloud

En los casos en los que el balanceador de carga usa HTTP/2 para comunicarse con un servidor que se ejecuta en una máquina virtual, el balanceador de carga respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado por el servidor, hasta un valor máximo de 100. En la dirección de la solicitud (Google Cloud balanceador de carga → servidor gRPC), el balanceador de carga usa el marco SETTINGS inicial del servidor gRPC para determinar cuántos flujos por conexión se pueden usar simultáneamente. Si el servidor anuncia un valor superior a 100, el balanceador de carga usa 100 como número máximo de flujos simultáneos. Si se anuncia un valor cero, el balanceador de carga no podrá reenviar solicitudes al servidor, lo que podría provocar errores.

Tamaño de la tabla de encabezados dinámica de HTTP/2

HTTP/2 mejora significativamente HTTP/1.1 con funciones como la multiplexación y la compresión de encabezados HPACK. HPACK usa una tabla dinámica que mejora la compresión de encabezados, lo que hace que todo sea más rápido. Para saber cómo influyen los cambios dinámicos en el tamaño de la tabla de encabezados en HTTP/2, cómo puede mejorar el rendimiento esta función y cómo un error específico en varias bibliotecas de clientes HTTP puede provocar problemas en la compresión de encabezados HPACK, consulta el artículo de la comunidad.

Limitaciones de HTTP/2

• HTTP/2 entre el balanceador de carga y la instancia puede requerir significativamente más conexiones TCP a la instancia que HTTP o HTTPS. La agrupación de conexiones, una optimización que reduce el número de estas conexiones con HTTP o HTTPS, no está disponible con HTTP/2. Por lo tanto, es posible que observes latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
• HTTP/2 entre el balanceador de carga y el backend no admite la ejecución del protocolo WebSocket a través de un solo flujo de una conexión HTTP/2 (RFC 8441).
• HTTP/2 entre el balanceador de carga y el backend no admite el envío desde el servidor.
• La tasa de errores de gRPC y el volumen de solicitudes no se muestran en laGoogle Cloud API ni en la Google Cloud consola. Si el endpoint de gRPC devuelve un error, los registros del balanceador de carga y los datos de monitorización informan del código de estado HTTP 200 OK.

HTTP/2 en texto sin formato a través de TCP (H2C)

HTTP/2 en texto sin cifrar a través de TCP, también conocido como H2C, te permite usar HTTP/2 sin TLS. H2C se admite en las siguientes conexiones:

• Conexiones entre los clientes y el balanceador de carga. No se requiere ninguna configuración especial.

• Conexiones entre el balanceador de carga y sus backends.

  Para configurar H2C en las conexiones entre el balanceador de carga y sus backends, debes definir el protocolo del servicio de backend como H2C.

La compatibilidad con H2C también está disponible para los balanceadores de carga creados con el controlador de GKE Gateway y Cloud Service Mesh.

H2C no es compatible con los balanceadores de carga de aplicación clásicos.

Compatibilidad con gRPC

gRPC es un framework de código abierto para llamadas a procedimientos remotos. Se basa en el estándar HTTP/2. Estos son algunos de los usos de gRPC:

• Sistemas distribuidos de baja latencia y alta escalabilidad
• Desarrollar clientes móviles que se comuniquen con un servidor en la nube
• Diseñar nuevos protocolos que deben ser precisos, eficientes e independientes del idioma
• Diseño por capas para habilitar la extensión, la autenticación y el registro

Para usar gRPC con tus aplicaciones, debes proxy las solicitudes de extremo a extremo a través de HTTP/2. Google Cloud Para ello, crea un balanceador de carga de aplicación con una de las siguientes configuraciones:

• Para el tráfico sin cifrar de extremo a extremo (sin TLS): crea un balanceador de carga HTTP (configurado con un proxy HTTP de destino). Además, puedes configurar el balanceador de carga para que use HTTP/2 en las conexiones sin cifrar entre el balanceador de carga y sus backends. Para ello, define el protocolo del servicio de backend como H2C.

• Para el tráfico cifrado de extremo a extremo (con TLS): crea un balanceador de carga HTTPS (configurado con un proxy HTTPS de destino y un certificado SSL). El balanceador de carga negocia HTTP/2 con los clientes como parte del handshake SSL mediante la extensión TLS ALPN.

  Además, debes asegurarte de que los backends puedan gestionar el tráfico TLS y configurar el balanceador de carga para que use HTTP/2 en las conexiones cifradas entre el balanceador de carga y sus backends. Para ello, debes definir el protocolo del servicio de backend como HTTP2.

  Es posible que el balanceador de carga siga negociando HTTPS con algunos clientes o que acepte solicitudes HTTP no seguras en un balanceador de carga configurado para usar HTTP/2 entre el balanceador de carga y las instancias de backend. El balanceador de carga transforma esas solicitudes HTTP o HTTPS para proxy las solicitudes a través de HTTP/2 a las instancias de backend.

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 carga de aplicaciones interno usa HTTPS como protocolo del servicio de backend, puede negociar TLS 1.2 o 1.3 con el backend.

Compatibilidad con TLS mutuo

TLS mutuo (mTLS) es un protocolo estándar del sector para la autenticación mutua entre un cliente y un servidor. mTLS ayuda a asegurar que tanto el cliente como el servidor se autentiquen entre sí verificando que cada uno tiene un certificado válido emitido por una autoridad de certificación (CA) de confianza. A diferencia de TLS estándar, donde solo se autentica el servidor, mTLS requiere que tanto el cliente como el servidor presenten certificados, lo que confirma la identidad de ambas partes antes de establecer la comunicación.

Todos los balanceadores de carga de aplicaciones admiten mTLS. Con mTLS, el balanceador de carga solicita que el cliente envíe un certificado para autenticarse durante el handshake TLS con el balanceador de carga. Puedes configurar un almacén de confianza de Gestor de certificados que el balanceador de carga usará para validar la cadena de confianza del certificado de cliente.

Para obtener más información sobre mTLS, consulta Autenticación TLS mutua.

Limitaciones

• No hay ninguna garantía de que una solicitud de un cliente de una zona de la región se envíe a un backend que esté en la misma zona que el cliente. La afinidad de sesión no reduce la comunicación entre zonas.

• Los balanceadores de carga de aplicaciones internos no son compatibles con las siguientes funciones:

  • Cloud CDN
  • Certificados SSL gestionados por Google de Compute Engine (se admiten los certificados gestionados por Google de Certificate Manager)

• Para usar certificados de Certificate Manager con balanceadores de carga de aplicación internos, debes usar la API o la CLI de gcloud. La consolaGoogle Cloud no admite certificados de Gestor de certificados.

• Un balanceador de carga de aplicaciones interno solo admite HTTP/2 a través de TLS.

• Los clientes que se conecten a un balanceador de carga de aplicaciones interno deben usar la versión 1.1 de HTTP o una posterior. No se admite HTTP 1.0.

• Google Cloud no te avisa si tu subred solo de proxy se queda sin direcciones IP.

• La regla de reenvío interna que usa tu balanceador de carga de aplicación interno debe tener exactamente un puerto.

• Cuando se usa un balanceador de carga de aplicaciones interno con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes de los proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyecto de servicio del mismo entorno de VPC compartida. Se trata de un problema conocido.

• Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el tiempo de espera del servicio backend. Los sistemas cliente deben implementar una lógica de reintento en lugar de depender de que una conexión TCP esté abierta durante largos periodos.

• Los balanceadores de carga de aplicaciones internos no admiten Cloud Functions (1.ª gen.) ni App Engine. Para obtener más información, consulta la descripción general de los NEGs sin servidor: balanceadores de carga admitidos.

• Los balanceadores de carga de aplicación internos no admiten Cloud Trace.

Siguientes pasos

• Para configurar el balanceo de carga en una configuración de VPC compartida, consulta Configurar un balanceador de carga de aplicaciones interno con VPC compartida.

• Para configurar el balanceo de carga de los servicios que se ejecutan en pods de GKE, consulta los artículos Despliegue de gateways de GKE, Balanceo de carga nativo de contenedores con NEG independientes y la sección Asignar un balanceador de carga de aplicaciones interno a NEG independientes.

• Para gestionar el recurso de subred de solo proxy, consulta Subredes de solo proxy para balanceadores de carga basados en Envoy.

• Para configurar el subconjunto de backend en balanceadores de carga de aplicación internos regionales, consulta Subconjunto de backend.

• Para configurar un balanceador de carga de aplicación interno regional con Private Service Connect, consulta Acceder a las APIs de Google regionales a través de backends.

• Para insertar lógica personalizada en la ruta de datos de balanceo de carga, configura las extensiones de Cloud Load Balancing.