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

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

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

El balanceo de cargas de HTTP(S) interno es un servicio administrado basado en el proxy de Envoy de código abierto. Esto permite funciones completas de control de tráfico basadas en parámetros HTTP(S). Después de configurar el balanceador de cargas, este asigna los proxies de Envoy de forma automática para satisfacer las necesidades de tráfico.

En un nivel alto, un balanceador de cargas de HTTP(S) interno consta de los siguientes elementos:

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

Se usan los siguientes componentes adicionales para entregar el servicio de balanceo de cargas:

  • Un mapa de URL, que define reglas de control de tráfico (basadas en parámetros de capa 7, como encabezados HTTP) que se asignan a servicios de backend específicos. El balanceador de cargas evalúa las solicitudes entrantes con el mapa de URL a fin de enrutar el tráfico a servicios de backend o realizar acciones adicionales (como redireccionamientos).
  • Verificaciones de estado, que verifican de forma periódica el estado de los backends y reducen el riesgo de que el tráfico de clientes se envíe a un backend sin respuesta.

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

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

Casos prácticos

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

Balanceo de cargas mediante el enrutamiento basado en rutas de acceso

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

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

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

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

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

Modernización de servicios heredados

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

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

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

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

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

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

Servicios web de tres niveles

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

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

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

Ejemplos de acceso

Puedes acceder a un balanceador de cargas de HTTP(S) interno en tu red de VPC desde una red conectada mediante el siguiente procedimiento:

  • Intercambio de tráfico entre redes de VPC
  • Cloud VPN y Cloud Interconnect

Para ver ejemplos detallados, consulta Balanceo de cargas de HTTP(S) interno y redes conectadas.

Arquitectura y recursos

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

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

En el diagrama anterior, la subred de solo proxy (proxy-only subnet) proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de HTTP(S) internos. Todos los balanceadores de cargas de HTTP(S) internos en una región y red de VPC comparten la misma subred de solo proxy porque también comparten un grupo de proxies de Envoy. Además:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • Las VM de backend o los extremos de todos los balanceadores de cargas de HTTP(S) internos en una región y una red de VPC reciben conexiones desde la subred de solo proxy.
  • La dirección IP de un balanceador de cargas de HTTP(S) interno no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada interna, que se describe a continuación.

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

  • Una regla de reenvío administrada interna especifica una dirección IP interna, un puerto y un proxy de HTTP(S) de destino regional. Los clientes usan la dirección IP y el puerto para conectarse a los proxies de Envoy del balanceador de cargas; la dirección IP de la regla de reenvío es la dirección IP del balanceador de cargas (a veces denominada dirección IP virtual o VIP).

    La dirección IP interna asociada con la regla de reenvío puede provenir de cualquier subred (en la misma red y región) con la marca --purpose configurada como PRIVATE. Ten en cuenta lo siguiente:

    • La dirección IP puede (pero no es necesario) provenir de la misma subred que los grupos de instancias de backend.
    • La dirección IP no debe provenir de la subred de solo proxy reservada que tiene la marca --purpose configurada como INTERNAL_HTTPS_LOAD_BALANCER.
  • Un proxy HTTP(S) de destino regional finaliza las conexiones HTTP(S) de los clientes. El proxy HTTP(S) consulta el mapa de URL para determinar el enrutamiento del tráfico a los backends. Un proxy HTTPS de destino usa un certificado SSL para autenticarse en los clientes.

    El balanceador de cargas conserva el encabezado del host de la solicitud original del cliente. El balanceador de cargas también agrega dos direcciones IP al encabezado X-Forwarded-For:

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

    Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado. Si la solicitud tiene un encabezado X-Forwarded-For, otra información, como las direcciones IP registradas por los proxies en el camino hacia el balanceador de cargas, se conserva antes de las dos direcciones IP. El balanceador de cargas no verifica ninguna dirección IP que preceda a las últimas dos direcciones IP en este encabezado.

    Si ejecutas un proxy como un servidor de backend, este suele agregar más información al encabezado X-Forwarded-For, y es posible que el software deba tenerlo en cuenta. Las solicitudes que se envían a través de un proxy desde el balanceador de cargas provienen de una dirección IP en la subred de solo proxy, y el proxy en tu instancia de backend podría registrar esta dirección, así como la dirección IP de la instancia de backend.

  • El proxy HTTP(S) usa un mapa de URL regional para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy desvía las solicitudes de los clientes a servicios de backend regionales específicos. En el mapa de URL se pueden especificar acciones adicionales, como volver a escribir encabezados, enviar redireccionamientos a clientes y configurar políticas de tiempo de espera, entre otras.

  • Un servicio de backend regional distribuye las solicitudes a backends en buen estado (ya sean grupos de instancias que contienen VM de Compute Engine o NEG que contienen contenedores de GKE).

  • Uno o más backends deben estar conectados al servicio de backend. Los backends pueden ser grupos de instancias o NEG con cualquiera de las siguientes opciones de configuración:

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

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

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

Certificados SSL

Si usas el balanceo de cargas basado en HTTPS, debes instalar uno o más certificados SSL en el proxy HTTPS de destino.

Los proxies HTTPS de destino usan estos certificados para proteger las comunicaciones entre el balanceador de cargas y el cliente.

A fin de obtener más información sobre los límites y las cuotas de los certificados SSL, consulta Certificados SSL en la página de cuotas del balanceo de cargas.

Para obtener la mejor seguridad, usa la encriptación de extremo a extremo en la implementación del balanceador de cargas de HTTPS. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Para obtener más información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe de Encriptación en tránsito en Google Cloud.

Reglas de firewall

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

Tiempos de espera y reintentos

El tiempo de espera del servicio de backend es un tiempo de espera de solicitudes y respuestas para el tráfico HTTP(S). Esta es la cantidad de tiempo que el balanceador de cargas espera a que un backend muestre una respuesta completa a una solicitud.

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

El balanceo de cargas de HTTP(S) interno tiene dos tipos de tiempos de espera distintos:
  • Un tiempo de espera del servicio de backend HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera para que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos. Considera aumentar este tiempo de espera en cualquiera de estas circunstancias:

    • Si esperas que a un backend le lleve más tiempo mostrar respuestas HTTP
    • Si ves una respuesta HTTP 408 con jsonPayload.statusDetail client_timed_out
    • Si la conexión se actualiza a un WebSocket

    Para el tráfico WebSocket enviado mediante un balanceador de cargas, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión WebSocket puede permanecer abierta, ya sea que esté activa o no. Para obtener más información, consulta Configuración del servicio de backend.

  • Un tiempo de espera de sesión TCP, cuyo valor se fija en 10 minutos (600 segundos). Este tiempo de espera de la sesión a veces se denomina tiempo de espera keepalive o inactivo, y su valor no se puede configurar mediante la modificación del servicio de backend. Debes configurar el software del servidor web que usan tus backends para que su tiempo de espera keepalive sea superior a 600 segundos a fin de evitar que el backend cierre de forma prematura las conexiones. Este tiempo de espera no se aplica a WebSockets.

En esta tabla, se ilustran los cambios necesarios a fin de modificar los tiempos de espera de keepalive para el software del servidor web común:

Software del 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;

El balanceador de cargas reintenta las solicitudes GET que fallaron en ciertas circunstancias, como cuando se agota el tiempo de espera del servicio de backend. No se reintentan las solicitudes POST que fallaron. Solo se puede reintentar dos veces. Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

Para obtener más información, consulta Registro y supervisión del balanceo de cargas de HTTP(S) interno.

Compatibilidad con WebSocket

Los balanceadores de cargas basados en HTTP(S) de Google Cloud tienen compatibilidad nativa con el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.

El protocolo WebSocket proporciona un canal de comunicación dúplex completo entre clientes y servidores. Una solicitud HTTP(S) inicia el canal. Para obtener información detallada sobre el protocolo, consulta RFC 6455.

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

El tiempo de espera para una conexión de WebSocket depende del tiempo de espera del servicio de backend configurable del balanceador de cargas, que es de 30 segundos según la configuración predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso. Para obtener más información sobre el tiempo de espera del servicio de backend y cómo configurarlo, consulta Tiempos de espera y reintentos.

La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener información, consulta Afinidad de sesión.

Tipos de tráfico, esquema y alcance

Los servicios de backend admiten los protocolos HTTP, HTTPS o HTTP/2. Los clientes y los backends no necesitan usar el mismo protocolo de solicitud. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas mediante HTTP/2, y el balanceador de cargas puede reenviar estas solicitudes a backends mediante HTTP/1.1.

Debido a que el alcance de un balanceador de cargas de HTTP(S) interno es regional, en vez de global, los clientes y los extremos o VM de backend deben estar todos en la misma región.

Arquitecturas de VPC compartida

El balanceo de cargas de HTTP(S) interno admite redes que usan VPC compartida. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida. En un nivel alto, haz lo siguiente:

  • Debes designar un proyecto host y adjuntarle uno o más proyectos de servicio.
  • El administrador del proyecto host crea una o más redes y subredes de VPC compartida, y las comparte con los proyectos de servicio.
  • Para los recursos aptos de proyectos de servicio, se pueden usar subredes en la red de VPC compartida.

En el contexto del balanceo de cargas de HTTP(S) interno, hay dos formas de configurar el balanceo de cargas dentro de una red de VPC compartida. Puedes crear el balanceador de cargas y sus instancias de backend en el proyecto de servicio o en el de host.

Balanceador de cargas y backends en un proyecto de servicio

En este modelo implementas el balanceador de cargas y las instancias de backend en un proyecto de servicio. Luego, configuras el balanceador de cargas y las instancias de backend para usar la red de VPC compartida.

Este modelo de implementación se adapta bien al caso práctico típico del modelo de implementación de red de VPC compartida: la división de la responsabilidad entre la administración de la red y el desarrollo del servicio. Permite a los administradores de red asignar espacio de IP interna de manera segura y eficiente, y mantiene una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios.

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

Proyecto host

El administrador del proyecto host realiza lo siguiente:

  • Configura la red de VPC compartida en el proyecto host.
  • Aprovisiona subredes de la red de VPC compartida.
  • Configura las reglas de firewall en la red de VPC compartida.

Proyecto de servicio

  • El administrador del proyecto de servicio crea el balanceador de cargas (regla de reenvío, proxy HTTP(S) de destino, mapa de URL, servicios de backend) y las instancias de backend en el proyecto de servicio.
  • Estos recursos de balanceo de cargas y las instancias de backend hacen referencia a la red compartida y las subredes del proyecto host de VPC compartida.

Este patrón permite a los desarrolladores de servicios crear servicios de balanceo de cargas en sus propios proyectos de servicio. El equipo de desarrollo de servicios también puede actualizar la configuración del balanceador de cargas y realizar cambios en las instancias de backend sin involucrar a los administradores del proyecto host.

Si los clientes están en la misma red de VPC compartida que el balanceador de cargas, pueden estar en el proyecto host o en un proyecto de servicio. Estos clientes pueden usar la dirección IP privada del balanceador de cargas para acceder a los servicios de balanceo de cargas.

Si deseas obtener información sobre cómo configurar un balanceador de cargas de HTTP(S) interno para una red de VPC compartida, consulta Configura el balanceo de cargas de HTTP(S) interno con una VPC compartida.

Balanceador de cargas y backends en un proyecto host

Con este modelo de implementación de redes, la red, el balanceador de cargas y los backends están en el proyecto host. Si bien esta configuración funciona, no es adecuada para implementaciones típicas de VPC compartida, ya que no separa las responsabilidades de la administración de red y el desarrollo de servicios.

Si aún necesitas ejecutar un balanceador de cargas y sus backends en el proyecto host, puedes seguir los pasos detallados en Configura el balanceo de cargas de HTTP(S) interno.

Limitaciones

  • El balanceo de cargas HTTP(S) interno opera a nivel regional.

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

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

  • Cuando se crea un balanceador de cargas de HTTP(S) interno en un proyecto host o un servicio de VPC compartida, se debe cumplir lo siguiente:

    • Todos los componentes y backends del balanceo de cargas deben existir en el mismo proyecto, ya sea en un proyecto host o en un proyecto de servicio. Por ejemplo, no puedes implementar la regla de reenvío del balanceador de cargas en un proyecto y crear instancias de backend en otro proyecto.

    • Los clientes pueden estar ubicados en el proyecto host, en cualquier proyecto de servicio adjunto o en cualquier red conectada. Los clientes deben usar la misma red de VPC compartida y estar en la misma región que el balanceador de cargas.

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

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

  • Dentro de cada red de VPC, cada regla de reenvío administrado interno debe tener su propia dirección IP. Para obtener más información, consulta Varias reglas de reenvío con una dirección IP común.

  • La regla de reenvío interno que usa el balanceador de cargas de HTTP(S) interno debe tener exactamente un puerto.

  • Si envías solicitudes a un balanceador de cargas de HTTP(S) interno a través de una VM de router intermedio (como un dispositivo de enrutamiento), debes configurar el dispositivo de enrutamiento para que realice las siguientes acciones:

    1. Configurar la VM de router (el dispositivo de enrutamiento) para realizar la traducción de la direcciones de red de origen (SNAT) antes de enviar paquetes de solicitudes al balanceador de cargas de HTTP(S) interno
    2. Configurar la VM de router para realizar la traducción de direcciones de red de destino (DNAT) cuando se entregan paquetes de respuesta enviados desde el balanceador de cargas de HTTP(S) interno

Próximos pasos