Configurer Cloud Service Mesh pour Cloud Run

Cette page explique comment configurer Cloud Service Mesh pour qu'il s'exécute sur une gamme d'infrastructures IT pour les services Cloud Run.

Cloud Service Mesh vous permet d'activer le maillage fonctionnalités avancées de gestion du trafic comme la répartition pondérée du trafic et l'équilibrage de charge global, ainsi que règles d'observabilité et de sécurité pour le trafic provenant d'une instance Cloud Run service vers un autre. Il vous offre également une solution de plan de données entièrement gérée qui élimine la charge opérationnelle liée à la maintenance de vos propres sidecars de maillage de services.

Avant de commencer

  1. Connaître Cloud Service Mesh

  2. Définissez votre projet :

    gcloud config set core/project PROJECT_ID

  3. Dans la console Google Cloud, activez les API suivantes pour votre projet :

  4. Mettez à jour les composants gcloud vers la dernière version (488.0.0 ou ultérieure):

    gcloud components update

Rôles requis

Obtenir les autorisations nécessaires pour configurer et déployer Cloud Run demandez à votre administrateur de vous accorder les autorisations IAM suivantes rôles:

Le compte de service du client Cloud Run doit également disposer du rôles suivants:

Pour obtenir la liste des rôles et des autorisations IAM associés à Cloud Run, consultez les sections Rôles IAM Cloud Run et Autorisations IAM Cloud Run. Si votre service Cloud Run communique avec les API Google Cloud, telles que les bibliothèques clientes Cloud, consultez le guide de configuration de l'identité du service. Pour en savoir plus sur l'attribution de rôles, consultez les sections Autorisations de déploiement et Gérer les accès.

Appels entre services Cloud Run à l'aide de Cloud Service Mesh

Cloud Run utilise le maillage de services API de routage des services. Ces API permettent à un service Cloud Run d'appeler d'autres services Cloud Run à l'aide d'une URL personnalisée plutôt que de l'URL run.app fournie. De plus, Cloud Run s'authentifie automatiquement auprès du service Cloud Run de destination afin que vous n'ayez pas à configurer votre propre authentification pour joindre des identifiants de requête à d'autres services Cloud Run.

Pour appeler un service Cloud Run à partir d'un autre à l'aide de Cloud Service Mesh, procédez comme suit :

  1. Configurer un Cloud Service Mesh
  2. Configurer Cloud DNS
  3. Créer le service Cloud Run de destination
  4. Créer le NEG sans serveur
  5. Créer le service Cloud Run client
  6. Appeler le service à partir du client maillé

Configurer un maillage de services Cloud

  1. Pour créer un routage de service à l'aide de l'URL par défaut, enregistrez la spécification Mesh dans un fichier nommé mesh.yaml :

    name: MESH_NAME

    Remplacez MESH_NAME par le nom de la ressource de maillage.

  2. Importez la ressource Mesh à partir de la spécification en exécutant la commande suivante :

    gcloud network-services meshes import MESH_NAME \
  --source=mesh.yaml \
  --location=global

    Remplacez MESH_NAME par le nom de la ressource de maillage.

Configurer Cloud DNS

Vous pouvez ignorer la configuration de Cloud DNS et passer à la section suivante si vous utilisez un point de terminaison Private Service Connect avec l'adresse URL run.app complète comme nom d'hôte, car seules les adresses IP privées sont capturées.

Lorsqu'un client de réseau maillé appelle le service de destination, le nom d'hôte utilisées dans la requête doivent pouvoir être résolues via DNS. Toute adresse IP RFC 1918 valide est acceptable, car le sidecar capture tout le trafic IP vers ces plages d'adresses IP et le redirige de manière appropriée.

L'exemple suivant montre comment créer une entrée * avec caractère générique dans Cloud DNS qui se résout en une seule adresse IP. Si vous ne souhaitez pas utiliser Zone Cloud DNS, créer une entrée Cloud DNS pour chaque nom d'hôte correspondant aux services Cloud Run que vous souhaitez adressables depuis le réseau maillé.

  • Pour créer un enregistrement Cloud DNS dans une zone exclusive, exécutez les commandes suivantes :

    1. Créer une zone DNS gérée privée dans Cloud DNS pour un service réseau maillé.

      gcloud dns managed-zones create MESH_NAME \
--description="Domain for DOMAIN_NAME service mesh routes" \
--dns-name=DOMAIN_NAME. \
--networks=VPC_NETWORK_NAME \
--visibility=private

    2. Créez un enregistrement DNS dans la zone gérée privée que vous venez de créer. Assurez-vous que l'adresse IP 10.0.0.1 n'est pas utilisée.

      gcloud dns record-sets create "*.DOMAIN_NAME." \
--type=A \
--zone="MESH_NAME" \
--rrdatas=10.0.0.1 \
--ttl=3600

      Remplacez les éléments suivants :

      • DOMAIN_NAME: nom du domaine DNS.
      • MESH_NAME : nom de la ressource de maillage.
      • VPC_NETWORK_NAME : nom de votre réseau VPC (par exemple, "default").

Accéder aux services internes avec Cloud Service Mesh

Cloud Run vous permet de limiter le trafic réseau entrant « interne ». Si cette restriction d'entrée est activée pour votre service, le trafic qui transite depuis votre réseau maillé via le réseau de cloud privé virtuel peut être défini comme "interne" lorsque vous activez un chemin d'accès à Cloud Run.

Pour accéder aux services internes avec Cloud Service Mesh, utilisez l'une des méthodes suivantes :

Créer le service Cloud Run de destination

Notez que la destination Cloud Run ne peut pas avoir URL par défaut désactivée

  1. Déployez un service Cloud Run nouveau ou existant:

    gcloud run deploy DESTINATION_SERVICE_NAME \
--no-allow-unauthenticated \
--region=REGION \
--image=IMAGE_URL

    Remplacez les éléments suivants :

    • DESTINATION_SERVICE_NAME: nom du service Cloud Run de destination.
    • REGION : nom de la région.
    • IMAGE_URL: référence à l'image de conteneur. comme us-docker.pkg.dev/cloudrun/container/hello:latest.

Créer le groupe de points de terminaison du réseau (NEG) sans serveur

  1. Créez le NEG de destination en exécutant la commande suivante:

    gcloud compute network-endpoint-groups create DESTINATION_SERVICE_NAME-neg \
--region=REGION \
--network-endpoint-type=serverless \
--cloud-run-service=DESTINATION_SERVICE_NAME

    Remplacez les éléments suivants :

    • REGION : nom de la région.
    • DESTINATION_SERVICE_NAME : nom du service Cloud Run de destination.

  2. Créez un service de backend interne autogéré qui référence le un NEG sans serveur.

    1. Créez le service de backend :

      gcloud compute backend-services create DESTINATION_SERVICE_NAME-REGION \
--global \
--load-balancing-scheme=INTERNAL_SELF_MANAGED

      Remplacez DESTINATION_SERVICE_NAME par le nom du service de destination et REGION par le nom de la région.

    2. Ajoutez le backend sans serveur au service de backend :

      gcloud compute backend-services add-backend DESTINATION_SERVICE_NAME-REGION \
--global \
--network-endpoint-group=DESTINATION_SERVICE_NAME-neg \
--network-endpoint-group-region=REGION

      Remplacez DESTINATION_SERVICE_NAME par le nom du service de destination et REGION par le nom de la région.

  3. Créez une route HTTP qui référence le service de backend.

    La ressource et les services Mesh sont configurés. Connectez-les à une ressource HTTPRoute qui associe un nom d'hôte à un service de backend.

    1. Créez la spécification HTTPRoute et enregistrez-la dans un fichier appelé http_route.yaml:

      name: "DESTINATION_SERVICE_NAME-route"
hostnames:
- "DESTINATION_SERVICE_NAME.DOMAIN_NAME"
meshes:
- "projects/PROJECT_ID/locations/global/meshes/MESH_NAME"
rules:
- action:
   destinations:
   - serviceName: "projects/PROJECT_ID/locations/global/backendServices/DESTINATION_SERVICE_NAME-REGION"

      Définissez les noms d'hôte sur les noms que vous souhaitez utiliser pour adresser le service. Tous les clients du même maillage de services peuvent appeler ce service à l'aide de l'URL http://<HOSTNAME>, quelle que soit la région et le projet de l'appelant. Si vous avez configuré Cloud DNS pour utiliser une adresse IP privée, le nom d'hôte de la route peut également être l'adresse URL run.app complète. Dans ce cas, vous pouvez ignorer l'étape de configuration de Cloud DNS.

      Remplacez les éléments suivants :

      • DESTINATION_SERVICE_NAME : nom du service Cloud Run de destination.
      • DOMAIN_NAME: nom du domaine DNS.
      • PROJECT_ID : ID du projet.
      • MESH_NAME : nom du maillage.
      • REGION : nom de la région.

    2. Créez la ressource HTTPRoute en utilisant la spécification indiquée dans la section Fichier http_route.yaml:

      gcloud network-services http-routes import DESTINATION_SERVICE_NAME-route \
--source=http_route.yaml \
--location=global

    3. Attribuez le rôle Demandeur Cloud Run (roles/iam.invoker) au service de destination Cloud Run en exécutant la commande suivante :

      gcloud run services add-iam-policy-binding DESTINATION_SERVICE_NAME \
--region REGION \
--member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--role=roles/run.invoker

      Remplacez les éléments suivants :

      • DESTINATION_SERVICE_NAME: nom du service Cloud Run de destination.
      • REGION : nom de la région.
      • PROJECT_NUMBER: numéro du projet.

Créer le service Cloud Run client

La création d'un service Cloud Run client crée un sidecar Envoy dont les ressources sont liées à votre QPS et à la taille totale de la configuration. La plupart des l'utilisation du processeur est inférieure à 1 % de celle d'un processeur virtuel et l'utilisation de la mémoire est inférieure à 50 Mo.

Vous devez disposer d'un accès de sortie réseau à un réseau cloud privé virtuel.

  • Pour créer le service client à des fins de test, déployez l'application Fortio dans Cloud Run pour autoriser le transfert du trafic vers des routes HTTP:

    gcloud beta run deploy CLIENT_SERVICE_NAME \
--region=REGION \
--image=fortio/fortio \
--network=VPC_NETWORK_NAME \
--subnet=SUBNET_NAME \
--mesh="projects/PROJECT_ID/locations/global/meshes/MESH_NAME"

    Remplacez les éléments suivants :

    • CLIENT_SERVICE_NAME: nom du le service client Cloud Run.
    • REGION : nom de votre région.
    • VPC_NETWORK_NAME: nom de votre sur le réseau VPC, Exemple : "default".
    • SUBNET_NAME : nom de votre sous-réseau (par exemple, "default").
    • PROJECT_ID : par l'ID du projet.
    • MESH_NAME : nom de la ressource de maillage.

Appeler le service depuis un client maillé

Pour transférer une requête vers la route de destination à l'aide de l'application de test fortio de la section précédente Créer un service client :

  1. Récupérez l'URL du service client Cloud Run que vous créé en exécutant la commande suivante:

    TEST_SERVICE_URL=$(gcloud run services describe CLIENT_SERVICE_NAME \
--region=REGION --format="value(status.url)" \
--project=PROJECT_ID)

    Remplacez les éléments suivants :

    • CLIENT_SERVICE_NAME: nom du client service Cloud Run.
    • REGION : nom de votre région.
    • PROJECT_ID : par l'ID du projet.

  2. Utilisez la commande curl pour envoyer une requête à l'itinéraire de destination du point de terminaison Fortio de l'étape précédente :

    curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" "$TEST_SERVICE_URL/fortio/fetch/DESTINATION_SERVICE_NAME.DOMAIN_NAME"

    Remplacez les éléments suivants :

    • DESTINATION_SERVICE_NAME : nom du service Cloud Run de destination.
    • DOMAIN_NAME : nom du domaine DNS.

Appeler le backend Compute Engine depuis Cloud Run

Pour déployer un routage de service Compute Engine et Cloud Service Mesh à l'aide de groupes d'instances gérés en tant que backends, configurez le serveur HTTP basé sur Compute Engine dans Cloud Service Mesh. Cela permet aux clients Cloud Run d'utiliser cette route du service de backend vers envoyer des requêtes directement aux instances Compute Engine.

Étapes suivantes