Información general sobre el balanceador de carga de red de proxy interno

El Google Cloud balanceador de carga de red de proxy interno es un balanceador de carga basado en proxy que se basa en el software de proxy Envoy de código abierto y en la pila de virtualización de redes de Andromeda.

El balanceador de carga de red de proxy interno es un balanceador de carga de capa 4 que te permite ejecutar y escalar el tráfico de tu servicio TCP mediante una dirección IP interna regional a la que solo pueden acceder los clientes de la misma red de VPC o los clientes conectados a tu red de VPC. El balanceador de carga primero finaliza la conexión TCP entre el cliente y el balanceador de carga en un proxy Envoy. El proxy abre una segunda conexión TCP a los back-ends alojados en Google Cloud, en entornos locales o en otros entornos de nube. Para ver más casos prácticos, consulta la descripción general del balanceador de carga de red de proxy.

Modos de funcionamiento

Puede configurar un balanceador de carga de red proxy interno en los siguientes modos:

• Balanceador de carga de red de proxy interno regional. Se trata de un balanceador de carga regional que se implementa como un servicio gestionado basado en el proxy Envoy de software libre. En el modo regional, todos los clientes y back-ends son de una región específica, lo que resulta útil cuando necesitas cumplir requisitos regionales.

• Balanceador de carga de red de proxy interno interregional. Se trata de un balanceador de carga multirregional que se implementa como un servicio gestionado basado en el proxy de código abierto Envoy. El modo interregional te permite balancear la carga del tráfico a servicios de backend distribuidos a nivel mundial con backends en varias regiones, incluida la gestión del tráfico, que asegura que el tráfico se dirija al backend más cercano. Este balanceador de carga también habilita la alta disponibilidad. Colocar backends en varias regiones ayuda a evitar fallos en una sola región. Si los back-ends de una región no funcionan, el tráfico puede redirigirse a otra región. Las direcciones IP de las reglas de reenvío del balanceador de carga siempre están accesibles en todas las regiones.

  En la siguiente tabla se describen las diferencias importantes entre los modos regional y multirregional:

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

Identificar el modo

gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

Arquitectura

En el siguiente diagrama se muestran los recursos Google Cloud necesarios para los balanceadores de carga de red de proxy internos.

Regional

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

Interregional

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

Subred de solo proxy

En el diagrama anterior, la subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses un balanceador de carga de red interno basado en Envoy.

En la siguiente tabla se describen los requisitos de las subredes de solo proxy para los balanceadores de carga de red de proxy internos:

Además:

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

Reglas de reenvío y direcciones IP

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

Especificación de la dirección IP. Cada regla de reenvío hace referencia a una sola dirección IP regional que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática que quieras usar o dejar que Cloud Load Balancing te asigne una. Te recomendamos que reserves una dirección IP estática. De lo contrario, tendrás que actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que elimines una regla de reenvío y crees una nueva.

Los clientes usan la dirección IP y el puerto para conectarse a los proxies de Envoy del balanceador de carga. La dirección IP de la regla de reenvío es la dirección IP del balanceador de carga (a veces se denomina dirección IP virtual o VIP). Los clientes que se conecten a un balanceador de carga deben usar TCP. Para ver la lista completa de protocolos admitidos, consulta Comparativa de funciones de los balanceadores de carga.

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

Especificación de puerto. Cada regla de reenvío que utilices en un balanceador de carga de red de proxy interno puede hacer referencia a un único puerto del intervalo 1-65535. Para admitir varios puertos, debes configurar varias reglas de reenvío.

En la siguiente tabla se muestran los requisitos de las reglas de reenvío de los balanceadores de carga de red de proxy interno:

Reglas de reenvío y redes de VPC

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

Proxies de destino

El balanceador de carga de red de proxy interno finaliza las conexiones TCP del cliente y crea nuevas conexiones con los back-ends. De forma predeterminada, la dirección IP del cliente original y la información del puerto no se conservan. Puedes conservar esta información mediante el protocolo PROXY. El proxy de destino enruta las solicitudes entrantes directamente al servicio de backend del balanceador de carga.

En la siguiente tabla se muestran las APIs de proxy de destino que requieren los balanceadores de carga de red de proxy interno:

Servicio de backend

Un servicio de backend dirige el tráfico entrante a uno o varios backends conectados. Un backend es un grupo de instancias o un grupo de puntos finales de red. El backend contiene información sobre el modo de balanceo para definir la capacidad en función de las conexiones (o, solo en el caso de los backends de grupos de instancias, la utilización).

Cada balanceador de carga de red de proxy interno tiene un único recurso de servicio de backend.

En la siguiente tabla se especifican los requisitos del servicio de backend de los balanceadores de carga de red de proxy interno:

Back-ends admitidos

El servicio backend admite los siguientes tipos de backends:

Todos los back-ends deben ser del mismo tipo (grupos de instancias o NEGs). Puedes usar simultáneamente diferentes tipos de backends de grupos de instancias o diferentes tipos de backends de NEGs, pero no puedes usar backends de grupos de instancias y de NEGs al mismo tiempo en el mismo servicio de backend.

Puedes combinar NEGs zonales y NEGs híbridas en el mismo servicio de backend.

Para minimizar las interrupciones del servicio para tus usuarios, habilita el drenaje de conexiones en los servicios backend. Estas interrupciones pueden producirse cuando se termina un backend, se elimina manualmente o se elimina mediante un escalador automático. Para obtener más información sobre cómo usar el drenaje de conexiones para minimizar las interrupciones del servicio, consulta Habilitar el drenaje de conexiones.

Back-ends y redes de VPC

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

  Definición de la red de backend

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

  Requisitos de red del backend

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

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

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

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

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

Backends e interfaces de red

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

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

Protocolo para comunicarse con los backends

Cuando configuras un servicio de backend para un balanceador de carga de red de proxy interno, defines el protocolo que usa el servicio de backend para comunicarse con los backends. El balanceador de carga solo usa el protocolo que especifiques y no intenta negociar una conexión con el otro protocolo. Los balanceadores de carga de red de proxy interno solo admiten TCP para comunicarse con los backends.

Comprobación del estado

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

Protocolo de comprobación del estado

Aunque no es obligatorio y no siempre es posible, es recomendable usar una comprobación de estado cuyo protocolo coincida con el protocolo del servicio backend. Por ejemplo, una comprobación de estado de TCP prueba con mayor precisión la conectividad TCP a los backends. Para ver la lista de protocolos de comprobación del estado admitidos, consulta la sección Comprobaciones del estado de la página de comparación de funciones del balanceador de carga.

En la siguiente tabla se especifica el ámbito de las comprobaciones de estado admitidas por los balanceadores de carga de red de proxy interno en cada modo:

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

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

Reglas de cortafuegos

Los balanceadores de carga de red de proxy interno requieren las siguientes reglas de cortafuegos:

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

Los puertos de estas reglas de cortafuegos deben configurarse de la siguiente manera:

• Permite el tráfico al puerto de destino para la comprobación del estado de cada servicio de backend.

• En el caso de los backends de grupos de instancias, determine los puertos que se van a configurar mediante la asignación entre el puerto con nombre del servicio de backend y los números de puerto asociados a ese puerto con nombre en cada grupo de instancias. Los números de puerto pueden variar entre los grupos de instancias asignados al mismo servicio de backend.

• En el caso de los backends de GCE_VM_IP_PORT NEG, permite el tráfico a los números de puerto de los endpoints.

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

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

Acceso de cliente

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

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

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

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

Arquitectura de VPC compartida

El balanceador de carga de red del proxy interno admite redes que usan VPC compartida. Las VPC compartidas te permiten mantener una separación clara de las responsabilidades entre los administradores de redes y los desarrolladores de servicios. Tus equipos de desarrollo pueden centrarse en crear servicios en proyectos de servicio, y los equipos de infraestructura de red pueden aprovisionar y administrar el balanceo de carga. Si no conoces la VPC compartida, consulta la documentación general sobre la VPC compartida.

Distribución del tráfico

Un balanceador de carga de red de proxy interno distribuye el tráfico a sus backends de la siguiente manera:

1. Las conexiones procedentes de un mismo cliente se envían a la misma zona siempre que haya back-ends (grupos de instancias o NEGs) en buen estado y con capacidad en esa zona, según lo determinado por el modo de balanceo. En el caso de los balanceadores de carga de red con proxy internos regionales, el modo de balanceo puede ser CONNECTION (backends de grupos de instancias o NEGs) o UTILIZATION (backends de grupos de instancias únicamente).
2. Las conexiones de un cliente se envían al mismo backend si has configurado la afinidad de sesión.
3. Una vez que se ha seleccionado un backend, el tráfico se distribuye entre las instancias (en un grupo de instancias) o los endpoints (en un NEG) según una política de balanceo de carga. Para ver los algoritmos de la política de balanceo de carga admitidos, consulta el ajuste localityLbPolicy en la documentación de la API del servicio de backend regional.

Afinidad de sesión

La afinidad de sesión te permite configurar el servicio de backend del balanceador de carga para que envíe todas las solicitudes del mismo cliente al mismo backend, siempre que el backend esté en buen estado y tenga capacidad.

• Ninguno

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

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

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

• Afinidad de IP de cliente

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

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

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

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

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

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

Pérdida de la afinidad de sesión

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

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

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

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

  • Añadir nuevas instancias o endpoints:

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

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

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

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

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

Conmutación por error

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

En la siguiente tabla se describe el comportamiento de conmutación por error de los balanceadores de carga de red de proxy internos:

Balanceo de carga para aplicaciones de GKE

Si creas aplicaciones en Google Kubernetes Engine (GKE), puedes usar NEGs zonales independientes para balancear la carga del tráfico directamente a los contenedores. Con los NEGs independientes, eres responsable de crear el objeto Service que crea el NEG zonal y, a continuación, de asociar el NEG con el servicio de backend para que el balanceador de carga pueda conectarse a los pods.

Documentación relacionada de GKE:

• Balanceo de carga nativo de contenedores mediante NEGs independientes

Cuotas y límites

Para obtener información sobre las cuotas y los límites, consulta Cuotas y límites.

Limitaciones

• El balanceador de carga de red de proxy interno no admite tráfico IPv6.
• El balanceador de carga de red de proxy interno no admite implementaciones de VPC compartida en las que el frontend del balanceador de carga se encuentra en un proyecto de host o de servicio, y el servicio de backend y los backends se encuentran en otro proyecto de servicio (también conocido como referencia de servicio entre proyectos).

Siguientes pasos

• Configurar un balanceador de carga de aplicación interno entre regiones con backends de grupos de instancias de VM

• Configurar un balanceador de carga de aplicación interno entre regiones con conectividad híbrida

• Configurar un balanceador de carga de red de proxy interno regional con un backend de grupo de instancias

• Configurar un balanceador de carga de red de proxy interno regional con un backend de NEG de zona

• Configurar un balanceador de carga de red de proxy interno regional con un backend de NEG híbrido

• Configurar un balanceador de carga de red de proxy interno regional con un backend de NEG de Internet

• Ver métricas con Cloud Monitoring