Descripción general de Cloud Load Balancing

Un balanceador de cargas distribuye el tráfico del usuario en varias instancias de tus aplicaciones. Si se distribuye la carga, el balanceo de cargas reduce el riesgo de que la aplicación experimente problemas de rendimiento. Cloud Load Balancing de Google se basa en tecnologías confiables y de alto rendimiento, como Maglev, Andromeda, Google Front Ends y Envoy, las mismas tecnologías que impulsan los propios productos de Google.

Cloud Load Balancing ofrece una cartera completa de balanceadores de cargas de aplicación y de red. Usa nuestros balanceadores de cargas de proxy globales para distribuir millones de solicitudes por segundo entre backends en varias regiones con nuestra flota de Google Front End en más de 80 ubicaciones distintas en todo el mundo, todas con una dirección IP anycast única. Implementa un control jurisdiccional sólido con nuestros balanceadores de cargas de proxy regionales, lo que mantiene los backends y proxies en una región de tu elección sin preocuparte por la descarga de TLS/SSL. Usa nuestros balanceadores de cargas de transferencia para enrutar con rapidez varios protocolos a backends con el alto rendimiento de retorno del servidor directo.

Descripción general de Cloud Load Balancing.
Descripción general de Cloud Load Balancing (haz clic para ampliar).

Funciones clave de Cloud Load Balancing

Cloud Load Balancing ofrece las siguientes funciones de balanceo de cargas:

  • Dirección IP Anycast única. Con Cloud Load Balancing, una sola dirección IP Anycast es el frontend de todas las instancias de backend en regiones de todo el mundo. Proporciona un balanceo de cargas entre regiones con conmutación automática por error multirregional, que traslada el tráfico a los backends de conmutación por error si los backends principales están en mal estado. Cloud Load Balancing reacciona de inmediato ante los cambios en los usuarios, el tráfico, la red, el estado del backend y otras condiciones relacionadas.

  • Ajuste de escala automático sin interrupciones. Cloud Load Balancing puede escalarse a medida que aumentan la cantidad de usuarios y el tráfico; esto incluye la administración con facilidad de aumentos de tráfico inesperados, inmediatos y enormes, ya que los desvía a otras regiones del mundo que puedan aceptarlos. El ajuste de escala automático no requiere preparación previa: puedes pasar de cero a un funcionamiento pleno en cuestión de segundos.

  • Balanceo de cargas definido por software. Cloud Load Balancing es un servicio completamente distribuido, definido por software y administrado para todo tu tráfico. No es una solución basada en instancias ni en dispositivos, por lo que no estarás encerrado en una infraestructura de balanceo de cargas física ni tendrás que enfrentar los desafíos de alta disponibilidad, escala y administración inherentes a los balanceadores de carga basados en instancias.

  • Balanceo de cargas de la capa 4 y la capa 7. Usa el balanceo de cargas basado en la capa 4 para dirigir el tráfico en función de los datos de los protocolos de red y capa de transporte, como TCP, UDP, ESP, GRE, ICMP y ICMPv6 . Usa balanceo de cargas basado en la capa 7 para agregar decisiones de enrutamiento de solicitudes en función de atributos, como el encabezado HTTP y el identificador uniforme de recursos

  • Balanceo de cargas interno y externo. Define si el balanceador de cargas se puede usar para acceso externo o interno. Un balanceador de cargas externo acepta tráfico de Internet, mientras que un balanceador de cargas interno solo acepta tráfico RFC 1918. Puedes usar el balanceo de cargas externo cuando tus usuarios lleguen a tus aplicaciones desde Internet. Puedes usar el balanceo de cargas interno cuando tus clientes estén dentro de Google Cloud. Para obtener más información, consulta balanceo de cargas externo en comparación con el interno.

  • Balanceo de cargas global y regional. Define el alcance del balanceador de cargas. Un balanceador de cargas global admite backends en varias regiones, mientras que un balanceador de cargas regional admite backends en una sola región. Aunque la dirección IP de un balanceador de cargas regional se encuentra en una región, se puede acceder a un balanceador de cargas regional de forma global. Puedes distribuir tus backend en una o varias regiones para finalizar las conexiones cerca de tus usuarios y cumplir con tus requisitos de alta disponibilidad. Para obtener más información, consulta Balanceo de cargas global frente a regional.

  • Enrutamiento del tráfico en nivel Premium y Estándar. Los servicios de balanceo de cargas en Google Cloud tienen diferentes opciones según el nivel de red que elijas, es decir, el nivel Premium o el Estándar, y el primero es más costoso que el segundo. El nivel Premium aprovecha la red troncal global de alta calidad de Google, mientras que el nivel Estándar usa Internet público para enrutar el tráfico a través de la red. El nivel de red que elijas depende de si priorizas el costo o el rendimiento de tu carga de trabajo empresarial. Algunos servicios de balanceo de cargas solo están disponibles en el nivel Premium y no en el nivel Estándar. Para obtener más información, consulta Nivel de servicio de red Premium frente a Estándar.

  • Compatibilidad con funciones avanzadas. Cloud Load Balancing admite funciones como el balanceo de cargas IPv6, el direccionamiento del tráfico basado en la IP de origen, el balanceo de cargas ponderado, los WebSockets, los encabezados de solicitudes definidos por el usuario y el reenvío de protocolos para direcciones IP virtuales (VIP).

    También incluye las siguientes integraciones:

    • Integración en Cloud CDN para la publicación de contenido en caché. Cloud CDN es compatible con el balanceador de cargas de aplicaciones externo global y con el balanceador de cargas de aplicaciones clásico.
    • Integración en Google Cloud Armor para proteger tu infraestructura de ataques de denegación de servicio distribuido (DDoS) y otros ataques a aplicaciones dirigidas a aplicaciones. La protección contra DDoS siempre activa está disponible para el balanceador de cargas de aplicaciones externo global, el balanceador de cargas de aplicaciones clásico, el balanceador de cargas de red de proxy externo y el balanceador de cargas de red de transferencia externo. Además, Google Cloud Armor admite la protección contra DDoS de red avanzada solo para los balanceadores de cargas de red de transferencia externos. Para obtener más información, consulta Configura la protección contra DDoS de red avanzada.

Tipos de balanceadores de cargas de Google Cloud

Cloud Load Balancing ofrece dos tipos de balanceadores de cargas: balanceadores de cargas de aplicación y balanceadores de cargas de red. Deberías elegir un balanceador de cargas de aplicaciones cuando necesites un balanceador de cargas de capa 7 para las aplicaciones con tráfico HTTP(S). Elige un balanceador de cargas de red cuando necesites un balanceador de cargas de capa 4 que admita la descarga de TLS (con un balanceador de cargas de proxy) o necesites compatibilidad con protocolos de IP como UDP, ICMP y ESP (con un balanceador de cargas de transferencia).

En la siguiente tabla, se proporciona una descripción general de alto nivel de los diferentes tipos de balanceadores de cargas de Google Cloud categorizados por la capa OSI en la que operan y si se usan para acceso externo o interno.

lan Cloud Load Balancing Externo
(Acepta tráfico de Internet)
Interno
(solo acepta tráfico de RFC 1918)
Balanceadores de cargas de aplicaciones

HTTPS
Balanceo de cargas de capa 7
  • global externo
  • regional externo
  • clásica
  • interno entre regiones
  • regional interno
Balanceadores de cargas de red

TCP/SSL/Otro
Balanceo de cargas de capa 4
Balanceadores de cargas de red de proxy
  • global externo
  • regional externo
  • clásica
  • interno entre regiones
  • regional interno
Balanceadores de cargas de red de transferencia
  • regional externo
  • regional interno

Balanceadores de cargas de aplicaciones

Los balanceadores de cargas de aplicaciones son balanceadores de cargas de capa 7 basados en proxy que te permiten ejecutar y escalar tus servicios detrás de cualquier dirección IP. El balanceador de cargas de aplicaciones distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de plataformas de Google Cloud, como Compute Engine y Google Kubernetes Engine (GKE), así como backends externos a Google Cloud.

En el siguiente diagrama, se proporciona una descripción general de alto nivel de los diferentes tipos de balanceadores de cargas de aplicaciones que se pueden implementar de forma externa o interna, según si tu aplicación está orientada a Internet o es interna.

Diferentes tipos de balanceadores de cargas de aplicaciones
Diferentes tipos de balanceadores de cargas de aplicaciones.

Los balanceadores de cargas de aplicaciones externas se implementan como servicios administrados en Google Front End (GFE) o proxies de Envoy. Los clientes pueden conectarse a estos balanceadores de cargas desde cualquier lugar de Internet. Ten en cuenta la siguiente información:

  • Estos balanceadores de cargas se pueden implementar en los siguientes modos: global, regional o clásico.
  • Los balanceadores de cargas de aplicaciones externos globales admiten backends en varias regiones.
  • Los balanceadores de cargas de aplicaciones externos regionales admiten backends en una sola región.
  • Los balanceadores de cargas de aplicaciones clásicos son globales en el nivel Premium. En el nivel Estándar, solo pueden distribuir el tráfico a los backends en una sola región.
  • Los balanceadores de cargas de aplicaciones usan el proxy de Envoy de código abierto para habilitar las funciones avanzadas de administración del tráfico.

Los balanceadores de cargas de aplicaciones internos se basan en la pila de virtualización de red de Andromeda y el proxy Envoy de código abierto. Este balanceador de cargas proporciona un balanceo interno basado en proxy para los datos de aplicación de la capa 7. El balanceador de cargas usa una dirección IP interna a la que solo pueden acceder los clientes de la misma red de VPC o los clientes conectados a tu red de VPC. Ten en cuenta lo siguiente:

  • Estos balanceadores de cargas se pueden implementar en los siguientes modos: regional o interregional.
  • Los balanceadores de cargas de aplicaciones internos regionales admiten backends solo en una sola región.
  • Los balanceadores de cargas de aplicaciones internos interregionales admiten backends en varias regiones y siempre son accesibles de forma global. Los clientes de cualquier región de Google Cloud pueden enviar tráfico al balanceador de cargas.

Para obtener más información sobre los balanceadores de cargas de aplicaciones, consulta Descripción general del balanceador de cargas de aplicaciones.

Balanceadores de cargas de red

Los balanceadores de cargas de red son balanceadores de cargas de capa 4 que pueden controlar TCP, UDP o algún otro tráfico de protocolo IP. Estos balanceadores de cargas están disponibles como balanceadores de cargas de proxy o balanceadores de cargas de transferencia. Puedes elegir un balanceador de cargas según las necesidades de tu aplicación y el tipo de tráfico que necesita controlar. Elige un balanceador de cargas de red de proxy si quieres configurar un balanceador de cargas de proxy inverso compatible con controles de tráfico avanzados y backends locales y en otros entornos de nube. Elige un balanceador de cargas de red de transferencia si quieres conservar la dirección IP de origen de los paquetes de cliente, prefieres el retorno directo del servidor para las respuestas o si quieres manejar una variedad de protocolos IP como TCP, UDP, ESP, GRE, ICMP y ICMPv6.

Balanceadores de cargas de red de proxy

Los balanceadores de cargas de red de proxy son balanceadores de cargas de proxy inverso de capa 4 que distribuyen el tráfico de TCP a instancias de máquina virtual (VM) en la red de VPC de Google Cloud. El tráfico finaliza en la capa de balanceo de cargas y, luego, se reenvía al backend disponible más cercano mediante el TCP.

En el siguiente diagrama, se proporciona una descripción general de alto nivel de los diferentes tipos de balanceadores de cargas de red del proxy que se pueden implementar de forma externa o interna, según si tu aplicación está orientada a Internet o es interna.

Diferentes tipos de balanceadores de cargas de red de proxy
Diferentes tipos de balanceadores de cargas de red de proxy.

Los balanceadores de cargas de red de proxy externos son balanceadores de cargas de capa 4 que distribuyen el tráfico que proviene de Internet a los backends en la red de VPC de Google Cloud de forma local o en otros entornos de nube. Estos balanceadores de cargas se compilan en Google Front End (GFE) o proxies de Envoy.

Estos balanceadores de cargas se pueden implementar en los siguientes modos: global, regional o clásico.

  • Los balanceadores de cargas de red del proxy externo global admiten backends en varias regiones.
  • Los balanceadores de cargas de red del proxy externo regionales admiten backends en una sola región.
  • Los balanceadores de cargas de red del proxy clásico son globales en el nivel Premium. En el nivel Estándar, solo pueden distribuir el tráfico a los backends en una sola región.

Los balanceadores de cargas de red de proxy internos son balanceadores de cargas regionales de capa 4 de Envoy que te permiten ejecutar y escalar el tráfico de servicio TCP detrás de una dirección IP interna a la que solo pueden acceder los clientes de la misma red de VPC o los clientes conectados a tu red de VPC.

Estos balanceadores de cargas se pueden implementar en uno de los siguientes modos: regional o interregional.

  • Los balanceadores de cargas de red del proxy internos regionales admiten backends en una sola región.
  • Los balanceadores de cargas de red de proxy internos interregionales admiten backends en varias regiones y siempre son accesibles. Los clientes de cualquier región de Google Cloud pueden enviar tráfico al balanceador de cargas.

Para obtener más información sobre los balanceadores de cargas de red de proxy, consulta Descripción general del balanceador de cargas de red de proxy.

Balanceadores de cargas de red de transferencia

Los balanceadores de cargas de red de transferencia son balanceadores de carga de transferencia regionales de capa 4. Estos balanceadores de cargas distribuyen el tráfico entre backends en la misma región que el balanceador de cargas. Se implementan mediante las herramientas de redes virtuales de Andromeda y Google Maglev.

Como su nombre lo indica, estos balanceadores de cargas no son proxies. Las VMs de backend reciben paquetes con balanceo de cargas, direcciones IP de origen y destino, y el protocolo del paquete y, si el protocolo se basa en puertos, los puertos de origen y de destino sin cambios. Las conexiones con balanceo de cargas se finalizan en los backends. Las respuestas de las VMs de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor (DSR).

Estos balanceadores de cargas, como se muestra en la siguiente imagen, se implementan en dos modos, según si el balanceador de cargas está orientado a Internet o es interno.

Diferentes tipos de balanceadores de cargas de red de transferencia
Diferentes tipos de balanceadores de cargas de red de transferencia.
  • Los balanceadores de cargas de red de transferencia externos se basan en Maglev. Los clientes pueden conectarse a estos balanceadores de cargas desde cualquier lugar de Internet, independientemente de sus Niveles de servicio de red. El balanceador de cargas también puede recibir tráfico de las VMs de Google Cloud con direcciones IP externas o de las VMs de Google Cloud que tienen acceso a Internet a través de Cloud NAT o NAT basada en la instancia.

    Los backends para balanceadores de cargas de red de transferencia externos se pueden implementar a través de un servicio de backend o un grupo de destino. Para implementaciones nuevas, recomendamos usar servicios de backend.

  • Los balanceadores de cargas de red de transferencia internos se basan en la pila de virtualización de red de Andromeda. Un balanceador de cargas de red de transferencia interno te permite balancear la carga del tráfico de TCP/UDP detrás de una dirección IP de balanceo de cargas interna a la que solo pueden acceder los sistemas en la misma red de VPC o los sistemas conectados a tu red de VPC. Además, este balanceador de cargas solo se puede configurar en el nivel Premium.

Para obtener más información sobre los balanceadores de cargas de red de transferencia, consulta Balanceador de cargas de red de transferencia.

Componentes del balanceador de cargas

Un balanceador de cargas es un sistema compuesto por varios componentes que interactúan entre sí. No hay un solo recurso de API que represente un balanceador de cargas. En cambio, varios componentes trabajan juntos para distribuir el tráfico entrante entre varios backends.

En el siguiente diagrama, se muestran los componentes principales de un balanceador de cargas de aplicaciones, un balanceador de cargas de red de proxy y un balanceador de cargas de red de transferencia.

Balanceador de cargas de aplicaciones

Componentes de un balanceador de cargas de aplicaciones
Componentes de un balanceador de cargas de aplicaciones (haz clic para ampliar).

Balanceador de cargas de red del proxy

Componentes de un balanceador de cargas de red de proxy
Componentes de un balanceador de cargas de red de proxy (haz clic para ampliar).

Balanceador de cargas de red de transferencia

Componentes de un balanceador de cargas de red de transferencia
Componentes de un balanceador de cargas de red de transferencia (haz clic para ampliar).

La siguiente información es una descripción general de alto nivel de los componentes clave de un balanceador de cargas, desde el punto en que el tráfico llega al balanceador de cargas hasta la etapa en la que se enruta al recurso de backend. Para comprender mejor cada componente del balanceador de cargas, consulta la página vinculada en cada sección.

Regla de reenvío

Una regla de reenvío especifica una dirección IP, un protocolo IP y uno o más puertos en los que el balanceador de cargas acepta tráfico. La regla de reenvío y su dirección IP adjunta representan el frontend de un balanceador de cargas de Google Cloud.

Para obtener más información, consulta Descripción general de las reglas de reenvío.

Proxy de destino

Los proxies de destino finalizan las conexiones entrantes de los clientes y crean conexiones nuevas desde el balanceador de cargas a los backends.

  • La primera conexión se origina en el cliente y finaliza en el proxy de destino del balanceador de cargas.

  • La segunda conexión comienza en el proxy de destino y finaliza en la instancia de backend, que controla la solicitud del cliente.

La primera conexión finaliza en un Google Front End (GFE) o en una subred designada especialmente conocida como subred de solo proxy, que se reserva exclusivamente para los proxies de Envoy. Para saber si un balanceador de cargas se basa en GFE o en Envoy, consulta la tabla de la sección Tecnologías subyacentes de los balanceadores de cargas de Google Cloud de este documento.

Solo los balanceadores de cargas basados en proxy, como los balanceadores de cargas de aplicaciones y los balanceadores de cargas de red de proxy, usan proxies de destino. En el caso de estos tipos de balanceadores de cargas, las respuestas de las instancias de backend se envían al proxy de destino en lugar de hacerlo directamente al cliente.

Para obtener más información, consulta Proxies de destino.

Subred de solo proxy

Una subred de solo proxy proporciona un grupo de direcciones IP que se reservan de forma exclusiva para proxies de Envoy que usan los balanceadores de cargas de Google Cloud. Los proxies finalizan las conexiones entrantes y, luego, crean conexiones nuevas al backend.

Para obtener más información, consulta Subredes de solo proxy para balanceadores de cargas basados en Envoy.

Certificados SSL

Los certificados SSL, también conocidos como certificados de seguridad de la capa de transporte (TLS), facilitan la comunicación segura entre los clientes y los balanceadores de cargas. Los balanceadores de cargas basados en proxy cuyas reglas de reenvío hacen referencia a un proxy HTTPS o SSL de destino requieren una clave privada y un certificado SSL como parte de la configuración del proxy de destino del balanceador de cargas.

Para obtener más información, consulta Certificados SSL.

Mapa de URL

Cuando se finaliza la conexión, el proxy HTTP(S) de destino usa el mapa de URL para decidir adónde enrutar la solicitud nueva (la segunda conexión, como se indica en la sección Proxy de destino). La solicitud se enruta al servicio de backend o al bucket de backend. Solo los balanceadores de cargas de aplicaciones usan los mapas de URL. Como los balanceadores de cargas de aplicaciones funcionan en la capa 7 del modelo OSI, pueden tomar decisiones de enrutamiento en función de atributos HTTP, como el nombre de dominio, la ruta de solicitud y los parámetros de consulta.

Para obtener más información, consulta Mapas de URL.

Servicio de backend

Un servicio de backend define cómo distribuye el tráfico tu balanceador de cargas. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo que se usa para conectarse a backends, varios parámetros de configuración de distribución y sesión, verificaciones de estado y tiempos de espera.

Esta configuración proporciona un control detallado sobre el comportamiento del balanceador de cargas y te permite dirigir el tráfico a los backends correctos, que pueden ser grupos de instancias de VM o grupos de extremos de red (NEG).

Para obtener más información, consulta Descripción general de los servicios de backend.

Bucket de backend

Si tu carga de trabajo entrega contenido estático con el protocolo HTTP(S), puedes usar un bucket de Cloud Storage para almacenar contenido estático y, luego, usar un bucket de backend para enrutar las solicitudes a él.

Verificaciones de estado

Cuando configuras el servicio de backend de un balanceador de cargas, debes especificar una o más verificaciones de estado para sus backends. Una verificación de estado, como su nombre lo indica, determina si las instancias de backend del balanceador de cargas se encuentran en buen estado. Esta determinación se basa en la capacidad del backend para responder al tráfico entrante. El tráfico al que un backend debe responder depende del tipo de balanceador de cargas. Puedes crear verificaciones de estado con protocolos de la capa 7 y de la capa 4 para supervisar instancias con balanceo de cargas.

Reglas de firewall

Para que las verificaciones de estado funcionen, debes crear reglas de firewall de entrada allow que permitan que los sondeos de verificación de estado lleguen a tus backends.

Los balanceadores de cargas basados en Google Front End requieren una regla de firewall de permiso de entrada que permita que el tráfico de los CIDR de Google Front End se conecte a tus backends. Los balanceadores de cargas basados en el proxy Envoy de código abierto requieren una regla de firewall allow de entrada que permita que el tráfico de la subred de solo proxy llegue a las instancias de backend.

Para obtener más información, consulta Reglas de firewall.

Backends

Los backends son el destino final del tráfico con carga balanceada.

Los diferentes balanceadores de cargas admiten diferentes tipos de backends. Cuando agregas un backend al servicio de backend, debes especificar un modo de balanceo que evalúe la capacidad del backend para controlar solicitudes nuevas y determine cómo se distribuye el tráfico entre los backends.

Para obtener más información, consulta Backends.

Tecnologías subyacentes de los balanceadores de cargas de Google Cloud

En la siguiente tabla, se enumera la tecnología subyacente sobre la que se compila cada balanceador de cargas de Google Cloud.

  • Google Front Ends (GFE) son sistemas distribuidos definidos por software que se ubican en puntos de presencia de Google (PoP) y realizan balanceo de cargas global junto con otros sistemas y planos de control.
  • Andromeda es una pila de virtualización de red definida por software de Google Cloud.
  • Maglev es un sistema distribuido para el balanceo de cargas de red.
  • Envoy es un proxy de servicio y de código abierto, diseñado para aplicaciones nativas de la nube.
Balanceador de cargas Tecnología
Balanceador de cargas de aplicaciones externo global Google Front End (GFE) basado en Envoy
Balanceador de cargas de aplicaciones clásico GFE
Balanceador de cargas de aplicaciones externo regional Envoy
Balanceador de cargas de aplicaciones interno entre regiones Envoy
Balanceador de cargas de aplicaciones interno regional Envoy
Balanceador de cargas de red del proxy externo global GFE basado en Envoy
Balanceador de cargas de red del proxy clásico GFE
Balanceador de cargas de red del proxy externo regional Envoy
Balanceador de cargas de red del proxy interno regional Envoy
Balanceador de cargas de red del proxy interno entre regiones Envoy
Balanceador de cargas de red de transferencia externo Maglev
Balanceador de cargas de red de transferencia interno Andromeda

Elige un balanceador de cargas

Para determinar qué producto de Cloud Load Balancing usar, primero debes determinar qué tipo de tráfico deben manejar tus balanceadores de cargas. Como regla general, cuando necesites un conjunto de funciones flexibles para tus aplicaciones con tráfico HTTP(S), debes elegir un balanceador de cargas de aplicaciones. Y debes elegir un balanceador de cargas de red cuando necesites descarga de TLS a gran escala o compatibilidad con UDP, o si necesitas exponer direcciones IP de cliente a tus aplicaciones.

Puedes reducir aún más las opciones en función de los requisitos de tu aplicación, por ejemplo, si es una app externa (orientada a Internet) o interna, si necesitas backends implementados de forma global o regional y si necesitas Premium o Nivel de servicio de red Estándar.

En el siguiente diagrama, se muestran todos los modos de implementación disponibles para Cloud Load Balancing. Para obtener más información, consulta la guía Cómo elegir un balanceador de cargas.

Elige un balanceador de cargas.
Elige un balanceador de cargas (haz clic para ampliar).

1. Los balanceadores de cargas de aplicaciones externos globales admiten dos modos de operación: global y clásico.

2. Los balanceadores de cargas de red de proxy externos globales admiten dos modos de operación: global y clásico.

3. Los balanceadores de cargas de red de transferencia conservan las direcciones IP de origen del cliente. Los balanceadores de cargas de red de transferencia también admiten protocolos adicionales como UDP, ICMP y ESP.

Resumen de tipos de balanceadores de carga de Google Cloud

En la siguiente tabla, se proporcionan detalles, como el nivel de servicio de red en el que opera cada balanceador de cargas, junto con su esquema de balanceo de cargas.

Balanceador de cargas Modo de implementación Tipo de tráfico Nivel de servicio de red Esquema de balanceo de cargas *
Balanceadores de cargas de aplicaciones Global externo HTTP o HTTPS Nivel Premium EXTERNAL_MANAGED
Regional y externo HTTP o HTTPS Nivel Premium o Estándar EXTERNAL_MANAGED
Clásica HTTP o HTTPS

Global en el nivel Premium

Regional en el nivel Estándar

EXTERNAL
Regional interno HTTP o HTTPS Nivel Premium INTERNAL_MANAGED
Interno entre regiones HTTP o HTTPS Nivel Premium INTERNAL_MANAGED
Balanceadores de cargas de red de proxy Global externo TCP con transferencia de SSL opcional Nivel Premium EXTERNAL_MANAGED
Regional y externo TCP Nivel Premium o Estándar EXTERNAL_MANAGED
Clásica TCP con transferencia de SSL opcional

Global en el nivel Premium

Regional en el nivel Estándar

EXTERNO
Regional interno TCP sin descarga de SSL Nivel Premium INTERNAL_MANAGED
Interno entre regiones TCP sin descarga de SSL Nivel Premium INTERNAL_MANAGED
Balanceadores de cargas de red de transferencia

Externo

Siempre regional

TCP, UDP, ESP, ICMP, ICMPv6 y GRE Nivel Premium o Estándar EXTERNO

Interno

Siempre regional

TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH y GRE Nivel Premium INTERNAL

* El esquema de balanceo de cargas es un atributo de la regla de reenvío y el servicio de backend de un balanceador de cargas y, luego, indica si el balanceador de cargas se puede usar para tráfico interno o externo.

El término administrado en "EXTERNAL_MANAGED" o "INTERNAL_MANAGED" indica que el balanceador de cargas se implementa como un servicio administrado en un Google Front End (GFE) o en el proxy de Envoy de código abierto. En un esquema de balanceo de cargas que es administrado, las solicitudes se enrutan al GFE o al proxy de Envoy.

Es posible conectar servicios de backend 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.

Interfaces

Puedes configurar y actualizar tus balanceadores de cargas mediante las siguientes interfaces:

  • Google Cloud CLI: Es una herramienta de línea de comandos incluida en Google Cloud CLI la documentación que se llama en esta herramienta con frecuencia para realizar tareas. Para obtener una descripción general completa de la herramienta, consulta la guía de la CLI de gcloud. Puedes encontrar comandos relacionados con el balanceo de cargas en el grupo de comandosgcloud compute.

    También puedes obtener ayuda detallada para cualquier comando de gcloud mediante la marca --help:

    gcloud compute http-health-checks create --help
    
    
  • La consola de Google Cloud: Las tareas de balanceo de cargas se pueden realizar con la consola de Google Cloud.

  • API de REST: Todas las tareas de balanceo de cargas pueden realizarse con la API de Google Cloud Load Balancing. En los documentos de referencia de la API, se describen los recursos y métodos disponibles.

  • Terraform: Puedes aprovisionar, actualizar y borrar la infraestructura de balanceo de cargas de Google Cloud mediante una herramienta de código abierto de infraestructura como código, como Terraform.

¿Qué sigue?