Configurar backends externos con grupos de endpoints de red de Internet

En este documento se explica cómo configurar backends externos para Cloud Service Mesh mediante grupos de puntos finales de red (NEGs) de Internet, que requieren un nombre de dominio completo. Este documento está dirigido a usuarios que tengan un nivel de familiaridad entre intermedio y avanzado con lo siguiente:

En esta guía de configuración se proporcionan instrucciones básicas para lo siguiente:

  • Configurar Cloud Service Mesh para que use un NEG de Internet y TLS sin autenticar para el tráfico saliente
  • Dirigir tráfico a un servicio de Cloud Run desde tu malla de servicios

Antes de empezar

Consulta la información general sobre Cloud Service Mesh con grupos de endpoints de red de Internet.

En esta guía, las configuraciones de ejemplo parten de las siguientes premisas:

  • Todos los recursos relevantes de Compute Engine, como los proxies intermedios, los recursos de Cloud Service Mesh, las zonas de Cloud DNS y la conectividad híbrida, están asociados a la red de nube privada virtual (VPC) predeterminada.
  • El servicio example.com:443 se ejecuta en tu infraestructura local. El dominio example.com se sirve mediante tres endpoints: 10.0.0.100, 10.0.0.101 y 10.0.0.102. Existen rutas que aseguran la conectividad de los proxies de Envoy a estos endpoints remotos.

La implementación resultante es similar a la siguiente.

Ejemplo de configuración con un NEG de Internet.
Ejemplo de configuración con un NEG de Internet (haz clic en la imagen para ampliarla)

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

Después de configurar Cloud Service Mesh con un NEG de Internet mediante el FQDN y TLS para el tráfico saliente, el ejemplo de implementación se comporta como se ilustra en el siguiente diagrama y descripción del tráfico.

Cómo se enruta el tráfico en el ejemplo.
Cómo se enruta el tráfico en el ejemplo (haz clic en la imagen para ampliarla)

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

Paso Descripción
0 Envoy recibe la configuración de backend del FQDN de Cloud Service Mesh a través de xDS.
0 Envoy, que se ejecuta en la VM, consulta continuamente el DNS para obtener el FQDN configurado.
1 La aplicación del usuario inicia una solicitud.
2 Parámetros de la solicitud.
3 El proxy de Envoy intercepta la solicitud. En el ejemplo se da por hecho que usas 0.0.0.0 como dirección IP virtual (VIP) de la regla de reenvío. Cuando 0.0.0.0 es el VIP, Envoy intercepta todas las solicitudes. El enrutamiento de solicitudes se basa únicamente en los parámetros de la capa 7 independientemente de la dirección IP de destino de la solicitud original generada por la aplicación.
4 Envoy selecciona un endpoint remoto correcto y realiza un handshake de TLS con el SNI obtenido de la política de TLS del cliente.
5 Envoy envía la solicitud al endpoint remoto.

No se muestra en el diagrama, pero, si se configuran comprobaciones del estado, Envoy comprueba continuamente el estado de los endpoints remotos y solo dirige las solicitudes a los endpoints en buen estado.

Configurar la conectividad híbrida

En este documento también se da por hecho que ya se ha establecido la conectividad híbrida:

  • La conectividad híbrida entre la red de VPC y los servicios on-premise o una nube pública de terceros se establece con Cloud VPN o Cloud Interconnect.
  • Las reglas y las rutas de cortafuegos de VPC están configuradas correctamente para establecer la accesibilidad bidireccional de Envoy a los endpoints de servicio privado y, opcionalmente, a un servidor DNS local.
  • Para que se produzca una conmutación por error de alta disponibilidad regional, el enrutamiento dinámico global debe estar habilitado. Para obtener más información, consulta el modo de enrutamiento dinámico.

Configurar Cloud DNS

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

gcloud

  1. Crea una zona privada gestionada de DNS y adjúntala a la red predeterminada:
    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
  1. Añade 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

Configurar Cloud Service Mesh con un NEG de FQDN de Internet

En esta sección, configurará Cloud Service Mesh con un nombre de dominio completo (FQDN) de Internet NEG.

Crear el NEG, la comprobación del 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
  1. Añade el endpoint 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
  1. Crea una comprobación del estado global:
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. Crea un servicio de backend global llamado on-prem-service-a y asocia la comprobación del estado a él:
    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
  1. Añade el NEG llamado on-prem-service-a-neg como 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

Crear un mapa de regla de enrutamiento

El mapa de URLs, 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 de tu malla.

Este mapa de URLs contiene una regla que dirige todo el tráfico HTTP a on-prem-service-a.

gcloud

  1. Crea la asignación de URLs:
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. Crea el proxy HTTP de destino y asocia el mapa de URLs al proxy de destino:
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. Crea la regla de reenvío global con la dirección IP 0.0.0.0. Se trata de una dirección IP especial que hace que tu plano de datos ignore la dirección IP de destino y enrute las solicitudes basándose únicamente en 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

Configurar TLS y HTTPS sin autenticación

Si quieres configurar HTTPS sin autenticación entre tus proxies de Envoy y tus servicios locales, puedes seguir estas instrucciones. En estas instrucciones también se explica cómo configurar SNI en el handshake de TLS.

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

gcloud

  1. Crea e importa la política de TLS del cliente. Define el SNI en el FQDN que has configurado 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
  1. Si has configurado una HTTP comprobación del estado con el servicio de backend en la sección anterior, desvincula la comprobación del estado del servicio de backend:
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. Crea una HTTPS comprobación del estado:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. Adjunta la política de TLS de cliente al servicio de backend que has creado anteriormente. De esta forma, se aplicará HTTPS sin autenticación a 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 NEGs de FQDN de Internet para enrutar el tráfico a cualquier servicio al que se pueda acceder mediante FQDN, como servicios externos e internos que se puedan resolver mediante DNS o servicios de Cloud Run.

Migrar de una NEG de IP:Port a una NEG de FQDN:Port

NON_GCP_PRIVATE_IP_PORT NEG requiere que programes los puntos finales de servicio en el NEG como pares IP:PORT estáticos, mientras que INTERNET_FQDN_NEG permite que los puntos finales se resuelvan dinámicamente mediante DNS. Para migrar a un NEG de Internet, configura los registros DNS de tus endpoints de servicio on-premise y Cloud Service Mesh, tal como se describe en los pasos siguientes:

  1. Configura los registros DNS de tu FQDN.
  2. Crea un NEG de Internet con el FQDN.
  3. Crea un servicio de backend con el NEG de Internet que has creado en el paso 2 como backend. Asocia la misma comprobación de estado que usaste con el servicio de backend de NEG de conectividad híbrida al nuevo servicio de backend. Verifica que los nuevos endpoints remotos estén en buen estado.
  4. Actualiza el mapa de reglas de enrutamiento para que haga referencia al nuevo servicio de backend. Para ello, sustituye el backend antiguo, que incluye el NEG de conectividad híbrida.
  5. Si quieres que no haya tiempo de inactividad durante la migración en directo en una implementación de producción, puedes usar el tráfico basado en el peso. Al principio, configura tu nuevo servicio backend para que reciba solo un pequeño porcentaje del tráfico (por ejemplo, el 5 %). Sigue las instrucciones para configurar la división del tráfico.
    1. Verifica que los nuevos endpoints remotos estén sirviendo el tráfico correctamente.
  6. Si usa la división del tráfico basada en el peso, configure el nuevo servicio de backend para que reciba el 100% del tráfico. Este paso agota el servicio de backend antiguo.
  7. Una vez que hayas verificado que los nuevos back-ends sirven tráfico sin problemas, elimina el servicio de back-end antiguo.

Solución de problemas

Para solucionar problemas de implementación, sigue las instrucciones de esta sección. Si los problemas no se resuelven con esta información, consulta el artículo Solucionar problemas de implementaciones que usan Envoy.

Un endpoint local no recibe tráfico

Si un endpoint no recibe tráfico, asegúrate de que supera las comprobaciones de estado y de que las consultas DNS del cliente de Envoy devuelven su dirección IP de forma coherente.

Envoy usa el modo strict_dns para gestionar las conexiones. Balancea la carga del tráfico entre todos los endpoints resueltos que estén en buen estado. El orden en el que se resuelven los endpoints no importa en el modo strict_dns, pero Envoy redirige el tráfico a cualquier endpoint que ya no esté presente en la lista de direcciones IP devueltas.

El encabezado de host HTTP no coincide con el nombre de dominio completo cuando la solicitud llega a mi servidor local

Supongamos 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 que el dominio altostrat.com se resuelve en 10.0.0.100, que es el endpoint de tu servicio local. Quieres enviar tráfico al dominio altostrat.com, que está configurado en tu NEG.

Es posible que la aplicación de Compute Engine o GKE defina el encabezado HTTP Host como example.com (Host: example.com), que se transfiere al endpoint local. Si usas HTTPS, Envoy define el SNI como altostrat.com durante el handshake TLS. Envoy obtiene la SNI del recurso de política de TLS de cliente.

Si este conflicto está causando problemas en el procesamiento o el enrutamiento de la solicitud cuando llega al endpoint local, puedes reescribir la cabecera Host a altostrat.com (Host: altostrat.com) como solución alternativa. Esto se puede hacer en Cloud Service Mesh mediante la reescritura de URLs o en el endpoint remoto si tiene la función de reescritura de cabeceras.

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

Envoy devuelve muchos errores 5xx

Si Envy devuelve un número excesivo de errores 5xx, haz lo siguiente:

  • Consulta los registros de Envoy para determinar si la respuesta procede 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 de que no haya errores SERVFAIL ni NXDOMAIN.
  • Asegúrate de que todos los endpoints remotos superen las comprobaciones de estado.
  • Si no se han configurado comprobaciones de estado, asegúrate de que se pueda acceder a todos los endpoints desde Envoy. Comprueba las reglas y las rutas del cortafuegos en el lado deGoogle Cloud y en el local.

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

Puedes enviar tráfico a servicios ubicados en Internet pública mediante backends de FQDN en Cloud Service Mesh. Primero debes establecer una conexión 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 que tienes las rutas correctas, en concreto la ruta predeterminada 0.0.0.0/0, y las reglas de cortafuegos configuradas.
  • Asegúrate de que las consultas de DNS se realicen correctamente y de 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 privado de GKE, debes configurar Cloud NAT u otro medio para establecer la conectividad a Internet saliente.

Si los errores persisten o recibes otros errores 5xx, consulta los registros de Envoy para acotar la fuente de los errores.

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

Puedes enviar tráfico a servicios sin servidor (Cloud Run, funciones de Cloud Run y App Engine) mediante backends de FQDN en Cloud Service Mesh. 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 privado de GKE, debes configurar el acceso privado de Google en la subred para poder acceder a las APIs y los servicios de Google.

Siguientes pasos