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

Last reviewed 2024-05-31 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 elegidos o creados. 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
  • Si el servicio está disponible a nivel global o regional
  • Si el servicio se consume de forma local, desde otras nubes o desde ninguna
  • 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 VPC de aplicaciones relevantes

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

  1. Decide 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 regional o global

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 redes de servicios que se describen en este documento. En algunos casos, existen restricciones de transitividad limitada entre VPC. 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 la resiliencia regional distribuyendo las cargas entre las zonas de una región. Puedes lograr la resiliencia global si distribuyes las cargas entre las regiones.

Ten en cuenta los siguientes factores cuando elijas un arquetipo:

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

Para obtener más información, consulta los arquetipos de implementación de Google 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 pueden entregarse 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 cerca geográficamente.

En el siguiente diagrama, se muestra una pila de aplicaciones global que se distribuye en varias 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

Define y accede a los servicios de la aplicación

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

Usa servicios administrados de terceros 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 cuáles debes crear.

Crea servicios de aplicaciones y accede a ellos

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

El patrón general de un servicio de aplicación se muestra en el siguiente diagrama. El servicio de la 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 con un balanceador de cargas.

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

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 la resiliencia regional o global. Se puede diseñar un servicio de software regional para la sincronización dentro de un presupuesto de latencia regional. Un servicio de aplicación global puede admitir conmutaciones por error síncronas entre nodos distribuidos en 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 considerar la latencia entre las regiones. En tu caso, es posible que debas depender de servicios regionales con redundancia en la misma región o en regiones cercanas, 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 para los clientes que se comunique con capas de servicio globales, regionales o híbridas. Elige las implementaciones de tu servicio para asegurarte de que la conmutación por error de red dinámica (o el balanceo de cargas entre 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 compilado a partir de balanceadores de cargas regionales puede llegar a backends en otras regiones, lo que proporciona 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 entre regiones. Cada balanceador de cargas envía solicitudes principalmente a la región local, pero puede realizar la conmutación por error a regiones remotas.

Balanceadores de cargas con backends en diferentes regiones

  • Un backend global es un conjunto 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, a los que se puede acceder desde otras regiones y que pueden llegar a backends en otras regiones, forma 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 acceso global (no se muestra en el diagrama).

Se puede usar el mismo patrón 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 a los que se puede acceder desde diferentes regiones

En el diagrama, observa que el servicio publicado tiene implementado el resguardo global en el entorno del productor. La adición de la conmutación por error global en el entorno del consumidor permite la resiliencia a las fallas regionales en la infraestructura de balanceo de cargas del consumidor. La conmutación por error entre regiones del servicio se debe implementar 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, ESP y ICMP.

Si deseas obtener una guía detallada para 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 un backend para un balanceador de cargas. Para publicar este servicio con Private Service Connect, crea un adjunto de servicio asociado con el 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 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 servicios de forma privada

Tu aplicación puede constar de servicios administrados que proporciona Google, servicios de terceros que proporcionan proveedores externos o grupos de pares de tu organización, y servicios que desarrolla tu equipo. Es posible que se pueda 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 con la red privada. Existen los siguientes tipos de servicio:

  • APIs públicas de Google
  • APIs sin servidor de Google
  • Servicios administrados publicados de Google
  • Servicios administrados publicados de proveedores y pares
  • 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 el productor de servicios. A ti y a tu aplicación se los conoce como el consumidor del servicio.

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

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

Te recomendamos que uses Private Service Connect para conectarte a 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:

Otras cargas de trabajo pueden consumir directamente los servicios publicados como extremos de Private Service Connect. Los servicios dependen de la autenticación y la resiliencia aprovisionadas por el productor del servicio. Si deseas obtener 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 muestran los servicios a los que se accede a través de los extremos de Private Service Connect:

Acceso a 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 pone el servicio del productor a disposición de las VMs y los nodos de GKE.
  • Tanto las redes del consumidor como las 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 configuración de red adicional, y los datos se transportan a través de la infraestructura 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.

Una consideración clave cuando se implementa el acceso a servicios privados o Private Service Connect es la transitividad. Por lo general, no se puede acceder a los servicios publicados a través de una conexión de intercambio de tráfico entre redes de VPC ni a través de Network Connectivity Center. La ubicación de la subred de acceso al servicio o los extremos 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 entre VPC de forma transitiva.

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:

Usa NEG para proporcionar accesibilidad.

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

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 global privada, 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 los patrones de consumo de servicios

Los servicios se pueden ejecutar en una variedad de ubicaciones: tu red de VPC, otra red de VPC, en 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
  • Un VIP para un balanceador de cargas que usa NEG de Private Service Connect

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

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

  • Crea los puntos de acceso
  • Implementar los puntos de acceso en una VPC que tenga el tipo de accesibilidad adecuado
  • Registra las direcciones IP y las URLs de los puntos de acceso de los consumidores en el DNS
  • Administrar los certificados de seguridad y la resiliencia 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 de acceso a los servicios a un equipo central, mientras que otras pueden estructurarse para brindar más independencia a cada consumidor o equipo de aplicaciones. 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 habilita la accesibilidad para implementar puntos de acceso de servicio en modo compartido o dedicado. Los puntos de acceso compartidos para consumidores se implementan en VPC de servicio, a los que se puede acceder desde cualquier otra VPC o red externa. Los puntos de acceso para consumidores dedicados se implementan en VPC de aplicaciones, a los que solo se puede acceder desde recursos dentro de esa VPC de aplicación.

La principal diferencia entre una VPC de servicio y una de aplicación es la conectividad transitiva del punto de acceso de servicio que habilita una VPC de servicio. Las VPC de servicio no se limitan a alojar puntos de acceso para consumidores. Una VPC puede alojar recursos de aplicaciones, así como puntos de acceso de consumidores compartidos. En ese caso, la VPC se debe configurar y controlar 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 de los consumidores de servicios en una VPC de servicios. Las VPC de servicios tienen accesibilidad transitiva a otras VPC.
  • Anuncia la subred del punto de acceso para consumidores como un anuncio de ruta personalizado desde el Cloud Router que establece un vínculo de red con otras redes a través de la VPN con alta disponibilidad. Para 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 a servicios privados.

En particular, para el acceso a servicios privados, 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 a servicios privados acceda a las VPC de la aplicación.
  • Crea reglas de firewall de entrada para permitir que la subred de acceso a servicios privados acceda a la VPC de servicios

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

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

Acceso a servicios administrados dedicados

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 acceda a las VPC de la aplicación.

Para obtener acceso a los servicios sin servidor, 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 la VPC dentro de las VPC de la aplicación

Ensambla la pila de aplicaciones

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 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 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 deben implementarse 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 específica del frontend del balanceador de cargas. Estas asignaciones de DNS se registran en la zona de DNS relevante para cada servicio de la aplicación.

En el siguiente diagrama, se muestra una pila regional con resiliencia activa-en espera:

Pila regional con resiliencia activa-en espera

Se implementa una instancia completa de la pila de aplicaciones en cada región 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 hace cargo 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 para 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 está escrita para hacer referencia a un conjunto de registros de nombres regionales que reflejan la pila de direcciones IP regional 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 globales, cada capa de servicio de la aplicación incluye backends en varias regiones. Si incluyes backends en varias regiones, se expande el grupo de resiliencia de la capa de servicio de la aplicación más allá de una sola región y se habilita la detección y reconvergencia de conmutación por error automatizada.

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

Pila global con 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 aplicación que aloja la aplicación principal que se ejecuta en instancias de carga de trabajo. Estas instancias de cargas de trabajo están detrás de los balanceadores de cargas. Se puede acceder a los balanceadores de cargas desde cualquier región de la red, y pueden llegar a los backends en cualquier región de la red.
  • Una VPC de servicios que aloja puntos de acceso para servicios que se ejecutan en otras ubicaciones, como en VPC de terceros. Se puede acceder a estos puntos de acceso de servicio a través de la conexión de VPN con alta disponibilidad entre la VPC de servicios y la VPC de tránsito.
  • VPC de productores de servicios alojados por otras organizaciones o la organización principal, y aplicaciones que se ejecutan en otras ubicaciones Los backends de Private Service Connect, que se implementan como backends globales en los balanceadores de cargas regionales alojados en la VPC de los servicios, permiten que se acceda a los servicios relevantes. 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 de una falla de todos los extremos del 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 internos del balanceador de cargas regional en todas las regiones, ya que usan el acceso global. Debido a que la pila de aplicaciones es global, se usan políticas de enrutamiento de DNS de ubicación geográfica para seleccionar el frontend regional más adecuado para una solicitud o un flujo en particular. En caso de falla del frontend, se pueden usar las verificaciones de estado del 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 disminuye 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 Determina el alcance del servicio: regional o global.

Proporcionar acceso privado a 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 servicio alojado de forma local o en otros entornos de nube que estén disponibles para los clientes en tu red de VPC, como se muestra en el siguiente diagrama:

Punto de acceso local con NEG híbridos

Si quieres que el servicio híbrido esté disponible en una red de VPC distinta de 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, 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 multinube, el uso de un NEG híbrido permite una comunicación segura entre aplicaciones.

Cuando una organización diferente publique 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íbridos 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 archivos adjuntos de servicio de Private Service Connect como un 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. No es necesario que la VPC del productor esté 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).

Cómo centralizar el acceso a los servicios

El acceso a los servicios 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:

VPC de servicios dedicados

En el siguiente diagrama, se muestran todos los servicios a los que se accede 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 consolidarte en menos balanceadores de cargas con mapas de URL para dirigir el tráfico de diferentes backends de servicios en lugar de usar diferentes balanceadores de cargas para cada servicio. En principio, una pila de aplicaciones se podría componer por completo con un solo balanceador de cargas de aplicaciones, además de backends de servicios y asignaciones de URL adecuadas.

En esta implementación, debes usar NEG híbridos 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 Google Cloud balanceadores de cargas de L7 con Private Service Connect.

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

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

Usa el balanceo de cargas de proxy para obtener los beneficios de escalamiento de la conectividad de VPC de radio de Network Connectivity Center entre las VPC, a la vez que proporcionas conectividad transitiva a los servicios publicados a través de los balanceadores de cargas de proxy.

No se puede acceder a los extremos de servicio ni a las reglas de reenvío de Private Service Connect para el acceso a servicios privados en las VPC de los radios de Network Connectivity Center. Del mismo modo, las redes detrás de conexiones híbridas (Cloud Interconnect o HA-VPN) no se pueden alcanzar a través de las VPC de radios de Network Connectivity Center, ya que las rutas dinámicas no se propagan a través de Network Connectivity Center.

Esta falta de transitividad se puede superar a través de la implementación de balanceadores de cargas de proxy con los recursos no transitivos administrados como NEG híbridos. Por lo tanto, podemos implementar balanceadores de cargas de proxy frente a los frontends de servicio y frente a las cargas de trabajo a las que se puede acceder en las conexiones híbridas.

Los frontends de proxy del balanceador de cargas se implementan en subredes de VPC que se propagan en las VPC de radio de Network Connectivity Center. Esta propagación permite la accesibilidad a través de Network Connectivity Center de los recursos no transitivos a través de los balanceadores de cargas de proxy.

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 resiliencia y las asignaciones de DNS adicionales en el proyecto de consumidor.

Otras consideraciones

En esta sección, se incluyen consideraciones sobre 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. Debido a 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 de intercambio de tráfico entre redes de VPC de concentrador y radios.

Cuando se consideran las opciones de diseño de GKE, como las centralizadas o decentralizadas, el acceso directo al plano de control desde fuentes multinube 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 de Google Cloud. Sin embargo, si GKE se implementa en VPCs descentralizadas, no es posible la comunicación directa con el plano de control. Si los requisitos de una organización requieren 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 conexión que actúa como proxy, lo que supera la limitación de emparejamiento no transitivo 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 impide 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 de diferentes perímetros de servicio se comuniquen (incluidas las redes de VPC que no están dentro del perímetro).

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

DNS para APIs o 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: