Utilizzare il DNS di zona per il tipo di DNS interno

Il DNS di zona riduce il rischio di interruzioni tra regioni e migliora l'affidabilità complessiva dei progetti su Compute Engine. Utilizzo di un ambiente a livello di zona Il DNS riduce l'impatto degli errori single-point che possono verificarsi quando utilizzando il DNS globale.

Prima di iniziare

  • Se non l'hai già fatto, configura l'autenticazione. L'autenticazione è la procedura mediante la quale la tua identità viene verificata per l'accesso alle API e ai servizi Google Cloud. Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi eseguire l'autenticazione Compute Engine come segue.

    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

      Per utilizzare gli esempi dell'API REST in questa pagina in un ambiente di sviluppo locale, utilizza le credenziali fornite a gcloud CLI.

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

        gcloud init

      Per ulteriori informazioni, vedi Esegui l'autenticazione per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per eseguire la migrazione al DNS di zona, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Crea o aggiorna un criterio dell'organizzazione: Amministratore criteri organizzazione (roles/orgpolicy.policyAdmin) sulla cartella o sull'organizzazione
  • Determina se una cartella è pronta per la migrazione al DNS zonale: Browser (roles/browser) nella cartella o nell'organizzazione
  • Esegui la migrazione di un progetto per utilizzare il DNS di zona: Project Editor (roles/resourcemanager.projectEditor) nel progetto
  • Esegui la migrazione delle VM al DNS di zona all'interno di un progetto: Amministratore istanze Compute (v1) (roles/compute.instanceAdmin.v1) del progetto
  • Se la VM utilizza un account di servizio: Utente account di servizio (roles/iam.serviceAccountUser) sull'account di servizio o sul progetto

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Questi ruoli predefiniti delle autorizzazioni necessarie per eseguire la migrazione al DNS di zona. Per vedere le autorizzazioni esatte obbligatorie, espandi la sezione Autorizzazioni obbligatorie:

Autorizzazioni obbligatorie

Per eseguire la migrazione a DNS di zona sono necessarie le seguenti autorizzazioni:

  • Imposta un vincolo dei criteri dell'organizzazione: orgpolicy.*
  • Determina se una cartella è pronta per la migrazione al DNS di zona:
    • resourcemanager.folders.get
    • resourcemanager.folders.list
    • resourcemanager.organizations.get
    • resourcemanager.projects.get
    • resourcemanager.projects.list
  • Controlla i nomi DNS globali e i metadati della VM: compute.projects.get
  • Imposta i metadati su una VM: compute.instances.setMetadata
  • Imposta metadati a livello di progetto: compute.projects.setCommonInstanceMetadata
  • Se le VM utilizzano account di servizio: iam.serviceAccounts.actAs

Potresti anche ottenere queste autorizzazioni con ruoli personalizzati o altri ruoli predefiniti.

Informazioni sui nomi DNS

I nomi DNS di zona includono il nome della VM, la zona in cui si trova e il progetto proprietario della VM. I nomi DNS globali non includono la zona in cui si trova la VM.

Quando effettui una chiamata a una VM utilizzando un nome DNS globale:

  • Il nome viene risolto a livello globale.
  • Ogni VM deve avere un nome DNS univoco.
  • Quando crei una nuova VM, il nome DNS della VM deve essere controllato rispetto a tutti gli altri nomi DNS globali registrati nello stesso progetto per evitare una collisione dei nomi DNS.

Quando effettui una chiamata a una VM utilizzando un nome DNS di zona:

  • Il nome è risolto all'interno di una zona.
  • I nomi DNS zonali devono essere univoci all'interno di una zona. Ad esempio, my-vm.zone1.google.com deve essere univoco per zone1. Tuttavia, a differenza dei nomi DNS globali, my-vm.zone2.google.com è anche un nome DNS valido quando si utilizza il DNS di zona.

Il DNS di zona è il metodo di risoluzione DNS interno predefinito per Compute Engine per le organizzazioni create dopo il 6 settembre 2018. I nomi DNS a livello di zona in una zona funzionano indipendentemente dalle altre zone, consentendoti di creare applicazioni multiregionali più tolleranti agli errori con caratteristiche di disponibilità migliori. Non è previsto alcun costo per l'utilizzo del DNS di zona. DNS zonale è distinto da Cloud DNS.

I progetti creati prima del 6 settembre 2018 sono stati configurati per utilizzare il DNS globale predefinito. Questi progetti possono continuare a usare il DNS globale, ma Google ha consiglia alle organizzazioni di eseguire la migrazione di questi progetti a DNS di zona per impedire che le interruzioni del servizio in un'altra regione influiscano sulle risorse delle regioni locali. L'utilizzo del DNS a livello di zona offre un'affidabilità superiore rispetto al DNS globale isolando gli errori nella registrazione DNS nelle singole zone. In questo modo si riduce l'impatto dei guasti singoli. Se si verifica un'interruzione in Google Cloud, viene isolata singola zona, le risorse e i costi non ne risentiranno in modo significativo.

Esegui la migrazione dal DNS globale al DNS di zona

Il DNS di zona ha sostituito il DNS globale come tipo di DNS interno predefinito per tutte le nuove organizzazioni integrate in Google Cloud dopo il 6 settembre 2018. Se i tuoi progetti esistenti utilizzano ancora il DNS globale, Google consiglia vivamente di passare a nomi DNS di zona. Se non esegui la migrazione al DNS di zona, rischi di riscontrare i seguenti problemi:

  • Impossibile creare nuove VM in qualsiasi regione con errori del control plane, in cui hai o avevi un progetto.
  • Incapacità di utilizzare alcuni servizi Compute Engine critici per i tuoi carichi di lavoro. come la scalabilità automatica o riparazione automatica per gruppi di istanze gestite (MIG).

Un approccio alternativo per migliorare l'affidabilità dei carichi di lavoro che utilizzano il DNS globale è eseguire la migrazione alle zone private Cloud DNS. L'utilizzo delle zone private Cloud DNS rimuove il controllo dell'unicità del nome richiesto dal DNS globale e isola gli errori per consentire la risoluzione dei nomi DNS. Per ulteriori informazioni su questa opzione, consulta la documentazione di Cloud DNS o contatta l'Assistenza clienti Cloud o il rappresentante del team dedicato al tuo account. Per informazioni su come Cloud DNS gestisce le interruzioni a livello di zona e di regione, vedi Architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.

Panoramica del processo di migrazione

Il processo di migrazione del DNS a livello di zona prevede due livelli:

  • A livello di organizzazione o di cartella: determina l'idoneità della cartella o dell'organizzazione. per eseguire la migrazione al DNS di zona. Impedisci ai nuovi progetti di utilizzare le impostazioni DNS. Eseguita amministratore dell'organizzazione.
  • A livello di progetto: esegui la migrazione di un singolo progetto dal DNS globale a quello di zona DNS. In genere viene eseguita dal proprietario del progetto.

L'immagine mostra un diagramma di flusso dei passaggi necessari per la migrazione a DNS di zona

In genere, la procedura prevede le seguenti fasi:

  1. Controlla l'idoneità di cartelle o organizzazioni per la migrazione a DNS di zona.
  2. Se la cartella o l'organizzazione è pronta per la migrazione al DNS di zona:
    1. L'amministratore dell'organizzazione imposta un criterio dell'organizzazione per la cartella o un'organizzazione per impedire l'uso futuro del DNS globale.
    2. I proprietari dei progetti eseguono la migrazione dei progetti in modo che utilizzino il DNS di zona.
  3. Se la cartella o l'organizzazione non è pronta per la migrazione al DNS di zona:
    1. I proprietari dei progetti eseguono la migrazione dei progetti pronti al DNS di zona.
    2. I proprietari dei progetti esaminano l'utilizzo del DNS globale nei progetti non pronti.
    3. I proprietari del progetto applicano miglioramenti al percorso di ricerca o altre modifiche da apportare il progetto pronto per la migrazione al DNS di zona.
    4. L'amministratore dell'organizzazione ricontrolla lo stato della cartella o dell'organizzazione l'idoneità per la migrazione del DNS a livello di zona.

Limitazioni

  • Il DNS di zona non sostituisce completamente il DNS globale. Là esistono alcuni tipi di query (interzona) che potrebbero non essere risolti DNS con ricerca automatica del percorso di ricerca. Verifica l'idoneità della migrazione della tua organizzazione folder e progetti per creare assicurarsi che siano compatibili con il DNS di zona prima della migrazione.

  • La procedura di migrazione dal DNS globale al DNS di zona introduce un nuovo dominio (ZONE.c.PROJECT_ID.internal) nel percorso di ricerca. Se una VM che esegue Linux o Unix ha già 6 domini nella di ricerca, assicurati che la VM sia in esecuzione con glibc 2.26 o versioni successive. I client DHCP con glibc 2.25 e versioni precedenti supportano solo fino a 6 ricerche domini, quindi potrebbe esserci il rischio di ignorare un dominio di ricerca esistente. Questo limite non si applica alle VM che utilizzano:

    • Immagini Windows
    • Immagini Container-Optimized OS
    • Immagini Debian 10 o versioni successive
    • Fedora CoreOS (versione 27 o successive)
    • Immagini RHEL 8 o successive
    • Immagini della release Ubuntu 18.04 o successive
    • Altre immagini con glibc 2.26 o versioni successive

  • L'attivazione del miglioramento del percorso di ricerca aggiunge altri domini di ricerca, ad esempioNEIGHBOR_ZONE.c.PROJECT_ID.internal. Come indicato nella limitazione precedente, i domini esistenti nel percorso di ricerca potrebbero essere rimossi se il limite di domini del percorso di ricerca viene superato quando si utilizza glibc versione 2.25 o precedenti.

  • Per utilizzare i miglioramenti del percorso di ricerca con Google Kubernetes Engine, devi utilizzare la versione di Google Kubernetes Engine 1.26 o successiva.

Controlla la versione di glibc

Per controllare la versione di glibc utilizzata dalla tua VM:

  1. Connettiti alla VM Linux.
  2. Esegui ldd --version per ottenere la versione glibc.

Controllare il numero di domini di ricerca se si utilizza glibc 2.25 o versioni precedenti

  1. Connettiti alla VM Linux.

  2. Controlla se la VM Linux ha già 6 domini nel percorso di ricerca. Puoi eseguire cat /etc/resolv.conf per visualizzare queste informazioni.

Passaggi per gli amministratori dell'organizzazione

In qualità di amministratore dell'organizzazione, devi eseguire le seguenti attività:

Controllare se l'organizzazione utilizza il DNS globale per impostazione predefinita

Il tipo predefinito del nome DNS interno per la tua organizzazione è determinato dalla data di creazione dell'organizzazione e dall'applicazione del vincolo constraints/compute.setNewProjectDefaultToZonalDNSOnly del criterio dell'organizzazione.

Console

  1. Vai alla pagina IAM e amministrazione>Identità e organizzazione nella console.

    Vai a Identità e Organizzazione

  2. Controlla la data di registrazione dell'organizzazione.

    Uno screenshot della sezione Identità e Pagina della console dell'organizzazione che mostra la data di completamento della registrazione

    • Se la tua organizzazione è stata creata dopo il 6 settembre 2018, i tuoi un'organizzazione usa il DNS di zona per impostazione predefinita. In questo caso, nessuna azione è obbligatorio.
    • Se la tua organizzazione è stata creata prima del 6 settembre 2018, la tua organizzazione utilizza il DNS globale per impostazione predefinita e la migrazione deve essere eseguita al DNS di zona.

  3. Se la tua organizzazione utilizza il DNS globale per impostazione predefinita, controlla se un vincolo dei criteri dell'organizzazione imposta il tipo DNS predefinito per tutti i progetti appena creati su DNS di zona.

    1. Vai alla sezione IAM e Pagina Amministrazione>Criteri dell'organizzazione nella console Google Cloud.
    2. Nel campo Filtro, inserisci constraints/compute.setNewProjectDefaultToZonalDNSOnly.
    3. Se il vincolo è configurato, fai clic sul nome Imposta l'impostazione del DNS interno per i nuovi progetti su Solo DNS di zona.
    4. Nella pagina Dettagli norme, controlla lo Stato.
      • Se lo stato è Enforced, significa che il tipo di DNS interno predefinito è il DNS di zona per tutti i nuovi progetti creati nell'organizzazione.
      • In caso contrario, il tipo DNS predefinito per il progetto viene comunque determinato dalla data di creazione dell'organizzazione.
    5. Se il vincolo non è stato configurato per l'organizzazione, il tipo DNS predefinito per il progetto è determinato dal momento di creazione dell'organizzazione, come descritto nel primo passaggio.

gcloud

Usa il comando organizations describe e il comando resource-manager org-policies list per determinare il tipo DNS predefinito per un'organizzazione.

  1. Controlla il valore dei metadati creationTime dell'organizzazione.

    gcloud organizations describe ORGANIZATION_ID

    Sostituisci ORGANIZATION_ID con il numero di ID dell'organizzazione o con il nome di dominio dell'organizzazione.

    • Se la tua organizzazione è stata creata dopo il 6 settembre 2018, i tuoi un'organizzazione usa il DNS di zona per impostazione predefinita. In questo caso, la tua organizzazione utilizza già il DNS zonale e non è richiesta alcuna ulteriore azione.
    • Se la tua organizzazione è stata creata prima del 6 settembre 2018, la tua organizzazione utilizza il DNS globale per impostazione predefinita e dovrebbe a DNS di zona.

  2. Se la tua organizzazione utilizza il DNS globale per impostazione predefinita, determina se il vincolo del criterio dell'organizzazione è configurato per impostare il tipo DNS predefinito per tutti i nuovi progetti creati al DNS di zona.

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

    Nell'output, cerca constraints/compute.setNewProjectDefaultToZonalDNSOnly.

    1. Se il vincolo è configurato e Status è Enforced, il tipo di DNS interno predefinito è DNS di zona per tutti i nuovi progetti creato nell'organizzazione.
    2. Se il vincolo non è stato configurato per l'organizzazione o non viene applicato, il tipo DNS interno predefinito è determinato dal momento di creazione dell'organizzazione, come descritto nel primo passaggio.

Determina quali progetti di una cartella o di un'organizzazione utilizzano il DNS globale

Per determinare quanti progetti utilizzano il DNS globale, ti consigliamo di utilizzare BigQuery per creare una tabella che elenchi i progetti relativi per la tua organizzazione e i relativi metadati. Puoi quindi utilizzare questa tabella per eseguire una query che mostri il conteggio totale dei progetti che utilizzano il DNS globale.

  1. Crea un set di dati BigQuery.

  2. Esporta i metadati degli asset per la tua organizzazione in una tabella BigQuery.

    1. Assicurati che l'API Cloud Asset Inventory sia abilitata.
    2. Configura le autorizzazioni obbligatorie per utilizzare l'API Cloud Asset Inventory.

    3. Utilizza il seguente comando gcloud CLI per esportare compute.googleapis.com/Project asset:

      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

      Sostituisci quanto segue:

      • ORGANIZATION_ID: il numero dell'ID organizzazione
      • PROJECT_ID: l'ID progetto
      • DATASET_ID: il nome del set di dati BigQuery
      • TABLE_NAME: la tabella in cui esporti i metadati. Se la tabella non esiste, viene creata.

  3. Vai alla pagina BigQuery nella nella console Google Cloud.

  4. Seleziona Crea una nuova query.

  5. Nell'area di testo dell'editor di query, inserisci la seguente query GoogleSQL e poi fai clic su  Esegui.

    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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto
    • DATASET_ID: il nome del set di dati BigQuery
    • TABLE_NAME: la tabella contenente i metadati esportati del passaggio 2.

    I progetti con il valore ZONAL_ONLY per vmDnsSetting hanno il DNS di zona configurato. In caso contrario, i progetti sono impostati per utilizzare il DNS globale.

  6. (Facoltativo) Per una visualizzazione dettagliata di vmDnsSetting per ogni inserisci la seguente query GoogleSQL e quindi fai clic su  Esegui.

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

Determina se una cartella è pronta per la migrazione al DNS di zona

Questo passaggio utilizza uno script bash e la tabella BigQuery creata nella sezione precedente per determinare l'idoneità alla migrazione della cartella.

  • La cartella è pronta se tutti i progetti non hanno eseguito query incompatible with zonal DNS negli ultimi 30 giorni.
  • Se una cartella non è pronta per la migrazione, lo script risponde con la ID progetto nella cartella che la rendono non pronta per la migrazione. I progetti in questo elenco di risultati non sono ancora compatibili con DNS di zona e richiedono ulteriori azioni.

Completa i seguenti passaggi:

  1. Recupera l'ID cartella. Se non conosci l'ID cartella:
    1. Nella console Google Cloud, vai alla Pagina Risorse gestite:
    2. Applica il filtro Name:FOLDER_NAME per ottenere ID cartella.

  2. Esegui una query sulla tabella BigQuery con il file compute.Project assets.

    Consulta Determinare quali progetti in una cartella o un'organizzazione utilizzano il DNS globale per istruzioni su come creare la tabella BigQuery.

    Inserisci la seguente query GoogleSQL, quindi Fai clic su  Esegui:

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

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto
    • DATASET_ID: il nome del set di dati BigQuery
    • TABLE_NAME: la tabella contenente i metadati esportati
    • FOLDER_NUMBER: il numero ID cartella

  3. Copia l'elenco di ID progetto e salvalo in un file.

  4. Esegui lo script bash seguente. Lo script esegue l'iterazione tramite gli ID progetto nel file salvato per determinare se una cartella è pronta per la migrazione.

#!/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

Sostituisci FILENAME con il nome del file in cui hai salvato l'elenco di ID progetto.

Comunica i risultati dell'analisi dell'idoneità della migrazione ai proprietari del progetto:

Applica il DNS di zona per impostazione predefinita per i nuovi progetti

Se viene creato un nuovo progetto in un'organizzazione creata prima del 6 settembre 2018, per impostazione predefinita il tipo di DNS interno utilizzato dal progetto è DNS globale. Per isolare eventuali errori nella registrazione DNS alle singole zone, puoi applicare il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly a livello di organizzazione o di cartella.

Quando imposti un criterio dell'organizzazione per eseguire l'override del tipo DNS interno predefinito, i progetti appena creati utilizzano il DNS di zona per impostazione predefinita. I criteri dell'organizzazione non influiscono sui progetti esistenti in cui l'API Compute Engine è già abilitata. Per passare da un progetto esistente all'altro DNS, consulta Passaggio dei progetti esistenti al DNS di zona.

Per applicare questa modifica ai criteri, devi disporre dell'accesso a livello di cartella o organizzazione con il ruolo IAM roles/orgpolicy.policyAdmin.

Per impostare il criterio dell'organizzazione per una cartella o un'organizzazione:

  1. Accedi alla console Google Cloud come super amministratore di Google Workspace o Cloud Identity.

  2. Nella console, vai alla pagina Criteri dell'organizzazione.

    Vai a Criteri dell'organizzazione

  3. Seleziona la cartella o l'organizzazione per cui vuoi per visualizzare i criteri dell'organizzazione. La console Google Cloud mostra un elenco dei vincoli dei criteri dell'organizzazione disponibili. L'elenco potrebbe estendersi più pagine.

  4. Per trovare il criterio per applicare il DNS di zona, fai clic su Filtra e seleziona Nome, quindi imposta il nome del filtro su Configura l'impostazione del DNS interno per i nuovi progetti su Solo DNS di zona.

  5. Fai clic sul nome del criterio per visualizzarne la dettagli.

    La pagina dei dettagli delle norme fornisce informazioni sulla limitazione e su come viene applicata.

    Per impostazione predefinita, l'applicazione non è definita per una cartella o un'organizzazione. Tuttavia, se per una cartella principale è stata definita un'applicazione forzata, viene ereditata dalla cartella padre più vicina un'applicazione definita. Per ulteriori informazioni, vedi Informazioni sulla valutazione della gerarchia.

  6. Per personalizzare il criterio dell'organizzazione, fai clic su Modifica.

  7. Nella pagina di modifica, seleziona Personalizza.

  8. In Applicazione forzata, seleziona On.

    Imposta il tipo di DNS interno predefinito per tutti i nuovi progetti in dell'organizzazione al DNS di zona.

  9. Fai clic su Salva.

Per convalidare la modifica dei criteri dell'organizzazione, puoi creare un nuovo progetto nella cartella o nell'organizzazione, quindi creare e avviare un'istanza VM e verificare se la VM è abilitata per il DNS zonale.

Se è necessario un DNS globale per risolvere una query sul nome DNS integrata nel carico di lavoro, puoi eseguire il rollback a livello di organizzazione o cartella a disattivare l'applicazione forzata.

Cartelle esenti non pronte per la migrazione al DNS di zona

Se in un'organizzazione sono presenti solo alcune cartelle non pronte per la migrazione al DNS zonale, ti consigliamo di impostare un criterio dell'organizzazione a livello di organizzazione, ma di concedere un'esenzione per le cartelle non ancora pronte per la migrazione.

L'esempio seguente mostra una gerarchia dell'organizzazione in cui solo una cartella non è pronto per la migrazione al DNS di zona.

organization/Example.com

  • folders/101
    • projects/301 (pronto per la migrazione)
    • folders/201
      • projects/303 (NON pronto)
      • projects/304 (pronta per la migrazione)
  • folders/102
    • projects/302 (pronta per la migrazione)

Per escludere una cartella dal criterio dell'organizzazione, completa la i seguenti passaggi per impostare l'opzione di applicazione forzata per il criterio a livello di cartella su Off.

  1. Accedi alla console Google Cloud come super amministratore di Google Workspace o Cloud Identity.

  2. Nella console, vai alla pagina Criteri dell'organizzazione.

    Vai a Criteri dell'organizzazione

  3. Fai clic su Seleziona e poi seleziona le cartelle da esentare dal criterio dell'organizzazione.

    La console Google Cloud mostra un elenco di vincoli dei criteri dell'organizzazione per cartella su una o più pagine.

  4. Per trovare il vincolo del criterio dell'organizzazione che applica il DNS di zona:

    1. Fai clic su Filtra.
    2. Seleziona Nome.
    3. Imposta il nome del filtro su Imposta l'impostazione del DNS interno per i nuovi progetti su Solo DNS di zona.

  5. Fai clic sul nome del vincolo dei criteri dell'organizzazione per aprire la pagina Dettagli criteri.

  6. Fai clic su Modifica.

  7. Nella pagina Modifica, seleziona Personalizza.

  8. In Applicazione, seleziona Off per disattivare l'applicazione forzata di blocco. Ciò significa che il tipo di DNS interno predefinito I progetti nella cartella sono determinati in base alla data di creazione dell'organizzazione.

  9. Fai clic su Salva.

Per ulteriori informazioni sulla personalizzazione dei vincoli dei criteri dell'organizzazione, consulta Personalizzazione dei criteri per i vincoli booleani nella documentazione di Resource Manager.

Passaggi per il proprietario del progetto

In qualità di proprietario del progetto, durante la migrazione eseguirai le seguenti attività da DNS globale a DNS di zona:

I proprietari del progetto possono anche completare le seguenti attività facoltative:

Controlla se il progetto utilizza il DNS globale per impostazione predefinita

Controlla i tuoi progetti per verificare se devono eseguire la migrazione dall'utilizzo Da DNS a DNS di zona. Devi eseguire la migrazione solo dei progetti configurati per utilizzare il DNS globale come predefinito per tutti i nomi DNS interni creati all'interno del progetto.

Console

  1. Nella console Google Cloud, vai alla pagina Metadati.

    Vai a Metadati

  2. Nella scheda Metadati, visualizza l'impostazione vmdnssetting. Il valore indica se il progetto utilizza il DNS globale per impostazione predefinita.

    • GlobalDefault: nel progetto è abilitato il DNS globale.
    • ZonalOnly: il progetto ha il DNS di zona abilitato. Non è necessario eseguire la migrazione di questo progetto.

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. Esegui il seguente comando gcloud CLI per controllare il valore di vmDnsSetting.

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

    Sostituisci PROJECT_ID con il nome del progetto.

    Il valore restituito indica se il progetto utilizza il DNS globale tramite predefinito.

    • GLOBAL_DEFAULT: il progetto ha a livello globale DNS abilitato.
    • ZONAL_ONLY: il progetto ha il DNS di zona attivo. Non è necessario eseguire la migrazione di questo progetto.

REST

Controlla il valore di vmDnsSetting utilizzando il metodo projects.get. In questo esempio viene utilizzato un parametro di query fields per includere solo i campi che che vuoi visualizzare.

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

Sostituisci PROJECT_ID con l'ID progetto.

Il valore di vmDnsSetting indica se il progetto utilizza il DNS globale per impostazione predefinita.

  • GLOBAL_DEFAULT: il progetto ha il DNS globale abilitato.
  • ZONAL_ONLY: nel progetto è abilitato il DNS di zona. Per questo progetto non è necessaria la migrazione.

Determina se il progetto è pronto per la migrazione

Nella console Google Cloud, nella pagina Istanze VM, se il tuo progetto deve eseguire la migrazione al DNS di zona, dovresti visualizzare un banner di notifica relativo alla migrazione al DNS di zona.

Quando visualizzi la pagina Istanze VM per il tuo progetto, se il progetto è pronto per la migrazione (compatibile con il DNS di zona), il banner include un consiglio per utilizzare il DNS di zona. Questo consiglio si basa sull'utilizzo del DNS interno nel progetto, ma è limitato agli ultimi 100 giorni.

Uno screenshot del banner "Pronto per la migrazione al DNS di zona" nella console

Se il progetto non è pronto per la migrazione al DNS di zona, viene visualizzato un banner diverso.

Uno screenshot del banner "Non pronto per la migrazione al DNS di zona" nella console

Per visualizzare l'utilizzo del DNS globale, fai clic sul pulsante Visualizza utilizzo DNS globale. Questo ti porta alla pagina Esplora log nella console Google Cloud. In questa pagina puoi visualizzare i log delle query di blocco della migrazione degli ultimi 30 giorni. Quando fai clic sul link nel banner, viene visualizzata la pagina Esplora log. configurato in modo da utilizzare il filtro logName per eseguire il pull delle query DNS globali e relativi campi di log.

Per visualizzare queste informazioni senza utilizzare il pulsante nel banner, segui questi passaggi:

  1. Nella console Google Cloud, vai alla pagina Esplora log.

    Vai a Esplora log

  2. Seleziona il progetto.

  3. Applica i filtri per nome della risorsa e del log:

    1. Fai clic su Risorsa.
    2. Nella finestra di dialogo Seleziona risorsa, seleziona Istanza VM e poi fai clic su Applica.
    3. Fai clic su Nome log.

    4. Nella finestra di dialogo Seleziona nomi log, seleziona gdnsusage e quindi fai clic su Applica.

In alternativa, puoi inserire quanto segue nel campo di query:

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

Tieni traccia dell'utilizzo del DNS globale all'interno del progetto

Sono state create due metriche per monitorare l'idoneità del progetto alla migrazione DNS di zona:

  • zonal_dns_ready: il numero aggregato di query completate nell'intervallo di tempo specificato che possono essere risolte utilizzando il DNS di zona anziché il DNS globale.
  • zonal_dns_risky: il numero aggregato di query completate nell'intervallo di tempo specificato che non possono essere risolte utilizzando il DNS zonale. Per questi delle query, Compute Engine non è stato in grado di determinare l'IP interno relativo dell'attuale nome host. Se questa metrica ha un valore diverso da zero, il progetto non è pronto per la migrazione.

L'intervallo di tempo utilizzato da queste metriche è un periodo di 100 giorni.

Per visualizzare queste metriche, utilizza Metrics Explorer nella console Google Cloud.

  1. Nella console Google Cloud, vai alla pagina  Esplora metriche:

    Vai a Esplora metriche

    Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.

  2. Sul lato destro della barra degli strumenti contenente il campo Seleziona una metrica, fai clic su Editor di codice, MQL o PromQL.

  3. Se il campo di immissione della query non si chiama Query MQL, nell'angolo in basso a destra del campo di immissione della query, seleziona MQL per Lingua.

  4. Nel campo di immissione della query, inserisci il seguente testo esattamente come appare:

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

  5. Fai clic sul pulsante Esegui query.

    La console Google Cloud mostra un grafico delle due metriche (zonal_dns_ready e zonal_dns_risky) e il numero corrispondente di query eseguite nel periodo di tempo per ogni metrica.

    Screenshot del grafico per le metriche di utilizzo del DNS globali

  6. Verifica il valore della metrica zonal_dns_risky.

Esegui la migrazione dei progetti pronti al DNS di zona

In generale, puoi utilizzare la seguente procedura di migrazione:

  1. Controlla le tue applicazioni e aggiornale per risolvere i problemi di compatibilità con le impostazioni solo per le zone:
    • Se hai un'applicazione che utilizza nomi DNS globali hardcoded, aggiornala in modo da utilizzare nomi DNS zonali.
    • Se un'applicazione utilizza i nomi delle VM per accedere alle VM in un'altra zona, che il nome della zona di destinazione venga aggiunto nella query, ad esempio: DESTINATION_VM_NAME.DESTINATION_ZONE_NAME.
    • Per risolvere i nomi DNS delle VM nei progetti di servizio che utilizzano una rete VPC condivisa, devi utilizzare il nome di dominio completo (FQDN) di zona delle VM.

  2. Fai clic sul pulsante Utilizza DNS zonale nel banner della pagina Istanze VM della console Google Cloud. In questo modo, i metadati del progetto vengono modificati in modo da utilizzare il DNS di zona.

    In alternativa, puoi modificare manualmente i progetti per utilizzare il DNS di zona predefinito, come descritto in Aggiorna manualmente progetti e VM per utilizzare il DNS di zona e Impedisci ai nuovi progetti di utilizzare il DNS globale per impostazione predefinita.

Aggiorna manualmente progetti e VM per utilizzare il DNS di zona

Dopo aver stabilito che il progetto è pronto per la migrazione al DNS di zona, puoi configurare il progetto e le VM in modo che utilizzino solo i nomi DNS di zona aggiornando e i relativi metadati. Abilita il DNS di zona per le tue VM impostando la voce dei metadati vmDnsSetting per il progetto o la VM. Se imposti la voce di metadati vmDnsSetting per una VM specifica, questa sostituisce qualsiasi impostazione vmDnsSetting ereditata dai metadati del progetto per la VM in questione.

La variabile vmDnsSetting supporta le seguenti impostazioni:

  • Consigliato: imposta vmDnsSetting=ZonalOnly nei metadati del progetto. Ciò significa che puoi accedere alle VM solo tramite i relativi nomi DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal) quando utilizzi i percorsi di ricerca. Le VM mantengono entrambi i percorsi di ricerca sia a livello di zona sia a livello globale, ma i relativi nomi DNS globali, che non includono ZONE come parte del nome DNS interno, non funzionano più. Quando questa impostazione è attiva, solo le VM nella stessa zona e nello stesso progetto possono accedere l'una all'altra utilizzando il nome globale. Altre VM possono accedere alle VM con vmDnsSetting impostato su ZonalOnly utilizzando solo i propri nomi DNS di zona e non può accedere a queste VM utilizzando i nomi DNS globali o i percorsi di ricerca. Questa è l'opzione preferita e più affidabile, a condizione che le tue applicazioni la supportino.

    L'impostazione vmDnsSetting=ZonalOnly è l'impostazione predefinita per le VM in progetti autonomi e progetti creati in un'organizzazione che ha abilitato l'API Compute Engine dopo il 6 settembre 2018.

  • Imposta vmDnsSetting=GlobalDefault in modo che le VM registrino sia i nomi DNS globali sia quelli di zona, ma utilizzino solo i nomi DNS globali come nomi di dominio predefiniti e voci del percorso di ricerca. Questa è l'impostazione predefinita per le VM nei progetti autonomi e nei progetti creati in un'organizzazione che ha attivato l'API Compute Engine prima del 6 settembre 2018.

Per informazioni su come impostare i metadati di progetto o i valori dei metadati della VM, consulta la sezione Impostazione di metadati personalizzati.

Dopo aver configurato la voce dei metadati vmDnsSetting per una VM, aggiorna il contratto DHCP sulla VM. Puoi aggiornare il lease riavviando la VM, aspettando che scada o eseguendo uno dei seguenti comandi:

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

Dopo aver aggiornato il lease DHCP, verifica se la tua VM è abilitata per il DNS di zona.

Modifica dei progetti non pronti per la migrazione

Un progetto non è pronto per la migrazione se è stata eseguita almeno una query DNS rischiosa in un determinato periodo di tempo, ad esempio negli ultimi 30 o 100 giorni. Una query rischiosa è una chiamata a una VM che utilizza un nome DNS globale (VM_NAME.c.PROJECT_ID.internal) che non può essere risolto senza problemi utilizzando un nome DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal). Le query rischiose potrebbero avere i seguenti attributi:

  • Effettuare una chiamata a una VM in un altro progetto
  • Effettuare una chiamata a una VM in un'altra zona

Per i progetti con query rischiose, in genere è necessario un lavoro aggiuntivo per eliminare tutte le ricerche DNS rischiose prima della migrazione.

Per i progetti non pronti per la migrazione, completa la seguenti passaggi:

  1. Attiva il miglioramento dei percorsi di ricerca per risolvere le ricerche di nomi DNS tra zone. In questo modo, i tuoi progetti potrebbero essere pronti per la migrazione senza influire sulle tue risorse.
  2. Se l'aggiustamento del percorso di ricerca non esegue la transizione di tutte le query tra zone, puoi aggiornare manualmente le query in modo che utilizzino i nomi DNS zonali.

Informazioni sulla funzionalità di miglioramento del percorso di ricerca

Per impostazione predefinita, la maggior parte delle distribuzioni Linux memorizza le informazioni DHCP in resolv.conf. Di seguito è riportato un resolv.conf file globale minimo:

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

L'opzione di configurazione search viene utilizzata per elencare i nomi host da usare quando una risoluzione DNS. Il server DNS tenta di risolvere la query utilizzando ciascuno dei nomi host nel percorso di ricerca fino a quando non viene trovata una corrispondenza del record DNS. Ad esempio, se una VM chiama ping my-vm, i domini nel percorso di ricerca vengono aggiunti alla query originale per ottenere i nomi di dominio completi (FQDN), ad esempio utilizzando my-vm.c.PROJECT_ID.internal. Se esiste una corrispondenza, il resolver DNS restituisce un indirizzo IP interno nella risposta. Altrimenti, tenterà di risolvere il nome DNS utilizzando il dominio successivo in del percorso di ricerca.

L'aggiunta di domini di zona extra nel percorso di ricerca delle VM può preparare alcuni progetti per la migrazione. Ad esempio, supponiamo che la tua VM si trovi nella zona us-west4-c. Questa VM effettua una chiamata a un'altra VM denominata myapp-vm che si trova nella zona us-west4-b.

  • Quando effettui una chiamata alla VM come myapp-vm, Compute Engine tenta di risolvere il nome DNS utilizzando un FQDN che aggiunge uno dei percorsi di ricerca al nome della VM, ad esempio myapp-vm.c.PROJECT_ID.internal.
  • Se la VM di destinazione utilizza il DNS di zona, il FQDN della VM di destinazione è registrato come myapp-vm.us-west4-b.c.PROJECT_ID.internal. Di conseguenza, il nome DNS non può essere risolto.
  • Se aggiungi us-west4-b.c.PROJECT_ID.internal alla ricerca dall'elenco, il nome DNS myapp-vm può quindi essere risolto us-west4-b.c.PROJECT_ID.internal viene aggiunto alla VM nome.

Google fornisce una funzionalità di miglioramento del percorso di ricerca che cerca automaticamente il nome DNS zonale di una VM in tutte le zone della stessa regione della VM. Di conseguenza, le query tra zone possono essere risolte senza richiedere un aggiornamento del file resolv.conf o del criterio DHCP. I miglioramenti del percorso di ricerca possono essere utili per risolvere query inter-zona fino all'80% delle volte. Questa funzionalità dovrebbe aiutare la maggior parte dei progetti con query rischiose a eseguire la migrazione al DNS di zona.

Attivare il miglioramento del percorso di ricerca per risolvere le ricerche dei nomi DNS tra zone

Per attivare la funzionalità di miglioramento del percorso di ricerca:

  1. Esegui il comando project-info add-metadata come segue.

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

  2. Lascia che il progetto utilizzi questa impostazione per alcuni giorni, poi controlla la metrica di monitoraggio per vedere se ci sono ancora query DNS globali rischiose o tra zone diverse.

    • Se il valore del progetto è 0, il progetto è pronto di cui eseguire la migrazione.
    • Se il progetto restituisce un valore diverso da zero, modifica tutte le query DNS globali per utilizzare il FQDN di zona, come descritto nella prossima sezione.

Aggiorna manualmente le query in modo che utilizzino i nomi DNS di zona

Se l'utilizzo della funzionalità di miglioramento del percorso di ricerca per aggiungere altri domini di zona nel percorso di ricerca del nome DNS non esegue la transizione di tutte le query tra zone, puoi utilizzare Logs Explorer per visualizzare l'utilizzo del DNS globale all'interno del progetto.

Per identificare le query DNS globali che devono essere modificate manualmente per utilizzare i nomi di dominio completi (FQDN) di zona, segui questi passaggi:

  1. Segui i passaggi in Determinare se il progetto è pronto per la migrazione per visualizzare l'utilizzo del DNS globale per un progetto. Utilizza Esplora log per accedere e eseguire query sull'utilizzo del DNS globale per le VM del tuo progetto.

  2. Nel riquadro Risultati query, ogni query ha un campo jsonPayload. Ogni jsonPayload campo contiene le seguenti informazioni:

    • Il nome della VM di origine, il relativo ID progetto e il nome della zona.
    • Il nome della VM di destinazione, il relativo ID progetto e il nome della zona.

    • Un messaggio di debug che fornisce informazioni su come aggiornare la query DNS globale che non può essere risolta utilizzando i nomi DNS di zona. Si tratta di sono considerate query di blocco della migrazione che dovresti eseguire il debug e risolvere.

      "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"

    • Un conteggio delle query di blocco della migrazione inviate dalla VM di origine alla VM di destinazione per quel giorno.

    Lo screenshot seguente mostra le informazioni del campo jsonPayload nella pagina della console di Esplora log.

    Screenshot di jsonPayload nei risultati della query del log di gdnsusage

  3. Utilizza le informazioni in jsonPayload per determinare il nome di dominio completo da utilizzare per aggiornare manualmente le query DNS globali per utilizzare il DNS di zona e rendere pronto per la migrazione. I casi d'uso più comuni per sapere dove aggiornare il FQDN e risolvere la compatibilità sono:

    • Nomi DNS interni del server dei metadati: non è richiesta alcuna azione perché il nome DNS restituito diventerà un FQDN zonale immediatamente dopo la migrazione al DNS zonale. Se il nome DNS è memorizzato nella cache, devi solo effettuare un'altra chiamata per aggiornare il valore della cache.
    • Nomi DNS interni utilizzati per accedere alle VM in un'altra regione: se hai un'applicazione che utilizza i nomi DNS interni per le VM in regioni diverse, puoi modificare il criterio DHCP o il file di configurazione per includere la zona nell'altra regione.
    • FQDN globale hardcoded: se disponi di un'applicazione che utilizza hardcoded con i nomi di dominio completo globali per le VM, puoi aggiornare la chiamata all'interno dell'applicazione per utilizzare invece il nome DNS interno o il nome di dominio completo di zona. Puoi fare in modo che a modificare il codice o la configurazione in Terraform.
    • VM nei progetti di servizio che utilizzano una rete VPC condiviso: risolvere i nomi DNS delle VM nei progetti di servizio che utilizzano Nella rete VPC condiviso, devi utilizzare i nomi di dominio completi di zona delle VM.

Dopo aver aggiornato le query DNS globali per utilizzare il DNS di zona:

  1. Utilizza la pagina Esplora log per eseguire di nuovo una query sull'utilizzo del DNS globale. Dopo il giorno correggi tutte le query DNS globali che bloccano la migrazione, non dovrebbero esserci log di debug visualizzato nei risultati della query.
  2. Ricontrolla la metrica di monitoraggio per verificare se tutte le query DNS rischiose sono state rimosse.

Verifica che la migrazione del progetto al DNS di zona sia completata

  1. Ripeti i passaggi nella Controlla se il progetto utilizza il DNS globale per impostazione predefinita.

  2. Per verificare che i metadati del progetto siano stati aggiornati, puoi eseguire il seguente comando:

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

    Il comando dovrebbe restituire ZONAL_ONLY.

  3. Verifica che il nome DNS interno di una VM utilizza un nome DNS di zona.

  4. Per verificare che il criterio dell'organizzazioneconstraints/compute.setNewProjectDefaultToZonalDNSOnly sia applicato, puoi:

    1. Crea un nuovo progetto nella cartella o nell'organizzazione.
    2. Creare e avviare un'istanza VM.
    3. Controlla se la VM utilizza un nome DNS di zona.

Ripristinare l'utilizzo del DNS globale

Puoi annullare la migrazione al DNS di zona modificando il DNS interno predefinito ridigita il DNS globale. Puoi farlo a livello di organizzazione, progetto, VM o contenitore.

Ripristina l'utilizzo del DNS globale per un'organizzazione o una cartella

Per ripristinare l'utilizzo del DNS globale per un'organizzazione o una cartella, completa la procedura seguente passaggi.

  1. Disabilita il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly nell'organizzazione a livello di cartella. Per istruzioni su come modificare questo criterio, consulta Applicare il DNS di zona per impostazione predefinita per i nuovi progetti.

    Imposta l'applicazione dell'opzione Imposta l'impostazione del DNS interno per i nuovi progetti su solo DNS di zona su Off.

  2. Se vuoi ripristinare l'utilizzo del DNS globale per l'intera organizzazione, verifica che nessuna delle cartelle dell'organizzazione applichi il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly.

  3. Utilizza le sezioni seguenti per verificare che il DNS globale sia configurato per progetti, VM e container.

Ripristinare l'utilizzo del DNS globale per un progetto

Per ripristinare l'utilizzo del DNS globale in un progetto, completa i passaggi riportati di seguito.

  1. Aggiungi quanto segue ai metadati del progetto: vmDnsSetting=GlobalDefault.

    Per informazioni su come impostare i valori dei metadati del progetto o della VM, consulta Impostazione di metadati personalizzati.

  2. Verifica che nessuna delle VM del progetto abbia il valore dei metadati vmDnsSetting impostato su ZonalOnly.

  3. Aggiorna il lease DHCP su ogni VM. Puoi aggiornare il lease riavviando alla VM, attendendo che in scadenza, oppure eseguendo uno dei seguenti comandi:

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

Ripristina l'utilizzo del DNS globale per una VM

Per ripristinare l'utilizzo del DNS globale per una VM specifica, completa i seguenti passaggi.

  1. Aggiungi quanto segue ai metadati della VM: vmDnsSetting=GlobalDefault.

    Per informazioni su come impostare i valori dei metadati della VM, consulta Impostare metadati personalizzati.

  2. Per forzare la modifica della configurazione DNS, riavvia la rete della VM utilizzando uno dei seguenti comandi:

  • Per Container-Optimized OS o Ubuntu:

    sudo systemctl restart systemd-networkd

  • Per CentOS, RedHat EL, Fedora CoreOS o Rocky Linux:

    sudo systemctl restart network

    o

    sudo systemctl restart NetworkManager.service

  • Per Debian:

    sudo systemctl restart networking

  • Per i sistemi Linux con nmcli:

    sudo nmcli networking off
sudo nmcli networking on

  • Per Windows:

    ipconfig /renew

Ripristina l'utilizzo del DNS globale per un container

Se esegui l'applicazione o il carico di lavoro in container, su Google Kubernetes Engine o nell'ambiente flessibile di App Engine, la configurazione DNS nelle impostazioni del container potrebbe non vengono aggiornate automaticamente finché non riavvii i container. Per disabilitare il DNS di zona su queste app contenitore, completa i seguenti passaggi.

  1. Imposta l'impostazione dei metadati del progetto vmDnsSetting su GlobalDefault nei progetti proprietari dei container e delle VM.

  2. Riavvia i contenitori in modo che le impostazioni DNS tornino allo stato originale.

Risolvere i problemi relativi alla procedura di migrazione dal DNS globale al DNS di zona

Se riscontri problemi con la procedura di migrazione, consulta la guida alla risoluzione dei problemi.

Nascondi il banner sulla migrazione del DNS di zona nella console Google Cloud

Puoi fare clic sul pulsante Ignora nella notifica di migrazione del DNS di zona visualizzato nella pagina Istanze VM della console Google Cloud. In questo modo, il banner non verrà visualizzato per il progetto a tempo indeterminato.

Se hai ignorato il banner, ma vuoi che venga visualizzato di nuovo, contatta Assistenza clienti Google Cloud per l'assistenza.

Passaggi successivi