Utiliser le DNS zonal pour votre type DNS interne

Le DNS zonal réduit les risques de pannes interrégionales et améliore la fiabilité globale de vos projets sur Compute Engine. L'utilisation du DNS zonal réduit l'impact des points de défaillance uniques qui peuvent survenir lors de l'utilisation du DNS global.

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 services et aux API Google Cloud. 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 vers un 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 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 vers un DNS zonal :

  • Définir une contrainte de règle d'administration : orgpolicy.*
  • Déterminer si un dossier est prêt à migrer vers un DNS zonal :
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • 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.

À propos des noms DNS

Les noms DNS zonaux incluent le nom de votre VM, la zone dans laquelle elle se trouve et le projet auquel elle appartient. Les noms DNS globaux n'incluent pas la zone dans laquelle se trouve la VM.

Lorsque vous appelez une VM à l'aide d'un nom DNS global :

  • Le nom est résolu au niveau global.
  • Chaque VM doit avoir un nom DNS unique.
  • Lorsque vous créez une VM, le nom DNS de la VM doit être comparé à tous les autres noms DNS globaux enregistrés dans le même projet afin d'éviter un conflit de noms DNS.

Lorsque vous appelez une VM à l'aide d'un nom DNS zonal :

  • Le nom est résolu dans une zone.
  • Les noms DNS zonaux doivent être uniques dans une même zone. Par exemple, my-vm.zone1.google.com doit être unique pour zone1. Toutefois, contrairement aux noms DNS globaux, my-vm.zone2.google.com est également un nom DNS valide lors de l'utilisation d'un DNS zonal.

Le DNS zonal est la méthode de résolution DNS interne par défaut pour Compute Engine pour les organisations créées après le 6 septembre 2018. Les noms DNS zonaux d'une zone fonctionnent indépendamment des autres zones, ce qui vous permet de créer des applications multirégionales plus tolérantes aux pannes avec de meilleures caractéristiques de disponibilité. L'utilisation de DNS zonaux est gratuite. Le DNS zonal est distinct de Cloud DNS.

Les projets créés avant le 6 septembre 2018 ont été configurés pour utiliser le DNS global par défaut. Ces projets peuvent continuer à utiliser le DNS global, mais Google recommande vivement aux organisations de migrer ces projets vers un DNS zonal afin d'éviter que des interruptions de service dans une autre région n'affectent les ressources régionales locales. L'utilisation du DNS zonal offre une fiabilité supérieure par rapport au DNS global en isolant les échecs d'enregistrement DNS dans des zones individuelles. Cela réduit l'impact des points de défaillance uniques. Si une panne se produit dans Google Cloud, elle est isolée dans une seule zone, sans impact significatif sur les ressources et les coûts.

Migrer du DNS global vers le DNS zonal

Le DNS zonal a remplacé le DNS global en tant que type DNS interne par défaut pour toutes les nouvelles organisations intégrées à Google Cloud après le 6 septembre 2018. Si vos projets existants utilisent toujours un DNS global, Google vous recommande vivement de modifier ces projets pour utiliser des noms DNS zonaux. En ne migrant pas vers le DNS zonal, vous risquez de rencontrer les problèmes suivants :

  • Impossibilité de créer des VM dans une région en cas de défaillance du plan de contrôle où vous avez ou avez déjà eu un projet.
  • Impossibilité d'utiliser certains services Compute Engine critiques pour vos charges de travail, tels que l'autoscaling ou l'autoréparation pour les groupes d'instances gérés (MIG).

Une autre approche permettant d'améliorer la fiabilité de vos charges de travail utilisant le DNS global consiste à migrer vers des zones privées Cloud DNS. L'utilisation des zones privées Cloud DNS supprime la vérification de l'unicité des noms requise par le DNS global et isole les défaillances pour permettre la résolution de noms DNS. Pour en savoir plus sur cette option, consultez la documentation Cloud DNS, ou contactez Cloud Customer Care ou votre responsable de compte. Pour plus d'informations sur la manière dont Cloud DNS gère les pannes zonales et régionales, consultez la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructures cloud.

Présentation du processus de migration

Le processus de migration DNS zonal comporte deux niveaux :

  • Au niveau de l'organisation ou du dossier : déterminez si vous êtes prêt à transférer le dossier ou l'organisation vers le DNS zonal. Empêchez les nouveaux projets d'utiliser le DNS global. Effectué par l'administrateur de l'organisation.
  • Au niveau du projet : migrez un seul projet à partir du DNS global vers le DNS zonal. Effectué en général par le propriétaire du projet.

L'image montre un organigramme des étapes de migration vers un DNS zonal

En règle générale, le processus comprend les étapes suivantes :

  1. Vérifiez que le dossier ou l'organisation est prêt pour la migration vers un DNS zonal.
  2. Si le dossier ou l'organisation est prêt à migrer vers un DNS zonal, procédez comme suit :
    1. L'administrateur de l'organisation définit une règle d'administration pour le dossier ou l'organisation afin d'empêcher l'utilisation du DNS global.
    2. Les propriétaires de projets migrent leurs projets pour utiliser le DNS zonal.
  3. Si le dossier ou l'organisation n'est pas prêt pour la migration vers le DNS zonal :
    1. Les propriétaires de projet migrent les projets prêts vers le DNS zonal.
    2. Les propriétaires de projet examinent l'utilisation du DNS global dans les projets qui ne sont pas prêts.
    3. Les propriétaires de projet appliquent des améliorations de chemin de recherche ou d'autres modifications pour rendre le projet prêt à migrer vers un DNS zonal.
    4. L'administrateur de l'organisation vérifie à nouveau l'état du dossier ou de l'organisation pour la migration DNS zonale.

Limites

  • Le DNS zonal ne remplace pas le DNS global. Certains types de requêtes (interzones) peuvent ne pas être résolus par un DNS zonal avec recherche automatique de chemin de recherche. Vérifiez que les dossiers et les projets de votre organisation sont prêts pour la migration afin de vous assurer qu'ils sont compatibles avec le DNS zonal avant la migration.

  • Le processus de migration DNS global vers DNS zonal introduit un nouveau domaine (ZONE.c.PROJECT_ID.internal) dans le chemin de recherche. Si une VM exécutant Linux ou Unix possède déjà six domaines dans le chemin de recherche, assurez-vous que la VM s'exécute avec glibc version 2.26 ou ultérieure. Les clients DHCP disposant de glibc 2.25 ou version antérieure n'acceptent que six domaines de recherche maximum. Il existe donc un risque de supprimer un domaine de recherche existant. Cette limite ne s'applique pas aux VM utilisant les :

    • Images Windows
    • Images Container-Optimized OS
    • Images Debian 10 ou version ultérieure
    • Fedora CoreOS (27 ou version ultérieure)
    • Images RHEL 8 ou version ultérieure
    • Images Ubuntu 18.04 ou version ultérieure
    • Autres images avec glibc 2.26 ou version ultérieure

  • L'activation de l'amélioration du chemin de recherche permet d'ajouter quelques domaines de recherche supplémentaires, tels que NEIGHBOR_ZONE.c.PROJECT_ID.internal. Comme indiqué dans la limite précédente, les domaines existants dans le chemin de recherche peuvent être supprimés si la limite de domaine du chemin de recherche est dépassée lors de l'utilisation de glibc 2.25 ou version antérieure.

  • Pour utiliser les améliorations du chemin de recherche avec Google Kubernetes Engine, vous devez utiliser Google Kubernetes Engine 1.26 ou version ultérieure.

Vérifier la version de Glibc

Pour vérifier la version de glibc utilisée par votre VM, procédez comme suit :

  1. Connectez-vous à votre VM Linux.
  2. Exécutez ldd --version pour obtenir la version de glibc.

Vérifier le nombre de domaines de recherche si vous utilisez Glibc 2.25 ou une version antérieure

  1. Connectez-vous à votre VM Linux.

  2. Vérifiez si votre VM Linux contient déjà six domaines dans le chemin de recherche. Vous pouvez exécuter cat /etc/resolv.conf pour afficher ces informations.

Étapes de l'administrateur de l'organisation

En tant qu'administrateur de l'organisation, vous effectuez les tâches suivantes :

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

Le type par défaut du nom DNS interne de votre organisation est déterminé par la date de création de celle-ci et si la contrainte de règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly est appliquée.

Console

  1. Accédez à la page IAM et administration>Identité et organisation de la console.

    Accéder à la page Identité et organisation

  2. Vérifiez la date d'inscription de l'organisation.

    Capture d'écran de la page "Identité et organisation" de la console, indiquant la date d'inscription

    • Si votre organisation a été créée après le 6 septembre 2018, elle utilise le DNS zonal par défaut. Dans ce cas, aucune autre action n'est requise.
    • Si votre organisation a été créée avant le 6 septembre 2018, elle utilise le DNS global par défaut et doit être migrée vers un DNS zonal.

  3. Si votre organisation utilise le DNS global par défaut, vérifiez si une contrainte de règle d'administration définit le type DNS par défaut de tous les projets nouvellement créés sur DNS zonal.

    1. Accédez à la page IAM et administration>Règles d'administration dans la console Google Cloud.
    2. Dans le champ Filtre, saisissez constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Si la contrainte est configurée, cliquez sur le nom Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.
    4. Sur la page des détails de la règle, vérifiez l'état.
      • Si l'état est Appliqué, le type DNS interne par défaut est le DNS zonal pour tous les nouveaux projets créés dans l'organisation.
      • Sinon, le type DNS par défaut du projet est toujours déterminé par l'heure de création de l'organisation.
    5. Si la contrainte n'a pas été configurée pour l'organisation, le type DNS par défaut du projet est déterminé par l'heure de création de l'organisation, comme décrit à la première étape.

gcloud

Exécutez les commandes organizations describe et resource-manager org-policies list pour déterminer le type DNS par défaut d'une organisation.

  1. Vérifiez la valeur de métadonnées creationTime de l'organisation.

    gcloud organizations describe ORGANIZATION_ID

    Remplacez ORGANIZATION_ID par l'ID de l'organisation ou le nom de domaine de l'organisation.

    • Si votre organisation a été créée après le 6 septembre 2018, elle utilise le DNS zonal par défaut. Dans ce cas, votre organisation utilise déjà le DNS zonal et aucune autre action n'est requise.
    • Si votre organisation a été créée avant le 6 septembre 2018, elle utilise le DNS global par défaut et doit être migrée vers un DNS zonal.

  2. Si votre organisation utilise le DNS global par défaut, déterminez si une contrainte de règle d'administration est configurée pour définir le type DNS par défaut de tous les projets nouvellement créés sur le DNS zonal.

    gcloud resource-manager org-policies list --organization=ORGANIZATION_ID \
   --filter="constraints/compute"

    Dans le résultat, recherchez constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Si la contrainte est configurée et que Status est défini sur Enforced, le type DNS interne par défaut est le DNS zonal pour tous les nouveaux projets créés dans l'organisation.
    2. Si la contrainte n'a pas été configurée pour l'organisation ou n'est pas appliquée, le type DNS interne par défaut est déterminé par l'heure de création de l'organisation, comme décrit à la première étape.

Déterminer quels projets d'un dossier ou d'une organisation utilisent le DNS global.

Pour déterminer combien de projets utilisent le DNS global, nous vous recommandons d'utiliser BigQuery afin de créer une table qui répertorie les projets relatifs de votre organisation et leurs métadonnées. Vous pouvez ensuite utiliser cette table pour exécuter une requête qui expose le nombre total de projets utilisant le DNS global.

  1. Créez un ensemble de données BigQuery.

  2. Exportez des métadonnées d'éléments pour votre organisation vers une table BigQuery.

    1. Assurez-vous que l'API Cloud Asset Inventory est activée.
    2. Configurez les autorisations requises pour utiliser l'API Cloud Asset Inventory.

    3. Exécutez la commande gcloud CLI suivante pour exporter l'élément compute.googleapis.com/Project :

      gcloud asset export \
   --content-type resource \
   --organization 'ORGANIZATION_ID' \
   --bigquery-table 'projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_NAME' \
   --asset-types='compute.googleapis.com/Project' \
   --output-bigquery-force

      Remplacez les éléments suivants :

      • ORGANIZATION_ID : numéro d'ID de l'organisation.
      • PROJECT_ID : ID du projet
      • DATASET_ID : nom de l'ensemble de données BigQuery
      • TABLE_NAME : table vers laquelle vous exportez les métadonnées. Si cette table n'existe pas, elle est créée.

  3. Accédez à la page BigQuery de la console Google Cloud.

  4. Sélectionnez Saisir une nouvelle requête.

  5. Dans la zone de texte de l'éditeur de requête, saisissez la requête GoogleSQL suivante, puis cliquez sur  Exécuter.

    SELECT
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting,
  count(*) as project_count
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY 1

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet
    • DATASET_ID : nom de l'ensemble de données BigQuery
    • TABLE_NAME : table contenant les métadonnées exportées à l'étape 2.

    Le DNS zonal est configuré pour les projets dont la valeur est ZONAL_ONLY pour vmDnsSetting. Sinon, les projets sont configurés pour utiliser le DNS global.

  6. Facultatif : Pour obtenir une vue détaillée de vmDnsSetting pour chaque projet, saisissez la requête GoogleSQL suivante, puis cliquez sur Exécuter.

    SELECT
  SUBSTR(name,35) as project_id,
  JSON_VALUE(SAFE.PARSE_JSON(resource.data).vmDnsSetting) AS vmDnsSetting
FROM PROJECT_ID.DATASET_ID.TABLE_NAME

Déterminer si un dossier est prêt à migrer vers un DNS zonal

Cette étape utilise un script bash et la table BigQuery créée dans la section précédente pour déterminer si le dossier est prêt pour la migration.

  • Le dossier est prêt si tous les projets ne comportent aucune requête incompatible avec un DNS zonal effectuée au cours des 30 derniers jours.
  • Si un dossier n'est pas prêt pour la migration, le script répond avec les ID de projet qui se trouvent dans le dossier et qui ne sont pas prêts pour la migration. Les projets figurant dans cette liste de résultats ne sont pas encore compatibles avec les DNS zonaux et nécessitent une action supplémentaire.

Procédez comme suit :

  1. Obtenez l'ID du dossier. Si vous ne connaissez pas l'ID du dossier :
    1. Dans la console Google Cloud, accédez à la page Ressources gérées.
    2. Appliquez le filtre Name:FOLDER_NAME pour obtenir l'ID du dossier.

  2. Interrogez la table BigQuery avec les données compute.Project assets exportées.

    Pour savoir comment créer la table BigQuery, consultez la section Déterminer quels projets d'un dossier ou d'une organisation utilisent le DNS global.

    Saisissez la requête GoogleSQL suivante, puis cliquez sur  Exécuter :

    SELECT
  SUBSTR(name,35) AS project_id,
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
WHERE CONTAINS_SUBSTR(ancestors, 'FOLDER_NUMBER')

    Remplacez les éléments suivants :

    • PROJECT_ID : ID du projet
    • DATASET_ID : nom de l'ensemble de données BigQuery
    • TABLE_NAME : table contenant les métadonnées exportées.
    • FOLDER_NUMBER : ID du dossier

  3. Copiez la liste d'ID de projet et enregistrez-la dans un fichier.

  4. Exécutez le script suivant bash. Le script parcourt les ID de projet dans le fichier enregistré pour déterminer si un dossier est prêt pour la migration.

#!/bin/bash
inaccessible_projects=()
unready_projects=()

for project in $(cat ~/FILENAME | tr '\n' ' '); do
  echo -e "Checking project $project..."
  ERROR=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.error'`
  if ! [[ "$ERROR" -eq "null" ]]; then
    inaccessible_projects+=($project)
    continue
  fi
  QUERY_COUNT=`curl -s --request POST "https://monitoring.googleapis.com/v3/projects/$project/timeSeries:query"   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Accept: application/json"   -H "Content-Type: application/json"   --data '{"query":"fetch compute.googleapis.com/Location | metric '"'"'compute.googleapis.com/global_dns/request_count'"'"' | filter metric.zonal_dns_readiness = '"'"'zonal_dns_risky'"'"' | every 30d | within 30d"}'   --compressed | jq --raw-output '.timeSeriesData[0].pointData[0].values[0].int64Value'`
  if [[ "$QUERY_COUNT" -ne "null" ]] && [[ "$QUERY_COUNT" -ne "0" ]]; then
    unready_projects+=($project)
  fi
done

error_len=${#inaccessible_projects[@]}
unready_len=${#unready_projects[@]}

echo -e "$error_len projects were inaccessible"
echo -e "$unready_len projects were not ready for migration"

if [ $error_len -ne 0 ]; then
  echo "Unable to access the following projects:"
  for project in "${inaccessible_projects[@]}"; do
    echo "$project"
  done
fi
if [ $unready_len -ne 0 ]; then
  echo "The following projects are not ready for migration:"
  for project in "${unready_projects[@]}"; do
    echo "$project"
  done
fi

if (( $error_len + $unready_len > 0 )); then
  echo "This folder is NOT ready for gDNS -> zDNS migration."
else
  echo "This folder is ready for gDNS -> zDNS migration."
fi

Remplacez FILENAME par le nom du fichier dans lequel vous avez enregistré la liste des ID de projet.

Transmettez les résultats de l'analyse d'aptitude à la migration aux propriétaires du projet :

Appliquer le DNS zonal par défaut pour les nouveaux projets

Si un nouveau projet est créé dans une organisation créée avant le 6 septembre 2018, le type DNS interne par défaut utilisé par le projet est le DNS global. Pour isoler les échecs d'enregistrement DNS aux zones individuelles, vous pouvez appliquer la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly au niveau de l'organisation ou du dossier.

Lorsque vous définissez une règle d'administration pour remplacer le type DNS interne par défaut, les projets nouvellement créés utilisent le DNS zonal par défaut. La règle d'administration n'a pas d'incidence sur les projets existants où l'API Compute Engine est déjà activée. Pour migrer des projets existants vers le DNS zonal, consultez la section Migrer des projets existants vers le DNS zonal.

Pour appliquer cette modification de règle, vous devez disposer d'un accès au niveau du dossier ou de l'organisation avec le rôle IAM roles/orgpolicy.policyAdmin.

Pour définir la règle d'administration pour un dossier ou une organisation, procédez comme suit :

  1. Connectez-vous à Google Cloud Console en tant que super-administrateur Google Workspace ou Cloud Identity.

  2. Dans la console, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  3. Sélectionnez le dossier ou l'organisation dont vous souhaitez afficher les règles d'administration. La console Google Cloud affiche la liste des contraintes de règles d'administration disponibles. Cette liste peut s'étendre sur plusieurs pages.

  4. Pour trouver la règle permettant d'appliquer le DNS zonal, cliquez sur Filtre et sélectionnez Nom, puis définissez le nom du filtre sur Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.

  5. Cliquez sur le nom de la règle pour en afficher les détails.

    La page des détails de la règle fournit des informations sur la contrainte et son application actuelle.

    Par défaut, la mesure d'application n'est pas définie pour un dossier ou une organisation. Toutefois, si un dossier parent a une mesure d'application définie, l'application est héritée du dossier parent le plus proche ayant une mesure d'application définie. Pour en savoir plus, consultez la page Comprendre le processus d'évaluation hiérarchique.

  6. Pour personnaliser la règle d'administration, cliquez sur Modifier.

  7. Sur la page de modification, sélectionnez Personnaliser.

  8. Sous Application, sélectionnez Activé.

    Cela définit le type DNS interne par défaut pour tous les nouveaux projets de l'organisation sur le DNS zonal.

  9. Cliquez sur Enregistrer.

Pour valider la modification des règles d'administration, vous pouvez créer un projet sous le dossier ou l'organisation, puis créer et démarrer une instance de VM et vérifier si votre VM est configurée pour utiliser le DNS zonal.

Si un DNS global interne est nécessaire pour résoudre une requête de nom DNS intégrée à votre charge de travail, vous pouvez annuler cette modification au niveau de l'organisation ou du dossier en désactivant la mesure d'application.

Exempter les dossiers non prêts à migrer vers le DNS zonal

Si une organisation ne contient que quelques dossiers qui ne sont pas prêts à migrer vers un DNS zonal, nous vous recommandons de définir une règle d'administration au niveau de l'organisation, mais en attribuant une exception aux dossiers qui ne sont pas encore prêts à migrer.

L'exemple suivant illustre une hiérarchie d'organisation dans laquelle un seul dossier n'est pas prêt à migrer vers un DNS zonal.

organisation/exemple.com

  • folders/101
    • projects/301 (prêt pour la migration)
    • folders/201
      • projects/303 (NON prêt)
      • projects/304 (prêt pour la migration)
  • folders/102
    • projects/302 (prêt pour la migration)

Pour exempter un dossier de la règle d'administration, procédez comme suit pour définir l'option d'application de la règle au niveau du dossier sur Off.

  1. Connectez-vous à Google Cloud Console en tant que super-administrateur Google Workspace ou Cloud Identity.

  2. Dans la console, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  3. Cliquez sur Sélectionner, puis sélectionnez les dossiers à exempter de la règle d'administration.

    La console Google Cloud affiche la liste des contraintes de règles d'administration pour ce dossier sur une ou plusieurs pages.

  4. Pour trouver la contrainte de règle d'administration qui applique un DNS zonal, procédez comme suit :

    1. Cliquez sur Filtrer.
    2. Sélectionnez Nom.
    3. Définissez le nom du filtre sur Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement.

  5. Cliquez sur le nom de la contrainte de règle d'administration pour ouvrir la page Détails de la règle.

  6. Cliquez sur Modifier.

  7. Sur la page Modifier, sélectionnez Personnaliser.

  8. Sous Application, sélectionnez Désactiver pour désactiver l'application de la contrainte. Cela signifie que le type DNS interne par défaut pour tous les projets du dossier est déterminé par l'heure de création de l'organisation.

  9. Cliquez sur Enregistrer.

Pour en savoir plus sur la personnalisation des contraintes de règles d'administration, consultez la section Personnaliser les règles pour les contraintes booléennes dans la documentation de Resource Manager.

Étapes du propriétaire du projet

En tant que propriétaire du projet, vous effectuez les tâches suivantes lors de la migration du DNS global vers le DNS zonal :

Les propriétaires de projet peuvent aussi effectuer les tâches facultatives suivantes :

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.

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

  2. Dans l'onglet Métadonnées, affichez le paramètre vmdnssetting. La valeur 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.

gcloud

    In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  1. 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.

Déterminer si votre projet est prêt à migrer

Dans la console Google Cloud, sur la page Instances de VM, si votre projet doit migrer vers un DNS zonal, vous devez voir une bannière de notification concernant la migration DNS zonal.

Lorsque vous consultez la page Instances de VM de votre projet, si votre projet est prêt pour la migration (compatible avec le DNS zonal), la bannière inclut un 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 100 derniers jours.

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

Si votre projet n'est pas prêt pour la migration vers un DNS zonal, une autre bannière s'affiche.

Capture d'écran de la bannière "Non prêt pour la migration vers un DNS zonal" dans la console

Pour afficher votre utilisation du DNS global, cliquez sur le bouton Afficher l'utilisation du DNS global. Vous êtes alors redirigé vers la page Explorateur de journaux de la console Google Cloud. Sur cette page, vous pouvez afficher les journaux de requêtes de blocage de migration des 30 derniers jours. Lorsque vous cliquez sur le lien dans la bannière, la page Explorateur de journaux est configurée pour utiliser le filtre logName afin d'extraire les requêtes de DNS global et les champs de journal correspondants.

Pour afficher ces informations sans utiliser le bouton de la bannière, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Explorateur de journaux.

    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"

Suivre l'utilisation du DNS global dans le projet

Deux métriques sont créées pour suivre la préparation des projets à la migration vers un DNS zonal :

  • zonal_dns_ready : nombre total de requêtes effectuées sur l'intervalle de temps spécifié pouvant être résolu à l'aide du DNS zonal au lieu du DNS global.
  • zonal_dns_risky : nombre total de requêtes effectuées sur l'intervalle de temps spécifié qui ne peut pas être résolu à l'aide du DNS zonal. Pour ces requêtes, Compute Engine n'a pas pu déterminer l'adresse IP interne correspondante à partir du nom d'hôte actuel. Si cette valeur est différente de zéro, le projet n'est pas prêt pour la migration.

L'intervalle de temps utilisé par ces métriques est une période de 100 jours.

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. Passez aux étapes de la section Modifier les projets qui ne sont pas prêts pour la migration.

Migrer des projets prêts pour le DNS zonal

De manière générale, vous pouvez utiliser le processus de migration suivant :

  1. Vérifiez vos applications et mettez-les à jour pour résoudre les problèmes de compatibilité avec les paramètres uniquement zonaux :
    • Si l'une de vos applications utilise des noms DNS globaux codés en dur, mettez-les à jour de sorte qu'ils utilisent des noms DNS zonaux.
    • Si une application utilise des noms de VM pour accéder à des VM d'une autre zone, assurez-vous que le nom de la zone de destination est ajouté dans la requête, par exemple : DESTINATION_VM_NAME.DESTINATION_ZONE_NAME.
    • Pour résoudre les noms DNS de VM dans les projets de service qui utilisent un réseau VPC partagé, vous devez utiliser le nom de domaine complet zonal des VM.

  2. Cliquez sur le bouton Utiliser le DNS zonal dans la bannière de la page Instances de VM de la console Google Cloud. Cela modifie les métadonnées du projet pour utiliser le DNS zonal.

    Vous pouvez également modifier manuellement vos projets pour utiliser le DNS zonal par défaut, comme décrit dans les sections Mettre à jour manuellement des projets et des VM afin d'utiliser un DNS zonal et Empêcher les nouveaux projets. d'utiliser le DNS global par défaut.

Mettre à jour manuellement des projets et des VM pour utiliser le DNS zonal

Après avoir déterminé que votre projet est prêt à migrer vers un DNS zonal, vous pouvez configurer le projet et les VM pour qu'ils n'utilisent que des noms DNS zonaux en mettant à jour leurs métadonnées. Activez les DNS zonaux pour vos VM en définissant l'entrée de métadonnées vmDnsSetting pour le projet ou la VM. Si vous définissez l'entrée de métadonnées vmDnsSetting pour une VM spécifique, elle remplace tout paramètre vmDnsSetting hérité des métadonnées du projet pour cette VM.

La variable vmDnsSetting accepte les paramètres suivants :

  • Recommandé : Définissez vmDnsSetting=ZonalOnly dans les métadonnées du projet. Cela signifie que vos VM ne sont accessibles que par leur nom DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal) lorsque vous utilisez des chemins de recherche. Les VM conservent toujours les chemins de recherche zonal et global, mais leur nom DNS global, qui n'inclut pas la ZONE dans le nom DNS interne, ne fonctionne plus. Seules les VM d'une même zone 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. D'autres VM peuvent accéder aux VM comportant le paramètre vmDnsSetting défini sur ZonalOnly en utilisant uniquement leur nom DNS zonal, mais elles ne peuvent pas y accéder avec leur nom DNS ou leur chemin de recherche global. Cette option est à privilégier et plus fiable à condition que vos applications soient compatibles.

    vmDnsSetting=ZonalOnly est le paramètre par défaut pour les VM de projets autonomes et de projets créés par des organisations ayant activé l'API Compute Engine après le 6 septembre 2018.

  • Définissez vmDnsSetting=GlobalDefault pour que les VM enregistrent à la fois les noms DNS globaux et zonaux, mais n'utilisez que des noms globaux comme noms de domaine par défaut et entrées de chemin de recherche. Il s'agit du paramètre par défaut pour les VM de projets autonomes et de projets créés par des organisations ayant activé l'API Compute Engine avant le 6 septembre 2018.

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

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

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

Après avoir actualisé le bail DHCP, vérifiez si votre VM est activée pour le DNS zonal.

Modifier des projets qui ne sont pas prêts pour la migration

Un projet qui n'est pas prêt à migrer signifie qu'au moins une requête DNS risquée a été effectuée dans un certain délai (dans les 30 derniers jours ou dans les 100 derniers jours, par exemple). Une requête risquée est un appel à une VM utilisant un nom DNS global (VM_NAME.c.PROJECT_ID.internal) qui ne peut pas être résolu de manière fluide à l'aide d'un nom DNS zonal (VM_NAME.ZONE.c.PROJECT_ID.internal). Les requêtes risquées peuvent présenter les attributs suivants :

  • Appel à une VM dans un autre projet
  • Appel à une VM dans une autre zone

Pour les projets comportant des requêtes risquées, un travail supplémentaire est généralement nécessaire pour éliminer toutes les résolutions DNS risquées avant la migration.

Pour les projets qui ne sont pas prêts pour la migration, procédez comme suit :

  1. Activez l'amélioration du chemin de recherche la résolution DNS entre différentes zones. Cela permet de préparer vos projets à la migration sans affecter vos ressources.
  2. Si l'ajustement du chemin de recherche ne transfère pas toutes vos requêtes interzones, vous pouvez mettre à jour manuellement les requêtes pour utiliser des noms DNS zonaux.

À propos de la fonctionnalité d'amélioration du chemin de recherche

Par défaut, la plupart des distributions Linux stockent les informations DHCP dans le fichier resolv.conf. Voici un exemple de resolv.conf file global minimal :

domain c.PROJECT_ID.internal
search c.PROJECT_ID.internal. google.internal.
nameserver 169.254.169.254

L'option de configuration search permet de répertorier les noms d'hôte à utiliser lors de la résolution DNS. Le serveur DNS tente de résoudre la requête en utilisant chacun des noms d'hôte dans le chemin de recherche jusqu'à ce qu'une correspondance DNS soit trouvée. Par exemple, si une VM appelle ping my-vm, les domaines du chemin de recherche sont ajoutés à la requête d'origine pour obtenir les noms de domaine complets, par exemple à l'aide de my-vm.c.PROJECT_ID.internal. En cas de correspondance, le résolveur DNS renvoie une adresse IP interne dans la réponse. Sinon, il tente de résoudre le nom DNS en utilisant le domaine suivant dans le chemin de recherche.

L'ajout de domaines zonaux supplémentaires dans le chemin de recherche de VM permet de préparer certains projets à la migration. Par exemple, supposons que votre VM se trouve dans la zone us-west4-c. Cette VM appelle une autre VM nommée myapp-vm, qui se trouve dans la zone us-west4-b.

  • Lorsque vous appelez la VM en tant que myapp-vm, Compute Engine tente de résoudre le nom DNS en utilisant un nom de domaine complet qui ajoute l'un des chemins de recherche au nom de la VM (par exemple, myapp-vm.c.PROJECT_ID.internal).
  • Si la VM cible utilise un DNS zonal, le nom de domaine complet de la VM cible est enregistré en tant que myapp-vm.us-west4-b.c.PROJECT_ID.internal. Par conséquent, le nom DNS ne peut pas être résolu.
  • Si vous ajoutez us-west4-b.c.PROJECT_ID.internal à la liste de recherche, le nom DNS myapp-vm peut alors être résolu lorsque us-west4-b.c.PROJECT_ID.internal est ajouté au nom de la VM.

Google fournit une fonctionnalité d'amélioration du chemin de recherche qui recherche automatiquement le nom DNS zonal d'une VM dans toutes les zones de la même région que la VM. Par conséquent, les requêtes entre différentes zones peuvent être résolues sans avoir à mettre à jour le fichier resolv.conf ni votre stratégie DHCP. L'améliorations du chemin de recherche permet de résoudre les requêtes interzones régionales jusqu'à 80 % du temps. Cette fonctionnalité devrait aider la majorité des projets comportant des requêtes à risque à migrer vers un DNS zonal.

Activez l'amélioration du chemin de recherche pour résoudre les recherches DNS entre différentes zones

Procédez comme suit pour activer la fonctionnalité d'amélioration du chemin de recherche.

  1. Exécutez la commande project-info add-metadata comme suit :

    gcloud compute project-info add-metadata  \
    --metadata=enable-search-path-improvement=true

  2. Autorisez le projet à utiliser ce paramètre pendant quelques jours, puis vérifiez la métrique de surveillance pour voir s'il existe toujours des requêtes DNS globales ou interzones à risque.

    • Si la valeur pour le projet est 0, le projet est maintenant prêt à être migré.
    • Si le projet renvoie une valeur non nulle, modifiez tous les noms de requête DNS globaux pour utiliser le nom de domaine complet zonal, comme décrit dans la section suivante.

Mettre à jour manuellement les requêtes afin d'utiliser des noms DNS zonaux

Si l'utilisation de la fonctionnalité d'amélioration du chemin de recherche pour ajouter des domaines zonaux supplémentaires dans le chemin de recherche de noms DNS ne transfère pas toutes vos requêtes interzones, vous pouvez utiliser l'explorateur de journaux pour afficher votre utilisation du DNS global dans le projet.

Pour identifier les requêtes DNS globales à modifier manuellement pour utiliser des noms de domaine complets zonaux, procédez comme suit :

  1. Suivez la procédure décrite dans la section Déterminer si votre projet est prêt à migrer pour afficher votre utilisation du DNS global pour un projet. Utilisez l'explorateur de journaux pour accéder aux requêtes DNS et les interroger pour les VM de votre projet.

  2. 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

  3. Utilisez les informations de jsonPayload 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.

Après avoir mis à jour les requêtes DNS globales pour utiliser le DNS zonal :

  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 confirmer que toutes les requêtes DNS à risque ont bien été supprimées.

Vérifier que la migration du projet vers le DNS zonal est terminée

  1. Répétez les étapes décrites dans la section Vérifier si votre projet utilise le DNS global par défaut.

  2. Pour vérifier que les métadonnées du projet ont été mises à jour, vous pouvez exécuter la commande suivante :

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

    La commande doit renvoyer ZONAL_ONLY.

  3. Vérifiez que le nom DNS interne d'une VM utilise un nom DNS zonal.

  4. Pour vérifier que la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly est appliquée, vous pouvez :

    1. Créer un projet dans le dossier ou l'organisation.
    2. Créer et démarrer une instance de VM
    3. Vérifier si la VM utilise un nom DNS zonal

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 organisation, projet, VM ou conteneur.

Rétablir l'utilisation du DNS global pour une organisation ou un dossier

Pour rétablir l'utilisation du DNS global pour une organisation ou un dossier, procédez comme suit :

  1. Désactivez la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly au niveau de l'organisation ou du dossier. Pour savoir comment modifier cette règle, consultez la page Appliquer le DNS zonal par défaut pour les nouveaux projets.

    Définissez l'application de Définit le paramètre DNS interne des nouveaux projets sur le DNS zonal uniquement sur Désactivé.

  2. Si vous souhaitez revenir à l'utilisation du DNS global pour l'ensemble de l'organisation, vérifiez qu'aucun des dossiers de l'organisation n'applique la règle d'administration constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Utilisez les sections suivantes pour vérifier que le DNS global est configuré pour les projets, les VM et les conteneurs.

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 ou d'une VM, consultez la section Définir des métadonnées personnalisées.

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

  3. Actualisez le bail DHCP sur chaque VM. Vous pouvez actualiser le bail en redémarrant la VM, en attendant l'expiration du bail ou en exécutant l'une des commandes suivantes :

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

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

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

  1. Ajoutez ce qui suit aux métadonnées de la VM : vmDnsSetting=GlobalDefault.

    Pour en savoir plus sur la définition des valeurs de métadonnées d'une VM, consultez la page Définir des métadonnées personnalisées.

  2. Pour forcer la modification de la configuration DNS, redémarrez le réseau de la VM à 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.

Masquer la bannière de migration DNS zonale dans la console Google Cloud

Vous pouvez cliquer sur le bouton Ignorer dans la bannière de notification de migration DNS zonal qui apparaît sur la page Instances de VM de la console Google Cloud. Cela empêche la bannière de s'afficher indéfiniment pour le projet.

Si vous avez ignoré la bannière, mais que vous souhaitez l'afficher à nouveau, contactez Cloud Customer Care pour obtenir de l'aide.

Étapes suivantes