Información general sobre los grupos de puntos finales de red de conectividad híbrida

Cloud Load Balancing admite el balanceo de carga del tráfico a endpoints que se extienden Google Cloudmás allá, como centros de datos on-premise y otras nubes públicas a las que puedes acceder mediante conectividad híbrida.

Una estrategia híbrida es una solución pragmática para adaptarse a los cambios en las demandas del mercado y modernizar las aplicaciones de forma gradual. Puede tratarse de una implementación híbrida temporal para permitir la migración a una solución moderna basada en la nube o de un elemento permanente de la infraestructura de TI de tu organización.

Configurar el balanceo de carga híbrido también te permite aprovechar las ventajas de las funciones de red de Cloud Load Balancing en los servicios que se ejecutan en tu infraestructura fuera de Google Cloud.

El balanceo de carga híbrido se admite en los siguientes Google Cloud balanceadores de carga:

Los servicios on-premise y otros servicios en la nube se tratan como cualquier otro backend de Cloud Load Balancing. La diferencia principal es que se usa un NEG de conectividad híbrida para configurar los endpoints de estos back-ends. Los endpoints deben ser combinaciones de IP:port válidas a las que pueda acceder el balanceador de carga mediante productos de conectividad híbrida, como Cloud VPN, Cloud Interconnect o máquinas virtuales de dispositivo router.

Caso práctico: enrutar el tráfico a una ubicación local u otra nube

El caso práctico más sencillo para usar NEGs híbridas es enrutar el tráfico de un Google Cloud balanceador de carga a una ubicación on-premise o a otro entorno de nube. Los clientes pueden originar tráfico desde Internet público, desde dentro de Google Cloudo desde un cliente local.

Clientes públicos

Puedes usar un balanceador de carga de aplicaciones externo con un backend de NEG híbrido para enrutar el tráfico de clientes externos a un backend local o en otra red de nube. También puede habilitar las siguientes funciones de red de valor añadido para sus servicios on-premise o en otras redes de nube:

  • Con el balanceador de carga de aplicación externo global y el balanceador de carga de aplicación clásico, puedes hacer lo siguiente:

    • Usa la infraestructura perimetral global de Google para finalizar las conexiones de los usuarios más cerca de ellos y, de este modo, reducir la latencia.
    • Protege tu servicio con Google Cloud Armor, un producto de seguridad de defensa contra ataques DDoS y WAF de perímetro disponible para todos los servicios a los que se accede a través de un balanceador de carga de aplicaciones externo.
    • Habilita tu servicio para optimizar la entrega mediante Cloud CDN. Con Cloud CDN, puedes almacenar contenido en caché cerca de tus usuarios. Cloud CDN ofrece funciones como la invalidación de caché y las URLs firmadas de Cloud CDN.
    • Usa certificados SSL gestionados por Google. Puedes reutilizar los certificados y las claves privadas que ya uses en otros productos de Google Cloud . De esta forma, no es necesario gestionar certificados independientes.

    En el siguiente diagrama se muestra un despliegue híbrido con un balanceador de carga de aplicaciones externo.

    Conectividad híbrida con un balanceador de carga de aplicación externo global.
    Conectividad híbrida con un balanceador de carga de aplicación externo global (haz clic para ampliar).

    En este diagrama, el tráfico de los clientes en Internet público entra en tu red privada local o en la nube a través de un Google Cloud balanceador de carga, como el balanceador de carga de aplicación externo. Cuando el tráfico llega al balanceador de carga, puedes aplicar servicios de perímetro de red, como la protección contra DDoS de Cloud Armor o la autenticación de usuarios de Identity-Aware Proxy (IAP).

  • Con el balanceador de carga de aplicación externo regional, puedes dirigir el tráfico externo a los endpoints que se encuentren en la misma región Google Cloud que los recursos del balanceador de carga. Usa este balanceador de carga si solo necesitas servir contenido desde una geolocalización (por ejemplo, para cumplir normativas) o si quieres usar el nivel de servicio de red estándar.

La forma en que se dirige la solicitud (si a un backend o a un endpoint local o en la nube) depende de cómo esté configurado el mapa de URLs. Google Cloud En función de tu mapa de URLs, el balanceador de carga selecciona un servicio de backend para la solicitud. Si el servicio de backend seleccionado se ha configurado con un NEG de conectividad híbrida (que solo se usa para los endpoints que no son deGoogle Cloud ), el balanceador de carga reenvía el tráfico a través de Cloud VPN, Cloud Interconnect o las VMs del dispositivo Router a su destino externo.

Clientes internos (dentro de Google Cloud o en las instalaciones)

También puedes configurar una implementación híbrida para clientes internos de Google Cloud. En este caso, el tráfico de clientes procede de la red de VPCGoogle Cloud , de tu red local o de otra nube, y se dirige a endpoints locales o de otras redes de nube.

El balanceador de carga de aplicaciones interno regional es un balanceador de carga regional, lo que significa que solo puede enrutar el tráfico a los endpoints que se encuentren en la misma Google Cloud región que los recursos del balanceador de carga. El balanceador de carga de aplicaciones interno entre regiones es un balanceador de carga multirregional que puede equilibrar la carga del tráfico a servicios de backend distribuidos a nivel mundial.

En el siguiente diagrama se muestra un despliegue híbrido con un balanceador de carga de aplicaciones interno regional.

Conectividad híbrida con balanceadores de carga de aplicaciones internos regionales.
Conectividad híbrida con balanceadores de carga de aplicación internos regionales (haz clic en la imagen para ampliarla).

Caso práctico: migrar a la nube

Si migras un servicio a la nube, puedes liberar capacidad on-premise y reducir el coste y la carga de mantener la infraestructura on-premise. Puedes configurar temporalmente un despliegue híbrido que te permita enrutar el tráfico tanto a tu servicio local actual como a un endpoint de servicioGoogle Cloud correspondiente.

En el siguiente diagrama se muestra esta configuración con un balanceador de carga de aplicaciones interno.

Migra a Google Cloud.
Migrar a Google Cloud (haz clic para ampliar).

Si utilizas un balanceador de carga de aplicaciones interno para gestionar clientes internos, puedes configurar el balanceador de carga para que use la división del tráfico basada en el peso y así dividir el tráfico entre los dos servicios. Google Cloud La división del tráfico te permite empezar enviando el 0% del tráfico al servicio Google Cloud y el 100% al servicio local. Después, puedes aumentar gradualmente la proporción de tráfico enviado al servicio Google Cloud . Finalmente, envía el 100% del tráfico al servicio Google Cloud y puedes retirar el servicio local.

Arquitectura híbrida

En esta sección se describe la arquitectura de balanceo de carga y los recursos necesarios para configurar una implementación de balanceo de carga híbrido.

Los servicios on-premise y otros servicios en la nube son como cualquier otro backend de Cloud Load Balancing. La diferencia principal es que se usa un NEG de conectividad híbrida para configurar los endpoints de estos back-ends. Los endpoints deben ser combinaciones IP:port válidas a las que puedan acceder tus clientes a través de la conectividad híbrida, como Cloud VPN, Cloud Interconnect o una VM de dispositivo router.

En los siguientes diagramas se muestran los Google Cloud recursos necesarios para habilitar el balanceo de carga híbrido en balanceadores de carga de aplicación externos y balanceadores de carga de aplicación internos regionales.

HTTP(S) externo global

Recursos de balanceador de carga de aplicación externo global para la conectividad híbrida.
Recursos del balanceador de carga de aplicación externo global para la conectividad híbrida (haz clic para ampliar).

HTTP(S) externo regional

Recursos de balanceador de carga de aplicación externo regional para la conectividad híbrida.
Recursos del balanceador de carga de aplicación externo regional para la conectividad híbrida (haz clic para ampliar).

HTTP(S) interno regional

Recursos de balanceador de carga de aplicación interno regional para la conectividad híbrida.
Recursos del balanceador de carga de aplicación interno regional para la conectividad híbrida (haz clic para ampliar).

Proxy interno regional

Recursos de balanceador de carga de red con proxy interno regional para la conectividad híbrida.
Recursos del balanceador de carga de red de proxy interno regional para la conectividad híbrida (haz clic para ampliar).

Regional o global

El enrutamiento de Cloud Load Balancing depende del ámbito del balanceador de carga configurado:

Balanceador de carga de aplicación externo y balanceador de carga de red de proxy externo. Estos balanceadores de carga se pueden configurar para el enrutamiento global o regional en función del nivel de red que se utilice. Crea el backend de NEG híbrido del balanceador de carga en la misma red y región en las que se haya configurado la conectividad híbrida. Los endpoints que no seanGoogle Cloud también deben configurarse de forma adecuada para aprovechar el balanceo de carga basado en la proximidad.

Balanceador de carga de aplicación interno entre regiones y balanceador de carga de red con proxy interno entre regiones. Se trata de un balanceador de carga multirregional que puede equilibrar la carga del tráfico a servicios de backend distribuidos en todo el mundo. Crea el backend del NEG híbrido del balanceador de carga en la misma red y región en las que se haya configurado la conectividad híbrida. Los endpoints que no seanGoogle Cloud también deben configurarse de forma adecuada para aprovechar el balanceo de carga basado en la proximidad.

Balanceador de carga de aplicaciones interno regional y balanceador de carga de red de proxy interno regional. Se trata de balanceadores de carga regionales. Es decir, solo pueden enrutar el tráfico a endpoints de la misma región que el balanceador de carga. Los componentes del balanceador de carga deben configurarse en la misma región en la que se haya configurado la conectividad híbrida. De forma predeterminada, los clientes que acceden al balanceador de carga también deben estar en la misma región. Sin embargo, si habilitas el acceso global, los clientes de cualquier región podrán acceder al balanceador de carga.

Por ejemplo, si la pasarela de Cloud VPN o la vinculación de VLAN de Cloud Interconnect se configuran en REGION_A, los recursos que necesita el balanceador de carga (como un servicio de backend, un NEG híbrido o una regla de reenvío) deben crearse en la región REGION_A. De forma predeterminada, los clientes que acceden al balanceador de carga también deben estar en la región REGION_A. Sin embargo, si habilitas el acceso global, los clientes de cualquier región podrán acceder al balanceador de carga.

Requisitos de conexión de red

Antes de configurar una implementación de balanceo de carga híbrido, debes configurar los siguientes recursos:

  • Google Cloud Red de VPC. Una red de VPC configurada en Google Cloud. Es la red de VPC que se usa para configurar Cloud Interconnect, Cloud VPN y Cloud Router. También es la misma red en la que crearás los recursos de balanceo de carga (regla de reenvío, proxy de destino, servicio de backend, etc.). Las direcciones IP y los intervalos de direcciones IP de las subredes, de las instalaciones locales y de otras nubes no deben solaparse. Google Cloud Cuando las direcciones IP se superponen, las rutas de subred tienen prioridad sobre la conectividad remota.

  • Conectividad híbrida. Tu Google Cloud y los entornos on-premise u otros entornos de nube deben estar conectados mediante conectividad híbrida, ya sea con vinculaciones de VLAN de Cloud Interconnect, túneles de Cloud VPN con Cloud Router o máquinas virtuales de dispositivo router. Te recomendamos que uses una conexión de alta disponibilidad. Un Cloud Router habilitado con el enrutamiento dinámico global obtiene información sobre el endpoint específico mediante BGP y lo programa en tu red deGoogle Cloud VPC. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.

    Cloud Interconnect, Cloud VPN o el dispositivo router deben configurarse en la misma red de VPC que quieras usar para la implementación del balanceo de carga híbrido. El router de Cloud también debe anunciar las siguientes rutas a tu entorno local:

    • Intervalos usados por las sondas de comprobación del estado de Google: 35.191.0.0/16 y 130.211.0.0/22. Esto es necesario para los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos, los balanceadores de carga de red con proxy externos globales y los balanceadores de carga de red con proxy clásicos.

    • El intervalo de la subred de solo proxy de la región: para los balanceadores de carga basados en Envoy, los balanceadores de carga de aplicaciones externos regionales,los balanceadores de carga de aplicaciones internos regionales, los balanceadores de carga de aplicaciones internos entre regiones,los balanceadores de carga de red con proxy externos regionales, los balanceadores de carga de red con proxy internos entre regiones y los balanceadores de carga de red con proxy internos regionales.

      La subred de solo proxy de la región publicitaria también es necesaria para que funcionen las comprobaciones de estado de Envoy distribuidas. La comprobación de estado de Envoy distribuida es el mecanismo de comprobación de estado predeterminado para los NEG híbridos zonales (es decir, los endpoints NON_GCP_PRIVATE_IP_PORT) que se encuentran detrás de los balanceadores de carga basados en Envoy.

    Puedes usar la misma red o una red de VPC diferente dentro del mismo proyecto para configurar tanto la red híbrida (Cloud Interconnect o Cloud VPN) como el balanceador de carga. Ten en cuenta lo siguiente:

    • Si usas redes de VPC diferentes, las dos redes deben estar conectadas mediante el emparejamiento entre redes de VPC o deben ser radios de VPC en el mismo hub de Network Connectivity Center.

    • Si usas la misma red de VPC, asegúrate de que los intervalos CIDR de las subredes de tu red de VPC no entren en conflicto con los intervalos CIDR remotos. Cuando las direcciones IP se superponen, se priorizan las rutas de subred sobre la conectividad remota.

  • Puntos finales de red (IP:Port) on-premise o en otras nubes. Uno o varios IP:Port endpoints de red configurados en tus entornos locales o en otros entornos de nube, a los que se puede acceder mediante Cloud Interconnect, Cloud VPN o una VM de dispositivo de router. Si hay varias rutas al endpoint IP, el enrutamiento seguirá el comportamiento descrito en la descripción general de las rutas de VPC y en la descripción general de Cloud Router.

  • Reglas de cortafuegos en tu entorno local u otra nube. Debes crear las siguientes reglas de firewall en tu entorno on-premise o en otra nube:

    • Reglas de cortafuegos de entrada para permitir el tráfico de las sondas de comprobación del estado de Google a tus endpoints. Los intervalos que se van a permitir son: 35.191.0.0/16 y 130.211.0.0/22. Ten en cuenta que Cloud Router también debe anunciar estos intervalos a tu red on-premise. Para obtener más información, consulta Intervalos de IPs de sondeo y reglas de firewall.
    • Reglas de cortafuegos de entrada para permitir que el tráfico que se está balanceando de carga llegue a los endpoints.
    • En el caso de los balanceadores de carga basados en Envoy (balanceadores de carga de aplicaciones externos regionales, balanceadores de carga de aplicaciones internos regionales, balanceadores de carga de aplicaciones internos entre regiones,balanceadores de carga de red con proxy externos regionales, balanceadores de carga de red con proxy internos entre regiones y balanceadores de carga de red con proxy internos regionales), también debes crear una regla de firewall para permitir que el tráfico de la subred de solo proxy de la región llegue a los endpoints que están en las instalaciones o en otros entornos de nube.

Componentes del balanceador de carga

En función del tipo de balanceador de carga, puedes configurar una implementación de balanceo de carga híbrido con los niveles de servicio de red Estándar o Premium.

Un balanceador de carga híbrido requiere una configuración especial solo para el servicio de backend. La configuración del frontend es la misma que la de cualquier otro balanceador de carga. Los balanceadores de carga basados en Envoy (balanceadores de carga de aplicación externos regionales, balanceadores de carga de aplicación internos regionales, balanceadores de carga de aplicación internos entre regiones,balanceadores de carga de red de proxy externos regionales, balanceadores de carga de red de proxy internos entre regiones y balanceadores de carga de red de proxy internos regionales) requieren una subred solo de proxy adicional para ejecutar proxies de Envoy en tu nombre.

Configuración de frontend

No es necesario configurar ningún frontend especial para el balanceo de carga híbrido. Las reglas de reenvío se usan para dirigir el tráfico a un proxy de destino según la dirección IP, el puerto y el protocolo. A continuación, el proxy de destino finaliza las conexiones de los clientes.

Los mapas de URLs se usan en los balanceadores de carga HTTP(S) para configurar el enrutamiento de solicitudes basado en URLs a los servicios de backend adecuados.

Para obtener más información sobre cada uno de estos componentes, consulta las secciones de arquitectura de los resúmenes de los balanceadores de carga específicos:

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de carga. Los balanceadores de carga usan la información de un servicio de backend para dirigir el tráfico entrante a uno o varios backends conectados.

Para configurar una implementación de balanceo de carga híbrido, configure el balanceador de carga con backends que estén tanto dentro de Google Cloudcomo fuera de Google Cloud.

  • Back-ends que no son deGoogle Cloud (on-premise u otra nube)

    Cualquier destino al que puedas acceder mediante los productos de conectividad híbrida de Google (Cloud VPN, Cloud Interconnect o VMs de dispositivo de router) y al que se pueda acceder con una combinación válida de IP:Port se puede configurar como endpoint del balanceador de carga.

    Configura tus back-ends que no sean deGoogle Cloud de la siguiente manera:

    1. Añade cada combinación deGoogle Cloud punto final de redIP:Port que no seaGoogle Cloud a un grupo de puntos finales de red (NEG) de conectividad híbrida. Asegúrate de que se pueda acceder a esta dirección IP y a este puerto desde Google Cloud mediante la conectividad híbrida (ya sea con Cloud VPN, Cloud Interconnect o VMs de dispositivo router). En los NEG de conectividad híbrida, el tipo de punto final de red se define como NON_GCP_PRIVATE_IP_PORT.
    2. Al crear el NEG, especifica una Google Cloud zona que minimice la distancia geográfica entre Google Cloud y tu entorno on-premise u otro entorno de nube. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort (Alemania), puedes especificar la zona europe-west3-a Google Cloud al crear el NEG.

    3. Añade este NEG de conectividad híbrida como backend del servicio de backend.

      Un NEG de conectividad híbrida solo debe incluir endpoints que no seanGoogle Cloud. Es posible que se descarte el tráfico si un NEG híbrido incluye endpoints de recursos de una red de VPC, como direcciones IP de reglas de reenvío de balanceadores de carga de red internos con paso a través. Google Cloud Configura los Google Cloud endpoints como se indica en la sección siguiente.

  • Google Cloud backends

    Configura tus Google Cloud endpoints de la siguiente manera:

    1. Crea un servicio de backend independiente para los Google Cloud backends.
    2. Configura varios backends (ya sean GCE_VM_IP_PORTNEG zonales o grupos de instancias) en la misma región en la que hayas configurado la conectividad híbrida.

Otros aspectos que se deben tener en cuenta:

  • Cada NEG de conectividad híbrida solo puede contener puntos finales de red del mismo tipo (NON_GCP_PRIVATE_IP_PORT).

  • Puedes usar un único servicio de backend para hacer referencia a backends basados enGoogle Cloud(con NEGs zonales con GCE_VM_IP_PORT endpoints) y a backends on-premise o de otra nube (con NEGs de conectividad híbrida con NON_GCP_PRIVATE_IP_PORT endpoints). No se permite ninguna otra combinación de tipos de backend mixtos. Cloud Service Mesh no admite tipos de backend mixtos en un mismo servicio de backend.

  • El esquema de balanceo de carga del servicio de backend debe ser uno de los siguientes:

    • EXTERNAL_MANAGED para balanceadores de carga de aplicación externos globales, balanceadores de carga de aplicación externos regionales, balanceadores de carga de red con proxy externo globales y balanceadores de carga de red con proxy externo regionales

    • EXTERNAL para balanceadores de carga de aplicación clásicos y balanceadores de carga de red de proxy clásicos

    • INTERNAL_MANAGED para balanceadores de carga de aplicaciones internos y balanceadores de carga de red de proxy internos

    INTERNAL_SELF_MANAGED se admite en despliegues de Cloud Service Mesh en varios entornos con NEGs de conectividad híbrida.

  • El protocolo del servicio de backend debe ser HTTP, HTTPS o HTTP2 para los balanceadores de carga de aplicaciones, y TCP o SSL para los balanceadores de carga de red de proxy. Para ver la lista de protocolos de servicio de backend admitidos por cada balanceador de carga, consulta Protocolos del balanceador de carga al backend.

  • El modo de balanceo del backend del NEG híbrido debe ser RATE para los balanceadores de carga de aplicaciones y CONNECTION para los balanceadores de carga de red de proxy. Para obtener información sobre los modos de balanceo, consulta el artículo Descripción general de los servicios backend.

  • Para añadir más endpoints de red, actualice los backends asociados a su servicio de backend.

  • Si usas comprobaciones de estado de Envoy distribuidas con backends de NEGs de conectividad híbrida (solo se admite en balanceadores de carga basados en Envoy), asegúrate de configurar endpoints de red únicos para todos los NEGs asociados al mismo servicio de backend. Si añade el mismo endpoint de red a varios NEGs, el comportamiento será indefinido.

Comprobaciones del estado centralizadas

Las comprobaciones de estado centralizadas, cuando se usan NEGs híbridos, son obligatorias para los balanceadores de carga de aplicación externos globales, los balanceadores de carga de aplicación clásicos, los balanceadores de carga de red con proxy externos globales y los balanceadores de carga de red con proxy clásicos. Otros balanceadores de carga basados en Envoy usan comprobaciones de estado de Envoy distribuidas, tal como se describe en la sección siguiente.

Para los endpoints NON_GCP_PRIVATE_IP_PORT externos a Google Cloud, crea reglas de cortafuegos en tus redes on-premise y en otras redes de nube. Ponte en contacto con el administrador de tu red para obtener ayuda. El Cloud Router que se utilice para la conectividad híbrida también debe anunciar los intervalos que usan las sondas de comprobación de estado de Google. Los intervalos que se van a anunciar son 35.191.0.0/16 y 130.211.0.0/22.

Para otros tipos de back-ends en Google Cloud, cree reglas de cortafuegos enGoogle Cloud como se muestra en este ejemplo.

Documentación relacionada:

Comprobaciones del estado de Envoy distribuidas

La configuración de la comprobación de estado varía en función del tipo de balanceador de carga:

  • Balanceador de carga de aplicación externo global, balanceador de carga de aplicación clásico, balanceador de carga de red con proxy externo global y balanceador de carga de red con proxy clásico. Estos balanceadores de carga no admiten comprobaciones del estado de Envoy distribuidas. Utilizan el mecanismo de comprobación de estado centralizado de Google, tal como se describe en la sección Comprobaciones de estado centralizadas.

  • Balanceador de carga de aplicaciones externo regional, balanceador de carga de aplicaciones interno regional, balanceador de carga de red con proxy externo regional, balanceador de carga de red con proxy interno regional , balanceador de carga de red con proxy interno entre regiones y balanceador de carga de aplicaciones interno entre regiones. Estos balanceadores de carga usan comprobaciones del estado de Envoy distribuidas para comprobar el estado de los NEG híbridos. Las comprobaciones del estado se originan en el propio software del proxy Envoy. Cada servicio backend debe estar asociado a una comprobación del estado que compruebe el estado de los backends. Las sondas de comprobación del estado proceden de los proxies de Envoy de la subred de solo proxy de la región. Para que las sondas de comprobación de estado funcionen correctamente, debes crear reglas de cortafuegos en el entorno externo que permitan que el tráfico de la subred de solo proxy llegue a tus backends externos.

    Para los endpoints de NON_GCP_PRIVATE_IP_PORT fuera de Google Cloud, debes crear estas reglas de cortafuegos en tus redes locales y en otras redes en la nube. Ponte en contacto con el administrador de tu red para obtenerlo. El Cloud Router que uses para la conectividad híbrida también debe anunciar el intervalo de la subred de solo proxy de la región.

Las comprobaciones de estado distribuidas de Envoy se crean mediante los mismos procesos de consola, CLI de gcloud y API que las comprobaciones de estado centralizadas.Google Cloud No es necesario realizar ninguna otra configuración.

Aspectos que debe tener en cuenta:

  • No se admiten las comprobaciones de estado de gRPC.
  • No se admiten las comprobaciones de estado con el protocolo PROXY v1 habilitado.
  • Si usas NEGs mixtos en los que un único servicio de backend tiene una combinación de NEGs de zona (GCE_VM_IP_PORT endpoints dentro deGoogle Cloud) y NEGs híbridos (NON_GCP_PRIVATE_IP_PORT endpoints fuera de Google Cloud), debes configurar reglas de cortafuegos para permitir el tráfico de los intervalos de IPs de sondeo de comprobación de estado de Google (130.211.0.0/22 y 35.191.0.0/16) a los endpoints de los NEGs de zona enGoogle Cloud. Esto se debe a que los NEGs zonales usan el sistema de comprobación de estado centralizado de Google.

  • Como el plano de datos de Envoy gestiona las comprobaciones de estado, no puedes usar la consola, la API ni la interfaz de línea de comandos de gcloud para comprobar el estado de estos endpoints externos.Google Cloud En el caso de los NEGs híbridos con balanceadores de carga basados en Envoy, la consola muestra el estado de la comprobación de estado como Google Cloud N/A. Este es el comportamiento esperado.

  • Cada proxy de Envoy asignado a la subred solo de proxy de la región de la red VPC inicia comprobaciones de estado de forma independiente. Por lo tanto, es posible que observes un aumento del tráfico de red debido a las comprobaciones de estado. El aumento depende del número de proxies de Envoy asignados a tu red de VPC en una región, la cantidad de tráfico que reciben estos proxies y el número de endpoints que cada proxy de Envoy debe comprobar. En el peor de los casos, el tráfico de red debido a las comprobaciones de estado aumenta a un ritmo cuadrático (O(n^2)).

  • Los registros de comprobación del estado de las comprobaciones del estado de Envoy distribuidas no incluyen estados de salud detallados. Para obtener más información sobre lo que se registra, consulta Registro de comprobaciones del estado. Para solucionar problemas de conectividad de los proxies de Envoy a los endpoints de tu NEG, también debes consultar los registros del balanceador de carga correspondiente.

Documentación relacionada:

Limitaciones

  • El Cloud Router que se utilice para la conectividad híbrida debe tener habilitado el enrutamiento dinámico global. No se admiten las rutas dinámicas regionales ni las rutas estáticas.
  • En el caso de los balanceadores de carga regionales basados en Envoy (balanceadores de carga de aplicaciones externos regionales, balanceadores de carga de red de proxy externos regionales, balanceadores de carga de red de proxy internos regionales y balanceadores de carga de aplicaciones internos regionales), la conectividad híbrida debe configurarse en la misma región que el balanceador de carga. Si están configurados en regiones diferentes, es posible que los back-ends aparezcan como correctos, pero las solicitudes de los clientes no se reenviarán a los back-ends.

  • Las consideraciones sobre las conexiones cifradas del balanceador de carga a los backends documentadas aquí también se aplican a los endpoints de backend que no sonGoogle Cloud configurados en el NEG de conectividad híbrida.

    Asegúrate de revisar también la configuración de seguridad de tu configuración de conectividad híbrida. Las conexiones de VPN de alta disponibilidad se cifran de forma predeterminada (IPsec). Las conexiones de Cloud Interconnect no están encriptadas de forma predeterminada. Para obtener más información, consulta el informe Encriptado en tránsito.

Almacenamiento de registros

Las solicitudes proxy a un endpoint de un NEG híbrido se registran en Cloud Logging de la misma forma que las solicitudes de otros backends. Si habilitas Cloud CDN en tu balanceador de carga de aplicación externo global, también se registrarán los aciertos de caché.

Para obtener más información, consulta estos artículos:

Cuota

Puede configurar tantos NEGs híbridos con puntos finales de red como le permita su cuota de grupos de puntos finales de red. Para obtener más información, consulta backends de NEG y Endpoints por NEG.

Siguientes pasos