Configura backends externos

En este documento, se proporcionan instrucciones para configurar backends externos en Traffic Director mediante grupos de extremos de red (NEG) de nombres de dominio completamente calificados (FQDN) de Internet. Se supone que estás familiarizado con los siguientes elementos en un nivel intermedio o avanzado:

• Balanceador de cargas de aplicaciones externo
• Cloud DNS
• Traffic Director
• Conectividad híbrida

En esta guía de configuración, encontrarás instrucciones básicas para lo siguiente:

• Configurar Traffic Director a fin de usar un NEG de Internet y TLS no autenticado para el tráfico saliente
• Enrutar el tráfico a un servicio de Cloud Run desde tu malla de servicios

Antes de comenzar

Revisa la descripción general de Traffic Director con grupos de extremos de red de Internet.

Para los fines de esta guía, en la configuración de ejemplo se supone lo siguiente:

• Todos los recursos relevantes de Compute Engine, como los proxies intermedios, los recursos de Traffic Director, la zona de Cloud DNS y la conectividad híbrida se conectan a la red de la Nube Privada Virtual (VPC) por defecto.
• El servicio example.com:443 se ejecuta en la infraestructura local. Tres extremos, 10.0.0.100, 10.0.0.101 y 10.0.0.102, entregan el dominio example.com. Existen rutas que garantizan la conectividad de los proxies de Envoy a estos extremos remotos.

La implementación resultante es similar a la siguiente:

Configuración de ejemplo con un NEG de Internet (haz clic para agrandar)

Enrutamiento del tráfico con un NEG de Internet y TLS con SNI

Después de configurar Traffic Director con un NEG de Internet mediante el FQDN y la TLS para el tráfico saliente, la implementación de ejemplo se comporta como se ilustra en los siguientes diagrama y descripción del tráfico.

Cómo se enruta el tráfico en el ejemplo (haz clic para ampliar)

Los pasos de la siguiente leyenda correspondientes a la numeración del diagrama anterior.

Paso	Descripción
0	Envoy recibe la configuración de backend del FQDN de Traffic Director a través de xDS.
0	Envoy, que se ejecuta en la VM, consulta DNS de forma continua para obtener el FQDN configurado.
1	La aplicación del usuario inicia una solicitud.
2	Parámetros de la solicitud.
3	El proxy Envoy intercepta la solicitud. En el ejemplo, se supone que usas 0.0.0.0 como la dirección IP virtual (VIP) de la regla de reenvío. Cuando 0.0.0.0 es la VIP, Envoy intercepta todas las solicitudes. El enrutamiento de solicitudes se basa solo en los parámetros de la capa 7, sin importar la dirección IP de destino en la solicitud original que genera la aplicación.
4	Envoy selecciona un extremo remoto en buen estado y realiza un protocolo de enlace TLS con la SNI que se obtuvo de la política de TLS del cliente.
5	Envoy envía mediante proxy la solicitud al extremo remoto.

No se muestra en el diagrama, pero si las verificaciones de estado están configuradas, Envoy verifica el estado de los extremos remotos de forma continua y enruta las solicitudes solo a los extremos en buen estado.

Configura la conectividad híbrida

En este documento, también se supone que ya se estableció la conectividad híbrida.

• La conectividad híbrida entre la red de VPC y los servicios locales o una nube pública de terceros se establece con Cloud VPN o Cloud Interconnect.
• Las reglas y rutas de firewall de VPC están configuradas de forma correcta para establecer la accesibilidad bidireccional desde Envoy hasta los extremos del servicio privado y, de forma opcional, a un servidor DNS local.
• Para una situación de conmutación por error regional de HA exitosa, debe estar habilitado el enrutamiento dinámico global. Para obtener más detalles, consulta Modo de enrutamiento dinámico.

Configura Cloud DNS

Usa los siguientes comandos a fin de configurar una zona privada de Cloud DNS para el dominio (FQDN) example.com que tiene registros A que apuntan a los extremos 10.0.0.100, 10.0.0.101 y 10.0.0.102 y 10.0.0.103

gcloud

1. Crea una zona privada administrada de DNS y conéctala a la red predeterminada.

   gcloud dns managed-zones create example-zone \
       --description=test \
       --dns-name=example.com \
       --networks=default \
       --visibility=private
   

2. Agrega registros DNS a la zona privada.

   gcloud dns record-sets transaction start \
       --zone=example-zone
   
   gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
       --name=example.com \
       --ttl=300 \
       --type=A \
       --zone=example-zone
   
   gcloud dns record-sets transaction execute \
       --zone=example-zone
   

Configura Traffic Director con un NEG de FQDN de Internet

En esta sección, configurarás Traffic Director con un NEG de FQDN de Internet.

Crea el NEG, la verificación de estado y el servicio de backend

gcloud

1. Crea el NEG de Internet.

   gcloud compute network-endpoint-groups create on-prem-service-a-neg \
       --global \
       --network-endpoint-type INTERNET_FQDN_PORT
   

2. Agrega el extremo FQDN:Port al NEG de Internet.

   gcloud compute network-endpoint-groups update on-prem-service-a-neg \
       --global \
       --add-endpoint=fqdn=example.com,port=443
   

3. Crea una verificación de estado global.

   gcloud compute health-checks create http service-a-http-health-check \
       --global
   

4. Crea un servicio de backend global llamado on-prem-service-a y asocia la verificación de estado con él.

   gcloud compute backend-services create on-prem-service-a \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --health-checks service-a-http-health-check
   

5. Agrega el NEG llamado on-prem-service-a-neg como el backend del servicio de backend.

   gcloud compute backend-services add-backend on-prem-service-a \
       --global \
       --global-network-endpoint-group \
       --network-endpoint-group on-prem-service-a-neg
   

Crea un mapa de reglas de enrutamiento

El mapa de URL, el proxy HTTP de destino y la regla de reenvío constituyen un mapa de reglas de enrutamiento que proporciona información de enrutamiento para el tráfico en tu malla.

Estos mapas de URL contienen una regla que enruta todo el tráfico HTTP a on-prem-service-a.

gcloud

1. Crea el mapa de URL:

   gcloud compute url-maps create td-url-map \
       --default-service on-prem-service-a
   

2. Crea el proxy HTTP de destino y asocia el mapa de URL con el proxy de destino.

   gcloud compute target-http-proxies create td-proxy \
       --url-map td-url-map
   

3. Crea la regla de reenvío global con la dirección IP 0.0.0.0. Esta es una dirección IP especial que hace que tu plano de datos ignore la dirección IP de destino y enrute las solicitudes solo en función de los parámetros HTTP de la solicitud.

   gcloud compute forwarding-rules create td-forwarding-rule \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --address=0.0.0.0 \
       --target-http-proxy=td-proxy \
       --ports=443 \
       --network=default
   

Configura TLS y HTTPS no autenticados

De forma opcional, si deseas configurar HTTPS no autenticado entre tus proxies de Envoy y tus servicios locales, usa estas instrucciones. En estas instrucciones, también se muestra cómo configurar SNI en el protocolo de enlace TLS.

Una política de TLS del cliente especifica la identidad del cliente y el mecanismo de autenticación cuando un cliente envíe solicitudes salientes a un servicio en particular. Una política de TLS de cliente se conecta a un recurso de servicio de backend mediante el campo securitySettings.

gcloud

1. Crea e importa la política de TLS del cliente. Establece la SNI en el FQDN que configuraste en el NEG:

   cat << EOF > client_unauthenticated_tls_policy.yaml
   name: "client_unauthenticated_tls_policy"
   sni: "example.com"
   EOF
   
   gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
       --source=client_unauthenticated_tls_policy.yaml \
       --location=global
   

2. Si configuraste una verificación de estado HTTP con el servicio de backend en la sección anterior, desvincula la verificación de estado del servicio de backend:

   gcloud compute backend-services update on-prem-service-a \
       --global \
       --no-health-checks
   

3. Crea una verificación de estado HTTPS:

   gcloud compute health-checks create https service-a-https-health-check \
       --global
   

4. Adjunta la política de TLS del cliente al servicio de backend que creaste antes. Esto aplica HTTPS no autenticado en todas las solicitudes salientes del cliente a este servicio de backend:

   gcloud compute backend-services export on-prem-service-a \
       --global \
       --destination=on-prem-service-a.yaml
   
   cat << EOF >> on-prem-service-a.yaml
   securitySettings:
     clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
   healthChecks:
     - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
   EOF
   
   gcloud compute backend-services import on-prem-service-a \
       --global \
       --source=on-prem-service-a.yaml
   

Puedes usar NEG de FQDN de Internet para enrutar el tráfico a cualquier servicio al que se pueda acceder a través del FQDN, por ejemplo, servicios internos y externos que se pueden resolver de DNS o servicios de Cloud Run.

Migra de un NEG IP:Port a un NEG FQDN:Port

El NEG NON_GCP_PRIVATE_IP_PORT requiere que programes los extremos de servicio en el NEG como pares IP:PORT estáticos, mientras que INTERNET_FQDN_NEG permite que los extremos se resuelvan de forma dinámica mediante DNS. Puedes migrar al NEG de Internet si configuras registros DNS para tus extremos de servicio locales y configuras Traffic Director como se describe en los siguientes pasos:

1. Configura registros DNS para el FQDN.
2. Crea un NEG de Internet nuevo con el FQDN.
3. Crea un servicio de backend nuevo con el NEG de Internet que creaste en el paso 2 como su backend. Asocia la misma verificación de estado que usaste con el servicio de backend de NEG de conectividad híbrida al nuevo servicio de backend. Verifica que los extremos remotos nuevos estén en buen estado.
4. Actualiza el mapa de reglas de enrutamiento para hacer referencia al servicio de backend nuevo. Para ello, reemplaza el backend anterior que incluye el NEG de conectividad híbrida.
5. Si deseas que no haya tiempo de inactividad durante la migración en vivo en una implementación de producción, puedes usar el tráfico basado en el peso. Primero, configura el servicio de backend nuevo para recibir solo un pequeño porcentaje de tráfico, por ejemplo, un 5%. Usa las instrucciones para configurar la división del tráfico.
6. Verificar que los nuevos extremos remotos entreguen tráfico de forma correcta.
7. Si usas la división de tráfico basada en el peso, configura el servicio de backend nuevo para que reciba el 100% del tráfico. Este paso desvía el servicio de backend anterior.
8. Después de verificar que los backends nuevos entreguen tráfico sin problemas, borra el servicio de backend anterior.

Soluciona problemas

Para resolver problemas de implementación, usa las instrucciones de esta sección. Si tus problemas no se resuelven con esta información, consulta Soluciona problemas de implementaciones que usan Envoy.

Un extremo local no recibe tráfico

Si un extremo no recibe tráfico, asegúrate de que pase las verificaciones de estado y que las consultas de DNS del cliente de Envoy muestren su dirección IP de forma coherente.

Envoy usa el modo strict_dns para administrar las conexiones. Balancea las cargas de tráfico en todos los extremos resueltos que están en buen estado. El orden en el que se resuelven los extremos en el modo strict_dns no importa, pero Envoy desvía el tráfico a cualquier extremo que ya no esté presente en la lista de direcciones IP mostradas.

El encabezado del host HTTP no coincide con el FQDN cuando la solicitud llega a mi servidor local

Considera un ejemplo en el que el dominio example.com se resuelve en 10.0.0.1, que es la dirección IP de la regla de reenvío, y el dominio altostrat.com se resuelve en 10.0.0.100, que es tu extremo de servicio local. Quieres enviar tráfico al dominio altostrat.com, que está configurado en el NEG.

Es posible que la aplicación en Compute Engine o GKE establezca el encabezado del Host HTTP en example.com (Host: example.com), que se traslada al extremo local. Si usas HTTPS, Envoy establece la SNI en altostrat.com durante el protocolo de enlace TLS. Envoy obtiene la SNI del recurso de la política de TLS de cliente.

Si este conflicto causa problemas en el procesamiento o el enrutamiento de la solicitud cuando llega al extremo local, como solución alternativa, puedes volver a escribir el encabezado de Host como altostrat.com (Host: altostrat.com ). Esto se puede hacer en Traffic Director mediante la reescritura de URL o en el extremo remoto si tiene capacidad de reescritura de encabezado.

Otra solución menos compleja es establecer el encabezado de Host como altostrat.com (Host: altostrat.com) y usar la dirección especial 0.0.0.0 como la dirección IP de la regla de reenvío.

Envoy muestra muchos errores 5xx

Si Envoy muestra una cantidad excesiva de errores 5xx, haz lo siguiente:

• Verifica los registros de Envoy para distinguir si la respuesta proviene del backend (backend local) y cuál es el motivo del error 5xx.
• Asegúrate de que las consultas de DNS se realicen correctamente y que no haya errores SERVFAIL ni NXDOMAIN.
• Asegúrate de que todos los extremos remotos pasen las verificaciones de estado.
• Si las verificaciones de estado no están configuradas, asegúrate de que se pueda acceder a todos los extremos desde Envoy. Verifica las reglas y rutas de firewall en el lado de Google Cloud, así como en el lado local.

No se puede acceder a servicios externos a través de la Internet pública desde la malla de servicios

Puedes enviar tráfico a servicios ubicados en la Internet pública mediante los backends de FQDN en Traffic Director. Primero debes establecer la conectividad a Internet entre los clientes de Envoy y el servicio externo. Si recibes un error 502 durante las conexiones al servicio externo, haz lo siguiente:

• Asegúrate de tener las rutas correctas, en particular la ruta predeterminada 0.0.0.0/0, y las reglas de firewall configuradas.
• Asegúrate de que las consultas de DNS se realicen correctamente y que no haya errores SERVFAIL ni NXDOMAIN.
• Si el proxy de Envoy se ejecuta en una VM de Compute Engine que no tiene una dirección IP externa o en un clúster de GKE privado, debes configurar Cloud NAT o algún otro medio para establecer la conectividad a Internet saliente.

Si los errores persisten o si recibes otros errores 5xx, revisa los registros de Envoy para limitar el origen de los errores.

No se puede acceder a los servicios sin servidores desde la malla de servicios

Puedes enviar tráfico a servicios sin servidores (Cloud Run, Cloud Functions y App Engine) mediante los backends de FQDN en Traffic Director. Si el proxy de Envoy se ejecuta en una VM de Compute Engine que no tiene una dirección IP externa o en un clúster de GKE privado, debes configurar el Acceso privado a Google en la subred para poder acceder a los servicios y las API de Google.

¿Qué sigue?

• Para obtener más información sobre las políticas de TLS de cliente, consulta Seguridad del servicio de Traffic Director y la API de Network Security.