Traffic Director con grupos de extremos de red de conectividad híbrida
Traffic Director admite entornos que se extienden más allá de Google Cloud, incluidos los centros de datos locales y otras nubes públicas a las que se puede acceder mediante la conectividad híbrida.
Configura Traffic Director para que tu malla de servicios pueda enviar tráfico a extremos que se encuentran fuera de Google Cloud. Estos extremos incluyen lo siguiente:
- Balanceadores de cargas locales.
- Aplicaciones de servidores en una instancia de máquina virtual (VM) en otra nube.
- Cualquier otro destino al que se pueda acceder con conectividad híbrida y con una dirección IP y un puerto.
Debes agregar la dirección IP y los puertos de cada extremo a un grupo de extremos de red de la conectividad híbrida (NEG). Los NEG de conectividad híbrida son del tipo NON_GCP_PRIVATE_IP_PORT.
La compatibilidad de Traffic Director con servicios locales y de múltiples nubes te permite hacer lo siguiente:
- Enrutar el tráfico de forma global, incluso a los extremos de los servicios locales y de múltiples nubes.
- Aprovechar los beneficios de Traffic Director y de malla de servicios, incluidas las funciones, como el descubrimiento de servicios y la administración avanzada del tráfico, en los servicios que se ejecutan en tu infraestructura existente fuera de Google Cloud.
- Combinar las funciones de Traffic Director con Cloud Load Balancing para conectar los servicios de Herramientas de redes de Google Cloud a múltiples entornos.
Los NEG de conectividad híbrida (NEG NON_GCP_PRIVATE_IP_PORT) no son compatibles con clientes de gRPC sin proxy.
Casos de uso
Traffic Director puede configurar las Herramientas de redes entre los servicios basados en VM y contenedores en múltiples entornos, incluidos los siguientes:
- Google Cloud
- Centros de datos locales
- Otras nubes públicas
Enruta el tráfico de la malla a una ubicación local o a otra nube
El caso de uso más simple para esta función es el enrutamiento de tráfico. Tu aplicación ejecuta un proxy de Envoy de Traffic Director . Traffic Director informa al cliente sobre tus servicios y los extremos de cada servicio.
En el diagrama anterior, cuando tu aplicación envía una solicitud al servicio on-prem, el cliente de Traffic Director inspecciona la solicitud saliente y actualiza su destino. El destino se configura en un extremo asociado con el servicio on-prem (en este caso, 10.2.0.1). La solicitud luego pasa por Cloud VPN o Cloud Interconnect hacia su destino previsto.
Si necesitas agregar más extremos, debes actualizar Traffic Director para agregarlos a tu servicio. No es necesario que cambies el código de tu aplicación.
Migra un servicio local existente a Google Cloud
Enviar tráfico a un extremo que no es de Google Cloud te permite enrutar el tráfico a otros entornos. Puedes combinar esta capacidad con la administración avanzada del tráfico para migrar servicios entre entornos.
En el diagrama anterior, se extiende el patrón anterior. En lugar de configurar Traffic Director para enviar todo el tráfico al servicio on-prem, debes configurar Traffic Director a fin de que use la división de tráfico basada en el peso para dividir el tráfico entre dos servicios.
La división del tráfico te permite comenzar enviando un 0% del tráfico al servicio cloud y un 100% al servicio on-prem. Luego, puedes aumentar de forma gradual la proporción del tráfico enviado al servicio de cloud. Por último, envías el 100% del tráfico al servicio cloud y puedes retirar el servicio on-prem.
Servicios de red perimetral de Google Cloud para implementaciones locales y de múltiples nubes
Por último, puedes combinar esta funcionalidad con las soluciones de Herramientas de redes de Google Cloud existentes. Google Cloud ofrece una amplia gama de servicios de red, como el balanceo de cargas externo global con Google Cloud Armor para la protección contra la denegación de servicio distribuido (DSD), que puedes usar con Traffic Director para agregar funciones nuevas a los servicios locales o de múltiples nubes. Lo mejor de todo es que no necesitas exponer estos servicios locales o de múltiples nubes a la Internet pública.
En el diagrama anterior, el tráfico de clientes en la Internet pública ingresa a la red de Google Cloud desde un balanceador de cargas de Google Cloud, como nuestro balanceador de cargas de aplicaciones externo global. Cuando el tráfico llega al balanceador de cargas, puedes aplicar servicios de red perimetral, como la protección contra DSD de Google Cloud Armor o la autenticación de usuario de Identity-Aware Proxy (IAP). Si deseas obtener más información, consulta Servicios de red perimetral para implementaciones de múltiples entornos.
Una vez que aplicas estos servicios, el tráfico se detiene brevemente en Google Cloud, en el que una aplicación o un proxy independiente (configurado por Traffic Director) reenvía el tráfico a través de Cloud VPN o Cloud Interconnect a tu servicio local.
Arquitectura y recursos de Google Cloud
En esta sección, se brinda información general sobre los recursos de Google Cloud que puedes usar para proporcionar una malla de servicios administrada por Traffic Director para entornos locales y de múltiples nubes.
En el siguiente diagrama, se muestran los recursos de Google Cloud que habilitan la asistencia de servicios locales y de múltiples nubes para Traffic Director. El recurso clave es el NEG (y sus extremos de red). Los otros recursos son los que configuras como parte de una configuración estándar de Traffic Director. Para simplificar, en el diagrama no se muestran opciones como varios servicios de backend globales.
Cuando configuras Traffic Director, se usa el recurso de la API de global backend services para crear servicios. Un servicio es una construcción lógica que combina lo siguiente:
- Políticas que se deben aplicar cuando un cliente intenta enviar tráfico al servicio.
- Uno o más backends o extremos que controlan el tráfico destinado al servicio.
Los servicios locales y de múltiples nubes son como cualquier otro servicio que configure Traffic Director. La diferencia clave es que usas un NEG de conectividad híbrida para configurar los extremos de estos servicios. Estos NEG tienen el tipo de extremo de red configurado como NON_GCP_PRIVATE_IP_PORT. Los extremos que agregues a los NEG de conectividad híbrida deben ser combinaciones IP:port válidas a las que puedan acceder tus clientes (por ejemplo, a través de una conectividad híbrida, como Cloud VPN o Cloud Interconnect).
Cada NEG tiene un tipo de extremo de red y solo puede contener extremos de red del mismo tipo. Este tipo determina lo siguiente:
- El destino al que tus servicios pueden enviar tráfico.
- El comportamiento de la verificación de estado.
Cuando crees tu NEG, configúralo de la siguiente manera para que puedas enviar tráfico a un destino local o de múltiples nubes.
- Configura el tipo de extremo de red en
NON_GCP_PRIVATE_IP_PORT. Representa una dirección IP accesible. Si esta dirección IP es local o se encuentra en otro proveedor de servicios en la nube, se debe poder acceder a ella desde Google Cloud mediante la conectividad híbrida, como la conectividad proporcionada por Cloud VPN o Cloud Interconnect. - Especifica una zona de Google Cloud que minimiza la distancia geográfica entre Google Cloud y tu entorno local o de múltiples nubes. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona
europe-west3-ade Google Cloud cuando crees el NEG.
El comportamiento de la verificación de estado para los extremos de red de este tipo difiere del comportamiento de la verificación de estado para otros tipos de extremos de red. Mientras que otros tipos de extremos de red usan el sistema centralizado de verificación de estado de Google Cloud, los extremos de red NON_GCP_PRIVATE_IP_PORT usan el mecanismo de verificación de estado distribuido de Envoy. Para obtener más información, consulta la sección Limitaciones y otras consideraciones.
Consideraciones de conectividad y redes
Tus clientes de Traffic Director, como los proxies de Envoy, deben poder conectarse a Traffic Director en trafficdirector.googleapis.com:443. Si pierdes conectividad con el plano de control de Traffic Director, ocurrirá lo siguiente:
- Los clientes existentes de Traffic Director no podrán recibir actualizaciones de configuración de Traffic Director. Seguirán operando según su configuración actual.
- Los clientes nuevos de Traffic Director no podrán conectarse con Traffic Director. No podrán usar la malla de servicios hasta que se vuelva a establecer la conectividad.
Si quieres enviar tráfico entre Google Cloud y entornos locales o de múltiples nubes, los entornos deben estar conectados a través de la conectividad híbrida. Recomendamos una conexión de alta disponibilidad habilitada mediante Cloud VPN o Cloud Interconnect.
Las direcciones IP locales, otras de la nube y de la subred de Google Cloud no deben superponerse.
Limitaciones y otras consideraciones
Las siguientes son limitaciones del uso de NEG de conectividad híbrida.
Configura proxyBind
Solo puedes establecer el valor de proxyBind cuando creas un targetHttpProxy.
No puedes actualizar un targetHttpProxy existente.
Interrupción y conectividad en la conectividad
Para obtener detalles sobre los requisitos y las limitaciones de conectividad, consulta la sección Consideraciones de conectividad y redes.
Tipos de backend mixtos
Un servicio de backend puede tener backends de VM o NEG. Si un servicio de backend tiene backends de NEG, todos los NEG deben contener el mismo tipo de extremo de red. No puedes tener un servicio de backend con varios NEG, cada uno con diferentes tipos de extremos.
Un mapa de URL puede tener reglas de host que se resuelvan en diferentes servicios de backend. Puedes tener un servicio de backend solo con NEG de conectividad híbrida (con extremos locales) y un servicio de backend con NEG independientes (con extremos de GKE). El mapa de URL puede contener reglas, por ejemplo, dividir el tráfico basado en el peso, que divide el tráfico en cada uno de estos servicios de backend.
Usa un NEG con extremos de tipo NON_GCP_PRIVATE_IP_PORT con backends de Google Cloud
Es posible crear un servicio de backend con un NEG de conectividad híbrida que apunta a los backends en Google Cloud. Sin embargo, no recomendamos este patrón, ya que los NEG de conectividad híbrida no se benefician de la verificación de estado centralizada. Para obtener una explicación de la verificación de estado centralizada y la verificación de estado distribuida, consulta la sección Verificación de estado.
Registro de extremos
Si deseas agregar un extremo a un NEG, debes actualizar el NEG. Esto se puede hacer de forma manual o se puede automatizar con las API de REST de NEG de Google Cloud o con la CLI de Google Cloud.
Cuando se inicia una instancia nueva de un servicio, puedes usar las API de Google Cloud para registrar la instancia con el NEG que configuraste. Cuando usas grupos de instancias administrados (MIG) de Compute Engine o GKE (en Google Cloud), el controlador de NEG o MIG maneja de forma automática el registro de extremos, respectivamente.
Verificaciones de estado
Cuando usas NEG de conectividad híbrida, el comportamiento de la verificación de estado difiere del comportamiento estándar de verificación de estado de las siguientes maneras:
- En el caso de los extremos de red del tipo
NON_GCP_PRIVATE_IP_PORT, Traffic Director configura sus clientes para usar el plano de datos a fin de controlar la verificación de estado. Para evitar enviar solicitudes a backends en mal estado, las instancias de Envoy realizan sus propias verificaciones de estado y usan sus propios mecanismos. - Debido a que tu plano de datos controla las verificaciones de estado, no puedes usar la consola de Google Cloud, la API o Google Cloud CLI para recuperar el estado de la verificación de estado.
En la práctica, usar NON_GCP_PRIVATE_IP_PORT significa lo siguiente:
- Debido a que los clientes de Traffic Director controlan cada verificación de estado de una manera distribuida, es posible que veas un aumento en el tráfico de red debido a la verificación de estado. El aumento depende de la cantidad de clientes de Traffic Director y de la cantidad de extremos que cada cliente necesita para la verificación de estado. Por ejemplo:
- Cuando agregas otro extremo a un NEG de conectividad híbrida, los clientes existentes de Traffic Director pueden comenzar a verificar el estado de los extremos en los NEG de conectividad híbrida.
- Cuando agregas otra instancia a la malla de servicios (por ejemplo, una instancia de VM que ejecuta el código de tu aplicación y un cliente de Traffic Director), la instancia nueva puede verificar el estado de los extremos en los NEG de conectividad híbrida.
- El tráfico de red debido a las verificaciones de estado aumenta a una frecuencia cuadrática (
O(n^2)).
Red de VPC
Una malla de servicios se identifica de forma única por su nombre de red de nube privada virtual (VPC). Los clientes de Traffic Director reciben la configuración desde Traffic Director en función de la red de VPC especificada en la configuración de arranque. Por lo tanto, incluso si tu malla está completamente fuera de un centro de datos de Google Cloud, debes proporcionar un nombre de red de VPC válido en tu configuración de arranque.
Cuenta de servicio
Dentro de Google Cloud, el arranque inicial predeterminado de Envoy está configurado para leer información de la cuenta de servicio desde uno o ambos de los entornos de implementación de Compute Engine y GKE. Cuando se ejecuta fuera de Google Cloud, debes especificar de forma explícita una cuenta de servicio, un nombre de red y un número de proyecto en tu arranque de Envoy. Esta cuenta de servicio debe tener permisos suficientes para conectarse a la API de Traffic Director.
¿Qué sigue?
- Si deseas configurar Traffic Director para implementaciones locales y en múltiples nubes, consulta Servicios de red perimetral para implementaciones de múltiples entornos.
- Para obtener más información sobre Traffic Director, consulta la descripción general de Traffic Director.
- Para obtener información sobre los NEG de Internet, consulta Traffic Director con grupos de extremos de red de Internet.