Configurer un équilibreur de charge d'application interne interrégional avec Cloud Run

Ce document vous explique comment déployer un équilibreur de charge d'application interne interrégional avec Cloud Run. Pour ce faire, vous devez utiliser un backend de NEG sans serveur pour l'équilibreur de charge.

Les NEG sans serveur vous permettent d'utiliser les services Cloud Run avec votre équilibreur de charge. Une fois que vous avez configuré un équilibreur de charge avec le backend du NEG sans serveur, les requêtes envoyées à l'équilibreur de charge sont acheminées vers le backend Cloud Run.

L'équilibrage de charge interrégional assure une redondance. Ainsi, si une région est inaccessible, le trafic est automatiquement redirigé vers une autre région. Selon l'emplacement d'Envoy, le trafic proxy est distribué aux services Cloud Run comme suit :

  • Si les services Cloud Run multirégionaux sont configurés dans la même région qu'Envoy, il est préférable d'utiliser le NEG situé dans la même région qu'Envoy. Le trafic n'est envoyé à la région de basculement que si la détection des anomalies est activée et que le NEG local n'est pas opérationnel.
  • Si les services Cloud Run multirégionaux ne sont pas configurés dans la même région qu'Envoy, le trafic est réparti uniformément entre tous les NEG. Les NEG situés plus près ne sont pas recommandés.
  • Si Identity-Aware Proxy est activé, un seul NEG sans serveur est accepté. Vous pouvez toutefois configurer d'autres services Cloud Run, mais l'équilibreur de charge ne leur envoie pas de trafic.

Avant de commencer

Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Déployer un service Cloud Run

Dans les instructions de cette page, nous partons du principe que vous disposez déjà d'un service Cloud Run.

Pour l'exemple de cette page, vous pouvez utiliser l'un des guides de démarrage rapide de Cloud Run pour déployer un service Cloud Run.

Pour empêcher l'accès au service Cloud Run depuis Internet, restreignez l'entrée à internal. Le trafic provenant de l'équilibreur de charge d'application interne est considéré comme du trafic interne.

En plaçant le service Cloud Run dans plusieurs régions, vous évitez les défaillances dans une seule région. Pour déployer le service Cloud Run dans les régions REGION_A et REGION_B, exécutez les commandes suivantes :

gcloud

gcloud run deploy CLOUD_RUN_SERVICE_NAMEA \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_A \
   --image=IMAGE_URLA

gcloud run deploy CLOUD_RUN_SERVICE_NAMEB \
   --platform=managed \
   --allow-unauthenticated \
   --ingress=internal \
   --region=REGION_B \
   --image=IMAGE_URLB

Notez le nom du service que vous créez. Enfin, le reste de la page vous explique comment configurer un équilibreur de charge qui dirige les requêtes vers ce service.

Configurer une ressource de certificat SSL

Créez une ressource de certificat SSL du gestionnaire de certificats comme suit :

Nous vous recommandons d'utiliser un certificat géré par Google.

Autorisations

Pour suivre ce guide, vous devez savoir comment créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :

Tâche Rôle requis
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge Administrateur de réseaux Compute
Ajouter et supprimer des règles de pare-feu Administrateur de sécurité de Compute
Créer des instances Administrateur d'instances Compute

Pour en savoir plus, consultez les guides suivants :

Vue d'ensemble de la configuration

Vous pouvez configurer l'équilibreur de charge d'application interne interrégional comme décrit dans le schéma suivant :

Équilibreur de charge d'application interne interrégional avec un déploiement Cloud Run.
Équilibreur de charge d'application interne interrégional avec un déploiement Cloud Run (cliquez pour agrandir).

Comme le montre le schéma, cet exemple crée un équilibreur de charge d'application interne interrégional dans un réseau VPC, avec un service de backend et deux déploiements Cloud Run dans les régions REGION_A et REGION_B.

La configuration de l'équilibreur de charge d'application interne interrégional est décrite comme suit :

  1. Un réseau VPC avec les sous-réseaux suivants :

    • Le sous-réseau SUBNET_A et un sous-réseau proxy réservé dans REGION_A.
    • Le sous-réseau SUBNET_B et un sous-réseau proxy réservé dans REGION_B.

    Vous devez créer des sous-réseaux proxy réservés dans chaque région du réseau VPC dans lequel vous utilisez des équilibreurs de charge d'application internes interrégionaux. Le sous-réseau proxy réservé de la région est partagé entre tous les équilibreurs de charge d'application internes interrégionaux dans la région. Les adresses sources des paquets envoyés depuis l'équilibreur de charge vers les backends de votre service sont attribuées à partir du sous-réseau proxy réservé. Dans cet exemple, le sous-réseau proxy réservé de la région REGION_A possède une plage d'adresses IP principale de 10.129.0.0/23 et, pour REGION_B, une plage d'adresses IP principale de 10.130.0.0/23 utilisant la taille de sous-réseau recommandée.

  2. Une règle de pare-feu qui autorise les flux de trafic de sous-réseau proxy réservé dans votre réseau. Cela signifie ajouter une règle qui autorise le trafic sur le port TCP 80, 443 et 8080 à partir de 10.129.0.0/23 et 10.130.0.0/23 (la plage des sous-réseaux proxy réservés dans cet exemple).

  3. Une autre règle de pare-feu pour les vérifications d'état.

  4. Une configuration haute disponibilité comprenant des backends sans serveur pour les déploiements Cloud Run dans les régions REGION_A et REGION_B. Si les backends d'une région sont indisponibles, le trafic bascule vers l'autre région.

  5. Un service de backend global surveillant l'utilisation et l'état des backends. Veillez à activer la détection des anomalies sur le service de backend.

  6. Un mappage d'URL global qui analyse l'URL des requêtes et les transfère à des services de backend spécifiques en fonction de l'hôte et du chemin d'accès de l'URL de la requête.

  7. Un proxy HTTP ou HTTPS global cible qui reçoit la requête de l'utilisateur et la transfère au mappage d'URL. Pour le protocole HTTPS, configurez une ressource de certificat SSL régional. Le proxy cible utilise le certificat SSL pour déchiffrer le trafic SSL si vous configurez l'équilibrage de charge HTTPS. Le proxy cible peut transférer le trafic vers vos instances à l'aide du protocole HTTP ou HTTPS.

  8. Les règles de transfert globales, qui disposent de l'adresse IP interne de votre équilibreur de charge, pour transmettre chaque requête entrante au proxy cible.

    L'adresse IP interne associée à la règle de transfert peut provenir de n'importe quel sous-réseau du même réseau et de la même région. Veuillez noter les conditions suivantes :

    • L'adresse IP peut (mais ne doit pas nécessairement) provenir du même sous-réseau que les groupes d'instances backend.
    • L'adresse IP ne doit pas provenir d'un sous-réseau proxy réservé dont l'option --purpose est définie sur GLOBAL_MANAGED_PROXY.
    • Si vous souhaitez utiliser la même adresse IP interne avec plusieurs règles de transfert, définissez l'option d'adresse IP --purpose sur SHARED_LOADBALANCER_VIP.

  9. Facultatif : Configurez des règles de routage DNS de type GEO pour acheminer le trafic client vers l'adresse IP virtuelle de l'équilibreur de charge dans la région la plus proche du client.

Configurer le réseau et les sous-réseaux

Au sein du réseau VPC, configurez un sous-réseau dans chaque région où vos backends sont configurés. En outre, configurez un sous-réseau proxy réservé (proxy-only-subnet) dans chaque région où vous souhaitez configurer l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et les sous-réseaux suivants :

  • Réseau : le réseau est un réseau VPC en mode personnalisé nommé NETWORK.

  • Sous-réseaux pour les backends. Un sous-réseau nommé SUBNET_A dans la région REGION_A utilise 10.1.2.0/24 pour sa plage d'adresses IP principale. Le sous-réseau nommé SUBNET_A dans la région REGION_B utilise 10.1.3.0/24 pour sa plage d'adresses IP principale.

  • Sous-réseau pour les proxys. Un sous-réseau nommé PROXY_SN_A dans la région REGION_A utilise 10.129.0.0/23 pour sa plage d'adresses IP principale. Un sous-réseau nommé PROXY_SN_B dans la région REGION_B utilise 10.130.0.0/23 pour sa plage d'adresses IP principale.

Les équilibreurs de charge d'application internes interrégionaux sont accessibles depuis n'importe quelle région du VPC. Ainsi, les clients de n'importe quelle région peuvent accéder aux backends de votre équilibreur de charge à l'échelle mondiale.

Configurer les sous-réseaux backend

Console

  1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.

  3. Saisissez un Nom pour le réseau.

  4. Dans la section Sous-réseaux, définissez le Mode de création du sous-réseau sur Personnalisé.

  5. Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Renseignez un Nom pour le sous-réseau.
    • Sélectionnez une région : REGION_A.
    • Saisissez une plage d'adresses IP : 10.1.2.0/24

  6. Cliquez sur OK.

  7. Cliquez sur Ajouter un sous-réseau.

  8. Créez un sous-réseau pour les backends de l'équilibreur de charge. Dans la section Nouveau sous-réseau, saisissez les informations suivantes :

    • Renseignez un Nom pour le sous-réseau.
    • Sélectionnez une région : REGION_B.
    • Saisissez une plage d'adresses IP : 10.1.3.0/24

  9. Cliquez sur OK.

  10. Cliquez sur Créer.

gcloud

  1. Créez le réseau VPC personnalisé à l'aide de la commande gcloud compute networks create :

    gcloud compute networks create NETWORK --subnet-mode=custom

  2. Créez un sous-réseau dans le réseau NETWORK de la région REGION_A à l'aide de la commande gcloud compute networks subnets create :

    gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

  3. Créez un sous-réseau dans le réseau NETWORK de la région REGION_B à l'aide de la commande gcloud compute networks subnets create :

    gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

API

Envoyez une requête POST à la méthode networks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Envoyez une requête POST à la méthode subnetworks.insert. Remplacez PROJECT_ID par l'ID du projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configurer le sous-réseau proxy réservé

Un sous-réseau proxy réservé fournit un ensemble d'adresses IP utilisées par Google Cloud pour exécuter des proxys Envoy en votre nom. Les proxys interrompent les connexions du client et en créent vers les backends.

Ce sous-réseau proxy réservé est utilisé par tous les équilibreurs de charge régionaux basés sur Envoy dans la même région que le réseau VPC. Il ne peut y avoir qu'un seul sous-réseau proxy réservé actif pour une utilisation donnée, par région et par réseau.

Console

Si vous utilisez la console Google Cloud, vous pouvez créer le sous-réseau proxy réservé ultérieurement sur la page Équilibrage de charge.

Si vous souhaitez créer le sous-réseau proxy réservé maintenant, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur le nom du réseau VPC.
  3. Dans l'onglet Sous-réseaux, cliquez sur Ajouter un sous-réseau.
  4. Saisissez un Nom pour le sous-réseau proxy réservé.
  5. Dans la liste Région, sélectionnez REGION_A.
  6. Dans la liste Objectif, sélectionnez Proxy géré interrégional.
  7. Dans le champ Plage d'adresses IP, saisissez 10.129.0.0/23.
  8. Cliquez sur Ajouter.

Créez le sous-réseau proxy réservé dans REGION_B.

  1. Cliquez sur Ajouter un sous-réseau.
  2. Saisissez un Nom pour le sous-réseau proxy réservé.
  3. Dans la liste Région, sélectionnez REGION_B.
  4. Dans la liste Objectif, sélectionnez Proxy géré interrégional.
  5. Dans le champ Plage d'adresses IP, saisissez 10.130.0.0/23.
  6. Cliquez sur Ajouter.

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

API

Créez les sous-réseaux proxy réservés avec la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": "PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Créer les NEG sans serveur

  1. Créez un NEG sans serveur pour votre service Cloud Run :

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-a \
   --region=REGION_A \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEA

    gcloud compute network-endpoint-groups create gl7ilb-serverless-neg-b \
   --region=REGION_B \
   --network-endpoint-type=serverless  \
   --cloud-run-service=CLOUD_RUN_SERVICE_NAMEB

Configurer l'équilibreur de charge

Le trafic provenant de l'équilibreur de charge vers les backends NEG sans serveur utilise des routes spéciales définies en dehors de votre VPC, qui ne sont pas soumises à des règles de pare-feu. Par conséquent, si votre équilibreur de charge ne dispose que de backends de NEG sans serveur, vous n'avez pas besoin de créer de règles de pare-feu pour autoriser le trafic provenant du sous-réseau proxy réservé vers le backend sans serveur.

Console

Démarrer la configuration

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer un équilibreur de charge.
  3. Dans le champ Type d'équilibreur de charge, sélectionnez Équilibreur de charge d'application (HTTP/HTTPS), puis cliquez sur Suivant.
  4. Pour Public ou interne, sélectionnez Interne, puis cliquez sur Suivant.
  5. Pour Déploiement interrégional ou régional, sélectionnez Recommandé pour les charges de travail interrégionales, puis cliquez sur Suivant.
  6. Cliquez sur Configurer.

Configuration de base

  1. Saisissez un Nom pour l'équilibreur de charge.
  2. Pour Réseau, sélectionnez NETWORK.

Configurer l'interface avec deux règles de transfert

Pour HTTP :

  1. Cliquez sur Configuration de l'interface.
    1. Saisissez un Nom pour la règle de transfert.
    2. Dans la liste Région du sous-réseau, sélectionnez REGION_A.

      Réserver un sous-réseau proxy réservé

    3. Dans la liste Sous-réseau, sélectionnez SUBNET_A.
    4. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.2.99.
      • Sélectionnez Réserver.
  2. Cliquez sur OK.
  3. Pour ajouter la deuxième règle de transfert, cliquez sur Ajouter une adresse IP et un port d'interface.
    1. Saisissez un Nom pour la règle de transfert.
    2. Dans la liste Région du sous-réseau, sélectionnez REGION_B.

      Réserver un sous-réseau proxy réservé

    3. Dans la liste Sous-réseau, sélectionnez SUBNET_B.
    4. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
      • Sélectionnez Réserver.
  4. Cliquez sur OK.

Pour HTTPS :

Si vous utilisez HTTPS entre le client et l'équilibreur de charge, vous devez disposer d'une ou de plusieurs ressources de certificat SSL pour configurer le proxy. Pour créer un certificat all-regions géré par Google, consultez la documentation suivante :

Après avoir créé le certificat géré par Google, associez-le directement au proxy cible. Les mappages de certificats ne sont pas compatibles avec les équilibreurs de charge d'application internes interrégionaux.

Pour créer un certificat autogéré all-regions, consultez la documentation suivante : Déployer un certificat régional autogéré.

  1. Cliquez sur Configuration de l'interface.
    1. Saisissez un Nom pour la règle de transfert.
    2. Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
    3. Assurez-vous que le Port est défini sur la valeur 443.
    4. Dans la liste Région du sous-réseau, sélectionnez REGION_A.

      Réserver un sous-réseau proxy réservé

    5. Dans la liste Sous-réseau, sélectionnez SUBNET_A.
    6. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
      • Sélectionnez Réserver.
    7. Dans la section Add certificate (Ajouter un certificat), sélectionnez le certificat.
    8. Facultatif : Pour ajouter des certificats en plus du certificat SSL principal :
      1. Cliquez sur Ajouter un certificat.
      2. Sélectionnez le certificat dans la liste.
    9. Sélectionnez une règle SSL dans la liste Règle SSL. Si vous n'avez pas créé de règle SSL, une règle SSL Google Cloud par défaut est appliquée.
    10. Cliquez sur OK.

    Ajoutez la deuxième configuration d'interface :

    1. Indiquez un nom pour la configuration de l'interface.
    2. Dans le champ Protocole, sélectionnez HTTPS (includes HTTP/2).
    3. Assurez-vous que le Port est défini sur la valeur 443.
    4. Dans la liste Région du sous-réseau, sélectionnez REGION_B.

      Réserver un sous-réseau proxy réservé

    5. Dans la liste Sous-réseau, sélectionnez SUBNET_B.
    6. Dans la liste Adresse IP, cliquez sur Créer une adresse IP. La page Réserver une adresse IP statique interne s'affiche.
      • Saisissez un Nom pour l'adresse IP statique.
      • Dans la section Adresse IP statique, sélectionnez Laissez-moi choisir.
      • Dans le champ Adresse IP personnalisée, saisissez 10.1.3.99.
      • Sélectionnez Réserver.
    7. Dans la section Add certificate (Ajouter un certificat), sélectionnez le certificat.
    8. Facultatif : Pour ajouter des certificats en plus du certificat SSL principal :
      1. Cliquez sur Ajouter un certificat.
      2. Sélectionnez le certificat dans la liste.
    9. Sélectionnez une règle SSL dans la liste Règle SSL. Si vous n'avez pas créé de règle SSL, une règle SSL Google Cloud par défaut est appliquée.
    10. Cliquez sur OK.
    Configurer le service de backend
    1. Cliquez sur Configuration du backend.
    2. Dans la liste Créer ou sélectionner des services de backend, cliquez sur Créer un service de backend.
    3. Saisissez un Nom pour le service de backend.
    4. Pour Protocole, sélectionnez HTTP.
    5. Pour le Port nommé, saisissez http.
    6. Dans la liste Type de backend, sélectionnez Groupe de points de terminaison du réseau sans serveur.
    7. Dans la section Nouveau backend :
      • Dans la liste Groupe de points de terminaison du réseau sans serveur, sélectionnez gl7ilb-serverless-neg-a.
      • Cliquez sur OK.
      • Pour ajouter un autre backend, cliquez sur Ajouter un backend.
      • Dans la liste Groupe de points de terminaison du réseau sans serveur, sélectionnez gl7ilb-serverless-neg-b.
      • Cliquez sur OK.

    Configurer les règles de routage

    1. Cliquez sur Règles de routage.
    2. Sous Mode, sélectionnez Règle d'hôte et de chemin d'accès simple.
    3. Assurez-vous qu'il n'existe qu'un seul service de backend pour tous les hôtes et chemins sans correspondance.

    Vérifier la configuration

    1. Cliquez sur Vérifier et finaliser.
    2. Vérifiez les paramètres de configuration de votre équilibreur de charge.
    3. Cliquez sur Créer.

gcloud

  1. Définissez le service de backend avec la commande gcloud compute backend-services create.

    gcloud compute backend-services create gil7-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --global

  2. Ajoutez des backends au service de backend à l'aide de la commande gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-a \
  --network-endpoint-group-region=REGION_A \
  --global

    gcloud compute backend-services add-backend gil7-backend-service \
  --network-endpoint-group=gl7ilb-serverless-neg-b \
  --network-endpoint-group-region=REGION_B \
  --global

  3. Créez le mappage d'URL à l'aide de la commande gcloud compute url-maps create.

    gcloud compute url-maps create gil7-map \
  --default-service=gil7-backend-service \
  --global

  4. Créez le proxy cible.

    Pour HTTP :

    Créez le proxy cible à l'aide de la commande gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create gil7-http-proxy \
  --url-map=gil7-map \
  --global

    Pour HTTPS :

    Pour créer un certificat géré par Google, consultez la documentation suivante :

    Après avoir créé le certificat géré par Google, associez-le directement au proxy cible. Les mappages de certificats ne sont pas compatibles avec les équilibreurs de charge d'application internes interrégionaux.

    Pour créer un certificat autogéré, consultez la documentation suivante :

    Attribuez vos chemins de fichiers à des noms de variables.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE

    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE

    Créez un certificat SSL toutes régions à l'aide de la commande gcloud certificate-manager certificates create.

    gcloud certificate-manager certificates create gilb-certificate \
  --private-key-file=$LB_PRIVATE_KEY \
  --certificate-file=$LB_CERT \
  –-scope=all-regions

    Utilisez le certificat SSL pour créer le proxy cible à l'aide de la commande gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create gil7-https-proxy \
  --url-map=gil7-map \
  --certificate-manager-certificates=gilb-certificate

  5. Créez deux règles de transfert, l'une avec une adresse IP virtuelle 10.1.2.99 dans la région REGION_B et l'autre avec une adresse IP virtuelle 10.1.3.99 dans la région REGION_A.

    Pour les réseaux personnalisés, vous devez faire référence au sous-réseau dans la règle de transfert. Notez qu'il s'agit du sous-réseau de l'instance de machine virtuelle (VM) et non du sous-réseau proxy.

    Pour HTTP :

    Utilisez la commande gcloud compute forwarding-rules create avec les options appropriées.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-http-proxy=gil7-http-proxy \
  --global

    Pour HTTPS :

    Créez la règle de transfert à l'aide de la commande gcloud compute forwarding-rules create avec les options appropriées.

    gcloud compute forwarding-rules create gil7-forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --address=10.1.3.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

    gcloud compute forwarding-rules create gil7-forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --address=10.1.2.99 \
  --ports=443 \
  --target-https-proxy=gil7-https-proxy \
  --global

API

Créez le service de backend global en envoyant une requête POST à la méthode backendServices.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gil7-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7ilb_serverless_negwest",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7ilb_serverless_negeast",
  }
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Créez le mappage d'URL en envoyant une requête POST à la méthode urlMaps.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/gil7-backend-service"
}

Pour HTTP :

Créez le proxy HTTP cible en envoyant une requête POST à la méthode targetHttpProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

Créez la règle de transfert en envoyant une requête POST à la méthode globalforwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Pour HTTPS :

Lisez les fichiers de certificat et de clé privée, puis créez le certificat SSL. L'exemple suivant montre comment effectuer cette opération avec Python.

Créez le proxy HTTPS cible en envoyant une requête POST à la méthode targetHttpsProxies.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetHttpsProxy

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Créez la règle de transfert en envoyant une requête POST à la méthode globalForwardingRules.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7-forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Tester l'équilibreur de charge

Maintenant que le service d'équilibrage de charge est en cours d'exécution, vous pouvez envoyer le trafic vers la règle de transfert et observer la répartition du trafic entre les différentes instances.

Configurer la règle de pare-feu

Cet exemple nécessite la règle de pare-feu fw-allow-ssh pour la VM cliente de test. fw-allow-ssh est une règle d'entrée applicable à la VM cliente de test et qui autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh.

gcloud

  1. Créez la règle de pare-feu fw-allow-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Créer une instance de VM pour tester la connectivité

  1. Créer une VM cliente :

    gcloud compute instances create l7-ilb-client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

    gcloud compute instances create l7-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

  2. Connectez-vous à chaque instance cliente via SSH.

    gcloud compute ssh l7-ilb-client-a \
   --zone=ZONE_A

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Vérifiez que l'adresse IP diffuse son nom d'hôte.

    • Vérifiez que la VM cliente peut atteindre les deux adresses IP. La commande aboutit et renvoie le nom de la VM de backend qui a diffusé la requête :

      curl 10.1.2.99

      curl 10.1.3.99

      Pour le test HTTPS, remplacez curl par :

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443

      curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443

      L'option -k indique à curl d'ignorer l'étape de validation du certificat.

    • Facultatif : utilisez l'enregistrement DNS configuré pour résoudre l'adresse IP.

      curl service.example.com

Exécuter 100 requêtes et vérifier que leur charge est équilibrée

Pour HTTP :

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Pour HTTPS :

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }

Tester le basculement

  1. Vérifiez le basculement vers les backends de la région REGION_A lorsque les backends de la région REGION_B sont non opérationnels ou inaccessibles. Nous simulerons cela en supprimant tous les backends de REGION_B :

    gcloud compute backend-services remove-backend gil7-backend-service \
   --network-endpoint-group=gl7ilb-serverless-neg-b \
   --network-endpoint-group-zone=ZONE_B

  2. Connectez-vous à une VM cliente dans REGION_B en utilisant SSH.

    gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

  3. Envoyez des requêtes à l'adresse IP faisant l'objet d'un équilibrage de charge dans la région REGION_B. Le résultat de la commande affiche les réponses des VM de backend dans REGION_A :

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Options de configuration supplémentaires

Cette section développe l'exemple de configuration et propose d'autres options de configuration. Toutes les tâches décrites ici sont facultatives. Vous pouvez les exécuter dans n'importe quel ordre.

Utiliser un masque d'URL

Lorsque vous créez un NEG sans serveur, au lieu de sélectionner un service Cloud Run spécifique, vous pouvez utiliser un masque d'URL qui pointe vers plusieurs services diffusés sur le même domaine. Un masque d'URL est un modèle de votre schéma d'URL. Le NEG sans serveur utilise ce modèle pour extraire le nom du service de l'URL de la requête entrante et mapper la requête au service approprié.

Les masques d'URL sont utiles si votre service est mappé sur un domaine personnalisé plutôt que sur l'adresse par défaut que Google Cloud fournit au service déployé. Un masque d'URL vous permet de cibler plusieurs services et versions avec une seule règle, même lorsque votre application utilise un format d'URL personnalisé.

Si vous ne l'avez pas déjà fait, consultez la section Masques d'URL de la présentation des NEG sans serveur.

Créer un masque d'URL

Pour créer un masque d'URL pour votre équilibreur de charge, commencez par l'URL de votre service. Cet exemple utilise un exemple d'application sans serveur s'exécutant sur https://example.com/login. Il s'agit de l'URL où le service login de l'application est diffusé.

  1. Supprimez http ou https de l'URL pour ne garder que example.com/login.
  2. Remplacez le nom du service par un espace réservé pour le masque d'URL.
    • Cloud Run : remplacez le nom du service Cloud Run par l'espace réservé <service>. Si le service Cloud Run est associé à un tag, remplacez celui-ci par l'espace réservé <tag>. Dans cet exemple, le masque d'URL final est example.com/<service>.

  3. Facultatif : Si le nom du service peut être extrait de la partie du chemin d'accès de l'URL, le domaine peut être omis. La partie du chemin d'accès du masque d'URL se distingue par le premier caractère de barre oblique (/). Si le caractère de barre oblique (/) est absent du masque d'URL, le masque est considéré comme représentant uniquement l'hôte. Par conséquent, dans cet exemple, le masque d'URL peut être réduit à /<service>.

    De même, si <service> peut être extrait de la partie hôte de l'URL, vous pouvez omettre complètement le chemin d'accès du masque d'URL.

    Vous pouvez également omettre les composants d'hôte ou de sous-domaine qui précèdent le premier espace réservé, ainsi que les composants de chemin d'accès qui suivent le dernier espace réservé. Dans ce cas, l'espace réservé capture les informations requises pour le composant.

Voici quelques exemples supplémentaires illustrant ces règles :

Ce tableau part du principe que vous disposez d'un domaine personnalisé appelé example.com et que tous vos services Cloud Run sont mappés sur ce domaine.

Service, nom du tag URL du domaine personnalisé Cloud Run Masque d'URL
service : login https://login-home.example.com/web <service>-home.example.com
service : login https://example.com/login/web example.com/<service> ou /<service>
service : login, tag : test https://test.login.example.com/web <tag>.<service>.example.com
service : login, tag : test https://example.com/home/login/test example.com/home/<service>/<tag> ou /home/<service>/<tag>
service : login, tag : test https://test.example.com/home/login/web <tag>.example.com/home/<service>

Créer un NEG sans serveur avec un masque d'URL

Console

Pour un nouvel équilibreur de charge, vous pouvez utiliser le même processus de bout en bout que celui décrit précédemment dans ce document. Au lieu de sélectionner un service spécifique lors de la configuration du service de backend, saisissez un masque d'URL.

Si vous disposez déjà d'un équilibreur de charge, vous pouvez modifier la configuration du backend et faire en sorte que le NEG sans serveur pointe vers un masque d'URL au lieu d'un service spécifique.

Pour ajouter un NEG sans serveur basé sur un masque d'URL à un service de backend existant, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.
    Accéder à la page "Équilibrage de charge"
  2. Cliquez sur le nom de l'équilibreur de charge contenant le service de backend que vous souhaitez modifier.
  3. Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier .
  4. Sur la page Modifier l'équilibreur de charge d'application externe global, cliquez sur Configuration du backend.
  5. Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.
  6. Cliquez sur Ajouter un backend.
  7. Sélectionnez Créer un groupe de points de terminaison du réseau sans serveur.
    1. Dans le champ Nom, saisissez helloworld-serverless-neg.
    2. Sous Région, la région de l'équilibreur de charge s'affiche.
    3. Sous Type de groupe de points de terminaison du réseau sans serveur, Cloud Run est le seul type de groupe de points de terminaison du réseau compatible.
      1. Sélectionnez Utiliser un masque d'URL.
      2. Saisissez un masque d'URL. Pour en savoir plus sur la création d'un masque d'URL, consultez la section sur la création de masque d'URL.
      3. Cliquez sur Créer.

  8. Dans la section Nouveau backend, cliquez sur Terminé.
  9. Cliquez sur Mettre à jour.

gcloud

Pour créer un NEG sans serveur avec un exemple de masque d'URL example.com/<service>, exécutez la commande suivante :

gcloud compute network-endpoint-groups create SERVERLESS_NEG_MASK_NAME \
    --region=REGION \
    --network-endpoint-type=serverless \
    --cloud-run-url-mask="example.com/<service>"

Utiliser la même adresse IP entre plusieurs règles de transfert internes

Pour que plusieurs règles de transfert internes partagent la même adresse IP interne, vous devez réserver l'adresse IP et définir son option --purpose sur SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Si vous devez rediriger le trafic HTTP vers HTTPS, vous pouvez créer deux règles de transfert avec une adresse IP commune. Pour en savoir plus, consultez la page Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge d'application internes.

Configurer des règles de routage DNS

Si vos clients se trouvent dans plusieurs régions, vous pouvez rendre votre équilibreur de charge d'application interne interrégional accessible par des adresses IP virtuelles dans ces régions. Cette configuration multirégionale minimise la latence et les coûts liés au transit sur le réseau. En outre, il vous permet de configurer une solution d'équilibrage de charge mondiale, basée sur DNS, qui offre une résilience en cas de pannes régionales. Pour en savoir plus, consultez la page Gérer les règles de routage DNS et les vérifications d'état.

gcloud

Pour créer une entrée DNS avec une valeur TTL de 30 secondes, utilisez la commande gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Remplacez les éléments suivants :

  • DNS_ENTRY : nom DNS ou nom de domaine du jeu d'enregistrements

    Par exemple : service.example.com

  • REGION_A et REGION_B : régions dans lesquelles vous avez configuré l'équilibreur de charge.

API

Créez l'enregistrement DNS en envoyant une requête POST à la méthode ResourceRecordSets.create. Remplacez PROJECT_ID par l'ID du projet.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Activer la détection des anomalies

Vous pouvez activer la détection des anomalies sur les services de backend globaux pour identifier les NEG sans serveur non opérationnels et réduire le nombre de requêtes envoyées aux NEG sans serveur non opérationnels.

La détection des anomalies est activée sur le service de backend à l'aide de l'une des méthodes suivantes :

  • La méthode consecutiveErrors (outlierDetection.consecutiveErrors), dans laquelle un code d'état HTTP de la série 5xx est considéré comme une erreur.
  • La méthode consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), dans laquelle seuls les codes d'état HTTP 502, 503 et 504 sont considérés comme des erreurs.

Procédez comme suit pour activer la détection des anomalies pour un service de backend existant. Sachez que même après l'activation de la détection des anomalies, certaines requêtes peuvent être envoyées au service non opérationnel et renvoyer un code d'état 5xx aux clients. Pour réduire davantage le taux d'erreur, vous pouvez configurer des valeurs plus agressives pour les paramètres de détection des anomalies. Pour en savoir plus, consultez le champ outlierDetection.

Console

  1. Dans Google Cloud Console, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur le nom de l'équilibreur de charge dont vous souhaitez modifier le service de backend.

  3. Sur la page Détails de l'équilibreur de charge, cliquez sur Modifier.

  4. Sur la page Modifier l'équilibreur de charge d'application interne interrégional, cliquez sur Configuration du backend.

  5. Sur la page Configuration du backend, cliquez sur le bouton Modifier correspondant au service de backend que vous souhaitez modifier.

  6. Faites défiler la page vers le bas et développez la section Configurations avancées.

  7. Dans la section Détection des anomalies, cochez la case Activer.

  8. Cliquez sur Modifier pour configurer la détection des anomalies.

    Vérifiez que les options suivantes sont configurées avec ces valeurs :

    Propriété Valeur
    Erreurs consécutives 5
    Intervalle 1000
    Durée d'éjection de base 30000
    Pourcentage maximal d'éjection 50
    Éjection pour erreurs consécutives 100

    Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus.

  9. Cliquez sur Enregistrer.

  10. Pour mettre à jour le service de backend, cliquez sur Mettre à jour.

  11. Pour mettre à jour l'équilibreur de charge, cliquez sur Mettre à jour sur la page Modifier l'équilibreur de charge d'application interne interrégional.

gcloud

  1. Exportez le service de backend dans un fichier YAML.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

    Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

  2. Modifiez la configuration YAML du service de backend pour ajouter les champs de détection des anomalies, comme indiqué dans la configuration YAML suivante, dans la section outlierDetection :

    Dans cet exemple, l'analyse de détection des anomalies s'exécute toutes les secondes. Si le nombre de codes d'état HTTP 5xx consécutifs reçus par un proxy Envoy est supérieur ou égal à cinq, le point de terminaison de backend est exclu du pool d'équilibrage de charge de ce proxy Envoy pendant 30 secondes. Lorsque le pourcentage d'application est défini sur 100 %, le service de backend exclut les points de terminaison non opérationnels des pools d'équilibrage de charge de ces proxys Envoy spécifiques à chaque exécution de l'analyse de détection des anomalies. Si les conditions d'exclusion sont remplies, jusqu'à 50 % des points de terminaison de backend du pool d'équilibrage de charge peuvent être exclus. 

    name: BACKEND_SERVICE_NAME
backends:
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
- balancingMode: UTILIZATION
  capacityScaler: 1.0
  group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
outlierDetection:
  baseEjectionTime:
    nanos: 0
    seconds: 30
  consecutiveErrors: 5
  enforcingConsecutiveErrors: 100
  interval:
    nanos: 0
    seconds: 1
  maxEjectionPercent: 50
port: 80
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
sessionAffinity: NONE
timeoutSec: 30
...

    Remplacez les éléments suivants :

    • BACKEND_SERVICE_NAME : nom du service de backend.
    • PROJECT_ID : ID de votre projet
    • REGION_A et REGION_B : régions dans lesquelles l'équilibreur de charge a été configuré.
    • SERVERLESS_NEG_NAME : nom du premier NEG sans serveur.
    • SERVERLESS_NEG_NAME_2 : nom du deuxième NEG sans serveur.

  3. Mettez à jour le service de backend en important la dernière configuration.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
  --source=BACKEND_SERVICE_NAME.yaml --global

    La détection des anomalies est désormais activée sur le service de backend.

Supprimer un NEG sans serveur

Il n'est pas possible de supprimer un groupe de points de terminaison du réseau s'il est associé à un service de backend. Avant de supprimer un NEG, assurez-vous qu'il est dissocié du service de backend.

Console

  1. Pour vous assurer que le NEG sans serveur que vous souhaitez supprimer n'est actuellement utilisé par aucun service de backend, accédez à l'onglet Services de backend de la page Composants de l'équilibrage de charge.
    Accéder à la page "Services de backend"
  2. Si le NEG sans serveur est actuellement utilisé, procédez comme suit :
    1. Cliquez sur le nom du service de backend qui utilise le NEG sans serveur.
    2. Cliquez sur Modifier ().
    3. Dans la liste des Backends, cliquez sur pour supprimer le backend NEG sans serveur du service de backend.
    4. Cliquez sur Enregistrer.

  3. Accédez à la page Groupe de points de terminaison du réseau dans Google Cloud Console.
    Accéder au groupe de points de terminaison du réseau
  4. Cochez la case correspondant au NEG sans serveur que vous souhaitez supprimer.
  5. Cliquez sur Supprimer.
  6. Cliquez à nouveau sur Supprimer pour confirmer votre choix.

gcloud

Pour supprimer un NEG sans serveur d'un service de backend, vous devez spécifier la région dans laquelle le NEG a été créé.

gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
    --network-endpoint-group=SERVERLESS_NEG_NAME \
    --network-endpoint-group-region=REGION \
    --region=REGION

Pour supprimer le NEG sans serveur, exécutez la commande suivante :

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME \
    --region=REGION

Étapes suivantes