Herramientas de redes de servicio para aplicaciones distribuidas en Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Este documento forma parte de una serie de guías de diseño para Cross-Cloud Network.

La serie consta de las siguientes partes:

En este documento, se describe cómo ensamblar una aplicación a partir de un conjunto de servicios de componentes creados o elegidos. Te recomendamos que leas todo el documento una vez antes de seguir los pasos.

En este documento, se te guiará a través de las siguientes decisiones:

  • Si creas el servicio individual por tu cuenta o consumes un servicio de terceros
  • Indica si el servicio está disponible a nivel global o regional.
  • Si el servicio se consume desde un entorno local, desde otras nubes o desde ninguno de los dos
  • Si accedes al extremo de servicio a través de una VPC de servicios compartidos o distribuyes los extremos a través de todas las VPCs de aplicaciones pertinentes

En este documento, se te guiará por los siguientes pasos:

  1. Cómo decidir si tu aplicación es global o regional
  2. Elegir servicios administrados de terceros o crear y publicar tus propios servicios
  3. Configurar el acceso privado a los extremos de servicio con un modo compartido o dedicado
  4. Ensamblar los servicios en aplicaciones para que coincidan con un arquetipo global o regional

Los desarrolladores definen la capa de redes de servicios para Cross-Cloud Network. En esta etapa, los administradores diseñaron una capa de conectividad para Cross-Cloud Network que permite flexibilidad en las opciones de Service Networking que se describen en este documento. En algunos casos, existen restricciones debido a la transitividad limitada entre VPCs. Describimos estas restricciones cuando pueden afectar las decisiones de diseño.

Decide si tu aplicación es regional o global

Determina si los clientes de la aplicación que estás creando necesitan un arquetipo de implementación regional o global. Puedes lograr resiliencia regional distribuyendo las cargas en las zonas de una región. Puedes lograr la resiliencia global distribuyendo las cargas en las regiones.

Ten en cuenta los siguientes factores cuando elijas un arquetipo:

  • Los requisitos de disponibilidad de la aplicación
  • Ubicación en la que se consume la aplicación
  • Costo

Para obtener más información, consulta arquetipos de implementación deGoogle Cloud .

En esta guía de diseño, se explica cómo admitir los siguientes arquetipos de implementación:

En una aplicación distribuida en varias nubes, los diferentes servicios de esa aplicación se pueden entregar desde diferentes proveedores de servicios en la nube (CSP) o centros de datos privados. Para garantizar una estructura de resiliencia coherente, coloca los servicios alojados en diferentes CSP en centros de datos de CSP que estén geográficamente cerca unos de otros.

En el siguiente diagrama, se muestra una pila de aplicaciones global que se distribuye en diferentes nubes y en la que se implementan diferentes servicios de aplicaciones en diferentes CSP. Cada servicio de aplicación global tiene instancias de carga de trabajo en diferentes regiones del mismo CSP.

Pila de aplicaciones global distribuida en varias nubes.

Cómo definir servicios de aplicaciones y acceder a ellos

Para ensamblar tu aplicación, puedes usar servicios administrados de terceros existentes, crear y alojar tus propios servicios de aplicaciones, o bien usar una combinación de ambos.

Usar servicios administrados externos existentes

Decide qué servicios administrados de terceros puedes usar para tu aplicación. Determina cuáles se construyen como servicios regionales o globales. Además, determina qué opciones de acceso privado admite cada servicio.

Cuando sepas qué servicios administrados puedes usar, podrás determinar qué servicios necesitas crear.

Crea servicios de aplicaciones y accede a ellos

Cada servicio está alojado en una o más instancias de cargas de trabajo a las que se puede acceder como un solo extremo o como un grupo de extremos.

El patrón general para un servicio de aplicación se muestra en el siguiente diagrama. El servicio de aplicación se implementa en una colección de instancias de carga de trabajo. (En este caso, una instancia de carga de trabajo podría ser una VM de Compute Engine, un clúster de Google Kubernetes Engine [GKE] o algún otro backend que ejecute código). Las instancias de la carga de trabajo se organizan como un conjunto de backends asociados a un balanceador de cargas.

En el siguiente diagrama, se muestra un balanceador de cargas genérico con un conjunto de backends.

Es un balanceador de cargas con backends.

Para lograr la distribución de carga elegida y automatizar las conmutaciones por error, estos grupos de extremos usan un balanceador de cargas de frontend. Con los grupos de instancias administrados (MIG), puedes aumentar o disminuir de forma elástica la capacidad del servicio ajustando automáticamente la escala de los extremos que forman el backend del balanceador de cargas. Además, según los requisitos del servicio de la aplicación, el balanceador de cargas también puede proporcionar autenticación, finalización de TLS y otros servicios específicos de la conexión.

Determina el alcance del servicio: regional o global

Decide si tu servicio necesita y puede admitir resiliencia regional o global. Un servicio de software regional se puede diseñar para la sincronización dentro de un presupuesto de latencia regional. Un servicio de aplicación global puede admitir conmutaciones por error síncronas en nodos distribuidos en diferentes regiones. Si tu aplicación es global, es posible que desees que los servicios que la admiten también lo sean. Sin embargo, si tu servicio requiere sincronización entre sus instancias para admitir la conmutación por error, debes tener en cuenta la latencia entre las regiones. En tu caso, es posible que debas depender de servicios regionales con redundancia en regiones cercanas o en la misma región, lo que admite la sincronización de baja latencia para la conmutación por error.

Cloud Load Balancing admite extremos alojados en una sola región o distribuidos en varias regiones. Por lo tanto, puedes crear una capa global orientada al cliente que se comunique con capas de servicio globales, regionales o híbridas. Elige tus implementaciones de servicios para asegurarte de que la conmutación por error dinámica de la red (o el balanceo de cargas en las regiones) se alinee con el estado de resiliencia y las capacidades de la lógica de tu aplicación.

En el siguiente diagrama, se muestra cómo un servicio global creado a partir de balanceadores de cargas regionales puede llegar a los backends en otras regiones y, de este modo, proporcionar una conmutación por error automática entre regiones. En este ejemplo, la lógica de la aplicación es global y el backend elegido admite la sincronización en todas las regiones. Cada balanceador de cargas envía principalmente solicitudes a la región local, pero puede conmutar por error a regiones remotas.

Balanceadores de cargas con backends en diferentes regiones

  • Un backend global es una colección de backends regionales a los que acceden uno o más balanceadores de cargas.
  • Aunque los backends son globales, el frontend de cada balanceador de cargas es regional.
  • En este patrón de arquitectura, los balanceadores de cargas distribuyen el tráfico principalmente solo dentro de su región, pero también pueden balancear el tráfico a otras regiones cuando los recursos de la región local no están disponibles.
  • Un conjunto de frontends de balanceador de cargas regionales, cada uno accesible desde otras regiones y cada uno capaz de llegar a los backends en otras regiones, forman un servicio global agregado.
  • Para ensamblar una pila de aplicaciones global, como se explica en Diseña pilas de aplicaciones globales, puedes usar el enrutamiento de DNS y las verificaciones de estado para lograr la conmutación por error interregional de los frontends.
  • Se puede acceder a los frontends del balanceador de cargas desde otras regiones con el acceso global (no se muestra en el diagrama).

Este mismo patrón se puede usar para incluir servicios publicados con conmutación por error global. En el siguiente diagrama, se muestra un servicio publicado que usa backends globales.

Balanceadores de cargas accesibles desde diferentes regiones

En el diagrama, ten en cuenta que el servicio publicado tiene una conmutación por error global implementada en el entorno del productor. La incorporación de la conmutación por error global en el entorno del consumidor permite la resiliencia ante fallas regionales en la infraestructura de balanceo de cargas del consumidor. La conmutación por error entre regiones del servicio debe implementarse tanto en la lógica de la aplicación del servicio como en el diseño del balanceo de cargas del productor de servicios. Los productores de servicios pueden implementar otros mecanismos.

Para determinar qué producto de Cloud Load Balancing usar, primero debes determinar qué tipo de tráfico deben manejar tus balanceadores de cargas. Ten en cuenta las siguientes reglas generales:

  • Usa un balanceador de cargas de aplicaciones para el tráfico HTTP(S).
  • Usa un balanceador de cargas de red de proxy para el tráfico TCP que no sea HTTP(S). Este balanceador de cargas de proxy también admite la descarga de TLS.
  • Usa un balanceador de cargas de red de transferencia para conservar la dirección IP de origen del cliente en el encabezado o para admitir protocolos adicionales, como UDP, ICMP y ESP.

Para obtener orientación detallada sobre cómo seleccionar el mejor balanceador de cargas para tu caso de uso, consulta Elige un balanceador de cargas.

Servicios con backends sin servidores

Se puede definir un servicio con backends sin servidores. El backend en el entorno del productor se puede organizar en un NEG sin servidores como backend para un balanceador de cargas. Este servicio se puede publicar con Private Service Connect creando un adjunto de servicio asociado al frontend del balanceador de cargas del productor. El servicio publicado se puede consumir a través de extremos o backends de Private Service Connect. Si el servicio requiere conexiones iniciadas por el productor, puedes usar un conector de Acceso a VPC sin servidores para permitir que los entornos de Cloud Run, App Engine estándar y Cloud Run Functions envíen paquetes a las direcciones IPv4 internas de los recursos en una red de VPC. El acceso a VPC sin servidores también admite el envío de paquetes a otras redes conectadas a la red de VPC seleccionada.

Métodos para acceder a los servicios de forma privada

Tu aplicación puede constar de servicios administrados proporcionados por Google, servicios de terceros proporcionados por proveedores externos o grupos de pares en tu organización, y servicios que desarrolla tu equipo. Se puede acceder a algunos de esos servicios a través de Internet con direcciones IP públicas. En esta sección, se describen los métodos que puedes usar para acceder a esos servicios a través de la red privada. Existen los siguientes tipos de servicio:

  • APIs públicas de Google
  • APIs sin servidores de Google
  • Servicios administrados publicados por Google
  • Servicios administrados publicados por proveedores y empresas similares
  • Tus servicios publicados

Ten en cuenta estas opciones cuando leas las secciones posteriores. Según cómo asignes tus servicios, puedes usar una o más de las opciones de acceso privado que se describen.

La organización (o el grupo dentro de una organización) que ensambla, publica y administra un servicio se conoce como productor de servicios. Tú y tu aplicación se conocen como el consumidor del servicio.

Algunos servicios administrados se publican exclusivamente con el acceso a servicios privados. Los diseños de red recomendados en Conectividad interna y redes de VPC admiten servicios publicados con acceso privado a servicios y Private Service Connect.

Para obtener una descripción general de las opciones para acceder a los servicios de forma privada, consulta Opciones de acceso privado a los servicios.

Te recomendamos que uses Private Service Connect para conectarte a los servicios administrados siempre que sea posible. Para obtener más información sobre los patrones de implementación de Private Service Connect, consulta Patrones de implementación de Private Service Connect.

Existen dos tipos de Private Service Connect, y los diferentes servicios se pueden publicar como cualquiera de los dos tipos:

Otros servicios pueden consumir directamente los servicios publicados como extremos de Private Service Connect. Los servicios dependen de la autenticación y la capacidad de recuperación que proporciona el productor del servicio. Si deseas tener un control adicional sobre la autenticación y la resiliencia del servicio, puedes usar backends de Private Service Connect para agregar una capa de balanceo de cargas para la autenticación y la resiliencia en la red del consumidor.

En el siguiente diagrama, se muestra el acceso a los servicios a través de los extremos de Private Service Connect:

Acceder a los servicios a través de extremos de Private Service Connect

En el diagrama, se muestra el siguiente patrón:

  • Se implementa un extremo de Private Service Connect en la VPC del consumidor, lo que hace que el servicio del productor esté disponible para las VMs y los nodos de GKE.
  • Tanto la red del consumidor como la del productor deben implementarse en la misma región.

En el diagrama anterior, se muestran los extremos como recursos regionales. Se puede acceder a los extremos desde otras regiones debido al acceso global.

Para obtener más información sobre los patrones de implementación, consulta Patrones de implementación de Private Service Connect.

Los backends de Private Service Connect usan un balanceador de cargas configurado con backends de grupos de extremos de red (NEG) de Private Service Connect Para obtener una lista de los balanceadores de cargas compatibles, consulta Acerca de los backends de Private Service Connect.

Los backends de Private Service Connect te permiten crear las siguientes configuraciones de backend:

  • Dominios y certificados de cliente frente a servicios administrados
  • Conmutación por error controlada por el consumidor entre servicios administrados en diferentes regiones
  • Configuración de seguridad centralizada y control de acceso para servicios administrados

En el siguiente diagrama, el balanceador de cargas global usa un NEG de Private Service Connect como un backend que establece la comunicación con el proveedor de servicios. No se requiere ninguna otra configuración de redes, y los datos se transfieren a través de la estructura de SDN de Google.

Balanceador de cargas global que usa un grupo de extremos de red.

La mayoría de los servicios están diseñados para las conexiones que inicia el consumidor. Cuando los servicios necesiten iniciar conexiones desde el productor, usa interfaces de Private Service Connect.

Un factor clave a la hora de implementar el acceso privado a servicios o Private Service Connect es la transitividad. Se puede acceder a los puntos de acceso del consumidor de Private Service Connect a través de Network Connectivity Center. No se puede acceder a los servicios publicados a través de una conexión de intercambio de tráfico entre redes de VPC para los puntos de acceso del consumidor de Private Service Connect o de acceso privado a servicios. En ausencia de transitividad entre VPCs para todos los puntos de acceso del consumidor de servicios, la ubicación de la subred o los extremos de acceso al servicio en la topología de VPC determina si diseñas la red para la implementación de servicios compartidos o dedicados.

Las opciones como la VPN con alta disponibilidad y los proxies administrados por el cliente proporcionan métodos para permitir la comunicación transitiva entre VPC.

No se puede acceder a los extremos de Private Service Connect a través del intercambio de tráfico entre redes de VPC. Si necesitas este tipo de conectividad, implementa un balanceador de cargas interno y un NEG de Private Service Connect como backend, como se muestra en el siguiente diagrama:

Usar NEG para proporcionar accesibilidad

Se puede acceder a las APIs de Google de forma privada con extremos y backends de Private Service Connect. En general, se recomienda el uso de extremos, ya que el productor de la API de Google proporciona autenticación basada en certificados y capacidad de recuperación.

Crea un extremo de Private Service Connect en cada VPC en la que se necesite acceder al servicio. Dado que la dirección IP del consumidor es una dirección IP privada global, se requiere una sola asignación de DNS para cada servicio, incluso si hay instancias de extremos en varias VPC, como se muestra en el siguiente diagrama:

Private Service Connect con las APIs de Google

Define patrones de consumo para los servicios publicados

Los servicios publicados pueden ejecutarse en una variedad de ubicaciones: tu red de VPC, otra red de VPC, un centro de datos local o en la nube. Independientemente de dónde se ejecute la carga de trabajo del servicio, tu aplicación consume esos servicios a través de un punto de acceso, como uno de los siguientes:

  • Una dirección IP en una subred de acceso a servicios privados
  • Un extremo de Private Service Connect
  • VIP para un balanceador de cargas que usa NEG de Private Service Connect

Los puntos de acceso para el consumidor se pueden compartir entre redes o dedicarse a una sola red. Decide si crearás puntos de acceso compartidos o dedicados para los consumidores según si tu organización delega la tarea de crear puntos de acceso a los servicios para los consumidores a cada grupo de aplicaciones o si administra el acceso a los servicios de manera consolidada.

La administración del acceso a los servicios implica las siguientes actividades:

  • Cómo crear los puntos de acceso
  • Implementar los puntos de acceso en una VPC de acceso a servicios, que es una VPC que tiene el tipo de accesibilidad adecuado
  • Registra las direcciones IP y URLs de los puntos de acceso del consumidor en el DNS
  • Administrar los certificados de seguridad y la capacidad de recuperación del servicio en el espacio del consumidor cuando se agrega el balanceo de cargas frente a los puntos de acceso del consumidor

Para algunas organizaciones, puede ser viable asignar la administración del acceso a los servicios a un equipo central, mientras que otras pueden estar estructuradas para brindar más independencia a cada equipo de aplicación o consumidor. Un subproducto de operar en el modo dedicado es que algunos de los elementos se replican. Por ejemplo, cada grupo de aplicaciones registra un servicio con varios nombres de DNS y administra varios conjuntos de certificados TLS.

El diseño de VPC que se describe en Segmentación y conectividad de red para aplicaciones distribuidas en Cross-Cloud Network permite la accesibilidad para implementar puntos de acceso al servicio en modo compartido o dedicado. Los puntos de acceso de consumidor compartidos se implementan en las VPC de acceso al servicio, a las que se puede acceder desde cualquier otra VPC o red externa. Los puntos de acceso exclusivos para el consumidor se implementan en las VPC de la aplicación, a las que solo se puede acceder desde los recursos dentro de esa VPC de la aplicación.

La principal diferencia entre una VPC de acceso a servicios y una VPC de aplicaciones es la conectividad transitiva del punto de acceso a servicios que habilita una VPC de acceso a servicios. Las VPC de acceso al servicio no se limitan a alojar puntos de acceso del consumidor. Una VPC puede alojar recursos de aplicaciones y puntos de acceso compartidos para los consumidores. En ese caso, la VPC debe configurarse y controlarse como una VPC de servicio.

Acceso compartido a los servicios administrados

Para todos los métodos de consumo de servicios, incluido Private Service Connect, asegúrate de realizar las siguientes tareas:

  • Implementa los puntos de acceso del consumidor de servicios en una VPC de servicios. Las VPC de servicio tienen accesibilidad transitiva a otras VPC.
  • Si la VPC de acceso al servicio está conectada con una VPN con alta disponibilidad, anuncia la subred del punto de acceso del consumidor como un anuncio de ruta personalizada desde el Cloud Router que se interconecta con otras redes a través de la VPN con alta disponibilidad. En el caso de las APIs de Google, anuncia la dirección IP del host de la API.
  • Actualiza las reglas de firewall de múltiples nubes para permitir la subred de acceso privado a servicios.

En el caso del acceso privado al servicio, asegúrate de cumplir con los siguientes requisitos adicionales:

  • Exporta rutas personalizadas a la red del productor de servicios. Para obtener más información, consulta Los hosts locales no pueden comunicarse con la red del productor de servicios
  • Crea reglas de firewall de entrada para permitir que la subred de acceso privado a servicios ingrese a las VPC de la aplicación
  • Crea reglas de firewall de entrada para permitir que la subred de acceso a servicios privados ingrese a la VPC de servicios.

Para el acceso a servicios sin servidores, asegúrate de cumplir con los siguientes requisitos:

  • El conector de acceso requiere una subred regular /28 dedicada
  • De forma predeterminada, Cloud Router anuncia subredes normales
  • Crea reglas de firewall de entrada para permitir el acceso a todas las subredes de la VPC dentro de las VPC
  • Actualiza las reglas de firewall de múltiples nubes para permitir la subred del conector de acceso a la VPC
  • Crea reglas de firewall de entrada para permitir que la subred de acceso a servicios privados ingrese a las VPC de la aplicación.

Acceso dedicado a servicios administrados

Asegúrate de realizar las siguientes tareas:

  • En cada VPC de la aplicación en la que se necesite acceso, implementa una regla de reenvío para que el servicio cree un punto de acceso.
  • Para el acceso a servicios privados, crea reglas de firewall de entrada para permitir que la subred de acceso a servicios privados ingrese a las VPC de la aplicación.

Para el acceso a servicios sin servidores, asegúrate de cumplir con los siguientes requisitos:

  • El conector de acceso requiere una subred regular /28 dedicada
  • Crea reglas de firewall de entrada para permitir la subred del conector de Acceso a VPC dentro de las VPC de la aplicación.

Ensambla la pila de la aplicación

En esta sección, se describe cómo ensamblar una pila de aplicaciones regional o global.

Diseña pilas de aplicaciones regionales

Cuando una aplicación sigue los arquetipos de implementación regional o multirregional, usa pilas de aplicaciones regionales. Las pilas de aplicaciones regionales se pueden considerar como una concatenación de capas de servicios de aplicaciones regionales. Por ejemplo, una capa de servicio web regional que se comunica con una capa de aplicación en la misma región, que a su vez se comunica con una capa de base de datos en la misma región, es una pila de aplicaciones regional.

Cada capa de servicio de la aplicación regional usa balanceadores de cargas para distribuir el tráfico entre los extremos de la capa en esa región. La confiabilidad se logra distribuyendo los recursos de backend en tres o más zonas de la región.

Las capas de servicio de aplicaciones en otros CSP o centros de datos locales se deben implementar en regiones equivalentes en las redes externas. Además, haz que los servicios publicados estén disponibles en la región de la pila. Para alinear la pila de aplicaciones dentro de una región, las URLs de la capa de servicio de la aplicación deben resolverse en la dirección IP regional del frontend del balanceador de cargas específico. Estas asignaciones de DNS se registran en la zona de DNS pertinente para cada servicio de aplicación.

En el siguiente diagrama, se muestra una pila regional con capacidad de recuperación activa-en espera:

Es una pila regional con resiliencia activa/en espera.

En cada región, se implementa una instancia completa de la pila de aplicaciones en los diferentes centros de datos de la nube. Cuando se produce una falla regional en cualquiera de las capas de servicio de la aplicación, la pila de la otra región se encarga de la entrega de toda la aplicación. Esta conmutación por error se realiza en respuesta a la supervisión fuera de banda de las diferentes capas de servicio de la aplicación.

Cuando se informa una falla en una de las capas de servicio, el frontend de la aplicación se vuelve a anclar a la pila de copia de seguridad. La aplicación se escribe para hacer referencia a un conjunto de registros de nombres regionales que reflejan la pila de direcciones IP regionales en el DNS, de modo que cada capa de la aplicación mantenga sus conexiones dentro de la misma región.

Diseña pilas de aplicaciones globales

Cuando una aplicación sigue el arquetipo de implementación de aplicaciones global, cada capa de servicio de la aplicación incluye backends en varias regiones. Incluir backends en varias regiones expande el grupo de resiliencia para la capa de servicio de la aplicación más allá de una sola región y habilita la detección y la reconvergencia automáticas de la conmutación por error.

En el siguiente diagrama, se muestra una pila de aplicaciones global:

Pila global que usa un proyecto de concentrador y un proyecto de aplicación.

En el diagrama anterior, se muestra una aplicación global ensamblada a partir de los siguientes componentes:

  • Servicios que se ejecutan en centros de datos locales con frontends de balanceador de cargas Se puede acceder a los puntos de acceso del balanceador de cargas a través de Cloud Interconnect desde la VPC de tránsito.
  • Una VPC de tránsito aloja conexiones híbridas entre el centro de datos externo y la VPC de la aplicación.
  • Una VPC de la aplicación que aloja la aplicación principal que se ejecuta en instancias de carga de trabajo. Estas instancias de carga de trabajo se encuentran detrás de los balanceadores de cargas. Se puede acceder a los balanceadores de cargas desde cualquier región de la red, y estos pueden acceder a los backends en cualquier región de la red.
  • Una VPC de servicios que aloja puntos de acceso para los servicios que se ejecutan en otras ubicaciones, como en VPCs de terceros. Se puede acceder a estos puntos de acceso a servicios a través de la conexión de VPN con alta disponibilidad entre la VPC de servicios y la VPC de tránsito.
  • Las VPCs de productores de servicios alojadas por otras organizaciones o la organización principal, y las aplicaciones que se ejecutan en otras ubicaciones. Los backends de Private Service Connect implementados como backends globales en los balanceadores de cargas regionales alojados en la VPC de los servicios hacen que los servicios pertinentes sean accesibles. Se puede acceder a los balanceadores de cargas regionales desde cualquier otra región.

Si deseas que se pueda acceder a la aplicación creada desde Internet, puedes agregar un balanceador de cargas de aplicaciones externo global que apunte a las cargas de trabajo de la aplicación en la VPC de la aplicación (no se muestra en el diagrama).

Para admitir una pila de aplicaciones global, usamos backends globales para cada capa de la aplicación. Esto permite la recuperación ante una falla de todos los extremos de backend en una región. Cada región tiene un frontend de balanceador de cargas regional para cada capa de servicio de la aplicación. Cuando se produce una conmutación por error regional, se puede acceder a los frontends del balanceador de cargas interno regional en todas las regiones, ya que usan acceso global. Dado que la pila de aplicaciones es global, se usan políticas de enrutamiento de ubicación geográfica de DNS para seleccionar el frontend regional más adecuado para una solicitud o un flujo en particular. En caso de una falla en el frontend, se pueden usar las verificaciones de estado de DNS para automatizar la conmutación por error de un frontend a otro.

Los servicios publicados con backends de Private Service Connect se benefician del acceso global de Private Service Connect. Esta función permite que se pueda acceder a un backend de Private Service Connect desde cualquier región y reduce las interrupciones por fallas en la capa de servicio de la aplicación. Esto significa que los backends de Private Service Connect se pueden aprovechar como backends globales, como se describe en Cómo determinar el alcance del servicio: regional o global.

Proporciona acceso privado a los servicios alojados en redes externas

Es posible que desees publicar un punto de acceso local para un servicio alojado en otra red. En estos casos, puedes usar un balanceador de cargas de proxy TCP regional interno con NEG híbridos. Puedes crear un productor de servicios alojado de forma local o en otros entornos de nube que estén disponibles para los consumidores de servicios (clientes) en tu red de VPC, como se muestra en el siguiente diagrama:

Punto de acceso local que usa NEG híbridos.

Si quieres que el servicio híbrido esté disponible en una red de VPC que no sea la que aloja el balanceador de cargas, puedes usar Private Service Connect para publicar el servicio. Si colocas un adjunto de servicio frente al balanceador de cargas del proxy TCP regional interno, puedes permitir que los clientes de otras redes de VPC accedan a los servicios híbridos que se ejecutan en entornos locales o en otros entornos de nube.

En un entorno de varias nubes, el uso de un NEG híbrido permite una comunicación segura entre aplicaciones.

Cuando una organización diferente publica un servicio de aplicación, usa un NEG híbrido para extender las abstracciones de acceso privado para ese servicio. En el siguiente diagrama, se ilustra esta situación:

NEG híbridas frente a servicios en otras redes

En el diagrama anterior, la capa de servicio de la aplicación se compone por completo en el CSP vecino, que se destaca en las partes del diagrama que no están en gris. Los balanceadores de cargas híbridos se usan junto con los adjuntos de servicio de Private Service Connect como mecanismo para publicar el servicio de aplicación externo para el consumo privado dentro deGoogle Cloud. Los balanceadores de cargas híbridos con NEG híbridos y adjuntos de servicio de Private Service Connect se encuentran en una VPC que forma parte de un proyecto del productor de servicios. Por lo general, este proyecto del productor de servicios puede ser una VPC diferente de la VPC de tránsito, ya que se encuentra dentro del alcance administrativo de la organización o el proyecto del productor y, por lo tanto, está separado de los servicios de tránsito comunes. La VPC del productor no necesita estar conectada a través del intercambio de tráfico entre redes de VPC o la VPN con alta disponibilidad con la VPC del consumidor (que es la VPC compartida de servicios en el diagrama).

Centraliza el acceso a los servicios

El acceso al servicio se puede centralizar en una red de VPC y se puede acceder a él desde otras redes de aplicaciones. En el siguiente diagrama, se muestra el patrón común que permite la centralización de los puntos de acceso:

Es la VPC de servicios dedicados.

En el siguiente diagrama, se muestra el acceso a todos los servicios desde una VPC de servicios dedicada:

VPC de servicios dedicados con balanceadores de cargas centralizados.

Cuando los servicios se presentan con balanceadores de cargas de aplicaciones, puedes consolidar menos balanceadores de cargas usando mapas de URL para dirigir el tráfico a diferentes backends de servicios en lugar de usar diferentes balanceadores de cargas para cada servicio. En principio, una pila de aplicaciones podría componerse por completo con un solo balanceador de cargas de aplicaciones, además de backends de servicio y asignaciones de URL adecuadas.

En esta implementación, debes usar NEG híbridas en todas las VPC para la mayoría de los tipos de backend. La excepción es un NEG o un backend de Private Service Connect, como se describe en Encadenamiento explícito de balanceadores de cargas de Google Cloud L7 con Private Service Connect.

El uso de NEG híbridas en varias VPCs implica renunciar a la reparación automática y al ajuste de escala automático para los backends. Los servicios publicados ya tienen un balanceador de cargas en el arrendatario del productor que proporciona ajuste de escala automático. Por lo tanto, solo te encontrarás con las limitaciones de los NEG híbridos si centralizas la función de balanceo de cargas para las capas de servicio que se componen de forma nativa en lugar de consumirse desde la publicación.

Cuando uses este patrón de redes de servicios, recuerda que los servicios se consumen a través de una capa adicional de balanceo de cargas.

Se puede acceder a los extremos de servicio de Private Service Connect en las VPCs de radio de Network Connectivity Center.

El modo centralizado agrega una capa de balanceo de cargas en el lado del consumidor del servicio. Cuando usas este modo, también debes administrar los certificados, la capacidad de recuperación y las asignaciones de DNS adicionales en el proyecto del consumidor.

Otras consideraciones

En esta sección, se incluyen consideraciones para productos y servicios comunes que no se abordan de forma explícita en este documento.

Consideraciones sobre el plano de control de GKE

El plano de control de GKE se implementa en un proyecto de usuario administrado por Google que está conectado a la VPC del cliente a través del intercambio de tráfico entre redes de VPC. Dado que el intercambio de tráfico entre redes de VPC no es transitivo, no es posible la comunicación directa con el plano de control a través de una topología de red con intercambio de tráfico entre redes de VPC de concentrador y radio.

Cuando se consideran las opciones de diseño de GKE, como el acceso centralizado o descentralizado, el acceso directo al plano de control desde fuentes de varias nubes es una consideración clave. Si GKE se implementa en una VPC centralizada, el acceso al plano de control está disponible en todas las nubes y dentro deGoogle Cloud. Sin embargo, si GKE se implementa en VPC descentralizadas, no es posible la comunicación directa con el plano de control. Si los requisitos de una organización exigen acceso al plano de control de GKE, además de adoptar el patrón de diseño descentralizado, los administradores de red pueden implementar un agente de Connect que actúe como proxy y, de este modo, superar la limitación de la interconexión no transitiva al plano de control de GKE.

Seguridad: Controles del servicio de VPC

En las cargas de trabajo que involucran datos sensibles, usa los Controles del servicio de VPC a fin de configurar perímetros de servicio en torno a los recursos de VPC y los servicios administrados por Google y controlar el movimiento de datos en el límite del perímetro. Mediante los Controles del servicio de VPC, puedes agrupar proyectos y la red local en un solo perímetro que impida el acceso a los datos a través de los servicios administrados por Google. Las reglas de entrada y salida de los Controles del servicio de VPC se pueden usar para permitir que los proyectos y servicios en diferentes perímetros de servicio se comuniquen (incluidas las redes de VPC que no están dentro del perímetro).

Si deseas conocer las arquitecturas de implementación recomendadas, un proceso de integración integral y las prácticas recomendadas operacionales, consulta las Prácticas recomendadas para los Controles del servicio de VPC para empresas y el Plano de bases de seguridad.

DNS para APIs y servicios

Los productores de servicios pueden publicar servicios mediante Private Service Connect. El productor de servicios puede configurar de forma opcional un nombre de dominio DNS para asociarlo con el servicio. Si se configura un nombre de dominio y un consumidor de servicios crea un extremo que se orienta a ese servicio, Private Service Connect y el Directorio de servicios crean de forma automática entradas de DNS para el servicio en una zona DNS privada en la red de VPC del consumidor de servicios.

¿Qué sigue?

Colaboradores

Autores:

  • Victor Moreno | Gerente de producto, Herramientas de redes de Cloud
  • Ghaleb Al-habian | Especialista en redes
  • Deepak Michael | Ingeniero de Atención al cliente especializado en herramientas de redes
  • Osvaldo Costa | Ingeniero de Atención al cliente especializado en herramientas de redes
  • Jonathan Almaleh | Consultor de soluciones técnicas de personal

Otros colaboradores: