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 des fonctionnalités avancées de gestion du trafic telles que la répartition du trafic pondérée et l'équilibrage de charge global, ainsi que des règles d'observabilité et de sécurité pour le trafic d'un service Cloud Run à 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. Avoir des connaissances sur 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 version ultérieure):

    gcloud components update

Rôles requis

Pour obtenir les autorisations nécessaires pour configurer et déployer des services Cloud Run, demandez à votre administrateur de vous accorder les rôles IAM suivants:

Le compte de service du client Cloud Run doit également disposer des 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 les API de routage de services de Cloud Service Mesh. 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 de réseau maillé

Configurer un Cloud Service Mesh

  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é dans la requête doit pouvoir être résolu via le 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 * générique dans la zone Cloud DNS qui se résout en une seule adresse IP. Si vous ne souhaitez pas utiliser de zone Cloud DNS exclusive, créez une entrée Cloud DNS pour chaque nom d'hôte correspondant aux services Cloud Run que vous souhaitez pouvoir adresser à partir du réseau maillé.

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

    1. Créez une zone DNS gérée privée dans Cloud DNS pour un réseau maillé de services.

      gcloud dns managed-zones create MESH_NAME \
      --description="Domain for DOMAIN_NAME service mesh routes" \
      --dns-name=DOMAIN_NAME. \
      --network=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 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 l'URL par défaut ne peut pas être désactivée pour la destination Cloud Run.

  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 du conteneur, par exemple us-docker.pkg.dev/cloudrun/container/hello:latest.

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

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

    gcloud compute network-endpoint-groups create destination-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 fait référence au 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-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 fait référence au 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 nommé 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 à l'aide de la spécification du 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 RPS et à la taille totale de la configuration. La plupart du temps, l'utilisation du processeur est inférieure à 1 % d'un vCPU et l'utilisation de la mémoire est inférieure à 50 Mo.

Vous devez disposer d'un accès sortant au réseau cloud privé virtuel.

  • Pour créer le service client à des fins de test, déployez l'application fortio dans Cloud Run afin d'autoriser le transfert du trafic vers les 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 service Cloud Run client.
    • REGION : nom de votre région.
    • VPC_NETWORK_NAME: nom de votre réseau VPC (par 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 un service à partir d'un client de maillage

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 avez 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 service Cloud Run client.
    • 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 ce routage de service de backend pour envoyer des requêtes directement aux instances Compute Engine.

Étapes suivantes