Configura backends externos con grupos de extremos de red de Internet

En este documento, se proporcionan instrucciones para configurar backends externos para Cloud Service Mesh mediante grupos de extremos de red de Internet (NEG), que requieren un nombre de dominio completamente calificado. Este documento está dirigido a usuarios con un nivel de familiaridad intermedio a avanzado con lo siguiente:

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

  • Configurar Cloud Service Mesh a fin de usar un NEG de Internet y TLS sin autenticar 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 Cloud Service Mesh 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 Cloud Service Mesh, las zonas de Cloud DNS y la conectividad híbrida, se conectan a la red de nube privada virtual (VPC) predeterminada.
  • 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.
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 Cloud Service Mesh con un NEG de Internet mediante el FQDN y el TLS para el tráfico saliente, la implementación de ejemplo se comporta como se ilustra en el siguiente diagrama y la 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 para ampliar)

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

Step Descripción
0 Envoy recibe la configuración del backend FQDN desde Cloud Service Mesh 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 de Envoy a extremos de servicios privados 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
  1. 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 Cloud Service Mesh con un NEG con FQDN de Internet

En esta sección, configurarás Cloud Service Mesh 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
  1. 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
  1. Crea una verificación de 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 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
  1. 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.

Este mapa de URL contiene 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
  1. Crea el proxy HTTP de destino y asocia el mapa de URL 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. Esta es una dirección IP especial que hace que el plano de datos ignore la dirección IP de destino y enrute las solicitudes basadas solo 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

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. Se vincula una política de TLS del cliente 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
  1. 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
  1. Crea una verificación de estado HTTPS:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. 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 mediante la configuración de registros DNS para los extremos de servicio locales y la configuración de Cloud Service Mesh 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 del NEG de conectividad híbrida con el servicio de backend nuevo. 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.
    1. Verificar que los nuevos extremos remotos entreguen tráfico de forma correcta.
  6. 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 vacía el servicio de backend anterior.
  7. 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 no se resuelven tus problemas 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 que se resuelven los extremos no importa en el modo strict_dns, pero Envoy desvía el tráfico a cualquier extremo que ya no esté presente en la lista de direcciones IP que se muestran.

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 el extremo del servicio local. Deseas enviar tráfico al dominio altostrat.com, que está configurado en tu NEG.

Es posible que la aplicación en Compute Engine o GKE configure el encabezado HTTP Host en example.com (Host: example.com), que se transfiere 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 del 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 Host en altostrat.com (Host: altostrat.com). Esto se puede hacer en Cloud Service Mesh con la reescritura de URL o en el extremo remoto si tiene la capacidad de reescritura de encabezado.

Otra solución menos compleja es establecer el encabezado 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 y 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 los servicios ubicados en la Internet pública mediante backends de FQDN en Cloud Service Mesh. 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 los servicios sin servidores (Cloud Run, Cloud Functions y App Engine) mediante backends 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 de GKE privado, debes configurar el Acceso privado a Google en la subred para poder acceder a las API y los servicios de Google.

¿Qué sigue?