En este documento, se presentan los conceptos que necesitas para configurar un balanceador de cargas de aplicaciones externo.
Un balanceador de cargas de aplicaciones externo es un balanceador de cargas de capa 7 basado en proxies que te permite ejecutar y escalar tus servicios detrás de una sola dirección IP externa. El balanceador de cargas de aplicaciones externo distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de plataformas de Google Cloud (como Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage, etcétera), así como backends externos conectados a través de Internet o a través de la conectividad híbrida. Para obtener más detalles, consulta Descripción general del balanceador de cargas de aplicaciones: casos de uso.
Modos de operación
Puedes configurar un balanceador de cargas de aplicaciones externo en los siguientes modos:
- Balanceador de cargas de aplicaciones externo global Este es un balanceador de cargas global que se implementa como un servicio administrado en Google Front End (GFE). Usa el proxy de Envoy de código abierto para admitir capacidades de administración de tráfico avanzadas, como la duplicación de tráfico, la división de tráfico basada en el peso, las transformaciones de encabezados de solicitud o respuesta y mucho más.
- Balanceador de cargas de aplicaciones clásico Este es el balanceador de cargas de aplicaciones externo clásico que es global en el nivel Premium, pero se puede configurar para que sea regional en el nivel Standard. Este balanceador de cargas se implementa en Google Front End (GFE). Los GFEs se distribuyen globalmente y operan juntos mediante el plano de control y la red global de Google.
- Balanceador de cargas de aplicaciones externo regional Este es un balanceador de cargas regional se implementa como un servicio administrado en el proxy de código abierto de Envoy. Incluye capacidades avanzadas de administración de tráfico, como duplicación de tráfico, división de tráfico basada en pesos, transformaciones de encabezados basados en solicitudes y respuestas, y mucho más.
| Modo de balanceador de cargas | Casos de uso recomendados | Funciones |
|---|---|---|
| Balanceador de cargas de aplicaciones externo global | Usa este balanceador de cargas para cargas de trabajo de HTTP(S) externas con usuarios de todo el mundo o servicios de backend en varias regiones. |
|
| Balanceador de cargas de aplicaciones clásico | Este balanceador de cargas es global en el nivel Premium. En el nivel de servicio de red Premium, este balanceador de cargas ofrece balanceo de cargas multirregión, intenta dirigir el tráfico al backend en buen estado más cercano que tenga capacidad y termina el tráfico HTTP(S) lo más cerca posible de tus usuarios. Para obtener detalles sobre el proceso de distribución de solicitudes, consulta Distribución de tráfico. En el nivel de servicio de red estándar, este balanceador de cargas puede distribuir el tráfico a los backends solo en una sola región. |
|
| Balanceador de cargas de aplicaciones externo regional | Este balanceador de cargas contiene muchas de las características del balanceador de cargas de aplicaciones clásico existente, junto con capacidades de administración avanzada del tráfico. Usa este balanceador de cargas si deseas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento). Este balanceador de cargas se puede configurar en el nivel Premium o Estándar. |
|
Identifica el modo
Consola de Cloud
En la consola de Google Cloud, ve a la página Balanceo de cargas.
En la pestaña Balanceadores de cargas, se muestran el tipo, el protocolo y la región del balanceador de cargas. Si la región está en blanco, entonces el balanceador de cargas es global. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
| Modo de balanceador de cargas | >Tipo de balanceador de cargas | Tipo de acceso | Región |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo global | Aplicación | Externo | |
| Balanceador de cargas de aplicaciones clásico | Application(Classic) | Externo | |
| Balanceador de cargas de aplicaciones externo regional | Aplicación | Externo | Especifica una región |
gcloud
- Para determinar el modo de un balanceador de cargas, ejecuta el siguiente comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
En el resultado del comando, verifica el esquema de balanceo de cargas, la región y el nivel de red. En la siguiente tabla, se resume cómo identificar el modo del balanceador de cargas.
| Modo de balanceador de cargas | Esquema de balanceo de cargas | Regla de reenvío | Nivel de red |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo global | EXTERNAL_MANAGED | Global | Premium |
| Balanceador de cargas de aplicaciones clásico | EXTERNO | Global | Estándar o Premium |
| Balanceador de cargas de aplicaciones externo regional | EXTERNAL_MANAGED | Especifica una región | Estándar o Premium |
Arquitectura
Los siguientes recursos son necesarios para implementar el balanceador de cargas de aplicaciones externo:
Solo para balanceadores de cargas de aplicaciones regionales externos, se usa una subred de solo proxy para enviar conexiones desde el balanceador de cargas a los backends.
Una regla de reenvío externo especifica una dirección IP externa, un puerto y un proxy HTTP(S) de destino global. Los clientes usan la dirección IP y el puerto para conectarse al balanceador de cargas.
Un proxy HTTP(S) de destino regional recibe una solicitud del cliente. El proxy HTTP(S) evalúa la solicitud mediante el mapa de URL para tomar decisiones de enrutamiento de tráfico. El proxy también puede autenticar las comunicaciones a través del uso de certificados SSL.
- En el balanceo de cargas de HTTPS, el proxy HTTPS de destino usa certificados SSL para demostrar su identidad a los clientes. Un proxy HTTPS de destino admite hasta una cantidad determinada de certificados SSL.
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). Según la decisión de enrutamiento, el proxy reenvía las solicitudes del cliente a servicios de backend o buckets específicos. El mapa de URL puede especificar acciones adicionales, como el envío de redireccionamientos a los clientes.
Un servicio de backend distribuye solicitudes a backends en buen estado. Los balanceadores de cargas de aplicaciones externos globales también admiten buckets de backend. Uno o más backends deben estar conectados al servicio o al bucket de backend.
Una verificación de estado global supervisa de manera periódica la preparación de los backends. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud.
Reglas de firewall para que tus backends acepten sondeos de verificaciones de estado. Los balanceadores de cargas de aplicaciones regionales externos requieren una regla de firewall adicional para permitir que el tráfico de la subred de solo proxy llegue a los backends.
Global
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo global. Esta arquitectura se aplica al balanceador de cargas de aplicaciones externo global y al balanceador de cargas de aplicaciones clásico en el nivel Premium.
Regional
En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones externo regional.
Subred de solo proxy
Las subredes de solo proxy solo son necesarias para los balanceadores de cargas de aplicaciones externos regionales.
La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones externos regionales.
La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas regionales basados en Envoy en la misma región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy. Además:
- Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
- Las VM de backend o los extremos de todos los balanceadores de cargas de aplicaciones externos regionales en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
- La dirección IP del balanceador de cargas de aplicaciones externo regional 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 externa, que se describe a continuación.
Si creaste una subred de solo proxy con --purpose=INTERNAL_HTTPS_LOAD_BALANCER, deberás migrar el propósito de la subred a REGIONAL_MANAGED_PROXY antes de poder crear otro balanceador de cargas basado en Envoy en la misma región de la red de VPC.
Reglas de reenvío y direcciones IP
Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino, una asignación de URL y uno o más servicios de backend.
Especificación de la dirección IP. Cada regla de reenvío proporciona una única dirección IP que se puede usar en registros DNS para tu aplicación. No se requiere el balanceo de cargas basado en DNS. Puedes especificar una dirección IP para usarla o permitir que Cloud Load Balancing te asigne una.
Especificación de puerto Cada regla de reenvío para un balanceador de cargas de aplicaciones puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para usar la misma dirección IP externa (VIP) y hacer referencia al mismo proxy HTTP(S) de destino siempre que la combinación general de la dirección IP, el puerto y el protocolo son únicos para cada regla de reenvío. De esta manera, puedes usar un solo balanceador de cargas con un mapa de URL compartido como proxy para varias aplicaciones.
El tipo de regla de reenvío, la dirección IP y el esquema de balanceo de cargas que usan los balanceadores de cargas de aplicaciones externos dependen del modo del balanceador de cargas y del nivel de servicio de red en el que se encuentre el balanceador de cargas.
| Modo de balanceador de cargas | Nivel de servicio de red | Regla de reenvío, dirección IP y esquema de balanceo de cargas | Enrutamiento de Internet al frontend del balanceador de cargas |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo global | Nivel Premium |
Regla de reenvío externa global Esquema de balanceo de cargas: |
Solicitudes enrutadas al GFE más cercano al cliente en Internet. |
| Balanceador de cargas de aplicaciones clásico | Nivel Premium |
Regla de reenvío externa global Esquema de balanceo de cargas: |
Solicitudes enrutadas al GFE más cercano al cliente en Internet. |
| Nivel Estándar |
Regla de reenvío regional externa Esquema de balanceo de cargas: |
Solicitudes enrutadas a un GFE en la región del balanceador de cargas. | |
| Balanceador de cargas de aplicaciones externo regional | Nivel Premium o Estándar |
Regla de reenvío regional externa Esquema de balanceo de cargas: |
Las solicitudes llegan a Google Cloud en el PoP más cercano al cliente. Luego, las solicitudes se enrutan a través de la red principal premium de Google Cloud hasta que llegan a los proxies de Envoy en la misma región que el balanceador de cargas. |
EXTERNAL_MANAGED a
reglas de reenvío EXTERNAL. Sin embargo, los servicios de backend de EXTERNAL
no se pueden adjuntar a las reglas de reenvío de EXTERNAL_MANAGED.
Para aprovechar las funciones nuevas disponibles solo con el balanceador de cargas de aplicaciones externo global, te recomendamos que migres tus recursos EXTERNAL existentes a EXTERNAL_MANAGED con el proceso de migración que se describe en Cómo migrar recursos del balanceador de cargas de aplicaciones clásico al balanceador de cargas de aplicaciones externo global.
Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.
Reglas de reenvío y redes de VPC
En esta sección, se describe cómo las reglas de reenvío que usan los balanceadores de cargas de aplicaciones externos se asocian con las redes de VPC.
| Modo de balanceador de cargas | Asociación de redes de VPC |
|---|---|
| Balanceador de cargas de aplicaciones externo global, Balanceador de cargas de aplicaciones clásico |
No hay una red de VPC asociada. La regla de reenvío siempre usa una dirección IP que está fuera de la red de VPC. Por lo tanto, la regla de reenvío no tiene una red de VPC asociada. |
| Balanceador de cargas de aplicaciones externo regional | La red de VPC de la regla de reenvío es la red en la que se creó la subred de solo proxy. Debes especificar la red cuando creas la regla de reenvío. Según si usas una dirección IPv4 o un rango de direcciones IPv6, siempre hay una red de VPC explícita o implícita asociada con la regla de reenvío.
|
Proxies de destino
Los proxies de destino finalizan las conexiones HTTP(S) de los clientes. Una o más reglas de reenvío dirigen el tráfico al proxy de destino y este consulta el mapa de URL para determinar cómo dirigir el tráfico a los backends.
No dependas del proxy para conservar las mayúsculas de los nombres de encabezado de solicitud o respuesta. Por ejemplo, es posible que un encabezado de respuesta Server: Apache/1.0 aparezca en el cliente como server: Apache/1.0.
En la siguiente tabla, se especifica el tipo de proxy de destino que requieren los balanceadores de cargas de aplicaciones externos.
| Modo de balanceador de cargas | Tipos de proxy de destino | Encabezados agregados por proxy | Los Encabezados personalizados son compatibles |
|---|---|---|---|
| Balanceador de cargas de aplicaciones externo global | HTTP global, HTTPS global |
Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:
Los proxies también establecen el encabezado |
Configurado en el servicio o bucket de backend
No compatible con Cloud CDN |
| Balanceador de cargas de aplicaciones clásico | HTTP global, HTTPS global |
Los proxies configuran encabezados de solicitud o respuesta HTTP de la siguiente manera:
Los proxies también establecen el encabezado |
Configurado en el servicio o bucket de backend |
| Balanceador de cargas de aplicaciones externo regional | HTTP regional, HTTPS regional |
|
Configurado en el mapa de URL |
Además de los encabezados que agrega el proxy de destino, el balanceador de cargas ajusta otros encabezados HTTP de las siguientes maneras:
Para el balanceador de cargas de aplicaciones externo global, es posible que los encabezados de solicitud y respuesta se conviertan en minúsculas.
La única excepción es cuando usas backends de NEG de Internet globales con HTTP/1.1. Para obtener detalles sobre cómo se procesan los encabezados HTTP/1.1 con los NEG de Internet globales, consulta la descripción general de los NEG de Internet.
Para el balanceador de cargas de aplicaciones clásico, los encabezados de respuesta y solicitud se convierten en minúsculas, excepto cuando usas HTTP/1.1. Con HTTP/1.1, los encabezados están en mayúsculas y minúsculas. La primera letra de la clave del encabezado y todas las letras que siguen a un guion (
-) se escriben en mayúsculas para preservar la compatibilidad con clientes HTTP/1.1. Por ejemplo,user-agentse cambia aUser-Agent, ycontent-encodingse cambia aContent-Encoding.
- Algunos encabezados se combinan. Cuando hay varias instancias de la misma clave de encabezado (por ejemplo,
Via), el balanceador de cargas combina sus valores en una lista separada por comas para una sola clave de encabezado. Solo se agrupan los encabezados cuyos valores se pueden representar como una lista separada por comas. Otros encabezados, comoSet-Cookie, nunca se combinan.
Encabezado del host
Cuando el balanceador de cargas realiza la solicitud HTTP, el balanceador de cargas conserva el encabezado del host de la solicitud original.
Encabezado X-Forwarded-For
El balanceador de cargas agrega dos direcciones IP separadas por una sola coma al encabezado X-Forwarded-For en el siguiente orden:
- 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.
X-Forwarded-For: <client-ip>,<load-balancer-ip>
Si la solicitud incluye un encabezado X-Forwarded-For, el balanceador de cargas conserva el valor proporcionado antes de <client-ip>,<load-balancer-ip>:
X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>
Cuando ejecutas el software del proxy HTTP inverso en los backends del balanceador de cargas, el software puede adjuntar una o las siguientes dos direcciones IP al final del encabezado X-Forwarded-For:
La dirección IP del Google Front End (GFE) que se conectó al backend. Estas direcciones IP se encuentran en los rangos
130.211.0.0/22y35.191.0.0/16.La dirección IP del sistema de backend en sí.
Por lo tanto, un proceso ascendente después del backend de tu balanceador de cargas podría recibir un encabezado X-Forwarded-For con el siguiente formato:
<existing-values>,<client-ip>,<load-balancer-ip>,<GFE-IP>,<backend-IP>
Compatibilidad con Cloud Trace
El seguimiento no es compatible con los balanceadores de cargas de aplicaciones. Los balanceadores de cargas de aplicaciones global y clásico agregan el encabezado X-Cloud-Trace-Context si no está presente. El balanceador de cargas de aplicaciones externo regional no agrega este encabezado. Si el encabezado X-Cloud-Trace-Context ya está presente, pasa por los equilibradores de carga sin modificaciones. Sin embargo, el balanceador de cargas no exporta ningún registro ni intervalo.
Mapas de URL
Las asignaciones de URL definen los patrones de coincidencia para el enrutamiento basado en URL de las solicitudes a los servicios de backend apropiados. El mapa de URL te permite dividir el tráfico a través del análisis de los componentes de URL para enviar solicitudes a diferentes conjuntos de backends. Se define un servicio predeterminado para manejar cualquier solicitud que no coincida con una regla de coincidencia de ruta o una regla de host especificadas.
En algunas situaciones, como en el ejemplo de balanceo de cargas multirregional, es posible que no definas ninguna regla de URL y solo te bases en el servicio predeterminado.
Los mapas de URL admiten varias funciones avanzadas de administración de tráfico, como la dirección de tráfico basada en encabezados, la división de tráfico según el peso y la duplicación de solicitudes. Para obtener más información, consulta lo siguiente:
En la siguiente tabla, se especifica el tipo de mapa de URL que requieren los balanceadores de cargas de aplicaciones externos en cada modo.
| Modo de balanceador de cargas | Tipo de mapa de URL |
|---|---|
| Balanceador de cargas de aplicaciones externo global | Global |
| Balanceador de cargas de aplicaciones clásico | Global (solo con un subconjunto de las funciones compatibles) |
| Balanceador de cargas de aplicaciones externo regional | Regional |
Certificados SSL
Los balanceadores de cargas de aplicaciones externos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas.
Google Cloud proporciona dos métodos de configuración para asignar claves privadas y certificados SSL a los proxies HTTPS de destino: los certificados SSL de Compute Engine y el Administrador de certificados. Para obtener una descripción de cada configuración, consulta Métodos de configuración de certificados en la descripción general de certificados SSL.
Google Cloud proporciona dos tipos de certificado: autoadministrados y administrados por Google. Para obtener una descripción de cada tipo, consulta Tipos de certificados en la descripción general de certificados SSL.
El tipo de balanceador de cargas de aplicaciones externo (global, regional o clásico) determina qué métodos de configuración y tipos de certificados son compatibles. Para obtener más información, consulta Certificados y balanceadores de cargas de Google Cloud en la descripción general de certificados SSL.
Políticas de SSL
Las políticas de SSL especifican el conjunto de características de SSL que los balanceadores de cargas de Google Cloud usan cuando negocian SSL con los clientes.
De forma predeterminada, el balanceo de cargas HTTPS usa un conjunto de funciones de SSL que proporciona una buena seguridad y una amplia compatibilidad. Algunas aplicaciones requieren más control sobre los cifrados y las versiones de SSL que se usan para sus conexiones HTTPS o SSL. Puedes definir una política de SSL para especificar el conjunto de características de SSL que usará tu balanceador de cargas cuando negocies SSL con los clientes. Además, puedes aplicar esa política de SSL a tu proxy HTTPS de destino.
En la siguiente tabla, se especifica la compatibilidad de las políticas de SSL con los balanceadores de cargas en cada modo.
| Modo de balanceador de cargas | Políticas de SSL compatibles |
|---|---|
| Balanceador de cargas de aplicaciones externo global | |
| Balanceador de cargas de aplicaciones clásico | |
| Balanceador de cargas de aplicaciones externo regional |
Servicios de backend
Un servicio de backend proporciona información de configuración al balanceador de cargas para que pueda dirigir las solicitudes a sus backends, por ejemplo, grupos de instancias de Compute Engine o grupos de extremos de red (NEG). Para obtener más información sobre los servicios de backend, consulta la Descripción general de los servicios de backend.
Para ver un ejemplo que muestra cómo configurar un balanceador de cargas con un servicio de backend y uno de Compute Engine, consulta Configura un balanceador de cargas de aplicaciones externo con un backend de Compute Engine.
Alcance del servicio de backend
En la siguiente tabla, se indica qué recurso y alcance del servicio de backend usan los balanceadores de cargas de aplicaciones externos:
| Modo de balanceador de cargas | Recurso de servicio de backend |
|---|---|
| Balanceador de cargas de aplicaciones externo global |
backendServices (global) |
| Balanceador de cargas de aplicaciones clásico |
backendServices (global) |
| Balanceador de cargas de aplicaciones externo regional |
regionBackendServices (regional) |
Protocolo para los backends
Los servicios de backend para los balanceadores de cargas de aplicaciones deben usar uno de los siguientes protocolos para enviar solicitudes a los backends:
HTTP, que usa HTTP/1.1 y no TLSHTTPS, que usa HTTP/1.1 y TLSHTTP/2, que usa HTTP/2 y TLS (no se admite HTTP/2 sin encriptación).
El balanceador de cargas solo usa el protocolo de servicio de backend que especifiques para comunicarse con sus backends. El balanceador de cargas no recurre a un protocolo diferente si no puede comunicarse con los backends con el protocolo de servicio de backend especificado.
El protocolo del servicio de backend no tiene que coincidir con el protocolo que usan los clientes para comunicarse con el balanceador de cargas. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas mediante HTTP/2, pero el balanceador de cargas puede comunicarse con los backends mediante HTTP/1.1 (HTTP o HTTPS).
Buckets de backend
Los buckets de backend dirigen el tráfico entrante a los buckets de Cloud Storage. Para ver un ejemplo que muestra cómo agregar un bucket a un balanceador de cargas de aplicaciones externo, consulta Configura un balanceador de cargas con buckets de backend. Para obtener información general sobre Cloud Storage, consulta ¿Qué es Cloud Storage?
Backends
En la siguiente tabla, se especifican los backends y las funciones relacionadas compatibles con los balanceadores de cargas de aplicaciones externos en cada modo.
|
Modo de balanceador de cargas |
Backends compatibles en un servicio de backend* | Compatible con buckets de backend | Compatible con Google Cloud Armor | Admite Cloud CDN# | Compatible con IAP# | Admite extensiones de servicio | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Grupos de instancias† | NEG zonales‡ | NEG de Internet | NEG sin servidores | NEG híbridos | NEGs de Private Service Connect | ||||||
| Balanceador de cargas de aplicaciones externo global | |||||||||||
| Balanceador de cargas de aplicaciones clásico |
Nivel premium |
|
|||||||||
| Balanceador de cargas de aplicaciones externo regional | |||||||||||
*Los backends de un servicio de backend deben ser del mismo tipo: todos los grupos de instancias o todos del mismo tipo de NEG. Una excepción a esta regla es que los NEG zonales y los NEG híbridos de GCE_VM_IP_PORT se pueden usar en el mismo servicio de backend para admitir una
arquitectura híbrida.
† Se admiten combinaciones de grupos de instancias no administrados zonales, administrados zonales y administrados regionales en el mismo servicio de backend. Cuando uses el ajuste de escala automático para un grupo de instancias administrado que sea un backend para dos o más servicios de backend, configura la política de ajuste de escala automático del grupo de instancias para usar varios indicadores.
‡ Los NEG zonales deben usar extremos GCE_VM_IP_PORT.
# IAP y Cloud CDN no son compatibles entre sí. No se pueden habilitar en el mismo servicio de backend.
Backends y redes de VPC
Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de balanceador de cargas.
Para los backends de balanceador de cargas de aplicaciones externos globales, se aplica lo siguiente:
Las instancias de backend (para backends de grupos de instancias) y los extremos de backend (para backends de NEG) se pueden ubicar en cualquier red de VPC dentro de la misma organización. No es necesario que las diferentes redes de VPC estén conectadas a través del intercambio de tráfico entre redes de VPC, ya que los GFE se comunican de forma directa con los backends en sus respectivas redes de VPC.
Los buckets de Cloud Storage no están asociados con una red de VPC. Se pueden ubicar en cualquier proyecto dentro de la misma organización.
Los balanceadores de cargas de aplicaciones externos globales también admiten entornos de VPC compartida en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Sin embargo, para los balanceadores de cargas de aplicaciones externos globales, no es necesario que configures la VPC compartida para poder hacer referencia a los servicios de backend o a los buckets de backend de otros proyectos de tu organización.
Para los backends del balanceador de cargas de aplicaciones clásico, se aplica lo siguiente:
Todas las instancias de backend de los backends de grupos de instancias y todos los extremos de backend de los backends de NEG deben estar ubicados en el mismo proyecto. Sin embargo, un backend de grupo de instancias o un NEG pueden usar una red de VPC diferente en ese proyecto. No es necesario que las diferentes redes de VPC estén conectadas mediante el intercambio de tráfico entre redes de VPC, ya que los GFE se comunican directamente con los backends en sus respectivas redes de VPC.
Los buckets de Cloud Storage no están asociados con una red de VPC. Sin embargo, deben estar ubicados en el mismo proyecto que el balanceador de cargas.
Para los backends de balanceador de cargas de aplicaciones externos regionales, se aplica lo siguiente:
Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend (esta función está en versión preliminar). La conectividad entre la red de VPC del balanceador de cargas y la red de VPC de backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN, adjuntos de VLAN de Cloud Interconnect o un framework de Network Connectivity Center.
Definición de la red de backend
- En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
- En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
- En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz
nic0de la primera VM que se agrega al grupo de instancias.
Requisitos de red del backend
La red de tu backend debe satisfacer 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 intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos 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 en el mismo concentrador de Network Connectivity Center. Los filtros de importación y exportación deben permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.
Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.
Los balanceadores de cargas de aplicaciones externos regionales también admiten entornos de VPC compartida en los que puedes compartir redes de VPC y sus recursos asociados entre proyectos. Si deseas que el servicio de backend y los backends del balanceador de cargas de aplicaciones externo regional estén en un proyecto diferente al de la regla de reenvío, debes configurar el balanceador de cargas en un entorno de VPC compartida con referencias a servicios entre proyectos.
Interfaces de red y backends
Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a diferentes NICs, usa backends de NEG en su lugar.
Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.
Verificaciones de estado
Cada servicio de backend especifica una verificación de estado que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.
Para los sondeos de verificación de estado, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend. Por lo general, los sondeos de verificación de estado se originan a partir del mecanismo centralizado de verificación de estado de Google.
Los balanceadores de cargas de aplicaciones externos regionales que usan backends de NEG híbridos son una excepción a esta regla, ya que sus verificaciones de estado se originan en la subred de solo proxy. Para obtener más información, consulta la descripción general de los NEG híbridos.
Protocolo de verificación de estado
Aunque no es obligatorio y no siempre es posible, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends. Por el contrario, los balanceadores de cargas de aplicaciones externos regionales que usan backends de NEG híbridos no admiten verificaciones de estado de gRPC. Para obtener la lista de protocolos de verificación de estado compatibles, consulta Funciones del balanceo de cargas.
En la siguiente tabla, se especifica el alcance de las verificaciones de estado que admiten los balanceadores de cargas de aplicaciones externos en cada modo.
| Modo de balanceador de cargas | Tipo de verificación de estado |
|---|---|
| Balanceador de cargas de aplicaciones externo global | Global |
| Balanceador de cargas de aplicaciones clásico | Global |
| Balanceador de cargas de aplicaciones externo regional | Regional |
Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:
Reglas de firewall
El balanceador de cargas requiere las siguientes reglas de firewall:
- Para los balanceadores de cargas de aplicaciones externos globales, una regla de permiso de entrada que permite que el tráfico de Google Front End (GFE) llegue a tus backends. Para el balanceador de cargas de aplicaciones externo regional, una regla de permiso de entrada que permite que el tráfico de la subred de solo proxy llegue a tus backends.
- Una regla de permiso de entrada que permita el tráfico de los rangos de sondeo de verificación de estado Para obtener más información sobre los sondeos de verificación de estado y por qué es necesario permitir el tráfico de ellos, consulta Sondea rangos de IP y reglas de firewall.
Las reglas de firewall se implementan a nivel de la instancia de VM, no en los proxies de GFE. No puedes usar las reglas de firewall de Google Cloud para evitar que el tráfico llegue al balanceador de cargas. Para el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, puedes usar Google Cloud Armor para lograrlo.
Los puertos de estas reglas de firewall deben configurarse de la siguiente manera:
Permite el tráfico al puerto de destino para cada verificación de estado del servicio de backend.
Para los backends de grupos de instancias: determina los puertos que se configurarán a través de la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados con ese puerto con nombre en cada grupo de instancias. Los números pueden variar entre grupos de instancias asignados al mismo servicio de backend.
Para los backends de NEG
GCE_VM_IP_PORT: permite el tráfico a los números de puerto de los extremos.
En la siguiente tabla, se resumen los rangos de direcciones IP de origen necesarios para las reglas de firewall:
| Modo de balanceador de cargas | Rangos de origen de la verificación de estado | Rangos de origen de solicitud |
|---|---|---|
| Balanceador de cargas de aplicaciones externo global |
Para el tráfico IPv6 a los backends:
|
La fuente de tráfico del GFE depende del tipo de backend:
|
| Balanceador de cargas de aplicaciones clásico |
|
La fuente de tráfico del GFE depende del tipo de backend:
|
| Balanceador de cargas de aplicaciones externo regional |
Para el tráfico IPv6 a los backends:
|
La subred de solo proxy que configuras. |
Compatibilidad con GKE
GKE usa balanceadores de cargas de aplicaciones externos de las siguientes maneras:
- Las puertas de enlace externas creadas con el controlador de GKE Gateway pueden usar cualquier modo de un balanceador de cargas de aplicaciones externo. Para controlar el modo del balanceador de cargas, elige una GatewayClass. El controlador de la puerta de enlace de GKE siempre usa backends de NEG zonales de
GCE_VM_IP_PORT.
- Los Ingress externos creados con el controlador de Ingress de GKE siempre son balanceadores de cargas de aplicaciones clásicos. El controlador de Ingress de GKE prefiere usar backends de NEG zonales de
GCE_VM_IP_PORT, aunque también se admiten backends de grupos de instancias.
- Puedes usar NEG zonales de
GCE_VM_IP_PORTque crean y administran los servicios de GKE como backends para cualquier balanceador de cargas de aplicaciones o balanceador de cargas de red de proxy. Para obtener más información, consulta Balanceo de cargas nativo del contenedor mediante NEG zonales independientes.
Arquitectura de VPC compartida
Los balanceadores de cargas de aplicaciones externos admiten redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común para que puedan comunicarse entre ellas de forma segura y eficiente a través de las IP internas de esa red. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.
Hay muchas formas de configurar un balanceador de cargas de aplicaciones externo 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.
| Balanceador de cargas | Componentes de frontend | Componentes de backend |
|---|---|---|
| Balanceador de cargas de aplicaciones externo global |
Si usas una red de VPC compartida para tus backends, crea la red requerida en el proyecto host de VPC compartida. La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio. |
Puedes realizar una de las siguientes acciones:
Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend. Los backends pueden ser parte de una red de VPC compartida desde el proyecto host o una red de VPC independiente, es decir, una red de VPC no compartida en el proyecto de servicio. |
| Balanceador de cargas de aplicaciones clásico | La dirección IP externa global, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto de servicio o host que los backends. | Se debe definir un servicio de backend global en el mismo proyecto de servicio o host que los backends (grupos de instancias o NEG). Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend. |
| Balanceador de cargas de aplicaciones externo regional | Crea la red y la subred de solo proxy necesarias en el proyecto host de la VPC compartida. La dirección IP externa regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio. |
Puedes realizar una de las siguientes acciones:
Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend. |
Si bien puedes crear todos los componentes y backends del balanceo de cargas en el proyecto host de la VPC compartida, este tipo de implementación no separa las responsabilidades de administración de red y de desarrollo de servicios.
Todos los componentes y backends del balanceador de cargas en un proyecto de servicio
En el siguiente diagrama de arquitectura, se muestra una implementación de VPC compartida estándar en la que todos los componentes y backends del balanceador de cargas se encuentran en un proyecto de servicio. Este tipo de implementación es compatible con todos los balanceadores de cargas de aplicaciones.
Los componentes del balanceador de cargas y los backends deben usar la misma red de VPC.
Backends sin servidores en un entorno de VPC compartida
Para un balanceador de cargas que usa un backend de NEG sin servidores, el servicio de backend de Cloud Run o funciones de Cloud Run debe estar en el mismo proyecto que el NEG sin servidores.
Además, para el balanceador de cargas de aplicaciones externo regional que admite referencias de servicio entre proyectos, el servicio de backend, el NEG sin servidores y el servicio de Cloud Run siempre deben estar en el mismo proyecto de servicio.
Referencia del servicio entre proyectos
La referencia de servicio entre proyectos es un modelo de implementación en el que el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto, y el servicio de backend y los backends del balanceador de cargas se encuentran en un proyecto diferente.
La referencia a servicios entre proyectos permite a las organizaciones configurar un balanceador de cargas central y enrutar el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puedes administrar de forma centralizada todas las reglas y las políticas de enrutamiento de tráfico en un mapa de URL. También puedes asociar el balanceador de cargas con un solo conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar la cantidad de balanceadores de cargas necesarios para implementar tu aplicación y reducir la administración, los costos operativos y los requisitos de cuota.
Si tienes proyectos diferentes para cada uno de los equipos funcionales, también puedes lograr la separación de los roles dentro de la organización. Los propietarios del servicio pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de red pueden aprovisionar y mantener balanceadores de cargas en otro proyecto, y ambos se pueden conectar a través de referencias de servicios entre proyectos.
Los propietarios del servicio pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a sus servicios a través de el balanceador de cargas. Esto se logra mediante un rol especial de IAM llamado rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser).
La compatibilidad con la referencia de servicios entre proyectos varía según el tipo de balanceador de cargas:
En el caso de los balanceadores de cargas de aplicaciones externos globales, el frontend y el mapa de URL del balanceador de cargas pueden hacer referencia a servicios de backend o buckets de backend de cualquier proyecto dentro de la misma organización. No se aplican restricciones de red de VPC. Si bien puedes usar un entorno de VPC compartida para configurar una implementación entre proyectos como se muestra en este ejemplo, esto no es un requisito.
En el caso de los balanceadores de cargas de aplicaciones externos regionales, debes crear el balanceador de cargas en un entorno de VPC compartida. El frontend y el mapa de URL del balanceador de cargas deben estar en un proyecto host o de servicio, y los servicios de backend y los backends del balanceador de cargas se pueden distribuir en proyectos host o de servicio en el mismo entorno de VPC compartida.
Si deseas obtener información sobre cómo configurar la VPC compartida para un balanceador de cargas de aplicaciones externo regional, con y sin referencias de servicios entre proyectos, consulta Configura un balanceador de cargas de aplicaciones externo regional con VPC compartida.
Limitaciones conocidas con la referencia del servicio entre proyectos
-
La referencia del servicio entre proyectos se puede usar con grupos de instancias, NEG sin servidores y la mayoría de los demás tipos de backend compatibles. Sin embargo, se aplican las siguientes limitaciones:
Con los balanceadores de cargas de aplicaciones externos globales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio tiene backends de NEG sin servidores con App Engine.
- Con los balanceadores de cargas de aplicaciones externos regionales, no puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales.
- La referencia del servicio entre proyectos no es compatible con el balanceador de cargas clásico de aplicaciones.
- Google Cloud no distingue entre recursos (por ejemplo, servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.
Ejemplo 1: frontend y backend del balanceador de cargas en diferentes proyectos de servicio
Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto de servicio A, y el mapa de URL hace referencia a un servicio de backend en el proyecto de servicio B.
En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requerirán acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol de IAM compute.loadBalancerServiceUser a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.
Ejemplo 2: frontend del balanceador de cargas en el proyecto host y backends en proyectos de servicio
Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas 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.
Ejemplo 3: Frontend y backends del balanceador de cargas en diferentes proyectos
Este es un ejemplo de una implementación en la que se crean el frontend y el mapa de URL del balanceador de cargas de aplicaciones externo global en un proyecto diferente del servicio de backend y los backends del balanceador de cargas. Este tipo de implementación no usa VPC compartida y solo es compatible con los balanceadores de cargas de aplicaciones externos globales.
Cómo funcionan las conexiones
Conexiones del balanceador de cargas de aplicaciones externo global
Varios proxies llamados Google Front End (GFE) implementan los balanceadores de cargas de aplicaciones externos globales. No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y las solicitudes de los clientes se dirigen al GFE del cliente más cercano.
Según dónde se encuentren tus clientes, varios GFE pueden iniciar conexiones HTTP(S) con tus backends. Los paquetes enviados desde GFE tienen direcciones IP de origen del mismo rango que usan los verificadores de estado: 35.191.0.0/16 y 130.211.0.0/22.
Según la configuración del servicio de backend, el protocolo que usa cada GFE para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Para las conexiones HTTP o HTTPS, la versión HTTP que se usa es HTTP 1.1.
El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. Los keepalives de HTTP intentan usar la misma sesión de TCP de forma eficiente; sin embargo, no hay garantía. GFE usa un tiempo de espera de keepalive HTTP del cliente de 610 segundos y un valor de tiempo de espera de keepalive de backend predeterminado de 600 segundos. Puedes actualizar el tiempo de espera de keepalive HTTP del cliente, pero el valor del tiempo de espera de keepalive del backend es fijo. Puedes configurar el tiempo de espera de la solicitud o la respuesta a través de la configuración del tiempo de espera del servicio de backend. Aunque están muy relacionados, un tiempo de espera de keepalive de HTTP y uno de inactividad de TCP no son lo mismo. Para obtener más información, consulta Tiempos de espera y reintentos.
Para garantizar que el tráfico tenga balanceo de cargas de manera uniforme, el balanceador de cargas podría cerrar de forma correcta una conexión TCP a través del envío de un paquete FIN ACK después de completar una respuesta que incluya un encabezado Connection: close, o puede emitir un marco HTTP/2 GOAWAY después de completar una respuesta. Este comportamiento no interfiere en ninguna solicitud o respuesta activa.
La cantidad de conexiones HTTP y sesiones TCP varía según la cantidad de conexiones de GFE, la cantidad de clientes que se conectan a GFE, el protocolo a los backends y la ubicación de implementación de backends.
Para obtener más información, consulta Cómo funcionan los balanceadores de cargas de aplicaciones externos en la guía de soluciones: Optimizaciones de la capacidad de las aplicaciones con el balanceo de cargas global.
Conexiones del balanceador de cargas de aplicaciones externo regional
El balanceador de cargas de aplicaciones externo regional es un servicio administrado que se implementa en el proxy de Envoy.
El balanceador de cargas de aplicaciones externo regional usa una subred compartida llamada subred de solo proxy para aprovisionar un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas basados en Envoy en una red y una región en particular comparten esta subred.
Los clientes usan la dirección IP y el puerto del balanceador de cargas para conectarse al balanceador de cargas. Las solicitudes del cliente se dirigen a la subred de solo proxy en la misma región que el cliente. El balanceador de cargas finaliza las solicitudes de los clientes y abre conexiones nuevas de la subred de solo proxy a tus backends. Por lo tanto, los paquetes enviados desde el balanceador de cargas tienen direcciones IP de origen de la subred de solo proxy.
Según la configuración del servicio de backend, el protocolo que usan los proxies de Envoy para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión HTTP es HTTP 1.1. El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. El proxy de Envoy establece el tiempo de espera de keepalive HTTP del cliente y el tiempo de espera de keepalive del backend en un valor predeterminado de 600 segundos cada uno. Puedes actualizar el tiempo de espera de keepalive HTTP del cliente, pero el valor del tiempo de espera de keepalive del backend es fijo. Puedes configurar el tiempo de espera de la solicitud o la respuesta a través de la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.
Comunicaciones del cliente con el balanceador de cargas
- Los clientes se pueden comunicar con el balanceador de cargas a través de el protocolo HTTP 1.1 o HTTP/2.
- Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas de HTTPS.
- No puedes inhabilitar HTTP/2 aunque realices un cambio de configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con
curl, usa el parámetro--http1.1. - Los balanceadores de cargas de aplicaciones externos admiten la respuesta
HTTP/1.1 100 Continue.
Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.
Direcciones IP de origen para paquetes de clientes
La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa de Google Cloud del balanceador de cargas. En otras palabras, existen dos conexiones TCP.
Para los balanceadores de cargas de aplicaciones externos globales:Sesión 1, que abarca desde el cliente original hasta el balanceador de cargas (GFE):
- Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
- Dirección IP de destino: Es la dirección IP del balanceador de cargas.
Conexión 2, desde el balanceador de cargas (GFE) hasta el extremo o la VM de backend:
Dirección IP de origen: Es una dirección IP en uno de los rangos especificados en Reglas de firewall.
Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.
Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):
- Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente usa NAT o un proxy de reenvío).
- Dirección IP de destino: Es la dirección IP del balanceador de cargas.
Conexión 2, desde el balanceador de cargas (subred de solo proxy) hasta la VM o el extremo de backend:
Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red como el balanceador de cargas.
Dirección IP de destino: La dirección IP interna del contenedor o la VM de backend en la red de VPC.
Rutas de acceso de enrutamiento especiales
Google Cloud usa rutas especiales no definidas en tu red de VPC para enrutar paquetes para los siguientes tipos de tráfico:
- Para las verificaciones de estado, excepto las verificaciones de estado de Envoy distribuidas. Si deseas obtener más información, consulta Rutas de acceso para las verificaciones de estado.
- Entre GFEs y backends de balanceadores de cargas de aplicaciones externos globales y balanceadores de cargas de aplicaciones clásicos Para obtener más información, consulta Rutas entre Google Front Ends y backends.
Google Cloud usa rutas de subred en subredes de solo proxy para enrutar paquetes para los siguientes tipos de tráfico:
- Cuando usas verificaciones de estado distribuidas de Envoy.
Para los balanceadores de cargas de aplicaciones externos regionales, Google Cloud usa proxies de Envoy de código abierto para finalizar las solicitudes de los clientes al balanceador de cargas. El balanceador de cargas finaliza la sesión TCP y abre una nueva sesión TCP desde la subred de solo proxy de la región a tu backend. Las rutas definidas dentro de la red de VPC facilitan la comunicación de los proxies de Envoy a los backends y de los backends a los proxies de Envoy.
Puertos abiertos
Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Cuando ejecutas un análisis de puerto, es posible que veas otros puertos abiertos para otros servicios de Google que se ejecutan en GFE.
Los balanceadores de cargas basados en GFE, los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones clásicos, siempre muestran los puertos 80 y 443 como abiertos (junto con cualquier otro puerto que hayas configurado en las reglas de reenvío de tu balanceador de cargas). Sin embargo, si no configuraste una regla de reenvío para el puerto 80 o el puerto 443, se rechazan las conexiones enviadas a esos puertos. Por el contrario, los balanceadores de cargas de aplicaciones externos regionales se implementan mediante proxies de Envoy y no muestran puertos adicionales abiertos durante un análisis.Ejecutar un análisis de puerto en la dirección IP de un balanceador de cargas basado en GFE no es útil desde la perspectiva de la auditoría por los siguientes motivos:
Por lo general, un análisis de puerto (por ejemplo, con
nmap) no espera ningún paquete de respuesta o un paquete RST de TCP cuando realiza sondeos de TCP SYN. Los GFE enviarán paquetes SYN-ACK en respuesta a los sondeos de SYN solo para los puertos en los que configuraste una regla de reenvío. Los GFE solo envían paquetes a tus backends en respuesta a los paquetes enviados a la dirección IP del balanceador de cargas y al puerto de destino configurado en su regla de reenvío. Los paquetes que se envían a una dirección IP o un puerto diferentes no se envían a los backends.Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Google Cloud Armor Standard, los GFE proporcionan protección siempre encendida contra ataques de DSD volumétricos basados en protocolos y desbordamientos SYN. Esta protección está disponible incluso si no configuraste Google Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te inscribes en Managed Protection Plus.
Cualquier GFE en la flota de Google puede responder a los paquetes enviados a la dirección IP de tu balanceador de cargas. Sin embargo, el análisis de una combinación de direcciones IP del balanceador de cargas y del puerto de destino solo intercepta un solo GFE por conexión TCP. La dirección IP de tu balanceador de cargas no se asigna a un solo dispositivo o sistema. Por lo tanto, analizar la dirección IP de un balanceador de cargas basado en GFE no analiza todos los GFE de la flota de Google.
Con esto en mente, las siguientes son algunas formas más efectivas de auditar la seguridad de tus instancias de backend:
Un auditor de seguridad debe inspeccionar la configuración de reglas de reenvío para la configuración del balanceador de cargas. Las reglas de reenvío definen el puerto de destino para el que tu balanceador de cargas acepta paquetes y los reenvía a los backends. Para los balanceadores de cargas basados en GFE, cada regla de reenvío externo solo puede hacer referencia a un solo puerto TCP de destino. Para un balanceador de cargas con el puerto TCP 443, el puerto UDP 443 se usa cuando la conexión se actualiza a QUIC (HTTP/3).
Un auditor de seguridad debe inspeccionar la configuración de la regla de firewall aplicable a las VM de backend. Las reglas de firewall que configuras bloquean el tráfico desde los GFE hacia las VMs de backend, pero no bloquean el tráfico entrante a los GFE. Para conocer las prácticas recomendadas, consulta la sección de reglas de firewall.
finalización de TLS
En la siguiente tabla, se resume cómo los balanceadores de cargas de aplicaciones externos administran la finalización de TLS.
| Modo de balanceador de cargas | finalización de TLS |
|---|---|
| Balanceador de cargas de aplicaciones externo global | La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo. |
| Balanceador de cargas de aplicaciones clásico | La TLS se finaliza en un GFE, que puede estar en cualquier parte del mundo. |
| Balanceador de cargas de aplicaciones externo regional | TLS finaliza en proxies de Envoy ubicados en una subred de solo proxy en una región elegida por el usuario. Usa este modo de balanceador de cargas si necesitas control geográfico sobre la región en la que se finaliza TLS. |
Tiempos de espera y reintentos
Los balanceadores de cargas de aplicaciones externos admiten los siguientes tipos de tiempos de espera para el tráfico HTTP/HTTPS:
| Tipo de tiempo de espera y descripción | Valores predeterminados | Admite valores de tiempo de espera personalizados | ||
|---|---|---|---|---|
| Global | Clásico | Regional | ||
| Tiempo de espera del servicio de backend1
Un tiempo de espera de solicitud y respuesta Representa la cantidad máxima de tiempo permitida entre el momento en que el balanceador de cargas envía el primer byte de una solicitud al backend y el momento en que el backend devuelve el último byte de la respuesta HTTP al balanceador de cargas. Si el backend no devolvió toda la respuesta HTTP al balanceador de cargas dentro de este límite de tiempo, se descartarán los datos de respuesta restantes. |
|
|||
| Tiempo de espera de keepalive de HTTP del cliente
Es la cantidad máxima de tiempo en que la conexión TCP entre un cliente y el proxy del balanceador de cargas puede estar inactiva. (Podría usarse la misma conexión TCP para varias solicitudes HTTP).
|
|
|||
| Tiempo de espera de keepalive de HTTP del backend
Es la cantidad máxima de tiempo en que la conexión TCP entre el proxy del balanceador de cargas y un backend puede estar inactiva. (Podría usarse la misma conexión TCP para varias solicitudes HTTP).
|
|
|||
| Tiempo de espera inactivo de la sesión de QUIC
Es la cantidad máxima de tiempo que una sesión de QUIC puede estar inactiva entre el cliente (en sentido descendente) y el GFE de un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico. |
Balanceadores de cargas de aplicaciones externos globales y balanceadores de cargas de aplicaciones clásicos El tiempo de espera de inactividad de la sesión de QUIC es el mínimo del tiempo de espera de inactividad del cliente o el tiempo de espera de inactividad de GFE (300 segundos). El tiempo de espera de inactividad de GFE se fija en 300 segundos. Se puede configurar el tiempo de espera de inactividad del cliente. |
|||
1No se puede configurar para backends de NEG sin servidores. No se puede configurar para buckets de backend.
Tiempo de espera del servicio de backend
El tiempo de espera del servicio de backend configurable representa la cantidad máxima de tiempo que el balanceador de cargas espera que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto por los NEG sin servidores, el valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos.
Por ejemplo, si quieres descargar un archivo de 500 MB y el valor del tiempo de espera del servicio de backend es de 90 segundos, el balanceador de cargas espera que el backend entregue todo el archivo de 500 MB en 90 segundos. Es posible configurar el tiempo de espera del servicio de backend para que no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de cargas al menos recibió encabezados de respuesta HTTP, el balanceador de cargas devuelve los encabezados de respuesta completos y todo el cuerpo de respuesta que pudo obtener dentro del tiempo de espera del servicio de backend.
Debes establecer el tiempo de espera del servicio de backend en el tiempo más largo que esperas que tu backend necesite para procesar una respuesta HTTP. Debes
aumentar el tiempo de espera del servicio de backend si el software que se ejecuta en el backend
necesita más tiempo para procesar una solicitud HTTP y devolver su respuesta completa.
Por ejemplo, debes aumentar el tiempo de espera si ves respuestas HTTP 408 con jsonPayload.statusDetail client_timed_out.
El tiempo de espera del servicio de backend acepta valores entre 1 y 2,147,483,647 segundos; sin embargo, los valores más grandes no son opciones de configuración prácticas.
Google Cloud tampoco garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend.
En el caso de los balanceadores de cargas de aplicaciones globales y clásicos, los GFE imponen un tiempo de espera máximo efectivo del servicio de backend de 86,400 segundos (1 día).
Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.
Para configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:
Console
Modifica el campo Tiempo de espera del servicio de backend del balanceador de cargas.
gcloud
Usa el
comando gcloud compute backend-services update para modificar el parámetro --timeout del recurso de servicio de backend.
API
Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico, modifica el parámetro timeoutSec para el recurso backendServices global.
Para un balanceador de cargas de aplicaciones externo regional, modifica el parámetro timeoutSec para el
recurso regionBackendServices.
| Modo de balanceador de cargas | Valores predeterminados | Descripción del tiempo de espera para WebSockets |
|---|---|---|
| Balanceador de cargas de aplicaciones externo global | tiempo de espera del servicio de backend: 30 segundos | Las conexiones de WebSocket activas no usan el tiempo de espera del servicio de backend configurado del balanceador de cargas. Las conexiones se cierran de forma automática después de 24 horas (86,400 segundos). Este límite de 24 horas es fijo y anula el tiempo de espera del servicio de backend si es superior a 24 horas. Las conexiones de WebSockets inactivas se cierran después de que se agote el tiempo de espera del servicio de backend. No recomendamos valores de tiempo de espera del servicio de backend superiores a 24 horas (86,400 segundos), ya que Google Cloud reinicia los GFEs de forma periódica para las actualizaciones de software y otras tareas de mantenimiento de rutina. El valor de tiempo de espera del servicio de backend no retrasa las actividades de mantenimiento. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que Google Cloud finalice las conexiones TCP para el mantenimiento. |
| Balanceador de cargas de aplicaciones clásico | tiempo de espera del servicio de backend: 30 segundos | Las conexiones de WebSocket, ya sean inactivas o activas, se cierran automáticamente después de que se agote el tiempo de espera del servicio de backend. No recomendamos valores de tiempo de espera del servicio de backend superiores a 24 horas (86,400 segundos), ya que Google Cloud reinicia los GFEs de forma periódica para las actualizaciones de software y otras tareas de mantenimiento de rutina. El valor de tiempo de espera del servicio de backend no retrasa las actividades de mantenimiento. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que Google Cloud finalice las conexiones TCP para el mantenimiento. |
| Balanceador de cargas de aplicaciones externo regional | tiempo de espera del servicio de backend: 30 segundos | Las conexiones de WebSocket activas no usan el tiempo de espera del servicio de backend del balanceador de cargas. Las conexiones de WebSockets inactivas se cierran después de que se agote el tiempo de espera del servicio de backend. Google Cloud reinicia o cambia la cantidad de tareas de software de Envoy de forma periódica. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que las tareas de Envoy reinicien o finalicen las conexiones TCP. |
Los balanceadores de cargas de aplicaciones externos regionales usan el parámetro routeActions.timeout configurado de los mapas de URL y omiten el tiempo de espera del servicio de backend. Cuando no se configura routeActions.timeout, se usa el valor del tiempo de espera del servicio de backend. Cuando se proporciona routeActions.timeout, se ignora el tiempo de espera del servicio de backend y se usa el valor de routeActions.timeout como el tiempo de espera de la solicitud y la respuesta.
Tiempo de espera de keepalive de HTTP del cliente
El tiempo de espera de keepalive de HTTP del cliente representa la cantidad máxima de tiempo que una conexión TCP puede estar inactiva entre el cliente (downstream) y uno de los siguientes tipos de proxies:
- Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico: Google Front End de primera capa
- Para un balanceador de cargas de aplicaciones externo regional: un proxy de Envoy
Un tiempo de espera de keepalive de HTTP representa el tiempo de espera de inactividad de TCP para las conexiones TCP subyacentes. El tiempo de espera de keepalive de HTTP del cliente no se aplica a websockets.
- Para un balanceador de cargas de aplicaciones externo global, el valor predeterminado es 610 segundos. Puedes configurar el tiempo de espera de keepalive de HTTP del cliente con un valor entre 5 y 1,200 segundos.
- En el caso de un balanceador de cargas de aplicaciones clásico, el tiempo de espera de keepalive de HTTP del cliente se fija en 610 segundos.
- Para un balanceador de cargas de aplicaciones externo regional, el valor predeterminado es de 600 segundos. Puedes configurar el tiempo de espera de keepalive de HTTP del cliente con un valor entre 5 y 600 segundos.
Para configurar el parámetro de tiempo de espera de keepalive, usa uno de los siguientes métodos:
Console
Modifica el campo HTTP keepalive timeout de la configuración del frontend del balanceador de cargas.
gcloud
Usa el comando gcloud compute target-http-proxies update o el comando gcloud compute target-https-proxies update para modificar el parámetro --http-keep-alive-timeout-sec del proxy HTTP de destino o el recurso del proxy HTTPS de destino.
API
Modifica el parámetro httpKeepAliveTimeoutSec para el
recurso targetHttpProxies o el
recurso targetHttpsProxies.
El tiempo de espera de keepalive del cliente HTTP del balanceador de cargas debe ser mayor que el tiempo de espera de keepalive de HTTP (TCP inactivo) que usan los clientes o proxies descendentes. Si un cliente descendente tiene un tiempo de espera de keepalive de HTTP (TCP inactivo) mayor que el del cliente HTTP del balanceador de cargas, es posible que se produzca una condición de carrera. Desde la perspectiva de un cliente descendente, una conexión TCP establecida puede estar inactiva durante más tiempo del que permite el balanceador de cargas. Esto significa que el cliente descendente puede enviar paquetes después de que el balanceador de cargas considera que la conexión TCP está cerrada. Cuando eso sucede, el balanceador de cargas responde con un paquete de restablecimiento de TCP (RST).
Tiempo de espera de keepalive de HTTP del backend
Los balanceadores de cargas de aplicaciones externos son proxies que usan al menos dos conexiones TCP:
- Para un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico, existe una primera conexión TCP entre el cliente (downstream) y un GFE de primera capa. Los GFE de la primera capa se conectan a los GFE de la segunda capa y, luego, los GFE de la segunda capa abren una segunda conexión TCP a tus backends.
- Para un balanceador de cargas de aplicaciones externo regional, existe una primera conexión TCP entre el cliente (downstream) y un proxy de Envoy. Luego, el proxy de Envoy abre una segunda conexión TCP a tus backends.
Es posible que las conexiones TCP secundarias del balanceador de cargas no se cierren después de cada solicitud; pueden permanecer abiertos para manejar varias solicitudes y respuestas HTTP. El tiempo de espera del keepalive de HTTP de backend define el tiempo de espera de inactividad de TCP entre el balanceador de cargas y los backends. El tiempo de espera de keepalive de HTTP de backend no se aplica a websockets.
El tiempo de espera de keepalive del backend se fija en 10 minutos (600 segundos) y no se puede cambiar. El tiempo de espera del keepalive del backend del balanceador de cargas debe ser menor que el que usa el software que se ejecuta en los backends. Esto evita una condición de carrera en la que el sistema operativo de los backends puede cerrar las conexiones TCP con un restablecimiento TCP (RST). Debido a que no se puede configurar el tiempo de espera de keepalive del backend para el balanceador de cargas, debes configurar el software de backend para que el valor de tiempo de espera de keepalive de HTTP (TCP inactivo) sea superior a 600 segundos.
En la siguiente tabla, se enumeran los cambios necesarios para modificar los valores de tiempo de espera de keepalive para el software del servidor web común.
| Software de servidor web | Parámetro | Parámetro de configuración predeterminado | Configuración recomendada |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Tiempo de espera de inactividad de la sesión de QUIC
El tiempo de espera de inactividad de la sesión de QUIC representa la cantidad máxima de tiempo que una sesión de QUIC puede estar inactiva entre el cliente y el GFE de un balanceador de cargas de aplicaciones externo global o un balanceador de cargas de aplicaciones clásico.
El valor de tiempo de espera de inactividad de la sesión de QUIC se define como el mínimo del tiempo de espera de inactividad del cliente o el tiempo de espera de inactividad del GFE (300 segundos). El tiempo de espera de inactividad de GFE se fija en 300 segundos. Se puede configurar el tiempo de espera de inactividad del cliente.
Reintentos
La compatibilidad con la lógica de reintento depende del modo del balanceador de cargas de aplicaciones externo.
| Modo de balanceador de cargas | Lógica de reintento |
|---|---|
| Balanceador de cargas de aplicaciones externo global |
Se puede configurar a través de una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos ( Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes Las solicitudes HTTP Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final. |
| Balanceador de cargas de aplicaciones clásico |
No se puede cambiar la política de reintento para los reintentos de conexión. Las solicitudes HTTP Las solicitudes HTTP El balanceador de cargas vuelve a intentar una solicitud Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final. Para obtener más información, consulta Registro y supervisión del balanceador de cargas de aplicaciones externo. Las solicitudes que no se ejecutan de forma correcta dan como resultado que el balanceador de cargas sintetiza una respuesta HTTP |
| Balanceador de cargas de aplicaciones externo regional |
Se puede configurar a través de una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos ( Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, Las solicitudes HTTP Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final. |
El protocolo WebSocket es compatible con GKE Ingress.
Solicitud ilegal y manejo de respuestas
El balanceador de cargas impide que las solicitudes de cliente y las respuestas de backend lleguen al backend o al cliente, respectivamente, por varios motivos. Algunas razones son solo para el cumplimiento de HTTP/1.1 y otras para evitar que se pasen datos inesperados a los backends o desde ellos. No se puede inhabilitar ninguna de las verificaciones.
El balanceador de cargas bloquea las siguientes solicitudes para el cumplimiento de HTTP/1.1:
- No se puede analizar la primera línea de la solicitud.
- A un encabezado le falta el delimitador de dos punto
:. - Los encabezados o la primera línea contienen caracteres no válidos.
- La longitud del contenido no es un número válido o hay varios encabezados de longitud del contenido.
- Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
- Hay un cuerpo no fragmentado y no se especifica la longitud del contenido.
- Los fragmentos del cuerpo no se pueden analizar. Este es el único caso en el que algunos datos llegan al backend. El balanceador de cargas cierra las conexiones con el cliente y el backend cuando recibe un fragmento no analizable.
Cómo administrar solicitudes
El balanceador de cargas bloquea la solicitud si se cumple alguna de las siguientes condiciones:
- El tamaño total de los encabezados y la URL de la solicitud supera el límite del tamaño máximo del encabezado de solicitud para los balanceadores de cargas de aplicaciones externos.
- El método de solicitud no permite un cuerpo, pero la solicitud tiene uno.
- La solicitud contiene un encabezado
Upgrade. El encabezadoUpgradeno se usa para habilitar las conexiones WebSocket. - La versión HTTP es desconocida.
Control de respuestas
El balanceador de cargas bloquea la respuesta del backend si se cumple alguna de las siguientes condiciones:
- El tamaño total de los encabezados de respuesta supera el límite del tamaño máximo del encabezado de respuesta del balanceador de cargas de aplicaciones externo.
- La versión HTTP es desconocida.
Cuando se manejan la solicitud y la respuesta, el balanceador de cargas puede quitar o reemplazar los encabezados de salto por salto en HTTP/1.1 antes de reenviarlos al destino previsto.
Distribución del tráfico
Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo, que define un método que mide la carga de backend y una capacidad objetivo. Los balanceadores de cargas de aplicaciones externos admiten dos modos de balanceo:
RATE, para grupos de instancias o NEG, es la cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.UTILIZATIONes el uso de backend de las VMs en un grupo de instancias.
La manera en que se distribuye el tráfico entre backends depende del modo del balanceador de cargas.
Balanceador de cargas de aplicaciones externo global
Antes de que Google Front End (GFE) envíe solicitudes a instancias de backend, GFE estima qué instancias de backend tienen capacidad para recibir solicitudes. Esta estimación de capacidad se realiza de forma proactiva, no al mismo tiempo que cuando llegan las solicitudes. Los GFE reciben información de manera periódica sobre la capacidad disponible y distribuyen las solicitudes entrantes según corresponda.
El significado de capacidad depende en parte del modo de balanceo. Para el modo RATE, es bastante simple: un GFE determina con exactitud cuántas solicitudes puede asignar por segundo. El balanceo de cargas basado en UTILIZATION es más complejo: el balanceador de cargas verifica el uso actual de las instancias y, luego, calcula una carga de consulta que cada instancia puede controlar. Esta estimación cambia a medida que cambian el uso de la instancia y los patrones de tráfico.
Ambos factores, la estimación de capacidad y la asignación proactiva, influyen en la distribución entre las instancias. Por lo tanto, Cloud Load Balancing se comporta de manera diferente a un balanceador de cargas round robin simple que distribuye las solicitudes en 50:50 exactas entre dos instancias. En cambio, el balanceo de cargas de Google Cloud intenta optimizar la selección de la instancia de backend para cada solicitud.
Para el balanceador de cargas de aplicaciones externo global, el balanceo de cargas tiene dos niveles. El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada backend (grupo de instancias o NEG). Luego, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos dentro del grupo. Para obtener más información, consulta la política de localidad del balanceo de cargas (documentación de la API del servicio de backend).
Para el balanceador de cargas de aplicaciones clásico, el modo de balanceo se usa para seleccionar el backend más favorable (grupo de instancias o NEG). Luego, el tráfico se distribuye de forma round robin entre las instancias o los extremos dentro del backend.
Cómo se distribuyen las solicitudes
Los balanceadores de cargas de aplicaciones externos basados en GFE usan el siguiente proceso para distribuir las solicitudes entrantes:
- Desde el cliente hasta el GFE de la primera capa. Los routers perimetrales anuncian la dirección IP externa de la regla de reenvío en los límites de la red de Google.
Cada anuncio enumera un salto siguiente a un sistema de balanceo de cargas de capa 3/4 (Maglev). Los sistemas Maglev enrutan el tráfico a Google Front End (GFE) de primera capa.
- Cuando se usa el nivel Premium, Google hace pública la dirección IP del balanceador de cargas desde todos los puntos de presencia y en todo el mundo. Cada dirección IP del balanceador de cargas es Anycast global.
- Cuando se usa el nivel Estándar, Google anuncia la dirección IP del balanceador de cargas desde los puntos de presencia asociados con la región de la regla de reenvío. El balanceador de cargas usa una dirección IP externa regional. El uso de una regla de reenvío de nivel Estándar te limita a los backends de NEG zonales y grupos de instancias en la misma región que la regla de reenvío del balanceador de cargas.
- Desde el GFE de la primera capa hasta el GFE de la segunda capa El GFE de la primera capa finaliza TLS si es necesario y, luego, enruta el tráfico a los GFE de segunda capa de acuerdo con el siguiente proceso:
- Los GFE de primera capa analizan el mapa de URL y seleccionan un servicio o un bucket de backend.
- Para los servicios de backend con NEG de Internet, los primeros GFE de capa seleccionan una puerta de enlace de reenvío externa de segunda capa ubicada con el GFE de la primera capa. La puerta de enlace de reenvío envía solicitudes al extremo NEG de Internet. Así finaliza el proceso de solicitud de distribución para los NEG de Internet.
- Para los servicios de backend con NEG sin servidores y NEG de Private Service Connect (PSC), y buckets de backend de una sola región, los GFE de primera capa seleccionan un GFE de segunda capa en la región que coincide con la región del NEG o del bucket. Para los buckets multirregionales de Cloud Storage, los GFE de la primera capa seleccionan los GFE de segunda capa en la región del bucket o en una región lo más cerca posible del bucket multirregional (definidos por el tiempo de ida y vuelta de la red).
- Para servicios de backend con grupos de instancias, NEG zonales con extremos
GCE_VM_IP_PORTy NEG híbridos, el sistema de administración de capacidad de Google informa a los GFE de primera capa sobre la capacidad usada y configurada para cada backend. La capacidad configurada para un backend se define por el modo de balanceo, la capacidad de destino del modo de balanceo y el escalador de capacidad.- Nivel Estándar: Los GFE de primera capa seleccionan un GFE de segunda capa en la región que contiene los backends.
- Nivel Premium: Los GFE de primera capa seleccionan los GFE de segunda capa de un conjunto de regiones aplicables. Las regiones aplicables son todas las regiones en las que se configuraron los backends, sin incluir las regiones con backends configurados que no tienen capacidad. Los GFE de primera capa seleccionan el GFE de segunda capa más cercano en una región aplicable (definida por el tiempo de ida y vuelta de la red). Si los backends están configurados en dos o más regiones, los GFE de primera capa pueden distribuir solicitudes en otras regiones aplicables si una región de primera elección está llena. La propagación a otras regiones es posible cuando todos los backends en la región de primera elección están al máximo de capacidad.
- Los GFE de segunda capa seleccionan backends. Los GFE de segunda capa se encuentran en zonas de una región. Usan el siguiente proceso para seleccionar un backend:
- Para los servicios de backend con NEG sin servidores, NEG de Private Service Connect y buckets de backend, los GFE de segunda capa reenvían solicitudes a los sistemas de producción de Google. Así finaliza el proceso de distribución de solicitudes para estos backends.
Para los servicios de backend con grupos de instancias, NEG zonales con extremos
GCE_VM_IP_PORTy NEG híbridos, los sistemas de sondeo de verificación de estado de Google informan a los GFE de segunda capa sobre la verificación de estado de las instancias o los extremos de backend.Solo en el nivel Premium: Si el GFE de segunda capa no tiene instancias o extremos de backend en buen estado en su región, podría enviar solicitudes a otro GFE de segunda capa en una región aplicable diferente con backends configurados. La propagación entre GFE de segunda capa en diferentes regiones no agota todas las combinaciones de región a región posibles. Si necesitas dirigir el tráfico fuera de los backends en una región en particular, en lugar de configurar backends para que fallen las verificaciones de estado, debes establecer el escalador de capacidad del backend en cero para que el GFE de primera capa excluya la región durante el paso anterior.
Luego, la GFE de segunda capa dirige las solicitudes a extremos o instancias de backend en las zonas de su región como se explica en el siguiente paso.
El GFE de segunda capa selecciona una zona. De forma predeterminada, los GFE de segunda capa usan el algoritmo
WATERFALL_BY_REGION, en el que cada GFE de segunda capa prefiere seleccionar extremos o instancias de backend en la misma zona que la que contiene el GFE de segunda capa. Debido a queWATERFALL_BY_REGIONminimiza el tráfico entre zonas, a tasas de solicitud bajas, cada GFE de segunda capa puede enviar solicitudes de forma exclusiva a los backends en la misma zona que el GFE de segunda capa.Solo para los balanceadores de cargas de aplicaciones externos globales, se pueden configurar los GFE de segunda capa para que usen uno de los siguientes algoritmos alternativos a través de un
serviceLbPolicy:SPRAY_TO_REGION: Los GFE de segunda capa no prefieren seleccionar extremos o instancias de backend en la misma zona que el GFE de segunda capa. Los GFE de segunda capa intentan distribuir el tráfico a todas las instancias de backend o los extremos en todas las zonas de la región. Esto puede generar una distribución más uniforme de la carga a expensas del aumento del tráfico entre zonas.WATERFALL_BY_ZONE: Los GFE de segunda capa prefieren seleccionar instancias de backend o extremos en la misma zona que el GFE de segunda capa Los GFE de segunda capa solo dirigen solicitudes a backends en diferentes zonas después de que todos los backends en la zona actual hayan alcanzado sus capacidades configuradas.
- El GFE de segunda capa selecciona instancias o extremos dentro de la zona. De forma predeterminada, un GFE de segunda capa distribuye las solicitudes entre los backends a través de round robin. Solo para los balanceadores de cargas de aplicaciones externos globales, puedes cambiar esto a través de una política de localidad de balanceo de cargas (
localityLbPolicy). La política de localidad de balanceo de cargas solo se aplica a los backends dentro de la zona seleccionada que se analizaron en el paso anterior.
Balanceador de cargas de aplicaciones externo regional
Para los balanceadores de cargas de aplicaciones externos regionales, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.
El modo de balanceo determina el peso o la fracción del tráfico que se debe enviar a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.
Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.
Para obtener más información, consulta lo siguiente:
- Modos de balanceo
- Política de balanceo de cargas de la localidad (documentación de la API de servicio de backend regional).
Afinidad de sesión
La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que el backend esté en buen estado y tenga la capacidad necesaria, según el modo de balanceo configurado.
Cuando uses la afinidad de sesión, te recomendamos el modo de balanceo RATE, en lugar de UTILIZATION. La afinidad de sesión funciona mejor si configuras el modo de balanceo en solicitudes por segundo (RPS).
Los balanceadores de cargas de aplicaciones externos ofrecen los siguientes tipos de afinidad de sesión:
- NONE. No se configuró la afinidad de sesión para el balanceador de cargas.
- Afinidad de IP de cliente
- Afinidad de cookie generada
- Afinidad de campo de encabezado
- Afinidad de cookie HTTP
- Afinidad de sesión en función de cookies con estado
En la siguiente tabla, se resumen las opciones de afinidad de sesión admitidas que son compatibles con los balanceadores de cargas de aplicaciones externos:
| Modo de balanceador de cargas | Opciones de afinidad de sesión | ||||||
|---|---|---|---|---|---|---|---|
| Ninguno | IP de cliente | Cookie generada | Campo de encabezado | Cookie HTTP | Cookie con estado | ||
| Balanceador de cargas de aplicaciones externo global | |||||||
| Balanceador de cargas de aplicaciones clásico | |||||||
| Balanceador de cargas de aplicaciones externo regional | |||||||
Alta disponibilidad y conmutación por error
La alta disponibilidad y la conmutación por error en los balanceadores de cargas de aplicaciones externos se pueden configurar a nivel del balanceador de cargas. Para ello, crea balanceadores de cargas de aplicaciones externos regionales de resguardo en cualquier región en la que necesites una copia de seguridad.
En la siguiente tabla, se describe el comportamiento de la conmutación por error.
| Modo de balanceador de cargas | Métodos de conmutación por error |
|---|---|
| Balanceador de cargas de aplicaciones externo global, Balanceador de cargas de aplicaciones clásico |
Puedes configurar una configuración de conmutación por error activa-pasiva en la que el tráfico se conmute por error a un balanceador de cargas de aplicaciones externo regional de copia de seguridad. Usas las verificaciones de estado para detectar interrupciones y las políticas de enrutamiento de Cloud DNS para enrutar el tráfico cuando se activa la conmutación por error. |
| Balanceador de cargas de aplicaciones externo regional | Usa uno de los siguientes métodos para garantizar una implementación de alta disponibilidad:
|
Compatibilidad con HTTP/2
HTTP/2 es una revisión importante del protocolo HTTP/1. HTTP/2 es compatible con las conexiones entre los clientes y el balanceador de cargas de aplicaciones externo, y con las conexiones entre el balanceador de cargas y sus backends.
El balanceador de cargas negocia automáticamente HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS. Incluso si un balanceador de cargas está configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla del lado del cliente, no en el balanceador de cargas.
Si un cliente no admite HTTP/2 y el balanceador de cargas está configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend, es posible que el balanceador de cargas aún negocie una conexión HTTPS o acepte solicitudes HTTP no seguras. Luego, el balanceador de cargas transforma esas solicitudes HTTPS o HTTP para representarlas a través de HTTP/2 en las instancias de backend.
Para usar HTTP/2, debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
Transmisiones simultáneas máximas de HTTP/2
La configuración de HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de transmisiones que acepta un extremo, que inicia el par. El valor que anuncia un cliente HTTP/2 a un balanceador de cargas de Google Cloud no tiene sentido, porque el balanceador de cargas no inicia transmisiones al cliente.
En los casos en que el balanceador de cargas usa HTTP/2 para comunicarse con un servidor que se ejecuta en una VM, el balanceador de cargas respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS que anuncia el servidor. Si se anuncia un valor de cero, el balanceador de cargas no puede reenviar solicitudes al servidor y puede generar errores.
Limitaciones de HTTP/2
- En comparación con el protocolo HTTP(S), el uso de HTTP/2 entre el balanceador de cargas y la instancia puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia. La agrupación de conexiones, una optimización que reduce la cantidad de conexiones con HTTP(S), no está disponible con HTTP/2 en este momento. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
- El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la ejecución del protocolo WebSocket a través de una sola transmisión de conexión HTTP/2 (RFC 8441).
- El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la extracción de servidor.
- La tasa de errores de gRPC y el volumen de solicitudes no son visibles en la API de Google Cloud ni en la consola de Google Cloud. Si el extremo de gRPC devuelve un error, los registros del balanceador de cargas y los datos de supervisión informan el código de respuesta HTTP
OK 200.
Compatibilidad con HTTP/3
HTTP/3 es un protocolo de Internet de nueva generación. Se basa en IETF QUIC, un protocolo desarrollado a partir del protocolo Google QUIC original. HTTP/3 es compatible entre el balanceador de cargas de aplicaciones externo, Cloud CDN y los clientes.
Específicamente:
- IETF QUIC es un protocolo de capa de transporte que proporciona control de congestión y confiabilidad similar a TCP. Usa TLS 1.3 para la seguridad y un rendimiento mejorado.
- HTTP/3 es una capa de aplicación basada en IETF QUIC, y se utiliza QUIC para manejar la multiplexación, el control de congestión, la detección de pérdida y la retransmisión.
- HTTP/3 permite un inicio más rápido de la conexión del cliente, resuelve el bloqueo de línea en las transmisiones multiplexadas y admite la migración de conexión cuando cambia la dirección IP de un cliente.
- HTTP/3 es compatible con conexiones entre clientes y el balanceador de cargas, no conexiones entre el balanceador de cargas y sus backends.
- Las conexiones HTTP/3 usan el algoritmo de control de congestión BBR.
Habilitar HTTP/3 en el balanceador de cargas puede mejorar los tiempos de carga de las páginas web, reducir el realmacenamiento en búfer de video y mejorar la capacidad de procesamiento en las conexiones de latencia más alta.
En la siguiente tabla, se especifica la compatibilidad de HTTP/3 con balanceadores de cargas de aplicaciones externos en cada modo.
| Modo de balanceador de cargas | Compatibilidad con HTTP/3 |
|---|---|
| Balanceador de cargas de aplicaciones externo global (siempre nivel Premium) | |
| Balanceador de cargas de aplicaciones clásico en el nivel Premium | |
| Balanceador de cargas de aplicaciones clásico en el nivel Estándar | |
| Balanceador de cargas de aplicaciones regional externo (nivel Premium o Estándar) |
Cómo se negocia HTTP/3
Cuando HTTP/3 está habilitado, el balanceador de cargas anuncia esta compatibilidad a los clientes, de manera que los clientes que admiten HTTP/3 intenten establecer conexiones HTTP/3 con el balanceador de cargas HTTPS.
- Los clientes implementados de forma correcta siempre recurren a HTTPS o HTTP/2 cuando no pueden establecer una conexión HTTP/3.
- Los clientes que admiten HTTP/3 usan su conocimiento previo almacenado en caché de la compatibilidad con HTTP/3 para ahorrar idas y vueltas innecesarias en el futuro.
- Debido a esta solución alternativa, habilitar o inhabilitar HTTP/3 en el balanceador de cargas no interrumpe la capacidad de este para conectarse con los clientes.
La compatibilidad se anuncia en el encabezado de respuesta HTTP Alt-Svc. Cuando HTTP/3 está habilitado, las respuestas del balanceador de cargas incluyen el siguiente valor del encabezado alt-svc:
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"
Si HTTP/3 se configuró de forma explícita como DISABLE, las respuestas no incluyen un encabezado de respuesta alt-svc.
Cuando tienes HTTP/3 habilitado en el balanceador de cargas de HTTPS, algunas circunstancias pueden hacer que tu cliente recurra a HTTPS o HTTP/2 en lugar de negociar HTTP/3. Se incluyen las siguientes:
- Cuando un cliente admite versiones de HTTP/3 que no son compatibles con las versiones de HTTP/3 compatibles con el balanceador de cargas HTTPS
- Cuando el balanceador de cargas detecta que el tráfico de UDP está bloqueado o sometido a un límite de frecuencia tal que impediría el funcionamiento de HTTP/3.
- Si el cliente no admite HTTP/3 en absoluto y, por lo tanto, no intenta negociar una conexión HTTP/3
Cuando una conexión recurre a HTTPS o HTTP/2, no consideramos esto como una falla del balanceador de cargas.
Antes de habilitar HTTP/3, asegúrate de que los comportamientos descritos con anterioridad sean aceptables para tus cargas de trabajo.
Configura HTTP/3
NONE (la opción predeterminada) y ENABLE habilitan la compatibilidad con HTTP/3 para tu balanceador de cargas.
Cuando el HTTP/3 está habilitado, el balanceador de cargas lo anuncia a los clientes, lo que permite que los clientes que lo admiten negocien una versión HTTP/3 con el balanceador de cargas. Los clientes que no admiten HTTP/3 no negocian una conexión HTTP/3. No es necesario que inhabilites HTTP/3 de forma explícita, a menos que hayas identificado implementaciones de cliente dañadas.
Los balanceadores de cargas de aplicaciones externos proporcionan tres formas de configurar HTTP/3, como se muestra en la siguiente tabla.
| Valor quicOverride | Comportamiento |
|---|---|
NONE |
La compatibilidad con HTTP/3 se anuncia a los clientes. |
ENABLE |
La compatibilidad con HTTP/3 se anuncia a los clientes. Nota: TLS 0-RTT (también conocido como datos anticipados de TLS) aún no es compatible con HTTP/3. |
DISABLE |
Inhabilita de manera explícita publicidad de HTTP/3 y Google QUIC para los clientes. |
Si deseas habilitar (o inhabilitar) HTTP/3 explícitamente, sigue estos pasos.
Console: HTTPS
- En la consola de Google Cloud, ve a la página Balanceo de cargas.
- Selecciona el balanceador de cargas que deseas editar.
- Haga clic en Configuración de frontend.
- Selecciona la dirección IP y el puerto de frontend que deseas editar. Para editar una configuración HTTP/3, el protocolo debe ser HTTPS.
Habilita HTTP/3
- Selecciona el menú Negociación de QUIC.
- Si quieres habilitar HTTP/3 para este frontend de forma explícita, selecciona Habilitado.
- Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de habilitar HTTP/3 en cada regla.
Inhabilita HTTP/3.
- Selecciona el menú Negociación de QUIC.
- Si quieres inhabilitar HTTP/3 para este frontend de forma explícita, selecciona Inhabilitado.
- Si tienes varias reglas de frontend que representan IPv4 y, también, IPv6, asegúrate de inhabilitar HTTP/3 para cada regla.
gcloud: HTTPS
Antes de que ejecutes este comando, debes crear un recurso de certificado SSL para cada certificado.
gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
--global \
--quic-override=QUIC_SETTING
Reemplaza QUIC_SETTING por uno de los siguientes valores:
NONE(predeterminado): Permite que Google controle cuándo se anuncia HTTP/3.Cuando seleccionas
NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia. En la consola de Google Cloud, esta opción se llama Automática (predeterminado).ENABLE: Anuncia HTTP/3 a los clientes.DISABLE: No anuncia HTTP/3 a los clientes.
API: HTTPS
POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride
{
"quicOverride": QUIC_SETTING
}
Reemplaza QUIC_SETTING por uno de los siguientes valores:
NONE(predeterminado): Permite que Google controle cuándo se anuncia HTTP/3.Cuando seleccionas
NONE, HTTP/3 se anuncia a los clientes, pero Google QUIC no se anuncia. En la consola de Google Cloud, esta opción se llama Automática (predeterminado).ENABLE: Anuncia HTTP/3 y Google QUIC a los clientesDISABLE: No anuncia HTTP/3 ni Google QUIC a los clientes.
Compatible con WebSocket
Los balanceadores de cargas basados en HTTP(S) de Google Cloud admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.
El protocolo de WebSocket proporciona un canal de comunicación dúplex completo entre los clientes y el balanceador de cargas. Para obtener más información, consulta RFC 6455.
El protocolo WebSocket funciona de la siguiente manera:
- El balanceador de cargas reconoce una solicitud
Upgradede WebSocket de un cliente HTTP(S). La solicitud contiene los encabezadosConnection: UpgradeyUpgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con el WebSocket. - El backend envía una respuesta
Upgradede WebSocket. La instancia de backend envía una respuesta101 switching protocolcon encabezadosConnection: Upgrade,Upgrade: websockety otros encabezados de respuesta relacionados con WebSocket. - El balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual.
Si la instancia de backend muestra una respuesta de error con
el código de respuesta 426 o 502, el balanceador de cargas cierra la conexión.
La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener más información, consulta afinidad de sesión.
Compatibilidad con gRPC
gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:
- Sistemas distribuidos altamente escalables y de baja latencia
- Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
- Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
- Diseño en capas para habilitar extensiones, autenticación y registros
Para usar gRPC con tus aplicaciones de Google Cloud, debes usar las solicitudes del proxy de extremo a extremo en HTTP/2. Para ello, haz lo siguiente:
- Configura un balanceador de cargas HTTPS.
- Habilita HTTP/2 como protocolo desde el balanceador de cargas hasta los backends.
El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.
El balanceador de cargas aún puede negociar HTTPS con algunos clientes o aceptar solicitudes HTTP no seguras en un balanceador de cargas configurado para usar HTTP/2 entre las instancias de backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.
Debes habilitar TLS en tus backends. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
Si quieres configurar un balanceador de cargas de aplicaciones externo a través de HTTP/2 con Ingress de Google Kubernetes Engine o a través de gRPC y HTTP/2 con Ingress, consulta HTTP/2 para el balanceo de cargas con Ingress.
Para obtener información sobre cómo solucionar problemas con HTTP/2, consulta Soluciona problemas de los backends con HTTP/2.
Para obtener información sobre las limitaciones de HTTP/2, consulta Limitaciones de HTTP/2.
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 usa HTTPS como protocolo de servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 con el backend.
Compatibilidad con TLS mutua
La TLS mutua, o mTLS, es un protocolo estándar de la industria para la autenticación mutua entre un cliente y un servidor. Garantiza que el cliente y el servidor se autentiquen mutuamente, ya que verifica que cada uno tenga un certificado válido emitido por una autoridad certificadora (AC) de confianza. A diferencia de la TLS estándar, en la que solo se autentica el servidor, la mTLS requiere que el cliente y el servidor presenten certificados que confirmen las identidades de ambas partes antes de que se establezca la comunicación.
Todos los balanceadores de cargas de aplicaciones admiten mTLS. Con la mTLS, el balanceador de cargas solicita que el cliente envíe un certificado para autenticarse durante el protocolo de enlace de TLS con el balanceador de cargas. Puedes configurar un almacén de confianza del Administrador de certificados que el balanceador de cargas use para validar la cadena de confianza del certificado de cliente.
Para obtener más información sobre mTLS, consulta Autenticación TLS mutua.
Limitaciones
- Los balanceadores de cargas HTTPS no envían una alerta de cierre
close_notifycuando finalizan conexiones SSL. Es decir, el balanceador de cargas cierra la conexión TCP en lugar de realizar un cierre SSL. - Los balanceadores de cargas de HTTPS solo admiten caracteres en minúsculas en dominios en un atributo de nombre común (
CN) o un nombre de entidad alternativo (SAN) del certificado. Los certificados con caracteres en mayúscula en los dominios solo se devuelven cuando se configuran como el certificado principal en el proxy de destino. - Los balanceadores de cargas HTTPS no usan la extensión de indicación del nombre del servidor (SNI) cuando se conectan al backend, excepto los balanceadores de cargas con backends de NEG de Internet. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.
- Cuando se usan balanceadores de cargas de aplicaciones externos regionales con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes en los 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.
Google Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.
No puedes crear un balanceador de cargas de aplicaciones externo regional en el nivel Premium con la consola de Google Cloud. Además, solo las regiones que admiten el nivel estándar están disponibles para estos balanceadores de cargas en la consola de Google Cloud. En su lugar, usa gcloud CLI o la API. En su lugar, usa gcloud CLI o la API.
- Cloud CDN te permite forzar que un objeto o un conjunto de objetos sean ignorados por la caché mediante la solicitud de una invalidación de caché. De forma predeterminada, cuando usas un balanceador de cargas de aplicaciones externo global con referencia del servicio entre proyectos de VPC compartida, los administradores del proyecto de servicio no tendrán los permisos necesarios para lo siguiente: invalidaciones de caché de solicitudes. Esto se debe a que la invalidación de caché se configura en el proyecto de frontend (es decir, el proyecto que tiene la regla de reenvío, el proxy de destino y el mapa de URL del balanceador de cargas). Por lo tanto, las invalidaciones de caché solo pueden emitirse las principales que tienen los roles de IAM para configurar los recursos relacionados con el balanceador de cargas en los proyectos de frontend (por ejemplo, el rol de administrador de red de Compute). Los administradores de servicios, que controlan el aprovisionamiento de los servicios de backend en un proyecto separado, deberán trabajar con el administrador del balanceador de cargas del proyecto de frontend para emitir la invalidación de caché para sus servicios entre proyectos.
¿Qué sigue?
- Si deseas obtener información sobre cómo implementar un balanceador de cargas de aplicaciones externo global, consulta Configura un balanceador de cargas de aplicaciones externo con un backend de Compute Engine.
- Si deseas obtener información sobre cómo implementar un balanceador de cargas de aplicaciones externo regional, consulta Configura un balanceador de cargas de aplicaciones externo regional con un backend de Compute Engine.
Si eres un usuario existente del balanceador de cargas de aplicaciones clásico, asegúrate de revisar la descripción general de la migración cuando planifiques una implementación nueva con el balanceador de cargas de aplicaciones externo global.
Si deseas obtener información sobre cómo automatizar la configuración del balanceador de cargas de aplicaciones externo con Terraform, consulta los ejemplos de módulos de Terraform para balanceadores de cargas de aplicaciones externos.
Si deseas obtener información sobre cómo configurar las capacidades de administración avanzada del tráfico disponibles con el balanceador de cargas de aplicaciones externo global, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos globales.
- Si deseas obtener información sobre cómo configurar las capacidades de administración avanzada del tráfico disponibles con el balanceador de cargas de aplicaciones externo regional, consulta Descripción general de la administración del tráfico en los balanceadores de cargas de aplicaciones externos regionales.
Para obtener más información sobre la entrega de sitios web, consulta Entrega sitios web.
Para encontrar las ubicaciones de los PoP de Google, consulta Ubicaciones de GFE.
Para obtener más información sobre la administración de capacidad, consulta el instructivo de administración de la capacidad con balanceo de cargas y Optimización de la capacidad de las aplicaciones con balanceo de cargas global.
Si quieres obtener información sobre cómo usar el Administrador de certificados para aprovisionar y administrar certificados SSL, consulta la Descripción general del Administrador de certificados.
Para insertar lógica personalizada en la ruta de datos del balanceo de cargas, configura textos destacados o complementos de Extensiones del servicio.
Solo para los balanceadores de cargas de aplicaciones externos regionales, puedes usar Apigee Shadow API Discovery para encontrar APIs shadow (también conocidas como APIs sin documentar) en tu infraestructura de Google Cloud existente. Asegúrate de leer las limitaciones asociadas antes de habilitar Shadow API Discovery.