Questo documento mostra come risolvere i problemi relativi ai metadati di Compute Engine server web.
Le VM di Compute Engine archiviano i metadati su un server metadati. Le VM hanno automaticamente accesso all'API del server metadati senza alcuna autorizzazione aggiuntiva. Tuttavia, a volte le VM potrebbero perdere l'accesso al server dei metadati per una delle seguenti cause:
- Impossibile risolvere il nome di dominio del server di metadati
- La connessione al server dei metadati è bloccata da una delle seguenti opzioni:
- Configurazione del firewall a livello di sistema operativo
- Configurazione del proxy
- Routing personalizzato
Quando le VM non possono accedere al server dei metadati, alcuni processi potrebbero non riuscire.
Per informazioni sulla risoluzione dei problemi relativi a gke-metadata-server, consulta
Risolvere i problemi di autenticazione di GKE.
Prima di iniziare
-
Se non l'hai già fatto, configura l'autenticazione.
Autenticazione è
Il processo 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.
- Il server non è al momento disponibile
- L'host sta eseguendo un evento di manutenzione
- Connettiti alla VM Linux.
Dalla VM Linux, esegui i seguenti comandi per testare la connettività al server di 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 verificare, 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 dei comandi precedenti corrisponde l'output, la VM è connessa al server dei metadati è necessaria un'ulteriore azione. Se i comandi non vanno a buon fine, procedi come segue:
Verifica che il server dei nomi sia configurato sul server 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, fai riferimento documentazione del sistema operativo per informazioni su come modificare il Criterio DHCP per mantenere la configurazione del server dei nomi su
169.254.169.254. Questo perché le modifiche a/etc/resolv.confverranno viene sovrascritta in un'ora se DNS di zona vengono applicate alle VM nel tuo 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/hostsNell'output dovrebbe essere presente la seguente riga:
169.254.169.254 metadata.google.internal # Added by Google
Se l'output non include la riga precedente, esegui questo :
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
- Connettiti alla tua VM Windows.
Dalla VM Windows, esegui questi 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 verificarlo, esegui questi 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 dei comandi precedenti corrisponde a quello suggerito, la VM è connessa al server dei metadati e non sono necessarie ulteriori azioni. Se i comandi non funzionano:
Verifica che esista una route permanente al server di metadati eseguendo 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 include la riga precedente, aggiungi il metodo 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 di metadati e il relativo indirizzo IP:
type %WINDIR%\System32\Drivers\Etc\HostsNell'output dovrebbe essere presente la seguente riga:
169.254.169.254 metadata.google.internal # Added by Google
Se l'output non include la riga precedente, esegui il comando seguente comando:
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
- Connettiti alla VM Linux.
Dalla VM Linux, esegui questi comandi:
export no_proxy=169.254.169.254,metadata,metadata.google.internalPer salvare le modifiche, esegui il comando seguente:
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment- Connetti la VM Windows.
Dalla VM Windows, esegui questi comandi:
set NO_PROXY=169.254.169.254,metadata,metadata.google.internalPer salvare le modifiche, esegui il comando seguente:
setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /mcurl: (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
- Il formato del percorso del flag
--cacertpotrebbe non essere corretto - Il certificato radice potrebbe non essere presente nel magazzino attendibile
La richiesta è stata accettata. Tuttavia, riceverai consigli che potresti le VM che effettuano richieste al server di metadati con una formattazione errata intestazioni. I suggerimenti vengono inviati una volta per VM. Puoi accedere a questi consigli utilizzando Google Cloud CLI o l'API REST Recommender.
Dopo aver applicato il consiglio, imposta lo stato del consiglio su
succeeded.A partire dal 20 gennaio 2024, il server dei metadati rifiuta qualsiasi richiesta con un'intestazione con formattazione errata.
REST
Per utilizzare gli esempi dell'API REST in questa pagina in un ambiente di sviluppo locale, utilizza le credenziali fornite a gcloud CLI.
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud initPer ulteriori informazioni, vedi Esegui l'autenticazione per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud.
Errori del server
Il server dei metadati potrebbe restituire il codice di stato
Error 503nelle seguenti circostanze:Se l'applicazione riceve un codice di errore 503, riprova a eseguire la richiesta.
Richieste non riuscite al server dei metadati
Di seguito sono riportati alcuni esempi di errori che potresti riscontrare in caso di errore della VM raggiungere il server 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
Risoluzione dei problemi relativi alle richieste al server di metadati non riuscite
Se la tua VM ha perso l'accesso al server dei metadati, segui questi passaggi:
Linux
Windows
Richieste non riuscite durante l'utilizzo di un proxy di rete
Un server proxy di rete impedisce l'accesso diretto della VM a internet. Tutte le query e inviati dall'interno di una VM vengono gestiti dal server proxy.
Quando utilizzi un'applicazione che riceve le credenziali dal server dei metadati, come un token di autenticazione, la VM richiede l'accesso diretto al server dei metadati. Se la VM è protetta da un proxy, devi impostare
NO_PROXYsia per l'indirizzo IP che per il nome host.Se non imposti la configurazione di
NO_PROXY, potresti visualizzare errori durante l'esecuzione di comandi Google Cloud CLI o di query direttamente sul server di metadati poiché le chiamate al numerometadata.google.internalverranno inviate al senza doverli risolvere localmente sull'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 questo problema relativo al proxy, aggiungi il nome host e l'indirizzo IP del server di metadati a la variabile di ambiente
NO_PROXYnel seguente modo:Linux
Windows
Risolvere i problemi relativi alle richieste non riuscite all'endpoint del server di metadati HTTPS
Questa sezione illustra alcuni degli errori che potresti visualizzare quando esegui query sull'endpoint del server di metadati HTTPS.
Gli errori elencati in questa sezione vengono restituiti quando esegui una query utilizzando il cURL per eseguire una query, tuttavia il messaggio di errore restituito è simile a quello di altri strumenti.
Certificato client errato
Se fornisci un valore errato per
-E, si verificano i seguenti errori flag.Per risolvere il problema, fornisci il percorso corretto del certificato di identità del cliente. Per visualizzare la località dei certificati di identità client, consulta Certificati di identità client.
Nome host non valido
Il seguente errore si verifica se il nome host utilizzato per accedere al server di metadati non è presente nel certificato.
curl: (60) SSL: no alternative certificate subject name matches target host name
Per risolvere il problema, verifica che il nome host o l'URL principale della query sia
metadata.google.internal. Per ulteriori informazioni sull'URL principale del server dei metadati, consulta la sezione Componenti di una richiesta di metadati.Certificato radice o client errato
Potresti visualizzare il seguente errore quando esegui una query sul server metadati HTTPS endpoint:
curl: (77) error setting certificate verify locations:
Ciò potrebbe verificarsi nei seguenti scenari:
Per risolvere questo problema, devi specificare sia il il certificato radice e il certificato client quando esegui una query sull'endpoint https. Per le località dei certificati, vedi Dove vengono archiviati i certificati.
Ad esempio, per eseguire una query sull'immagine di avvio di una VM, esegui la seguente query:
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"Formato dell'intestazione errato
Il server dei metadati esegue controlli di formattazione per verificare che le intestazioni siano conformi con le linee guida per la formattazione dell'intestazione RFC 7230 Sezione 3.2. Se il formato dell'intestazione non supera questi controlli, si verifica quanto segue:
Di seguito sono riportati esempi di formati di richieste di intestazioni validi e non validi.
Non valido: contiene spazi vuoti tra il nome dell'intestazione e i due punti
Metadata-Flavor : Google
Valido: non devono esserci spazi vuoti tra le intestazioni nome e due punti, lo spazio vuoto dopo i due punti viene ignorato dal controllo
Metadata-Flavor: Google
Valido: nessun spazio vuoto nell'intestazione
Metadata-Flavor:Google
Per ulteriori informazioni su come eseguire query sul server dei metadati, consulta Accedere 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 2024-10-14 UTC.
-