Questo documento mostra come risolvere i problemi relativi al server dei metadati di Compute Engine.
Le VM Compute Engine archiviano i metadati su un server dei metadati. Le VM hanno automaticamente accesso all'API del server metadati senza autorizzazioni aggiuntive. Tuttavia, a volte le VM potrebbero perdere l'accesso al server dei metadati per una delle seguenti cause:
- mancata risoluzione del nome di dominio del server dei metadati
- connessione al server dei metadati bloccata da uno dei seguenti elementi:
- configurazione del firewall a livello di sistema operativo
- configurazione del proxy
- Routing personalizzato
Quando le VM non riescono ad accedere al server dei metadati, alcuni processi potrebbero non andare a buon fine.
Per informazioni sulla risoluzione dei problemi relativi a gke-metadata-server, consulta
Risolvi i problemi di autenticazione di GKE.
Prima di iniziare
-
Se non l'hai ancora fatto, configura l'autenticazione.
L'autenticazione è
il processo mediante il quale la tua identità viene verificata per l'accesso a servizi e API Google Cloud .
Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi autenticarti su Compute Engine selezionando una delle seguenti opzioni:
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. After installation, initialize the Google Cloud CLI by running the following command:
gcloud initIf you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
- Set a default region and zone.
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.
Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:
gcloud initIf you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.
Per saperne di più, consulta Autenticarsi per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud .
Risolvere i problemi relativi ai codici del server
I seguenti codici di server vengono restituiti quando effettui chiamate al server metadati di Compute Engine. Consulta questa sezione per scoprire come rispondere a ogni codice del server restituito dal server dei metadati.
Codici server comuni
Il server dei metadati spesso restituisce questi codici.
Codice del server Descrizione Risoluzione 200 Ok: la richiesta è andata a buon fine N/D 400 Richiesta non valida: questo stato di errore viene restituito per molti scenari diversi, ad esempio quando una richiesta contiene parametri di query impropri o non sono stati soddisfatti i requisiti dell'endpoint. Leggi con attenzione il messaggio di errore per trovare suggerimenti su come risolvere il problema 403 Operazione non consentita: questo stato di errore viene restituito nei seguenti scenari: - L'endpoint richiesto è disattivato dalle impostazioni del progetto o delle istanze
- La richiesta non supera i controlli di sicurezza. Questo problema può verificarsi se la connessione TCP al server è stata chiusa a livello di rete.
Controlla le impostazioni del progetto e dell'istanza per assicurarti che l'endpoint sia attivo o controlla la configurazione di rete 404 Non trovato: l'endpoint richiesto non esiste Correggi il percorso della richiesta 429 Troppe richieste: questo accade perché alcuni endpoint utilizzano la limitazione di frequenza per evitare il sovraccarico del servizio di supporto. Ti consigliamo vivamente di eseguire nuovi tentativi con il backoff esponenziale. Per saperne di più, consulta l'elenco di endpoint con limitazione di frequenza. Attendi qualche secondo e riprova a effettuare la chiamata 503 Servizio non disponibile: il server dei metadati non è pronto a gestire la richiesta. Il server dei metadati potrebbe restituire il codice di stato Error 503in una delle seguenti circostanze:- Il server dei metadati è ancora in fase di avvio
- Il server dei metadati è in fase di migrazione
- Il server dei metadati è momentaneamente non disponibile
- La macchina host sta eseguendo un evento di manutenzione
- Il server dei metadati potrebbe restituire un valore
503quando viene applicata una limitazione di frequenza ad alcuni endpoint.
Gli errori 503 sono temporanei e dovrebbero risolversi al massimo nel giro di alcuni secondi. Per risolvere il problema, attendi qualche secondo e riprova a effettuare la chiamata. Codici di server rari
Questi codici del server, benché rari, potrebbero essere restituiti anche dal server dei metadati.
Codice del server Descrizione Risoluzione 301 Spostato permanentemente: viene fornito per i percorsi con reindirizzamenti Aggiorna il percorso della richiesta 405 Non consentito: questo codice di errore viene restituito se viene richiesto un metodo non supportato.
Il server dei metadati supporta solo le operazioniGET, ad eccezione dei metadati scrivibili dal guest, che consentono le operazioniSET.Aggiorna il metodo nel percorso della richiesta Codici di errore degli endpoint con limiti di frequenza
I seguenti endpoint sono soggetti a limiti di frequenza e potrebbero restituire codici di errore. Per gestire i codici di errore restituiti, consulta la sezione Indicazioni per i nuovi tentativi.
Endpoint Codice di stato Descrizione oslogin/429I limiti di frequenza di OS Login sono condivisi tra le richieste di utenti, autorizzazioni e gruppi. instance/service-accounts/identity503L'endpoint che firma l'identità potrebbe restituire codici di risposta 429o503per segnalare una risposta con limite di frequenza.instance/service-accounts/default/token429I token memorizzati nella cache nel server dei metadati non sono soggetti a limitazione di frequenza. I token non memorizzati nella cache sono soggetti a limitazione di frequenza. instance/guest-attributes/429,503Le richieste relative agli attributi guest potrebbero essere limitate se superi 3 QPS o 10 QPM. In tal caso, vengono restituiti i codici di errore 429o503.Indicazioni per i nuovi tentativi
Il server dei metadati restituisce regolarmente codici di errore 503 e 429. Per rendere resilienti le applicazioni, ti consigliamo di implementare la logica per i nuovi tentativi per le applicazioni che eseguono query sul server dei metadati. Ti consigliamo inoltre di implementare il backoff esponenziale nei tuoi script per tenere conto di eventuali limitazioni di frequenza.
Risolvi i problemi relativi alle richieste al server dei metadati non andate a buon fine
Di seguito sono riportati alcuni esempi di errori che potresti riscontrare se la VM non riesce a raggiungere il server dei metadati:
curl: (6) Could not resolve host: metadata.google.internal
postAttribute error: Put "http://metadata.google.internal/computeMetadata/v1/instance/guest-attributes/guestInventory/ShortName": dial tcp: lookup metadata.google.internal on [::1]:53: read udp [::1]:58319->[::1]:53: read: connection refused
Se la VM non ha più accesso al server dei metadati, segui questi passaggi:
Linux
- Connetti la VM Linux.
Dalla VM Linux, esegui i seguenti comandi per testare la connettività al server dei metadati:
Esegui una query sul server dei nomi di dominio:
nslookup metadata.google.internalL'output dovrebbe essere simile al seguente:
Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Verifica che il server dei metadati sia raggiungibile. Per farlo, esegui i seguenti comandi:
ping -c 3 metadata.google.internalL'output dovrebbe essere simile al seguente:
PING metadata.google.internal (169.254.169.254) 56(84) bytes of data. 64 bytes from metadata.google.internal (169.254.169.254): icmp_seq=1 ttl=255 time=0.812 ms
ping -c 3 169.254.169.254L'output dovrebbe essere simile al seguente:
PING 169.254.169.254 (169.254.169.254) 56(84) bytes of data. 64 bytes from 169.254.169.254: icmp_seq=1 ttl=255 time=1.11 ms
Se l'output di questi comandi corrisponde all'output suggerito, la VM viene connessa al server dei metadati e non sono necessarie ulteriori azioni. Se i comandi non vanno a buon fine, procedi nel seguente modo:
Verifica che il server dei nomi sia configurato in modo da puntare verso il server dei metadati:
cat /etc/resolv.confL'output dovrebbe essere simile al seguente:
domain ZONE.c.PROJECT_ID.internal search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal. nameserver 169.254.169.254
Se l'output non contiene le righe precedenti, consulta la documentazione del sistema operativo per informazioni su come modificare la policy DHCP per mantenere la configurazione del server DNS su
169.254.169.254. Questo perché le modifiche a/etc/resolv.confverranno sovrascritte nell'arco di un'ora se le impostazioni del DNS di zona vengono applicate alle VM del progetto. Se il tuo progetto utilizza ancora un DNS globale, il fileresolv.conftornerà al DHCP predefinito entro 24 ore.Verifica che esista la mappatura tra il nome di dominio del server dei metadati e il relativo indirizzo IP:
cat /etc/hostsL'output dovrebbe contenere la seguente riga:
169.254.169.254 metadata.google.internal # Added by Google
Se l'output non contiene suddetta riga, esegui il seguente comando:
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
Windows
- Connettiti alla VM Windows.
Dalla VM Windows, esegui i seguenti comandi:
Esegui una query sul server dei nomi di dominio:
nslookup metadata.google.internalL'output dovrebbe essere simile al seguente:
Server: UnKnown Address: 10.128.0.1 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Verifica che il server dei metadati sia raggiungibile. Per farlo, esegui i seguenti comandi:
ping -n 3 metadata.google.internalL'output dovrebbe essere simile al seguente:
Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data: Reply from 169.254.169.254: bytes=32 time=1ms TTL=255
ping -n 3 169.254.169.254L'output dovrebbe essere simile al seguente:
Pinging metadata.google.internal [169.254.169.254] with 32 bytes of data: Reply from 169.254.169.254: bytes=32 time=1ms TTL=255
Se l'output di questi comandi corrisponde all'output suggerito, la VM viene connessa al server dei metadati e non sono necessarie ulteriori azioni. Se i comandi non vanno a buon fine, procedi nel seguente modo:
Verifica che esista una route permanente al server dei metadati tramite il comando:
route printL'output dovrebbe contenere quanto segue.
Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 On-link 1
Se l'output non contiene suddetta riga, aggiungi la route utilizzando i seguenti comandi:
$Adapters = Get-NetKVMAdapterRegistry $FirstAdapter = $Adapters | Select-Object -First 1 route /p add 169.254.169.254 mask 255.255.255.255 0.0.0.0 'if' $FirstAdapter.InterfaceIndex metric 1Verifica che esista la mappatura tra il nome di dominio del server dei metadati e il relativo indirizzo IP:
type %WINDIR%\System32\Drivers\Etc\HostsL'output dovrebbe contenere la seguente riga:
169.254.169.254 metadata.google.internal # Added by Google
Se l'output non contiene suddetta riga, esegui il seguente comando:
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
Risolvi i problemi relativi alle richieste non andate a buon fine quando utilizzi un proxy di rete
Un server proxy di rete impedisce l'accesso diretto della VM a internet. Tutte le query inviate dall'interno di una VM vengono gestite dal server proxy.
Quando utilizzi un'applicazione che ottiene le credenziali dal server dei metadati, come un token di autenticazione, la VM richiede l'accesso diretto al server dei metadati. Se la VM utilizza un proxy, devi impostare la configurazione
NO_PROXYsia per l'indirizzo IP sia per il nome host.Se non imposti la configurazione
NO_PROXY, potresti visualizzare errori quando esegui i comandi Google Cloud CLI o fai query direttamente sul server dei metadati. Questo perché le chiamate ametadata.google.internalverranno inviate al proxy senza essere risolte localmente nell'istanza stessa.Di seguito è riportato un esempio di errore che potresti visualizzare:
ERROR 403 (Forbidden): Your client does not have permission to get URL
Per risolvere il problema del proxy, aggiungi il nome host e l'indirizzo IP del server dei metadati alla variabile di ambiente
NO_PROXYnel seguente modo:Linux
- Connetti la VM Linux.
Dalla VM Linux, esegui i seguenti comandi:
export no_proxy=169.254.169.254,metadata,metadata.google.internalPer salvare le modifiche, esegui il seguente comando:
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment
Windows
- Connettiti alla VM Windows.
Dalla VM Windows, esegui i seguenti comandi:
set NO_PROXY=169.254.169.254,metadata,metadata.google.internalPer salvare le modifiche, esegui il seguente comando:
setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m
Risolvi i problemi relativi alle richieste all'endpoint del server dei metadati HTTPS non andate a buon fine
Questa sezione illustra alcuni degli errori che potresti visualizzare quando fai query sull'endpoint del server dei metadati HTTPS.
Gli errori riportati in questa sezione vengono restituiti quando fai una query utilizzando lo strumento cURL, ma il messaggio di errore restituito è simile anche per altri strumenti.
Certificato client errato
Se fornisci un valore errato per il flag
-E, si verificano i seguenti errori.curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0
curl: (58) unable to set private key file:
curl: (58) could not load PEM client certificate, OpenSSL error error:02001002:system library:fopen:No such file or directory
Per risolvere il problema, fornisci il percorso corretto del certificato di identità del client. Per visualizzare la posizione dei certificati di identità del client, consulta Certificati di identità del client.
Nome host errato
Il seguente errore si verifica se il nome host utilizzato per accedere al server dei metadati non viene trovato nel certificato.
curl: (60) SSL: no alternative certificate subject name matches target host name
Per risolvere il problema, verifica che l'URL di base o il nome host nella query sia
metadata.google.internal. Per ulteriori informazioni sull'URL di base del server dei metadati, consulta la sezione Componenti di una richiesta di metadati.Certificato client o radice errato
Quando fai una query sull'endpoint del server dei metadati HTTPS, potresti visualizzare il seguente errore:
curl: (77) error setting certificate verify locations:
Questo è possibile nei seguenti scenari:
- Il percorso per il flag
--cacertpotrebbe non essere valido - Il certificato radice potrebbe non essere presente nell'archivio di attendibilità
Per risolvere il problema, devi specificare sia il certificato radice sia il certificato client quando fai una query sull'endpoint HTTPS. Per le posizioni dei certificati, consulta Dove sono archiviati i certificati.
Ad esempio, per fare una query sull'immagine di avvio di una VM, procedi in questo modo:
user@myinst:~$ curl "https://metadata.google.internal/computeMetadata/v1/instance/image" \ -E /run/google-mds-mtls/client.key \ --cacert /run/google-mds-mtls/root.crt \ -H "Metadata-Flavor: Google"Risolvi i problemi relativi al formato errato dell'intestazione
Il server dei metadati esegue controlli di formattazione per garantire che le intestazioni rispettino le linee guida per la formattazione delle intestazioni riportate nella sezione 3.2 del documento RFC 7230. Se il formato dell'intestazione non supera questi controlli, si verifica quanto segue:
La richiesta è accettata. Tuttavia, riceverai suggerimenti che ti informano che alcune VM stanno inviando richieste al server dei metadati con intestazioni non formattate correttamente. I suggerimenti vengono inviati una volta per ciascuna VM. Puoi visualizzarli utilizzando Google Cloud CLI o il motore per suggerimenti di API REST.
Dopo aver applicato il suggerimento, imposta il suo stato su
succeeded.A partire dal 20 gennaio 2024, il server dei metadati rifiuta qualsiasi richiesta con un'intestazione formattata in modo errato.
Di seguito sono riportati esempi di formati di intestazioni di richieste validi e non validi.
Non valido: contiene spazi vuoti tra il nome dell'intestazione e i due punti.
Metadata-Flavor : Google
Valido: non sono presenti spazi vuoti tra il nome dell'intestazione e i due punti. Lo spazio dopo i due punti viene ignorato dal controllo.
Metadata-Flavor: Google
Valido: non sono presenti spazi vuoti nell'intestazione.
Metadata-Flavor:Google
Per ulteriori informazioni su come fare query sul server dei metadati, consulta Accedi ai metadati della VM.
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 2025-08-18 UTC.
-