Usa 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 tuoi progetti su Compute Engine. L'utilizzo del DNS di zona riduce l'impatto degli errori a punto singolo che possono verificarsi quando si utilizza il DNS globale.

Prima di iniziare

  • Se non l'hai ancora fatto, configura l'autenticazione. L'autenticazione è il processo mediante il quale viene verificata l'identità per l'accesso ai servizi e alle API Google Cloud. Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi autenticarti in Compute Engine nel seguente modo.

    Seleziona la scheda relativa a come prevedi di utilizzare gli esempi in questa pagina:

    Console

    Quando utilizzi la console Google Cloud per accedere ai servizi e alle API di Google Cloud, non devi configurare l'autenticazione.

    gcloud

    1. Installa Google Cloud CLI, quindi initialize eseguendo questo comando: 

      gcloud init
    2. Imposta una regione e una zona predefinite.

    REST

    Per utilizzare gli esempi di API REST in questa pagina in un ambiente di sviluppo locale, devi utilizzare le credenziali che fornisci a gcloud CLI.

      Installa Google Cloud CLI, quindi initialize eseguendo questo comando: 

      gcloud init

Ruoli obbligatori

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

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

Per saperne di più sulla concessione dei ruoli, consulta Gestire l'accesso.

Questi ruoli predefiniti contengono le autorizzazioni necessarie per la migrazione al DNS di zona. Per visualizzare le autorizzazioni esatte necessarie, espandi la sezione Autorizzazioni richieste:

Autorizzazioni obbligatorie

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

  • Imposta un vincolo del criterio 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
  • Verifica la presenza di nomi DNS globali e metadati delle 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 essere in grado di ottenere queste autorizzazioni con i 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 la VM 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 verificato 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 viene risolto all'interno di una zona.
  • I nomi DNS di zona 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 di zona in una zona funzionano indipendentemente dalle altre zone, consentendo di creare più applicazioni multiregionali a tolleranza di errore con caratteristiche di disponibilità migliori. Non è previsto alcun costo per l'utilizzo del DNS di zona. Il DNS di zona è separato da Cloud DNS.

I progetti creati prima del 6 settembre 2018 sono stati configurati per utilizzare il DNS globale per impostazione predefinita. Questi progetti possono continuare a utilizzare il DNS globale, ma Google consiglia vivamente alle organizzazioni di eseguire la migrazione di questi progetti al DNS di zona per evitare che le interruzioni del servizio in un'altra regione influiscano sulle risorse regionali locali. L'utilizzo del DNS di zona offre affidabilità maggiore rispetto al DNS globale, isolando gli errori nella registrazione DNS per le singole zone. Ciò riduce l'impatto degli errori single-point. Un'interruzione di Google Cloud che si verifica è isolata in una singola zona e le risorse e i costi non hanno un impatto significativo.

Esegui la migrazione dal DNS globale al DNS di zona

Il DNS di zona ha sostituito il DNS globale come tipo DNS interno predefinito per tutte le nuove organizzazioni inserite in Google Cloud dopo il 6 settembre 2018. Se i tuoi progetti esistenti utilizzano ancora il DNS globale, Google consigliamo vivamente di utilizzare i nomi DNS di zona per questi progetti. Se non esegui la migrazione al DNS di zona, rischi che si verifichino i seguenti problemi:

  • Impossibile creare nuove VM in qualsiasi regione in cui si verificano errori del piano di controllo in cui esiste o avevi un progetto in precedenza.
  • Impossibilità di utilizzare alcuni servizi Compute Engine fondamentali per i tuoi carichi di lavoro, ad esempio con la scalabilità automatica o la autohealing per i 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 di Cloud DNS. L'utilizzo delle zone private di Cloud DNS rimuove il controllo dell'unicità dei nomi 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 Google Cloud o il rappresentante del tuo account team. Per informazioni su come Cloud DNS gestisce le interruzioni a livello di zona e a livello di regione, consulta Architettura del ripristino di emergenza in caso di interruzioni dell'infrastruttura cloud.

Panoramica del processo di migrazione

Il processo di migrazione del DNS di zona ha due livelli:

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

L'immagine mostra un diagramma di flusso dei passaggi della migrazione al DNS di zona

In genere, la procedura prevede i seguenti passaggi:

  1. Verifica l'idoneità della cartella o dell'organizzazione per la migrazione al 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 l'organizzazione per impedire l'uso futuro del DNS globale.
    2. I proprietari del progetto eseguono la migrazione dei propri progetti per utilizzare il DNS di zona.
  3. Se la cartella o l'organizzazione non è pronta per la migrazione al DNS di zona:
    1. I proprietari del progetto eseguono la migrazione dei progetti pronti al DNS di zona.
    2. I proprietari del progetto esaminano l'utilizzo del DNS globale in progetti non ancora pronti.
    3. I proprietari del progetto applicano miglioramenti al percorso di ricerca o altre modifiche per rendere il progetto pronto per la migrazione al DNS di zona.
    4. L'amministratore dell'organizzazione ricontrolla lo stato dell'idoneità della cartella o dell'organizzazione per la migrazione del DNS di zona.

Limitazioni

  • Il DNS di zona non sostituisce completamente il DNS globale. Esistono alcuni tipi di query (tra zone) che potrebbero non essere risolti dal DNS di zona con la ricerca automatica del percorso di ricerca. Verifica l'idoneità alla migrazione delle cartelle e dei progetti della tua organizzazione per assicurarti che siano compatibili con il DNS di zona prima della migrazione.

  • Il processo 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 nel percorso di ricerca, assicurati che la VM sia in esecuzione con glibc versione 2.26 o successive. I client DHCP con glibc 2.25 e versioni precedenti supportano solo fino a 6 domini di ricerca, pertanto 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 successive
    • Fedora CoreOS (versione 27 o successive)
    • Immagini RHEL 8 o versioni successive
    • Immagini di Ubuntu release 18.04 o successive
    • Altre immagini con glibc versione 2.26 o successive

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

  • Per utilizzare i miglioramenti del percorso di ricerca con Google Kubernetes Engine, devi utilizzare Google Kubernetes Engine 1.26 o versioni successive.

Controlla la versione di glibc

Per controllare la versione di glibc utilizzata dalla VM:

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

Controlla il numero di domini di ricerca se utilizzi glibc 2.25 o versioni precedenti

  1. Connettiti alla VM Linux.

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

Passaggi per l'amministratore dell'organizzazione

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

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

Il tipo predefinito di nome del DNS interno dell'organizzazione è determinato dalla data di creazione dell'organizzazione e dall'applicazione o meno del vincolo dei criteri constraints/compute.setNewProjectDefaultToZonalDNSOnly.

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 pagina della console Identity & Organization che mostra la data di completamento della registrazione

    • Se la tua organizzazione è stata creata dopo il 6 settembre 2018, utilizza il DNS di zona per impostazione predefinita. In questo caso, non è richiesta alcuna azione.
    • Se la tua organizzazione è stata creata prima del 6 settembre 2018, utilizza il DNS globale per impostazione predefinita ed è quindi necessario eseguirne la migrazione al DNS di zona.

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

    1. Vai alla pagina IAM e 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 è Applicato, il tipo di DNS interno predefinito è DNS di zona per tutti i nuovi progetti creati nell'organizzazione.
      • In caso contrario, il tipo DNS predefinito per il progetto viene comunque determinato dall'ora di creazione dell'organizzazione.
    5. Se il vincolo non è stato configurato per l'organizzazione, il tipo di DNS predefinito per il progetto è determinato in base al momento di creazione dell'organizzazione, come descritto nel primo passaggio.

gcloud

Utilizza il comando organizations describe e il comando resource-manager org-policies list per determinare il tipo di 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 ID dell'organizzazione o con il nome di dominio dell'organizzazione.

    • Se la tua organizzazione è stata creata dopo il 6 settembre 2018, utilizza il DNS di zona per impostazione predefinita. In questo caso, la tua organizzazione utilizza già il DNS di zona e non sono necessarie ulteriori azioni.
    • Se la tua organizzazione è stata creata prima del 6 settembre 2018, utilizza il DNS globale per impostazione predefinita ed è quindi necessario eseguirne la migrazione al DNS di zona.

  2. Se la tua organizzazione utilizza il DNS globale per impostazione predefinita, determina se è configurato un vincolo del criterio dell'organizzazione per impostare il tipo DNS predefinito per tutti i progetti appena creati sul 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 il Status è Enforced, il tipo di DNS interno predefinito è DNS di zona per tutti i nuovi progetti creati nell'organizzazione.
    2. Se il vincolo non è stato configurato per l'organizzazione o non è applicato, il tipo di DNS interno predefinito è determinato dalla data e ora di creazione dell'organizzazione, come descritto nel primo passaggio.

Stabilisci quali progetti in una cartella o un'organizzazione utilizzano il DNS globale

Per determinare quanti progetti utilizzano il DNS globale, consigliamo di utilizzare BigQuery per creare una tabella che elenca i progetti relativi per la tua organizzazione e i relativi metadati. Puoi quindi utilizzare questa tabella per eseguire una query che mostri il numero totale di 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 necessarie per utilizzare l'API Cloud Asset Inventory.

    3. Utilizza il seguente comando gcloud CLI per esportare l'asset 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

      Sostituisci quanto segue:

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

  3. Vai alla pagina BigQuery nella console Google Cloud.

  4. Seleziona Crea una nuova query.

  5. Nell'area di testo dell'editor query, inserisci la seguente query GoogleSQL e 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 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 progetto, inserisci la seguente query GoogleSQL e 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 effettuato query incompatibili con il DNS di zona negli ultimi 30 giorni.
  • Se una cartella non è pronta per la migrazione, lo script risponde con gli ID progetto all'interno della cartella, rendendo la cartella non pronta per la migrazione. I progetti in questo elenco di risultati non sono ancora compatibili con il DNS di zona e richiedono un'azione aggiuntiva.

Procedi con 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 l'ID cartella.

  2. Esegui una query sulla tabella BigQuery con i dati compute.Project assets esportati.

    Per le istruzioni su come creare la tabella BigQuery, consulta Determinare quali progetti in una cartella o un'organizzazione utilizzano il DNS globale.

    Inserisci la seguente query GoogleSQL e 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 che contiene i metadati esportati
    • FOLDER_NUMBER: il numero ID della cartella

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

  4. Esegui il seguente script bash. Lo script viene ripetuto attraverso 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.

Trasmetti i risultati dell'analisi di idoneità alla 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 è il DNS globale. Per isolare eventuali errori nella registrazione DNS in singole zone, puoi applicare il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly a livello di organizzazione o cartella.

Quando imposti un criterio dell'organizzazione per sostituire il tipo di DNS interno predefinito, i progetti appena creati utilizzano il DNS di zona per impostazione predefinita. Il criterio dell'organizzazione non influisce sui progetti esistenti in cui l'API Compute Engine è già abilitata. Per far sì che i progetti esistenti utilizzino il DNS di zona, consulta l'articolo sul trasferimento 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.

Utilizza i passaggi seguenti 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 visualizzare i criteri dell'organizzazione. Nella console Google Cloud viene visualizzato un elenco dei vincoli dei criteri dell'organizzazione disponibili. L'elenco potrebbe abbracciare 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 Imposta l'impostazione del DNS interno per i nuovi progetti su Solo DNS di zona.

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

    La pagina dei dettagli del criterio fornisce informazioni sul vincolo e su come viene applicato.

    Per impostazione predefinita, l'applicazione forzata non è definita per una cartella o un'organizzazione. Tuttavia, se per una cartella principale è stata definita un'applicazione definita, l'applicazione viene ereditata dalla cartella principale più vicina per cui è stata definita un'applicazione. Per maggiori informazioni, consulta 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, seleziona On.

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

  9. Fai clic su Salva.

Per convalidare la modifica al criterio dell'organizzazione, puoi creare un nuovo progetto nella cartella o nell'organizzazione, quindi creare e avviare un'istanza VM e controllare se la tua VM è abilitata per il DNS di zona.

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

Cartelle esenti non sono pronte per la migrazione al DNS di zona

Se solo poche cartelle all'interno di un'organizzazione non sono pronte per la migrazione al DNS di zona, ti consigliamo di impostare un criterio dell'organizzazione a livello di organizzazione, ma 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 è pronta per la migrazione al DNS di zona.

organizzazione/Example.com

  • folders/101
    • projects/301 (pronta 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 i passaggi seguenti per impostare l'opzione di applicazione forzata del 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, quindi scegli le cartelle che vuoi escludere dal criterio dell'organizzazione.

    La console Google Cloud mostra un elenco di vincoli dei criteri dell'organizzazione per quella 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 del criterio dell'organizzazione per aprire la pagina Dettagli criterio.

  6. Fai clic su Modifica.

  7. Nella pagina Modifica, seleziona Personalizza.

  8. In Applicazione, seleziona Off per disabilitare l'applicazione forzata del vincolo. Ciò significa che il tipo DNS interno predefinito per tutti i progetti nella cartella è determinato da data e ora 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, esegui le seguenti attività durante la migrazione dal DNS globale al DNS di zona:

I proprietari del progetto possono anche completare queste attività facoltative:

Controlla se il progetto utilizza il DNS globale per impostazione predefinita

Controlla i tuoi progetti per verificare se devono eseguire la migrazione dal DNS globale al DNS di zona. Devi eseguire solo la migrazione 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 DNS di zona è abilitato nel progetto. Non è necessario eseguire la migrazione di questo progetto.

gcloud

    Nella console Google Cloud, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

  1. Esegui il seguente comando gcloud CLI per verificare 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 per impostazione predefinita.

    • GLOBAL_DEFAULT: nel progetto è abilitato il DNS globale.
    • ZONAL_ONLY: nel progetto è abilitato il DNS di zona. 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 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 vmDnsSetting indica se il progetto utilizza il DNS globale per impostazione predefinita.

  • GLOBAL_DEFAULT: nel progetto è abilitato il DNS globale.
  • ZONAL_ONLY: il DNS di zona è abilitato nel progetto. Non è necessario eseguire la migrazione di questo progetto.

Determina se il progetto è pronto per la migrazione

Nella pagina Istanze VM della console Google Cloud, se il tuo progetto deve eseguire la migrazione al DNS di zona, dovresti vedere un banner di notifica sulla migrazione del DNS di zona.

Quando visualizzi la pagina Istanze VM del progetto, se quest'ultimo è pronto per la migrazione (compatibile con il DNS di zona), il banner include il suggerimento per utilizzare il DNS di zona. Questo suggerimento 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 banner del DNS di zona nella console

Per visualizzare l'utilizzo del DNS globale, fai clic sul pulsante View Global DNS Usage (Visualizza utilizzo del DNS globale). Accederai 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, la pagina Esplora log è configurata per utilizzare il filtro logName per estrarre le query DNS globali e i relativi campi di log.

Per visualizzare queste informazioni senza utilizzare il pulsante nel banner:

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

    Vai a Esplora log

  2. Seleziona il progetto.

  3. Applica i filtri delle risorse e dei nomi di log:

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

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

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

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

Monitora l'utilizzo del DNS globale all'interno del progetto

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

  • zonal_dns_ready: il numero aggregato di query completate nell'intervallo di tempo specificato che può essere risolto 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 può essere risolto utilizzando il DNS di zona. Per queste query, Compute Engine non è stato in grado di determinare l'indirizzo IP interno relativo dal nome host attuale. 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. Nel pannello di navigazione della console Google Cloud, seleziona Monitoring e poi  Metrics Explorer:

    Vai a Metrics Explorer

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

  3. Se il nome del campo di immissione della query non è Query MQL, seleziona MQL nell'angolo in basso a destra del campo di immissione della query in 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 ciascuna metrica.

    Screenshot del grafico delle metriche di utilizzo del DNS globale

  6. Controlla il valore della metrica zonal_dns_risky.

Esegui la migrazione dei progetti pronti al DNS di zona

In generale, puoi utilizzare il seguente processo di migrazione:

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

  2. Fai clic sul pulsante Utilizza DNS di zona nel banner della pagina Istanze VM della console Google Cloud. Questa operazione modifica i metadati del progetto in modo da utilizzare il DNS di zona.

    In alternativa, puoi modificare manualmente i tuoi progetti in modo che utilizzino per impostazione predefinita il DNS di zona, come descritto in Aggiornare manualmente i progetti e le VM per l'utilizzo del DNS di zona e Impedire 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 nomi DNS di zona aggiornando i rispettivi metadati. Abilita il DNS di zona per le tue VM impostando la voce di metadati vmDnsSetting per il progetto o la VM. Se imposti la voce di metadati vmDnsSetting per una VM specifica, verrà sostituita l'impostazione vmDnsSetting ereditata dai metadati del progetto per quella VM.

La variabile vmDnsSetting supporta le seguenti impostazioni:

  • Consigliato: imposta vmDnsSetting=ZonalOnly nei metadati del progetto. Ciò significa che alle VM è possibile accedere solo tramite i nomi DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal). Le VM mantengono comunque i percorsi di ricerca globale e di zona, ma i nomi DNS globali, che non includono ZONE nel nome DNS interno, smetteranno di funzionare. Altre VM possono indirizzare le VM con vmDnsSetting impostato su ZonalOnly utilizzando solo i nomi DNS di zona e non possono risolvere i problemi di queste VM utilizzando i nomi DNS globali o i percorsi di ricerca. Questa è l'opzione preferita e più affidabile, a condizione che le 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 nomi DNS sia globali che di zona, ma utilizzano solo nomi DNS globali come nomi di dominio predefiniti e voci del percorso di ricerca. Questa è l'impostazione predefinita per le VM in progetti autonomi e progetti creati in un'organizzazione che ha abilitato l'API Compute Engine prima del 6 settembre 2018.

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

Dopo aver configurato la voce dei metadati vmDnsSetting per una VM, aggiorna il lease DHCP sulla VM. Puoi aggiornare il lease riavviando la VM, attendendo la scadenza del lease o eseguendo uno dei seguenti comandi:

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

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

Modifica i progetti non pronti per la migrazione

Se un progetto non è pronto per la migrazione, significa che è stata effettuata almeno una query DNS rischiosa entro un determinato periodo di tempo, ad esempio gli ultimi 30 giorni o gli ultimi 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 soluzione di continuità utilizzando un nome DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal). Le query rischiose potrebbero avere i seguenti attributi:

  • Effettua una chiamata a una VM in un altro progetto
  • Chiamata a una VM in una zona diversa

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

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

  1. Attiva il miglioramento del percorso di ricerca per risolvere le ricerche di nomi DNS tra zone. Questa operazione potrebbe rendere i tuoi progetti pronti per la migrazione senza influire sulle tue risorse.
  2. Se l'aggiustamento del percorso di ricerca non comporta la transizione di tutte le query tra zone tra zone, puoi aggiornare manualmente le query in modo che utilizzino i nomi DNS di zona.

Informazioni sulla funzionalità di miglioramento dei percorsi di ricerca

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

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 utilizzare durante l'esecuzione della risoluzione DNS. Il server DNS tenta di risolvere la query utilizzando ciascuno dei nomi host nel percorso di ricerca fino a quando non trova una corrispondenza di 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 viene rilevata una corrispondenza, il resolver DNS restituisce un indirizzo IP interno nella risposta. In caso contrario, prova a risolvere il nome DNS utilizzando il dominio successivo nel percorso di ricerca.

L'aggiunta di ulteriori domini di zona 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 nome di dominio completo 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 nome di dominio completo per la VM di destinazione viene 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 all'elenco di ricerca, il nome DNS myapp-vm può essere risolto quando us-west4-b.c.PROJECT_ID.internal viene aggiunto al nome della VM.

Google offre una funzionalità di miglioramento del percorso di ricerca che cerca automaticamente il nome DNS di zona 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 dei percorsi di ricerca consentono di risolvere fino all'80% delle query tra zone diverse all'interno di regioni. Questa funzionalità dovrebbe aiutare la maggior parte dei progetti con query rischiose a diventare pronta per la migrazione al DNS di zona.

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

Per attivare la funzionalità di miglioramento del percorso di ricerca, procedi nel seguente modo.

  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 verificare se sono ancora presenti query DNS globali rischiose o tra zone.

    • Se il valore del progetto è 0, allora il progetto è pronto per la migrazione.
    • Se il progetto restituisce un valore diverso da zero, modifica tutti i nomi di tutte le query DNS globali in modo da utilizzare il FQDN a livello di zona, come descritto nella sezione successiva.

Aggiorna manualmente le query in modo da utilizzare i nomi DNS di zona

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

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

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

  2. Nel riquadro Risultati delle query, ogni query ha un campo jsonPayload. Ogni campo jsonPayload 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 nomi DNS di zona. Queste sono considerate query di blocco della migrazione di cui devi eseguire il debug e correggere.

      "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 che mostra il numero di query di blocco della migrazione che la VM di origine invia alla VM di destinazione per quel giorno.

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

    Screenshot di jsonPayload nei risultati della query di log gdnsusage

  3. Utilizza le informazioni in jsonPayload per determinare quale nome di dominio completo usare per aggiornare manualmente le query DNS globali in modo da utilizzare il DNS di zona e preparare il progetto per la migrazione. I casi d'uso più comuni in cui aggiornare il nome di dominio completo e risolvere la compatibilità sono:

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

Dopo aver aggiornato le query DNS globali in modo da utilizzare il DNS di zona:

  1. Utilizza la pagina Esplora log per eseguire nuovamente query sull'utilizzo del DNS globale. Dopo aver corretto tutte le query DNS globali che bloccano le query, nei risultati della query non dovrebbero essere visualizzati i log di debug.
  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 stata completata

  1. Ripeti i passaggi descritti in Verificare se il progetto utilizza il DNS globale per impostazione predefinita.

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

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

    Il comando dovrebbe restituire ZONAL_ONLY.

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

  4. Per verificare che il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly sia stato applicato in modo forzato, puoi:

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

Ripristina l'utilizzo del DNS globale

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

Ripristina il DNS globale per un'organizzazione o una cartella

Per ripristinare l'utilizzo del DNS globale per un'organizzazione o una cartella, segui questi passaggi.

  1. Disabilita il criterio dell'organizzazione constraints/compute.setNewProjectDefaultToZonalDNSOnly a livello di organizzazione o 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 a livello di zona su Off.

  2. Se vuoi ripristinare l'utilizzo del DNS globale per l'intera organizzazione, verifica che nessuna cartella 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.

Ripristina il DNS globale per un progetto

Per ripristinare un progetto in modo che utilizzi il DNS globale, completa i seguenti passaggi.

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

    Per informazioni su come impostare i metadati di progetto o i valori dei metadati delle VM, consulta Impostare i metadati personalizzati.

  2. Verifica che per nessuna delle VM nel progetto il valore dei metadati vmDnsSetting sia impostato su ZonalOnly.

  3. Aggiorna il lease DHCP su ogni VM. Puoi aggiornare il lease riavviando la VM, attendendo che il lease scada o eseguendo uno dei seguenti comandi:

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

Ripristina il 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 i 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

  • Per Debian:

    sudo systemctl restart networking

  • Per Windows:

    ipconfig /renew

Ripristino dell'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 essere aggiornata automaticamente finché non riavvii i container. Per disabilitare il DNS di zona in queste app di container, completa i seguenti passaggi.

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

  2. Riavvia i container in modo che le impostazioni DNS vengano ripristinati allo stato originale.

Risolvi i problemi del processo di migrazione dal DNS globale al DNS di zona

In caso di problemi con il processo di migrazione, consulta la guida alla risoluzione dei problemi.

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

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

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

Passaggi successivi