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)

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

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

Casos de uso

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

Servicios web de tres niveles

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

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

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

Balanceo de cargas mediante el enrutamiento basado en ruta de acceso

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

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

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

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

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

Modernización de servicios heredados

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

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

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

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

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

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

Arquitectura y recursos

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

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

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

Subred de solo proxy

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

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

Regla de reenvío y dirección IP

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

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.

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

Proxy de destino

Un proxy HTTP(S) de destino regional finaliza las conexiones HTTP(S) de los clientes. El proxy HTTP(S) consulta el mapa de URL para determinar el enrutamiento del tráfico a los backends. Un proxy HTTPS de destino usa un certificado SSL para autenticarse en los clientes.

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

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

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

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

Certificado SSL

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 información sobre cómo Google encripta el tráfico de los usuarios, consulta el informe Encriptación en tránsito en Google Cloud.

Mapa de URL

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

Servicio de backend

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

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

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

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

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

Verificación de estado

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

Reglas de firewall

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

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. Para estos balanceadores de cargas, puedes cambiar el valor de tiempo de espera a fin de que los backends tengan más o menos tiempo de responder a las solicitudes.

El balanceo de cargas de HTTP(S) interno tiene tres tipos de tiempos de espera distintos:
  • Un tiempo de espera del servicio de backend HTTP configurable, que representa la cantidad de tiempo que el balanceador de cargas espera para que el backend muestre una respuesta HTTP completa. El valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos. El rango completo de valores de tiempo de espera permitido es de 1 a 2,147,483,647 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;
  • Un tiempo de espera de inactividad de la transmisión, cuyo valor se fija en 5 minutos (300 segundos) Este valor no se puede configurar. Las transmisiones HTTP se vuelven inactivas después de 5 minutos sin actividad.
  • 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.

    Accede a redes conectadas

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

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

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

    Conmutación por error

    Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado dentro de la misma región. Si todos los backends están en mal estado, el balanceador de cargas muestra una respuesta HTTP 503 Service Unavailable.

    Compatible con WebSocket

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

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

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

    El tiempo de espera para una conexión de WebSocket depende del tiempo de espera del servicio de backend configurable del balanceador de cargas, que es de 30 segundos según la configuración predeterminada. Este tiempo de espera se aplica a las conexiones de WebSocket sin importar si están en uso. 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.

    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 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, el balanceador de cargas y los backends existen en un proyecto de servicio y usan direcciones IP en las subredes de una red de VPC compartida.

    Este modelo de implementación se alinea estrechamente con los casos prácticos típicos de VPC compartida, como los siguientes:

    • La división de la responsabilidad entre la administración de red y el desarrollo de servicios mantiene una separación clara de las responsabilidades entre los administradores de red y los desarrolladores de servicios.
    • Permite que los administradores de red administren de forma segura y eficiente las direcciones IP internas.
    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

    En el proyecto host ocurre lo siguiente:

    Proyecto de servicio

    • La función de propietario, editor o una más detallada del proyecto de servicio (como un administrador de Compute) crea instancias de backend.
    • La función de propietario, editor o una más detallada del proyecto de servicio (como un administrador de red o administrador del balanceador de cargas) crea los componentes del balanceador de cargas (regla de reenvío, HTTP(S) de destino, proxy, mapa de URL, servicios de backend y verificaciones de estado).
    • Estos recursos de balanceo de cargas y las instancias de backend hacen referencia a una red de VPC compartida y subredes en el proyecto host.

    Los clientes pueden acceder al balanceador de cargas si están en la misma región y red de VPC compartida que el balanceador de cargas. Los clientes pueden estar en un proyecto de servicio o en el proyecto host.

    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

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

    La configuración de este modelo es la misma que la configuración del balanceador de cargas en una red de VPC independiente. Sigue los pasos en la página sobre cómo configurar el balanceo de cargas HTTP(S) interno.

    Compatibilidad con TLS

    De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente.

    Cuando el balanceador de cargas de HTTP(S) interno usa HTTPS como un protocolo de servicio de backend, puede negociar TLS 1.0, 1.1, 1.2 o 1.3 para el backend.

    Limitaciones

    • 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 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 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.

    • 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

    ¿Qué sigue?