Il DNS di zona riduce il rischio di interruzioni tra regioni e migliora l'affidabilità complessiva dei tuoi 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.
Autenticazione è
la procedura di verifica dell'identità per l'accesso ai servizi e alle API di 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
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- Set a default region and zone.
-
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 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
) del 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 -
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 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
- Il nome è 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 altri nomi DNS globali registrati nello stesso progetto per evitare la creazione di un nome DNS. una collisione.
- Il nome è 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 perzone1
. A differenza del DNS globale,my-vm.zone2.google.com
è anche un nome DNS valido quando si utilizza il DNS di zona. - Impossibile creare nuove VM in nessuna regione piano di controllo degli errori, in cui hai già un progetto o ne avevi in precedenza.
- 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).
- 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. Di solito viene eseguita dal proprietario del progetto.
- Controlla l'idoneità di cartelle o organizzazioni per la migrazione a DNS di zona.
- Se la cartella o l'organizzazione è pronta per la migrazione al DNS di zona:
- L'amministratore dell'organizzazione imposta un criterio dell'organizzazione per la cartella o un'organizzazione per impedire l'uso futuro del DNS globale.
- I proprietari dei progetti eseguono la migrazione dei propri progetti per utilizzare il DNS di zona.
- Se la cartella o l'organizzazione non è pronta per la migrazione al DNS di zona:
- I proprietari dei progetti eseguono la migrazione dei progetti pronti al DNS di zona.
- I proprietari del progetto esaminano l'utilizzo del DNS globale in progetti che non sono pronto.
- 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.
- L'amministratore dell'organizzazione ricontrolla lo stato della cartella o dell'organizzazione l'idoneità per la migrazione del DNS a livello di zona.
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.
Il processo di migrazione da DNS globale a 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 conglibc
2.26 o versioni successive. I client DHCP conglibc
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 Ubuntu release 18.04 o successive
- Altre immagini con
glibc
2.26 o versioni successive
L'attivazione del miglioramento del percorso di ricerca consente di aggiungere altri domini di ricerca, ad esempio
NEIGHBOR_ZONE.c.PROJECT_ID.internal
. Come accennato nella limitazione precedente, i domini esistenti nella ricerca percorso potrebbe essere rimosso se viene superato il limite di domini del percorso di ricerca quando utilizziglibc
2.25 o versioni precedenti.Per usare i miglioramenti dei percorsi di ricerca con Google Kubernetes Engine, devi usare Google Kubernetes Engine versione 1.26 o successive.
- Connettiti alla VM Linux.
- Esegui
ldd --version
per ottenere la versioneglibc
. Controlla se la VM Linux ha già 6 domini nel percorso di ricerca. Puoi eseguire
cat /etc/resolv.conf
per visualizzare queste informazioni.- Controlla se la tua organizzazione utilizza il DNS globale per impostazione predefinita.
- Determina quali progetti in una cartella o un'organizzazione utilizzano il DNS globale.
- Determina se una cartella è pronta per la migrazione al DNS di zona.
- Configura il DNS di zona come predefinito per i nuovi progetti.
- Cartelle esenti non pronte per la migrazione a DNS di zona dal vincolo del criterio dell'organizzazione.
Vai alla sezione IAM e Amministratore>Identità e Organizzazione nella console.
Controlla la data di registrazione 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, 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.
Se la tua organizzazione utilizza il DNS globale per impostazione predefinita, verifica se il vincolo del criterio dell'organizzazione imposta il tipo DNS predefinito per tutti i nuovi di progetti creati con il DNS di zona.
- Vai alla sezione IAM e Pagina Amministrazione>Criteri dell'organizzazione nella console Google Cloud.
- Nel campo Filter (Filtro), inserisci
constraints/compute.setNewProjectDefaultToZonalDNSOnly
. - Se il vincolo è configurato, fai clic sul nome Configura l'impostazione del DNS interno per i nuovi progetti su Solo DNS di zona.
- 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 è ancora determinato al momento della creazione dell'organizzazione.
- Se il vincolo non è stato configurato per l'organizzazione, viene impostato il valore predefinito Il tipo di DNS per il progetto è determinato dalla creazione dell'organizzazione come descritto nel primo passaggio.
Controlla il valore dei metadati
creationTime
dell'organizzazione.gcloud organizations describe ORGANIZATION_ID
Sostituisci ORGANIZATION_ID con l'ID organizzazione o 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, sta già utilizzando il DNS di zona e non è necessaria un'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.
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
.- Se il vincolo è configurato e
Status
èEnforced
, il tipo di DNS interno predefinito è DNS di zona per tutti i nuovi progetti creato nell'organizzazione. - Se il vincolo non è stato configurato per l'organizzazione o non è applicato, il tipo di DNS interno predefinito è determinato data e ora di creazione dell'organizzazione, come descritto nel primo passaggio.
- Se il vincolo è configurato e
- Crea un set di dati BigQuery.
Esporta i metadati degli asset per la tua organizzazione in una tabella BigQuery.
- Assicurati che l'API Cloud Asset Inventory sia abilitata.
- Configura le autorizzazioni necessari per utilizzare l'API Cloud Asset Inventory.
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: 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, è stata creata.
Vai alla pagina BigQuery nella nella console Google Cloud.
Seleziona
Crea una nuova query.Nell'area di testo dell'editor di query, inserisci il seguente codice SQL 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: ID progetto
- DATASET_ID: il nome del set di dati BigQuery
- TABLE_NAME: la tabella che contiene i metadati esportati; dal passaggio 2.
I progetti con valore
ZONAL_ONLY
pervmDnsSetting
sono a livello di zona DNS configurato. In caso contrario, i progetti sono impostati per utilizzare il DNS globale.(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
- La cartella è pronta se tutti i progetti non hanno eseguito query che incompatibile con il DNS di zona 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.
- Recupera l'ID cartella. Se non conosci l'ID cartella:
- Nella console Google Cloud, vai alla Pagina Risorse gestite:
- Applica il filtro
Name:FOLDER_NAME
per ottenere ID cartella.
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: 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 cartella
Copia l'elenco di ID progetto e salvalo in un file.
Esegui il seguente script
bash
. Lo script esegue l'iterazione tramite gli ID progetto nel file salvato per determinare se una cartella è pronta per la migrazione.- Per le cartelle e i progetti di cui è sicura la migrazione, invia una notifica ai proprietari del progetto in modo che possa iniziare a eseguire la migrazione dei progetti pronti.
- Per le cartelle che contengono progetti di cui non è possibile eseguire la migrazione, indica proprietari del progetto di modificare i progetti non pronti per la migrazione.
Accedi alla console Google Cloud come Google Workspace o Cloud Identity come super amministratore.
Nella console, vai alla pagina Criteri dell'organizzazione.
Seleziona la cartella o l'organizzazione per cui vuoi per visualizzare i criteri dell'organizzazione. La console Google Cloud mostra vincoli dei criteri dell'organizzazione disponibili. L'elenco potrebbe estendersi più pagine.
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.
Fai clic sul nome del criterio per visualizzarne la dettagli.
La pagina dei dettagli del criterio fornisce informazioni sul vincolo e su come viene applicato un vincolo di rete.
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.
Per personalizzare il criterio dell'organizzazione, fai clic su Modifica.
Nella pagina di modifica, seleziona Personalizza.
In Applicazione, seleziona On.
Imposta il tipo di DNS interno predefinito per tutti i nuovi progetti in dell'organizzazione al DNS di zona.
Fai clic su Salva.
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)
- Accedi alla console Google Cloud come Google Workspace o Cloud Identity come super amministratore.
Nella console, vai alla pagina Criteri dell'organizzazione.
Fai clic su Seleziona, poi seleziona le cartelle da escludere dal criterio dell'organizzazione.
La console Google Cloud mostra un elenco di vincoli dei criteri dell'organizzazione per cartella su una o più pagine.
Per trovare il vincolo del criterio dell'organizzazione che applica il DNS di zona:
- Fai clic su Filtra.
- Seleziona Nome.
- Imposta il nome del filtro su Configura l'impostazione DNS interno per nuovi progetti solo al DNS di zona.
Fai clic sul nome del vincolo del criterio dell'organizzazione per aprire Pagina Dettagli norme.
Fai clic su Modifica.
Nella pagina Modifica, seleziona Personalizza.
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 dall'ora di creazione dell'organizzazione.
Fai clic su Salva.
- Determina il tipo di DNS interno predefinito per il progetto.
- Determina se il progetto è pronto per la migrazione al DNS di zona.
- Eseguire la migrazione di un progetto utilizzando DNS di zona.
- Monitora l'utilizzo del DNS globale all'interno del progetto.
- Modifica i progetti non pronti per la migrazione al DNS di zona.
- Verifica che la migrazione del progetto al DNS di zona sia completata
- Ripristina l'utilizzo del DNS globale di un progetto.
- Nascondi il banner di migrazione del DNS a livello di zona.
Nella console Google Cloud, vai alla pagina Metadati.
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
: nel progetto è abilitato il DNS di zona. Non è necessario eseguire la migrazione di questo progetto.
Esegui il seguente comando gcloud CLI per verificare il valore
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 un DNS di zona in un bucket in cui è abilitato il controllo delle versioni. Non è necessario eseguire la migrazione di questo progetto.
GLOBAL_DEFAULT
: nel progetto è abilitato il DNS globale.ZONAL_ONLY
: nel progetto è abilitato il DNS di zona. Questo non è necessario eseguire la migrazione del progetto.Nella console Google Cloud, vai alla pagina Esplora log.
Seleziona il progetto.
Applica i filtri dei nomi di risorse e log:
- Fai clic su Risorsa.
- Nella finestra di dialogo Seleziona risorsa, seleziona Istanza VM, quindi fai clic su Applica.
- Fai clic su Nome log.
Nella finestra di dialogo Seleziona nomi log, seleziona gdnsusage e quindi fai clic su Applica.
zonal_dns_ready
: il numero aggregato di query completate nel di un 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 nel intervallo di tempo specificato che non può essere risolto utilizzando il DNS di zona. Per questi delle query, Compute Engine non è stato in grado di determinare l'IP interno relativo dell'attuale nome host. Se il valore di questa metrica è diverso da zero, significa che il progetto non è pronto per la migrazione.-
Nella console Google Cloud, vai alla pagina leaderboard Esplora metriche:
Se utilizzi la barra di ricerca per trovare questa pagina, seleziona il risultato con il sottotitolo Monitoring.
Sul lato destro della barra degli strumenti che contiene il pulsante Seleziona una metrica fai clic su Editor di codice, MQL o PromQL.
Se il campo di immissione della query non è denominato Query MQL, in basso a destra nell'angolo del campo di immissione della query, seleziona MQL per Lingua.
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
Fai clic sul pulsante Esegui query.
La console Google Cloud mostra un grafico delle due metriche (
zonal_dns_ready
ezonal_dns_risky
) e il numero corrispondente di query eseguite nel periodo di tempo per ogni metrica.Verifica il valore della metrica
zonal_dns_risky
.- Se il valore è
0
, il progetto è pronto per la migrazione a un ambiente DNS. Puoi eseguire la migrazione del progetto, come descritto in Esegui la migrazione di progetti pronti al DNS di zona. - Se il valore è un numero diverso da zero, come
0.02k
, come mostrato nel screenshot precedente, ci sono alcune query che potrebbero non funzionare dopo la migrazione al DNS di zona. Il progetto non è pronto per la migrazione. Continua con i passaggi in Modifica i progetti non pronti per la migrazione.
- Se il valore è
- Controlla le applicazioni e aggiornale per risolvere i problemi di compatibilità con
impostazioni solo a livello di zona:
- Se la tua applicazione utilizza il DNS globale hardcoded i nomi degli utenti, aggiornali nomi DNS di zona.
- 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 sulla rete VPC condiviso, devi utilizzare Nome di dominio completo (FQDN) della zona delle VM.
Fai clic sul pulsante Utilizza DNS di zona nel banner della pagina Istanze VM della console Google Cloud. In questo modo, i metadati di 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.
Consigliato: imposta
vmDnsSetting=ZonalOnly
nei metadati di progetto. Questo significa che alle tue VM è possibile accedere solo tramite i loro nomi DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal
) quando si utilizzano i percorsi di ricerca. Le VM mantengono sia l'infrastruttura a livello di zona che quella globale di ricerca, ma i relativi nomi DNS globali, che non includono il valoreZONE
come parte del nome DNS interno, non funziona più. Solo VM nella stessa zona e lo stesso progetto possono accedervi utilizzando il nome globale quando sia attiva. Altre VM possono accedere alle VM convmDnsSetting
impostato suZonalOnly
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 è la soluzione preferita affidabile, purché le applicazioni siano in grado di supportarla.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 globale che nomi DNS di zona, ma utilizzano solo nomi DNS globali come nomi di dominio predefiniti e percorsi di ricerca. Questa è l'impostazione predefinita per le VM in modalità autonoma di progetti e progetti creati in un'organizzazione che ha abilitato l'API Compute Engine prima del 6 settembre 2018.- VM Linux:
sudo dhclient -v -r
- VM Windows Server:
ipconfig /renew
- Effettua una chiamata a una VM in un progetto diverso
- Effettua una chiamata a una VM in una zona diversa
- Attiva il miglioramento dei percorsi di ricerca per risolvere le ricerche di nomi DNS tra zone. Ciò potrebbe rendere i tuoi progetti pronti per la migrazione senza influire sulle tue Google Cloud.
- Se l'aggiustamento del percorso di ricerca non esegue la transizione di tutti i query SQL, puoi aggiornare manualmente le query per utilizzare nomi DNS di zona.
- 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 alla il nome della VM, ad esempiomyapp-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
alla ricerca dall'elenco, il nome DNSmyapp-vm
può quindi essere risoltous-west4-b.c.PROJECT_ID.internal
viene aggiunto alla VM . Esegui il comando
project-info add-metadata
come segue.gcloud compute project-info add-metadata \ --metadata=enable-search-path-improvement=true
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.
- Se il valore del progetto è
Segui i passaggi in Determinare se il progetto è pronto per la migrazione per visualizzare l'utilizzo del DNS globale per un progetto. Utilizzare Esplora log per accedere ed eseguire query sull'utilizzo del DNS globale per le VM nel tuo progetto.
Nel riquadro Risultati delle query, ogni query ha un campo
jsonPayload
. Ciascuna Il campojsonPayload
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 l'impostazione Query DNS che non può essere risolta utilizzando 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 di query che mostra il numero di query di blocco della migrazione sulla VM di origine che invia alla VM di destinazione per quel giorno.
Il seguente screenshot mostra le informazioni del campo
jsonPayload
nel Pagina della console Esplora log.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 relativi a dove eseguire l'aggiornamento il nome di dominio completo e risolvere la compatibilità:- Nomi DNS interni dal server di metadati: non è richiesta alcuna azione perché il nome DNS restituito diventerà immediatamente un FQDN di zona dopo la migrazione al DNS di zona. Se il nome DNS viene memorizzato nella cache, devi effettuare una nuova chiamata per aggiornare il valore della cache.
- Nomi DNS interni utilizzati per accedere alle VM in un'altra regione: se disponi di un che utilizza i nomi DNS interni per le VM in diversi regioni, puoi modificare il criterio DHCP o il file di configurazione 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.
- Utilizza la pagina Esplora log per eseguire nuovamente 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.
- Ricontrolla la metrica di monitoraggio per vedere se tutti i DNS a rischio query sono state rimosse.
Ripeti i passaggi nella Controlla se il progetto utilizza il DNS globale per impostazione predefinita.
Per verificare che i metadati di progetto siano stati aggiornati, puoi eseguire questo :
gcloud compute project-info describe --flatten="vmDnsSetting"
Il comando dovrebbe restituire
ZONAL_ONLY
.Verifica che il nome DNS interno di una VM utilizza un nome DNS di zona.
Per verificare che il criterio dell'organizzazione
constraints/compute.setNewProjectDefaultToZonalDNSOnly
è in fase di applicazione, puoi:- Crea un nuovo progetto nella cartella o nell'organizzazione.
- Creare e avviare un'istanza VM.
- Controlla se la VM utilizza un nome DNS di zona.
Disabilita il criterio dell'organizzazione
constraints/compute.setNewProjectDefaultToZonalDNSOnly
nell'organizzazione a livello di cartella. Per istruzioni su come modificare queste norme, consulta Applica il DNS di zona per impostazione predefinita per i nuovi progetti.Configura l'applicazione di Configura l'impostazione del DNS interno per i nuovi progetti su Imposta l'opzione Solo DNS di zona su Off.
Se vuoi ripristinare l'uso del DNS globale per l'intera organizzazione, e verificare che nessuna delle cartelle nell'organizzazione applichi criterio dell'organizzazione
constraints/compute.setNewProjectDefaultToZonalDNSOnly
.Utilizza le sezioni seguenti per verificare che il DNS globale sia configurato per progetti, VM e container.
Aggiungi quanto segue ai metadati del progetto:
vmDnsSetting=GlobalDefault
.Per informazioni su come impostare i metadati di progetto o i valori dei metadati della VM, consulta Impostazione di metadati personalizzati.
Verifica che nessuna delle VM nel progetto abbia i metadati
vmDnsSetting
impostato suZonalOnly
.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
- VM Linux:
Aggiungi quanto segue ai metadati della VM:
vmDnsSetting=GlobalDefault
.Per informazioni su come impostare i valori dei metadati della VM, consulta Impostazione di metadati personalizzati.
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
Configura l'impostazione dei metadati di progetto
vmDnsSetting
suGlobalDefault
nella a progetti proprietari dei container e delle VM.Riavvia i container in modo che le relative impostazioni DNS ripristinino le impostazioni originali stato.
- Consulta la gerarchia delle risorse di Google Cloud per informazioni sulla relazione tra organizzazioni, cartelle e progetti.
- Scopri di più sul DNS interno per Compute Engine.
REST
Per utilizzare gli esempi di API REST in questa pagina in un ambiente di sviluppo locale, utilizzi le credenziali che fornisci 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 seguenti ruoli IAM:
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:
Potresti anche riuscire a ottenere queste autorizzazioni con ruoli personalizzati 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 in cui si trova la VM.
Quando effettui una chiamata a una VM utilizzando un nome DNS globale:
Quando effettui una chiamata a una VM utilizzando un nome 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. DNS di zona i nomi in una zona funzionano indipendentemente dalle altre zone, consentendoti Creare applicazioni multiregionali a tolleranza di errore con una migliore disponibilità caratteristiche. Non è previsto alcun costo per l'utilizzo del DNS di zona. Il DNS di zona è separate 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 di zona offre un'affidabilità maggiore rispetto al DNS globale isolando errori nella registrazione DNS nelle singole zone. Questo riduce l'impatto e gli errori single-point. 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 DNS interno predefinito per tutte le nuove organizzazioni con onboarding in Google Cloud dopo il 6 settembre, 2018. Se i tuoi progetti esistenti utilizzano ancora il DNS globale, Google consiglia vivamente di cambiare i progetti in modo che utilizzino i modelli a livello di zona Nomi DNS. Se non esegui la migrazione al DNS di zona, potresti riscontrare quanto segue problemi:
Un approccio alternativo per migliorare l'affidabilità dei carichi di lavoro che utilizzano il DNS globale deve essere migrato nelle zone private di Cloud DNS. L'utilizzo delle zone private di Cloud DNS rimuove il controllo di univocità dei nomi richiesto il DNS globale e isola gli errori per consentire la risoluzione dei nomi DNS. Per ulteriori informazioni informazioni su questa opzione, consulta documentazione di Cloud DNS o contatta il rappresentante dell'assistenza clienti Google Cloud o del team dedicato all'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:
In genere, la procedura prevede le seguenti fasi:
Limitazioni
Controlla la versione di glibc
Per controllare la versione di
glibc
utilizzata dalla tua VM:Controlla il numero di domini di ricerca se utilizzi glibc 2.25 o versioni precedenti
Passaggi per l'amministratore 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 di nome DNS interno per la tua organizzazione è determinato da la data di creazione dell'organizzazione e se il criterio dell'organizzazione il vincolo
constraints/compute.setNewProjectDefaultToZonalDNSOnly
è stato applicato in modo forzato.Console
gcloud
Usa il comando
organizations describe
e il comandoresource-manager org-policies list
per determinare il tipo DNS predefinito per un'organizzazione.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 utilizzando BigQuery per creare una tabella che elenca i relativi progetti per della tua organizzazione e dei relativi metadati. Puoi quindi utilizzare questa tabella per eseguire una query che espone il conteggio dei progetti totali che utilizzano il DNS globale.
Determina se una cartella è pronta per la migrazione al DNS di zona
Questo passaggio utilizza uno script
bash
e la tabella BigQuery creata in la sezione precedente per determinare l'idoneità della migrazione della cartella.Completa i seguenti passaggi:
#!/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 dell'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 già creata in precedenza 6 settembre 2018, per impostazione predefinita il tipo DNS interno utilizzato dal progetto è il DNS globale. Per isolare eventuali errori nella registrazione DNS nelle singole zone, puoi applicare il criterio dell'organizzazione
constraints/compute.setNewProjectDefaultToZonalDNSOnly
presso un'organizzazione o a livello di cartella.Quando imposti un criterio dell'organizzazione per eseguire l'override del DNS interno predefinito. i progetti appena creati utilizzano il DNS di zona per impostazione predefinita. La il criterio dell'organizzazione non influisce 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 dell'organizzazione.
Per convalidare la modifica ai criteri dell'organizzazione, puoi creare un nuovo progetto in la cartella o l'organizzazione, creare e avviare un'istanza VM, e verifica se la tua VM è abilitata per il DNS di zona.
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 all'interno dell'organizzazione sono presenti solo poche cartelle che non sono pronte per eseguire la migrazione a DNS di zona, ti consigliamo di impostare un criterio dell'organizzazione a livello di organizzazione, ma concedendo un'esenzione per le cartelle che non pronto 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.
organizzazione/Esempio.com
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
.Per ulteriori informazioni sulla personalizzazione dei vincoli dei criteri dell'organizzazione, consulta Personalizzazione dei criteri per i vincoli booleani nel 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 delle Da DNS a 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
gcloud
In the Google Cloud console, 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.
REST
Verifica il valore di
vmDnsSetting
utilizzando il metodo Metodoprojects.get
. In questo esempio viene utilizzato un parametro di queryfields
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
vmDnsSetting
indica se il progetto utilizza il DNS globale per impostazione predefinita.Determina se il progetto è pronto per la migrazione
Nella console Google Cloud, nella pagina Istanze VM, se il tuo progetto deve eseguire la migrazione a un DNS di zona, dovresti vedere una notifica banner sulla migrazione DNS a livello di zona.
Quando visualizzi le istanze VM pagina del tuo progetto, se il progetto è pronto per la migrazione (compatibile con il DNS di zona), il banner include una suggerimento per utilizzare il DNS di zona. Questo suggerimento si basa su dati interni Utilizzo del DNS nel progetto, ma limitato agli ultimi 100 giorni.
Se il progetto non è pronto per la migrazione al DNS di zona, viene visualizzato un banner diverso .
Per visualizzare l'utilizzo del DNS globale, fai clic sul pulsante Visualizza l'utilizzo del DNS globale. Questo ti porta alla pagina Esplora log nella console Google Cloud. Attivato 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, procedi come descritto di seguito: seguenti:
In alternativa, puoi inserire quanto segue nel campo 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:
L'intervallo di tempo utilizzato da queste metriche è un periodo di 100 giorni.
Per visualizzare queste metriche, utilizza Metrics Explorer nella console Google Cloud.
Esegui la migrazione dei progetti pronti al DNS di zona
In generale, puoi utilizzare il seguente processo di migrazione:
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 il
vmDnsSetting
di metadati per il progetto o la VM. Se impostivmDnsSetting
voce di metadati per una VM specifica, sostituisce qualsiasi impostazionevmDnsSetting
ereditato dai metadati di progetto per quella VM.La variabile
vmDnsSetting
supporta le seguenti impostazioni: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 la lease DHCP sulla VM. Puoi aggiornare il lease riavviando VM o in attesa della scadenza del lease oppure eseguendo uno dei seguenti :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 indica che almeno una query DNS rischiosa è stata effettuata entro un determinato periodo di tempo, ad esempio gli ultimi 30 giorni o 100 giorni. Una query rischiosa è una chiamata a una VM utilizzando un nome DNS globale (
VM_NAME.c.PROJECT_ID.internal
) che non possono essere perfettamente è stato risolto utilizzando un nome DNS di zona (VM_NAME.ZONE.c.PROJECT_ID.internal
). Le query rischiose potrebbero avere i seguenti attributi:Per i progetti con query rischiose, di solito è necessario un po' di lavoro aggiuntivo elimina tutte le ricerche DNS rischiose prima della migrazione.
Per i progetti non pronti per la migrazione, completa la seguenti passaggi:
Informazioni sulla funzionalità di miglioramento del percorso di ricerca
Per impostazione predefinita, la maggior parte delle distribuzioni Linux archivia le informazioni DHCP in
resolv.conf
. Di seguito unresolv.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 ognuno dei nomi host nel percorso di ricerca finché non viene trovato. Ad esempio, se una VM chiamaping my-vm
, i domini nel percorso di ricerca vengono aggiunti alla query originale per ottenere i nomi di dominio completi (FQDN), ad esempio utilizzandomy-vm.c.PROJECT_ID.internal
. In caso di 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 VM si trovi nella zona
us-west4-c
. Questa VM effettua una chiamata a un'altra VM denominatamyapp-vm
che si trova nellaus-west4-b
zona.Google offre una funzionalità di miglioramento del percorso di ricerca che esegue automaticamente le ricerche per il nome DNS di zona per una VM in tutte le zone nella stessa regione della VM. Come è possibile risolvere le query in più zone senza dover aggiornare
resolv.conf
o il tuo 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.Abilita il miglioramento dei percorsi di ricerca per risolvere le ricerche di nomi DNS tra zone
Per attivare la funzionalità di miglioramento del percorso di ricerca, segui questi passaggi.
Aggiorna manualmente le query in modo che utilizzino i nomi DNS di zona
Se utilizzi la funzionalità di miglioramento dei percorsi di ricerca per aggiungere domini di zona supplementari nella Il percorso di ricerca del nome DNS non esegue la transizione di tutte le query tra zone, puoi usare Esplora log per visualizzare l'utilizzo del DNS globale all'interno del progetto.
a identificare le query DNS globali che devono essere modificate manualmente per utilizzare anziché nomi di dominio completi (FQDN) di zona, completa questi passaggi:
Dopo aver aggiornato le query DNS globali per utilizzare il DNS di zona:
Verifica che la migrazione del progetto al DNS di zona sia completata
Ripristina 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 a livello di container.
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.
Ripristina l'utilizzo del DNS globale per un progetto
Per ripristinare l'utilizzo del DNS globale in un progetto, completa i passaggi riportati di seguito.
Ripristina l'utilizzo del DNS globale per una VM
Per ripristinare l'utilizzo del DNS globale per una VM specifica, completa i passaggi riportati di seguito.
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.
Risoluzione dei problemi del processo di migrazione dal DNS globale al DNS di zona
In caso di problemi con il processo di migrazione, consulta guida alla risoluzione dei problemi.
Nascondi il banner sulla migrazione del DNS a livello 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 viene 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
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2024-09-08 UTC.
[{ "type": "thumb-down", "id": "hardToUnderstand", "label":"Hard to understand" },{ "type": "thumb-down", "id": "incorrectInformationOrSampleCode", "label":"Incorrect information or sample code" },{ "type": "thumb-down", "id": "missingTheInformationSamplesINeed", "label":"Missing the information/samples I need" },{ "type": "thumb-down", "id": "translationIssue", "label":"Problema di traduzione" },{ "type": "thumb-down", "id": "otherDown", "label":"Altra" }] [{ "type": "thumb-up", "id": "easyToUnderstand", "label":"Facile da capire" },{ "type": "thumb-up", "id": "solvedMyProblem", "label":"Il problema è stato risolto" },{ "type": "thumb-up", "id": "otherUp", "label":"Altra" }] -