Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Configurar la integración con Directorio de servicios

En esta guía se presupone que tienes un despliegue de Cloud Service Mesh en ejecución y que has registrado al menos un servicio en Service Directory. Las instrucciones de configuración se aplican tanto si usas Envoy como gRPC sin proxy.

Para usar Service Directory y Cloud Service Mesh, el primer paso es publicar tu servicio en Service Directory. Consulta información sobre cómo publicar un servicio en Service Directory o la documentación de Service Directory para obtener una descripción general.

Una vez que el servicio se haya registrado en Directorio de servicios, crea un enlace de servicio mediante los recursos de la API de Cloud Service Mesh. Crea un servicio de backend dedicado a la integración con Service Directory, ya que un servicio de backend que haga referencia a enlaces de servicio no puede tener backends ni una comprobación de estado asociada.

Requisitos de las reglas de reenvío y de host de Cloud Service Mesh con las APIs de balanceo de carga

Si configuras Cloud Service Mesh para usarlo con Service Directory y usas las APIs de balanceo de carga antiguas, sigue estas directrices:

Asegúrate de que la regla de reenvío de Cloud Service Mesh usa la dirección IP virtual (VIP) 0.0.0.0.
Si tienes una zona privada, asegúrate de que la regla de host del mapa de URLs coincida con el nombre DNS que Directorio de servicios configura en tu zona privada de Cloud DNS.

Si no sigues estas directrices, es probable que las solicitudes salientes de tus aplicaciones fallen.

Definir el endpoint de la API `network-services`

Antes de crear y usar un servicio backend, asegúrate de que el endpoint de la API network-services esté configurado para que se haga referencia correctamente a los recursos de las vinculaciones de servicios en network-services resources. Define el endpoint de la API network-services con el siguiente comando.

export CLOUDSDK_API_ENDPOINT_OVERRIDES_NETWORKSERVICES="https://networkservices.googleapis.com/"

Requisitos de roles y permisos

Asegúrate de que tienes los siguientes permisos y roles antes de crear tu implementación de Cloud Service Mesh.

Permisos y roles de vinculación de servicios

En esta sección no se tratan los permisos de propietario, editor y lector a nivel de proyecto. En ella se describen los permisos y los roles necesarios para crear, leer, actualizar y eliminar recursos.

Acción	Permiso	Roles
Crea un enlace de servicio.	`networkservices.serviceBindings.create`	Administrador de red
Obtén un enlace de servicio.	`networkservices.serviceBindings.get`	Administrador de red, Lector de red
Permiso para mostrar las vinculaciones de servicio de un Google Cloud proyecto.	`networkservices.serviceBindings.list`	Administrador de red, Lector de red
Actualizar las vinculaciones de servicio.	`networkservices.serviceBindings.update`	Administrador de red
Eliminar enlaces de servicio.	`networkservices.serviceBindings.delete`	Administrador de red

Permisos de servicio de Service Directory

El administrador de Service Directory debe conceder el permiso servicedirectory.services.bind a la cuenta de servicio que intenta asociar la vinculación de servicio al servicio Service Directory. De esta forma, la cuenta de servicio puede usar un servicio de Service Directory, lo que significa que la cuenta puede hacer referencia a un servicio de Service Directory en un enlace de servicio.

Cumplimiento de los permisos

Las comprobaciones de permisos de gestión de identidades y accesos se realizan al configurar Cloud Service Mesh. Debes tener los permisos necesarios para crear enlaces de servicio y para asociar enlaces de servicio con servicios de Service Directory concretos. Si tienes los permisos correctos, puedes configurar tus clientes de malla para que conozcan un servicio de Service Directory y le envíen tráfico.

Como estas comprobaciones se realizan durante la configuración, si se quita el permiso de enlace de un servicio de Service Directory, no se interrumpirán los flujos de tráfico. Una vez que se ha establecido un enlace de servicio, si se quita un permiso, no se verá afectado el hecho de que un cliente de malla pueda obtener información sobre un servicio de Service Directory y enviarle tráfico.

Para evitar que un cliente de malla se comunique con un servicio de Service Directory, puedes usar otros mecanismos:

Restringir el acceso al servicio Directorio de servicios. Por ejemplo, puedes usar reglas de cortafuegos.
Permiso para eliminar el servicio de Directorio de servicios.
Actualiza la configuración de Cloud Service Mesh. Por ejemplo, puedes quitar la vinculación de servicio del servicio de backend.

Prácticas recomendadas

Aunque Directorio de Servicios permite registrar puntos finales mediante la API de Directorio de Servicios, recomendamos usar integraciones que se registren automáticamente en Directorio de Servicios cuando estén disponibles. Para obtener más información sobre estas integraciones, consulta la información general sobre Directorio de servicios para GKE y la información general sobre Directorio de servicios y Cloud Load Balancing.
Te recomendamos que uses el mismo espacio de nombres y servicio para un servicio lógico concreto, aunque se haya desplegado en diferentes regiones.

Usar Directorio de servicios para el descubrimiento de servicios

En el siguiente diagrama se muestra un resumen del estado final de este procedimiento de configuración, incluida la configuración, cómo interactúan los diferentes sistemas y cómo se resuelve una solicitud en los endpoints de un servicio. En este ejemplo se da por hecho que ya tienes un servicio registrado en Directorio de servicios.

Detalles de configuración para usar Service Directory en el descubrimiento de servicios. — Detalles de la configuración para usar Service Directory en la detección de servicios (haz clic en la imagen para ampliarla)

Para que un servicio de Directorio de servicios esté disponible en Cloud Service Mesh, debes seguir estos pasos.

Crea un servicio de backend en Cloud Service Mesh y no crees backends para el servicio de backend.
Crea un enlace de servicio global para el servicio Service Directory.
Vincula el servicio de Service Directory a este servicio de backend. Opcionalmente, puede definir campos y políticas adicionales en el servicio backend.
Crea una configuración de enrutamiento o actualiza una que ya tengas para que las solicitudes de los clientes se puedan enrutar al nuevo servicio de backend.

No puedes definir una comprobación de estado en un servicio backend que haga referencia a un enlace de servicio. El servicio de backend tampoco puede tener backends.

Crear la integración

Sigue estas instrucciones para integrar Cloud Service Mesh con Service Directory.

Crear un servicio backend

Sigue estas instrucciones para crear un servicio de backend en tu implementación de Cloud Service Mesh.

Crea un servicio de backend para usarlo con los servicios de Directorio de servicios.

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Crea un enlace de servicio que haga referencia a un servicio de Service Directory.

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service

Vincula el servicio al servicio de backend.

gcloud beta compute backend-services update td-sd-demo-service \
 --global \
 --service-bindings my-sd-binding

Después de crear el servicio de backend y vincular uno o varios servicios de Service Directory, Cloud Service Mesh empieza a monitorizar los endpoints asociados al servicio de Service Directory. Los endpoints son pares IP:puerto distintos. Para que se pueda enrutar este servicio, debes configurar el enrutamiento.

Configurar el enrutamiento

Sigue estas instrucciones para actualizar la configuración de las rutas.

APIs de enrutamiento de servicios

En el siguiente ejemplo se da por hecho que tienes un recurso Mesh llamado sidecar- mesh. Crea un recurso HTTPRoute con los nombres de host definidos en myservice.example.com y el destino definido en el servicio de backend td-sd-demo-service que has creado en la sección anterior.

Crea la especificación HTTPRoute y guárdala en un archivo llamado httproute.yaml.

name: td-sd-demo-route
hostnames:
‐ myservice.example.com
meshes:
‐ projects/PROJECT_NUMBER/locations/global/meshes/sidecar-mesh
rules:
‐ action:
  destinations:
  ‐ serviceName: "projects/PROJECT_NUMBER/locations/global/backendServices/td-sd-demo-service"

Importa la especificación HTTPRoute.

gcloud network-services httproutes import td-sd-demo-route \
  --source=httproute.yaml \
  --location=global

APIs de balanceo de carga

En el siguiente ejemplo se da por hecho que ya tienes una configuración de enrutamiento básica, incluida una asignación de URLs llamada my-url-map.

Primero, crea un comparador de rutas para este mapa de URLs. El comparador de rutas es sencillo. Cuando se usa, se resuelve en td-sd-demo-service, que has creado en el paso anterior.
A continuación, añade una regla de host al mapa de URLs. Esta regla de host hace que se utilice el matcher de ruta si una solicitud especifica el nombre de host myservice.example.com.

Crea un matcher de ruta sencillo que apunte a tu servicio de backend.

gcloud compute url-maps add-path-matcher my-url-map \
 --global \
 --default-service td-sd-demo-service \
 --path-matcher-name my-path-matcher

Asigna el servicio de backend a una nueva regla de host en el mapa de URLs.

gcloud compute url-maps add-host-rule my-url-map \
 --global \
 --path-matcher-name=my-path-matcher \
 --hosts=myservice.example.com

Adjuntar el mismo servicio desde varias regiones

Cloud Service Mesh te permite vincular varios servicios de Service Directory al mismo servicio de backend. Por ejemplo, puede tener dos servicios de Service Directory idénticos, pero con endpoints en diferentes Google Cloud regiones o zonas. Es decir, un único servicio de backend global podría tener dos enlaces de servicio globales, uno que apunte a un servicio en us-east1 y otro que apunte a un servicio en us-west1.

Crea un servicio de backend para el servicio de Service Directory que has importado.

gcloud compute backend-services create td-sd-demo-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Crea un enlace de servicio al servicio Directorio de servicios en us-east1.

gcloud beta network-services service-bindings create us-east1-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

Crea un enlace de servicio al servicio Directorio de servicios en us-west1.

gcloud beta network-services service-bindings create us-west1-binding \
 --location global
 --service-directory-region us-west1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

Vincula los servicios us-east1 y us-west1 al servicio de backend.

gcloud compute backend-services update td-sd-demo-service \
  --global \
  --service-bindings us-east1-binding,us-west1-binding

Aplicar políticas de gestión avanzada del tráfico

En la sección anterior, has usado Cloud Service Mesh para configurar políticas de enrutamiento en un servicio de Service Directory. Puedes aplicar este patrón a situaciones de gestión del tráfico más avanzadas.

Veamos esta situación. Tienes un servicio de prueba que está fuera de la malla de Cloud Service Mesh. El servicio de prueba es un backend de un balanceador de carga de aplicaciones interno. Quieres reproducir parte del tráfico de producción que se origina en la malla de Cloud Service Mesh a este servicio externo. Cloud Service Mesh puede hacerlo mediante RequestMirrorPolicy, que puede enviar tráfico a otro servicio de backend cuando se procesa la solicitud. Este proceso también se denomina duplicación de una solicitud y te permite examinar el tráfico sin afectar a tus servicios de producción.

Puedes habilitar los clientes de Envoy para que reflejen el tráfico a un servicio de prueba añadiendo o quitando manualmente el endpoint del servicio de prueba de la malla de Cloud Service Mesh. Sin embargo, el proceso es más sencillo si utilizas la integración de Service Directory.

Usar Directorio de servicios para el descubrimiento de servicios con creación de reflejos. — Usar Service Directory para descubrir servicios con la función de creación de reflejos(haz clic en la imagen para ampliarla)

En este ejemplo, se empieza por dirigir un servicio backend al registro de Service Directory del servicio de prueba de pagos. A continuación, añade una política de réplica de solicitudes al servicio en Cloud Service Mesh.

Crea un servicio de backend para la política de réplica de solicitudes.

gcloud compute backend-services create payments-test-bes \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED

Crea un enlace de servicio que haga referencia a un servicio de Service Directory.

gcloud beta network-services service-bindings create my-sd-binding \
 --location global \
 --service-directory-region us-east1 \
 --service-directory-namespace my-namespace \
 --service-directory-service my-service \

Vincula el servicio de Directorio de servicios al servicio de backend de prueba.

gcloud beta compute backend-services update payments-test-bes \
 --global \
 --service-bindings my-sd-binding

Edita el mapa de URLs para reflejar las solicitudes al servicio de prueba.
```
gcloud compute url-maps edit my-url-map \
  --region=global
```

Una vez que la configuración del mapa de URLs se haya cargado en un editor, añade la política de réplica de solicitudes para replicar las solicitudes en el servicio de Service Directory.

defaultService: my-project/global/default-service
   hostRules:
    - hosts:
      - '*'
      pathMatcher: path-matcher-one
   pathMatchers:
    - defaultService: my-project/global/default-service
     name: path-matcher-one
     pathRules:
      - paths:
        - /payments/
        service: my-project/global/default-service
        requestMirrorPolicy:
          backendService: myproject/global/payments-test-bes

Quitar una vinculación de servicio de un servicio backend

Para quitar una vinculación de servicio del servicio de backend, pasa una lista nueva de vinculaciones de servicio al comando gcloud compute backend-services update. La nueva lista no debe incluir la vinculación de servicio que quieras eliminar:

Para quitar todas las vinculaciones de servicio, define la marca --no-service-bindings.
Para quitar una o varias vinculaciones de servicio, pasa una nueva lista de vinculaciones de servicio que omita las vinculaciones de servicio que quieras quitar a la marca --service-bindings.

Añadir o quitar enlaces de servicio

El comando bind-service añade una vinculación de servicio al conjunto de vinculaciones de servicio del servicio backend.

gcloud compute backend-services bind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

El comando unbind-service elimina una vinculación de servicio del conjunto de vinculaciones de servicio del servicio de backend.

gcloud compute backend-services unbind-service BACKEND_SERVICE_NAME \
  --service-binding-name SERVICE_BINDING_URL \
  --global

Los comandos bind-service y unbind-service son construcciones de Google Cloud CLI. No son estructuras a nivel de API.

Siguientes pasos

Para obtener información sobre la observabilidad con esta integración, consulta Observabilidad y depuración con Service Directory.