Mettre à jour vos projets pour utiliser le DNS zonal

Ce document explique comment migrer un projet existant du DNS global vers le DNS zonal. Le DNS zonal améliore la fiabilité en isolant les pannes au sein des zones, ce qui évite les perturbations des services essentiels tels que la création d'instances et la réparation automatique.

Avant de commencer

  • Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux Google Cloud services et aux API. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine en sélectionnant l'une des options suivantes:

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

      3. REST

      Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

        Install the Google Cloud CLI, then initialize it by running the following command: 

        gcloud init

      Pour en savoir plus, consultez la section S'authentifier pour utiliser REST dans la documentation sur l'authentification Google Cloud.

Rôles requis

Pour obtenir les autorisations nécessaires pour migrer des projets vers le DNS zonal, demandez à votre administrateur de vous accorder les rôles IAM suivants:

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour migrer des projets vers un DNS zonal. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour migrer des projets vers le DNS zonal:

  • Rechercher les noms DNS globaux et les métadonnées de VM : compute.projects.get
  • Définir les métadonnées d'une VM : compute.instances.setMetadata
  • Définir des métadonnées à l'échelle du projet : compute.projects.setCommonInstanceMetadata
  • Si vos VM utilisent des comptes de service : iam.serviceAccounts.actAs

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Migrer votre projet vers le DNS zonal

Pour migrer un projet vers le DNS zonal, procédez comme suit:

  1. Vérifier si votre projet utilise le DNS global par défaut
  2. Déterminer l'aptitude à la migration de vos projets à l'aide de l'analyse des requêtes
  3. Migrer des projets compatibles avec le DNS zonal
  4. Corriger les requêtes incompatibles
  5. Surveillez les journaux DNS globaux pour vérifier que la migration est prête.
  6. Migrer les projets restants vers le DNS zonal
  7. Vérifier si une modification du DNS zonal a un impact sur votre projet

Vérifier si votre projet utilise le DNS global par défaut

Vérifiez vos projets pour savoir s'ils doivent migrer d'un DNS global vers un DNS zonal. Pour les noms DNS internes créés au sein du projet, vous ne devez migrer que les projets configurés pour utiliser le DNS global par défaut.

Console

  1. Dans la console Google Cloud, accédez à la page Métadonnées de Compute Engine.

    Accéder à la page "Métadonnées"

  2. Dans l'onglet Métadonnées, affichez le paramètre vmdnssetting, le cas échéant. La valeur attribuée indique si le projet utilise le DNS global par défaut.

    • GlobalDefault : le DNS global est activé dans le projet.
    • ZonalOnly : le DNS zonal est activé dans le projet. Il n'est pas nécessaire de migrer ce projet.

    Si le paramètre de métadonnées vmdnssetting n'est pas répertorié, vérifiez si votre organisation utilise le DNS global par défaut.

gcloud

Exécutez la commande gcloud CLI suivante pour vérifier la valeur de vmDnsSetting.

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

Remplacez PROJECT_ID par le nom du fichier.

La valeur renvoyée indique si le projet utilise le DNS global par défaut.

  • GLOBAL_DEFAULT : le DNS global est activé dans le projet.
  • ZONAL_ONLY : le DNS zonal est activé dans le projet. Il n'est pas nécessaire de migrer ce projet.

REST

Vérifiez la valeur de vmDnsSetting à l'aide de la méthode projects.get. Cet exemple utilise un paramètre de requête fields pour n'inclure que les champs que vous souhaitez afficher.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

Remplacez PROJECT_ID par l'ID du projet.

La valeur de vmDnsSetting indique si le projet utilise le DNS global par défaut.

  • GLOBAL_DEFAULT : le DNS global est activé dans le projet.
  • ZONAL_ONLY : le DNS zonal est activé dans le projet. Il n'est pas nécessaire de migrer ce projet.

Utiliser l'analyse des requêtes pour déterminer si un projet est prêt à être migré

Pour évaluer si un projet peut être migré vers le DNS zonal sans modifier le code ni modifier l'utilisation du DNS global, Google Cloud analyse l'historique des requêtes DNS. Cette analyse fournit les métriques suivantes qui indiquent la compatibilité du projet avec le DNS zonal:

  • zonal_dns_ready (Requêtes compatibles): cette métrique représente le nombre total de requêtes sur une période de 100 jours pouvant être résolues à l'aide du DNS zonal.

  • zonal_dns_risky (Requêtes incompatibles): cette métrique représente le nombre total de requêtes qui ne peuvent pas être résolues à l'aide du DNS zonal. Ces requêtes impliquent généralement une communication interrégionale ou d'autres scénarios où la résolution zonale échoue. Important : si cette métrique a une valeur non nulle, votre projet n'est pas encore prêt à être migré. Vous devez résoudre ces requêtes incompatibles avant de passer au DNS zonal.

Pour afficher ces métriques, utilisez l'explorateur de métriques dans la console Google Cloud.

  1. Dans la console Google Cloud, accédez à la page Explorateur de métriques :

    Accéder à l'explorateur de métriques

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. À droite de la barre d'outils contenant le champ Sélectionner une métrique, cliquez sur Éditeur de code, MQL ou PromQL.

  3. Si le champ de saisie de la requête n'est pas intitulé Requête MQL, puis en bas à droite du champ de saisie de la requête, dans Langage, sélectionnez MQL.

  4. Dans le champ de saisie de la requête, saisissez le texte suivant tel qu'il apparaît :

    fetch compute.googleapis.com/Location
| metric 'compute.googleapis.com/global_dns/request_count'
| every 1d
| within 7d

  5. Cliquez sur le bouton Run query (Exécuter la requête).

    La console Google Cloud affiche un graphique des deux métriques (zonal_dns_ready et zonal_dns_risky) et le nombre correspondant de requêtes effectuées sur la période pour chaque métrique.

    Capture d'écran du graphique pour les métriques d'utilisation du DNS global.

  6. Vérifiez la valeur de la métrique zonal_dns_risky.

    • Si la valeur est 0, le projet est prêt pour la migration vers le DNS zonal. Vous pouvez migrer le projet, comme décrit dans la section Migrer des projets prêts pour le DNS zonal.
    • Si la valeur est un nombre différent de zéro, tel que 0.02k, comme indiqué dans la capture d'écran précédente, certaines requêtes peuvent ne pas fonctionner après la migration vers le DNS zonal. Le projet n'est pas prêt pour la migration. Suivez la procédure décrite dans Corriger les requêtes incompatibles.

Migrer des projets compatibles avec le DNS zonal

Utilisez l'une des options suivantes pour migrer des projets prêts à passer au DNS zonal:

  • Cliquez sur le bouton Utiliser le DNS zonal dans la console Google Cloud.

    1. Lorsque vous consultez la page Instances de VM de votre projet, si votre projet est prêt pour la migration (compatible avec les requêtes DNS zonales), la bannière inclut une recommandation pour utiliser un DNS zonal. Cette recommandation est basée sur l'utilisation du DNS interne dans le projet, mais est limitée aux 30 derniers jours.

      Capture d'écran de la bannière "Prêt à migrer vers un DNS zonal" dans la console.

      Si vous cliquez sur le bouton Utiliser le DNS zonal, les métadonnées du projet sont mises à jour pour utiliser le DNS zonal.

    2. Facultatif: Affichez et interrogez les métadonnées de VM pour confirmer la modification des métadonnées.

  • Modifiez manuellement les métadonnées du projet pour utiliser le DNS zonal.

    1. Activez les DNS zonaux pour vos instances en définissant l'entrée de métadonnées vmDnsSetting pour le projet. Une fois cette entrée de métadonnées définie, vos instances de calcul ne sont accessibles que par leur nom DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal) lorsque vous utilisez des chemins de recherche. Les instances conservent les chemins de recherche zonal et global, mais leur nom DNS global, qui n'inclut pas ZONE dans le nom DNS interne, ne fonctionne plus. Seules les instances d'une même région et d'un même projet peuvent accéder les unes aux autres à l'aide du nom global lorsque ce paramètre est en place.

      Console

      1. Pour modifier le paramètre au niveau du projet, dans la console Google Cloud, accédez à la page Métadonnées de Compute Engine.

        Accéder à la page "Métadonnées personnalisées"

      2. Cliquez sur Modifier.

      3. Si une clé avec la valeur VmDnsSetting existe, remplacez-la par ZonalOnly.

      4. Si une clé avec la valeur VmDnsSetting n'existe pas, cliquez sur Ajouter un élément.

        • Dans le champ Clé, saisissez VmDnsSetting.
        • Dans le champ Valeur, saisissez ZonalOnly.

      5. Pour terminer de modifier vos entrées de métadonnées personnalisées, cliquez sur Enregistrer.

      gcloud

      1. Pour mettre à jour le paramètre de métadonnées du projet en cours, utilisez la commande project-info add-metadata.

        gcloud compute project-info add-metadata \
    --metadata vmDnsSetting=ZonalOnly

      2. (Facultatif) Pour vérifier les paramètres de métadonnées d'un projet, utilisez la commande suivante :

        gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

        Remplacez PROJECT_ID par le nom du projet à interroger.

      REST

      Pour mettre à jour le paramètre de métadonnées au niveau du projet, créez une requête POST à l'aide de la méthode projects.setCommonInstanceMetadata.

      1. Facultatif: Pour effectuer un verrouillage optimiste, vous pouvez éventuellement fournir une empreinte.

        Une empreinte est une chaîne aléatoire de caractères générée par Compute Engine. L'empreinte change après chaque requête et si vous fournissez une empreinte non concordante, votre requête est refusée.

        Si vous ne fournissez pas d'empreinte, aucune vérification de cohérence n'est effectuée et la requête projects.setCommonInstanceMetadata aboutit. Si vous utilisez la méthode instances.setMetadata, une empreinte digitale est toujours requise.

        Pour obtenir l'empreinte actuelle d'un projet, appelez la méthode project.get.

        GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID

        Le résultat ressemble à ce qui suit :

        {
 "name": "myproject",
 "commonInstanceMetadata": {
   "kind": "compute#metadata",
   "fingerprint": "FikclA7UBC0=",
   ...
 }
}

      2. Envoyez une requête POST à la méthode projects.setCommonInstanceMetadata pour définir la paire clé-valeur des métadonnées:

        POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata

{
"fingerprint": "FikclA7UBC0=",
"items": [
  {
  "key": "vmDnsSetting",
  "value": "ZonalOnly"
  }
]
}

        Remplacez PROJECT_ID par l'ID de votre projet.

    2. Après avoir configuré l'entrée de métadonnées vmDnsSetting pour votre projet, actualisez le bail DHCP sur chaque instance de ce projet. Vous pouvez actualiser le bail en redémarrant l'instance, en attendant son expiration ou en exécutant l'une des commandes suivantes:

      Instances Linux

      sudo dhclient -v -r

      Instances Windows 

      ipconfig /renew

    3. Vérifiez que votre projet utilise le DNS zonal.

Corriger les requêtes incompatibles

Un projet qui n'est pas prêt à migrer signifie qu'au moins une requête DNS incompatible a été effectuée dans un certain délai (dans les 30 derniers jours, par exemple). Les requêtes incompatibles peuvent présenter les attributs suivants:

  • Appeler une instance de calcul dans un autre projet
  • Appeler une instance de calcul dans une autre région

Si votre projet contient des requêtes incompatibles, la bannière suivante s'affiche sur la page Instances de VM de la console Google Cloud:

Bannière indiquant que votre projet n'est pas prêt à migrer vers un DNS zonal.

Pour corriger toutes les requêtes incompatibles, nous vous recommandons d'utiliser le nom de domaine complet zonal de l'instance source dans la requête. Cette approche garantit que la résolution des requêtes reste ininterrompue après la migration du projet vers le DNS zonal.

Pour résoudre les requêtes incompatibles, procédez comme suit:

  1. Utilisez l'explorateur de journaux pour accéder aux requêtes DNS et les interroger pour les instances de calcul de votre projet.

    Accéder à l'explorateur de journaux

  2. Sélectionnez le projet.

  3. Appliquez les filtres de ressource et de nom de journal :

    1. Cliquez sur Ressource.
    2. Dans la boîte de dialogue Sélectionner une ressource, sélectionnez Instance de VM, puis cliquez sur Appliquer.
    3. Cliquez sur Nom du journal.

    4. Dans la boîte de dialogue Sélectionner des noms de journal, sélectionnez gdnsusage, puis cliquez sur Appliquer.

    Vous pouvez également saisir les informations suivantes dans le champ de requête :

       resource.type="gce_instance"
   log_name="projects/PROJECT_ID/logs/compute.googleapis.com%2Fgdnsusage"

  4. Dans le volet Résultats de requête, chaque requête comporte un champ jsonPayload. Chaque champ jsonPayload contient les informations suivantes :

    • Nom de la VM source, ID de projet et nom de zone.
    • Nom de la VM de destination, ID de projet et nom de zone.

    • Message de débogage fournissant des informations sur la mise à jour de la requête DNS globale qui ne peut pas être résolue à l'aide de noms DNS zonaux. Ces requêtes sont considérées comme des requêtes qui bloquent la migration, que vous devez déboguer et corriger.

      "To use Zonal DNS, update the Global DNS query sent from the source VM
VM_NAME.c.PROJECT_ID.internal to the following zonal
FQDN: VM_NAME.ZONE.c.PROJECT_ID.internal"

    • Nombre de requêtes indiquant le nombre de requêtes qui bloquent la migration envoyées par la VM source à la VM de destination pour le jour donné.

    La capture d'écran suivante montre les informations sur les champs jsonPayload dans la page de la console de l'explorateur de journaux.

    Capture d'écran de la réponse jsonPayload dans les résultats de la requête de journal gdnsusage.

  5. Utilisez les informations de jsonPayload que vous avez obtenues à l'étape précédente pour déterminer le nom de domaine complet à utiliser pour mettre à jour manuellement vos requêtes DNS globales afin d'utiliser le DNS zonal, ainsi que pour préparer le projet à la migration. Les cas d'utilisation les plus courants de mise à jour du nom de domaine complet et de résolution de compatibilité sont les suivants:

    • Noms DNS internes du serveur de métadonnées : aucune action n'est requise, car le nom DNS renvoyé deviendra un nom de domaine complet zonal immédiatement après la migration vers le DNS zonal. Si le nom DNS est mis en cache, il vous suffit d'effectuer un autre appel pour mettre à jour la valeur du cache.
    • Noms DNS internes utilisés pour accéder aux VM d'une autre région : si vous disposez d'une application qui utilise les noms DNS internes pour des VM de différentes régions, vous pouvez modifier la règle DHCP ou le fichier de configuration pour inclure la zone dans l'autre région.
    • Nom de domaine complet global codé en dur : si votre application utilise des noms de domaine complets globaux codés en dur pour les VM, vous pouvez mettre à jour l'appel dans l'application de manière à utiliser le nom DNS interne ou le nom de domaine complet zonal à la place. Vous pouvez effectuer cette modification via un changement de code ou de configuration dans Terraform.
    • VM dans les projets de service qui utilisent un réseau VPC partagé : pour résoudre les noms DNS des VM dans les projets de service qui utilisent un réseau VPC partagé, vous devez utiliser les noms de domaine complets zonaux des VM.

  6. Après avoir mis à jour les requêtes DNS globales pour utiliser le DNS zonal, procédez comme suit:

    1. Utilisez la page de l'explorateur de journaux pour interroger à nouveau l'utilisation du DNS global. Une fois que vous avez corrigé toutes les requêtes DNS globales bloquantes, aucun journal de débogage ne s'affiche dans les résultats de la requête.

    2. Revérifiez la métrique de surveillance pour vérifier que toutes les requêtes DNS incompatibles ont été supprimées.

Afficher les journaux DNS globaux dans l'explorateur de journaux

L'explorateur de journaux affiche principalement les journaux DNS globaux pour les projets dont les requêtes sont incompatibles avec le DNS zonal. Ces journaux vous aident à identifier et à analyser ces requêtes problématiques avant la migration.

Vous pouvez également utiliser l'explorateur de journaux pour ces requêtes incompatibles afin d'effectuer les opérations suivantes:

  • Créer des tableaux de bord: visualisez vos modèles de requêtes DNS globaux incompatibles pour obtenir des insights sur le comportement de communication de votre application.
  • Agréger les journaux: analysez les journaux DNS de l'ensemble de votre organisation pour identifier les tendances plus générales et les axes d'amélioration potentiels.

Vérifier si une modification du DNS zonal a un impact sur votre projet

Après avoir migré vers le DNS zonal, vous devez impérativement vérifier que vos applications et services fonctionnent toujours correctement. Étant donné que le DNS zonal modifie la manière dont les noms DNS internes sont résolus, certaines applications peuvent rencontrer des problèmes si elles s'appuient sur des noms DNS globaux.

La section suivante décrit comment vérifier les impacts potentiels et les résoudre:

  1. Communication des instances de ligne de commande

    Tâche: Essayez d'envoyer un ping à une instance à partir d'une autre instance à l'aide de la CLI gcloud.

    gcloud compute ssh VM-A --command "ping VM-B"

    Erreur potentielle : "Impossible de résoudre l'hôte" : cela signifie que VM-A ne parvient pas à trouver l'adresse IP de VM-B.

    Résolution: remplacez le nom d'hôte que vous utilisez pour VM-B par son nom de domaine complet (FQDN), qui inclut le nom de zone : INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

  2. Communication entre instances dans les services Compute Engine

    Tâche: Si vous utilisez des vérifications d'état pour les groupes d'instances gérés (MIG) qui reposent sur des noms DNS internes, vérifiez si les vérifications d'état sont réussies.

    Erreur potentielle : "Échec de la vérification de l'état" : cela indique que la vérification de l'état ne peut pas atteindre sa cible en raison de problèmes de résolution DNS.

    Résolution: Assurez-vous que la vérification d'état utilise le nom de domaine complet de l'instance cible, y compris le nom de zone.

  3. Cas d'utilisation spécifiques à l'application

    De nombreuses applications s'appuient sur le DNS interne pour des tâches telles que les suivantes:

    • Se connecter à des bases de données (par exemple, Cloud SQL)

    • Interagir avec des files d'attente de messages (par exemple, Pub/Sub)

    • Erreurs potentielles: elles varient en fonction de l'application, mais peuvent inclure les éléments suivants:

      • "Impossible de se connecter à SERVICE_NAME"
      • "Connexion expirée"
      • "Aucun hôte de ce type n'est connu"

    • Résolution: Vérifiez la configuration de votre application pour vous assurer qu'elle utilise le nom de domaine complet (y compris le nom de zone) lors de la référence des services.

Rétablir l'utilisation du DNS global

Vous pouvez annuler la migration vers un DNS zonal en rétablissant le type DNS interne par défaut sur le DNS global. Vous pouvez le faire au niveau de l'organisation, du projet, de l'instance ou du conteneur.

Rétablir l'utilisation du DNS global pour un projet

Pour rétablir l'utilisation du DNS global pour un projet, procédez comme suit :

  1. Ajoutez ce qui suit aux métadonnées du projet : vmDnsSetting=GlobalDefault.

    Pour en savoir plus sur la définition des valeurs de métadonnées d'un projet, consultez la section Définir et supprimer des métadonnées personnalisées.

  2. Vérifiez qu'aucune des instances du projet n'a la valeur de métadonnées vmDnsSetting définie sur ZonalOnly.

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata[]"

    Remplacez INSTANCE_NAME par le nom de l'instance à vérifier.

  3. Actualisez le bail DHCP sur chaque instance. Vous pouvez actualiser le bail en redémarrant l'instance, en attendant son expiration ou en exécutant l'une des commandes suivantes dans le système d'exploitation invité:

    • Instances Linux : sudo dhclient -v -r
    • Instance Windows Server: ipconfig /renew

Rétablir l'utilisation du DNS global pour une instance

Pour rétablir l'utilisation du DNS global pour une instance spécifique, procédez comme suit :

  1. Mettez à jour les métadonnées de l'instance pour inclure vmDnsSetting=GlobalDefault.

    Pour en savoir plus sur la définition des valeurs de métadonnées d'une instance Compute Engine, consultez la section Définir et supprimer des métadonnées personnalisées.

  2. Pour forcer la modification de la configuration DNS, redémarrez le réseau de l'instance à l'aide de l'une des commandes suivantes:

    • Pour Container-Optimized OS ou Ubuntu :

      sudo systemctl restart systemd-networkd

    • Pour CentOS, RedHat EL, Fedora CoreOS ou Rocky Linux :

      sudo systemctl restart network

      ou

      sudo systemctl restart NetworkManager.service

    • Pour Debian :

      sudo systemctl restart networking

    • Pour les systèmes Linux avec nmcli :

      sudo nmcli networking off
sudo nmcli networking on

    • Pour Windows :

      ipconfig /renew

Rétablir l'utilisation du DNS global pour un conteneur

Si vous exécutez votre application dans des conteneurs, sur Google Kubernetes Engine ou sur un environnement flexible App Engine, la configuration DNS de vos paramètres de conteneur risque de ne pas se mettre à jour automatiquement tant que vous ne redémarrez pas les conteneurs. Pour désactiver le DNS zonal sur ces applications de conteneur, procédez comme suit :

  1. Définissez le paramètre de métadonnées du projet vmDnsSetting sur GlobalDefault pour les projets qui possèdent les conteneurs et les VM.

  2. Redémarrez les conteneurs afin que leurs paramètres DNS reviennent à leur état d'origine.

Résoudre les problèmes liés au processus de migration DNS global vers DNS zonal

Si vous rencontrez des problèmes avec le processus de migration, consultez le guide de dépannage.

Étape suivante