Este documento mostra-lhe como resolver problemas com o servidor de metadados do Compute Engine.
As VMs do Compute Engine armazenam metadados num servidor de metadados. As VMs têm automaticamente acesso à API do servidor de metadados sem autorização adicional. No entanto, por vezes, as VMs podem perder o acesso ao servidor de metadados devido a uma das seguintes causas:
- Falha ao resolver o nome de domínio do servidor de metadados
- A ligação ao servidor de metadados está bloqueada por um dos seguintes motivos:
- Configuração da firewall ao nível do SO
- Configuração do proxy
- Encaminhamento personalizado
Quando as VMs não conseguem aceder ao servidor de metadados, alguns processos podem falhar.
Para obter informações sobre a resolução de problemas do gke-metadata-server, consulte o artigo
Resolva problemas de autenticação do GKE.
Antes de começar
-
Se ainda não o tiver feito, configure a autenticação.
A autenticação valida a sua identidade para aceder a Google Cloud serviços e APIs. Para executar código ou exemplos a partir de um ambiente de desenvolvimento local, pode autenticar-se no Compute Engine selecionando uma das seguintes opções:
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
-
Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando:
gcloud initSe estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.
- Set a default region and zone.
REST
Para usar os exemplos da API REST nesta página num ambiente de desenvolvimento local, usa as credenciais que fornece à CLI gcloud.
Instale a CLI Google Cloud. Após a instalação, inicialize a CLI gcloud executando o seguinte comando:
gcloud initSe estiver a usar um fornecedor de identidade (IdP) externo, primeiro tem de iniciar sessão na CLI gcloud com a sua identidade federada.
Para mais informações, consulte o artigo Autenticar para usar REST na Google Cloud documentação de autenticação.
Resolva problemas com códigos de servidor
Os seguintes códigos de servidor são devolvidos quando faz chamadas para o servidor de metadados do Compute Engine. Reveja esta secção para saber como responder a cada código de servidor devolvido pelo servidor de metadados.
Códigos de servidor comuns
Estes códigos de servidor são devolvidos frequentemente pelo servidor de metadados.
Código do servidor Descrição Resolução 200 OK: o pedido foi bem-sucedido N/A 400 Pedido incorreto: este estado de erro é devolvido para muitos cenários diferentes, como quando um pedido tem parâmetros de consulta inadequados ou os requisitos para esse ponto final não foram cumpridos. Reveja a mensagem de erro para ver sugestões sobre como corrigir o erro 403 Proibido: este estado de erro é devolvido nos seguintes cenários: - O ponto final pedido está desativado pelas definições do projeto ou das instâncias
- O pedido falha nas verificações de segurança. Este problema pode ocorrer se a sua ligação TCP ao servidor tiver sido fechada na camada de rede.
Verifique as definições do projeto e da instância para garantir que o ponto final está ativado ou verifique a configuração de rede 404 Não encontrado: o ponto final pedido não existe Corrija o caminho do pedido 429 Demasiados pedidos: isto ocorre porque alguns pontos finais usam limites de taxa para evitar a sobrecarga no serviço de apoio. Voltar a tentar com retirada exponencial é fortemente recomendado. Para mais informações, consulte a lista de pontos finais com limite de taxa. Aguarde alguns segundos e repita a chamada 503 Serviço indisponível: o servidor de metadados não está pronto para publicação. O servidor de metadados pode devolver o código de estado Error 503em qualquer uma das seguintes circunstâncias:- O servidor de metadados ainda está a ser iniciado
- O servidor de metadados está em processo de migração
- O servidor de metadados está temporariamente indisponível
- A máquina anfitriã está a realizar um evento de manutenção
- O servidor de metadados pode devolver um
503quando limita a taxa de alguns pontos finais.
Os erros 503 são transitórios e devem ser resolvidos após, no máximo, alguns segundos. Para resolver o problema, aguarde alguns segundos e repita a chamada. Códigos de servidor raros
Embora raros, estes códigos de servidor também podem ser devolvidos pelo servidor de metadados.
Código do servidor Descrição Resolução 301 Movido permanentemente: este código é fornecido para caminhos que têm redirecionamentos Atualize o caminho do pedido 405 Não permitido: este código de erro é devolvido se for pedido um método não suportado.
O servidor de metadados só suporta operaçõesGET, com exceção dos metadados graváveis por convidados, que permitem operaçõesSET.Atualize o método no caminho do pedido Códigos de erro de pontos finais com velocidade limitada
Os seguintes pontos finais estão sujeitos a limites de taxa e podem devolver códigos de erro. Para processar estes códigos de erro devolvidos, consulte as Orientações de repetição.
Ponto final Código de estado Descrição oslogin/429Os limites de taxa de início de sessão do SO são partilhados entre pedidos de utilizadores, autorização e grupos. instance/service-accounts/identity503O ponto final de assinatura de identidade pode devolver códigos de resposta 429ou503para indicar uma resposta com limite de taxa.instance/service-accounts/default/token429Os tokens em cache no servidor de metadados não estão sujeitos a limites de taxa. Os tokens não colocados em cache estão sujeitos a limitação de velocidade. instance/guest-attributes/429,503Os pedidos de atributos de hóspedes podem ser limitados se exceder 3 QPS ou 10 QPM. Se ocorrer a limitação, são devolvidos os códigos de erro 429ou503.Tentar orientações novamente
O servidor de metadados devolve rotineiramente códigos de erro 503 e 429. Para tornar as suas aplicações resilientes, recomendamos que implemente uma lógica de repetição para aplicações que consultam o servidor de metadados. Também sugerimos que implemente o recuo exponencial nos seus scripts para ter em conta uma possível limitação de taxa.
Resolva problemas de pedidos com falha ao servidor de metadados
Seguem-se exemplos de erros que pode encontrar se a sua VM não conseguir aceder ao servidor de metadados:
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 a sua VM tiver perdido o acesso ao servidor de metadados, faça o seguinte:
Linux
- Estabeleça ligação à sua VM do Linux.
Na sua VM do Linux, execute os seguintes comandos para testar a conetividade com o servidor de metadados:
Consultar o servidor de nomes de domínio:
nslookup metadata.google.internalO resultado deve ser semelhante ao seguinte:
Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Verifique se o servidor de metadados é acessível. Para validar, execute os seguintes comandos:
ping -c 3 metadata.google.internalO resultado deve ser semelhante ao seguinte:
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.254O resultado deve ser semelhante ao seguinte:
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 o resultado dos comandos anteriores corresponder ao resultado sugerido, a sua VM está ligada ao servidor de metadados e não é necessária nenhuma ação adicional. Se os comandos falharem, faça o seguinte:
Verifique se o servidor de nomes está configurado para o servidor de metadados:
cat /etc/resolv.confO resultado deve ser semelhante ao seguinte:
domain ZONE.c.PROJECT_ID.internal search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal. nameserver 169.254.169.254
Se a saída não tiver as linhas anteriores, consulte a documentação do seu sistema operativo para obter informações sobre como editar a política de DHCP para manter a configuração do servidor de nomes em
169.254.169.254. Isto deve-se ao facto de as alterações a/etc/resolv.confserem substituídas no prazo de uma hora se as definições de DNS zonal forem aplicadas às VMs no seu projeto. Caso o seu projeto ainda esteja a usar um DNS global, o ficheiroresolv.confé revertido para o DHCP predefinido em 24 horas.Verifique se existe o mapeamento entre o nome do domínio do servidor de metadados e o respetivo endereço IP:
cat /etc/hostsA seguinte linha deve estar no resultado:
169.254.169.254 metadata.google.internal # Added by Google
Se o resultado não tiver a linha anterior, execute o seguinte comando:
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
Windows
- Estabeleça ligação à sua VM do Windows.
Na VM do Windows, execute os seguintes comandos:
Consultar o servidor de nomes de domínio:
nslookup metadata.google.internalO resultado deve ser semelhante ao seguinte:
Server: UnKnown Address: 10.128.0.1 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Verifique se o servidor de metadados é acessível. Para validar, execute os seguintes comandos:
ping -n 3 metadata.google.internalO resultado deve ser semelhante ao seguinte:
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.254O resultado deve ser semelhante ao seguinte:
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 o resultado dos comandos anteriores corresponder ao resultado sugerido, a VM está ligada ao servidor de metadados e não é necessária nenhuma ação adicional. Se os comandos falharem, faça o seguinte:
Verifique se existe um caminho persistente para o servidor de metadados executando o comando:
route printO resultado deve conter o seguinte:
Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 On-link 1
Se o resultado não tiver a linha anterior, adicione a rota através dos seguintes comandos:
$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 1Verifique se existe o mapeamento entre o nome do domínio do servidor de metadados e o respetivo endereço IP:
type %WINDIR%\System32\Drivers\Etc\HostsA seguinte linha deve estar no resultado:
169.254.169.254 metadata.google.internal # Added by Google
Se o resultado não tiver a linha anterior, execute o seguinte comando:
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
Resolva problemas de pedidos com falhas ao usar um proxy de rede
Um servidor proxy de rede impede o acesso direto da VM à Internet. Todas as consultas enviadas a partir de uma MV são processadas pelo servidor proxy.
Quando usa uma aplicação que recebe credenciais do servidor de metadados, como um token de autenticação, a VM requer acesso direto ao servidor de metadados. Se a VM estiver atrás de um proxy, tem de definir a
NO_PROXYconfiguração para o endereço IP e o nome do anfitrião.Se não definir a configuração
NO_PROXY, pode ver erros ao executar comandos da CLI do Google Cloud ou consultar o servidor de metadados diretamente, uma vez que as chamadas parametadata.google.internalsão enviadas para o proxy sem serem resolvidas localmente na própria instância.Segue-se um exemplo de um erro que pode ver:
ERROR 403 (Forbidden): Your client does not have permission to get URL
Para resolver este problema de proxy, adicione o nome do anfitrião e o endereço IP do servidor de metadados à variável de ambiente
NO_PROXYfazendo o seguinte:Linux
- Estabeleça ligação à sua VM do Linux.
Na VM do Linux, execute os seguintes comandos:
export no_proxy=169.254.169.254,metadata,metadata.google.internalPara guardar as alterações, execute o seguinte comando:
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment
Windows
- Estabeleça ligação à sua VM do Windows.
Na VM do Windows, execute os seguintes comandos:
set NO_PROXY=169.254.169.254,metadata,metadata.google.internalPara guardar as alterações, execute o seguinte comando:
setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m
Resolva problemas de pedidos com falhas para o ponto final do servidor de metadados HTTPS
Esta secção aborda alguns dos erros que pode ver quando consulta o ponto final do servidor de metadados HTTPS.
Os erros indicados nesta secção são devolvidos quando faz consultas através da ferramenta cURL. No entanto, a mensagem de erro devolvida é semelhante para outras ferramentas.
Certificado de cliente incorreto
Ocorrem os seguintes erros se fornecer um valor incorreto para a flag
-Ecurl: (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
Para resolver este problema, indique o caminho correto para o certificado de identidade do cliente. Para ver a localização dos certificados de identidade do cliente, consulte o artigo Certificados de identidade do cliente.
Nome do anfitrião incorreto
O seguinte erro ocorre se o nome de anfitrião usado para aceder ao servidor de metadados não for encontrado no certificado.
curl: (60) SSL: no alternative certificate subject name matches target host name
Para resolver este problema, verifique se o URL de raiz ou o nome de anfitrião na sua consulta é
metadata.google.internal. Para mais informações sobre o URL raiz do servidor de metadados, consulte Partes de um pedido de metadados.Certificado de cliente ou de raiz incorreto
Pode ver o seguinte erro quando consulta o ponto final do servidor de metadados HTTPS:
curl: (77) error setting certificate verify locations:
Isto pode acontecer nos seguintes cenários:
- O caminho para a flag
--cacertpode ter um formato incorreto - O certificado de raiz pode estar em falta na loja de confiança
Para resolver este problema, tem de especificar o certificado de raiz e o certificado de cliente quando consultar o ponto final https. Para ver as localizações dos certificados, consulte o artigo Onde são armazenados os certificados.
Por exemplo, para consultar a imagem de arranque de uma VM, execute a seguinte consulta:
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"Resolva problemas de formato de cabeçalho incorreto
O servidor de metadados realiza verificações de formatação para garantir que os cabeçalhos estão em conformidade com a diretriz de formatação de cabeçalhos da secção 3.2 da RFC 7230. Se o formato do cabeçalho falhar nestas verificações, ocorre o seguinte:
O pedido é aceite. No entanto, recebe recomendações de que tem VMs a fazer pedidos ao servidor de metadados com cabeçalhos com formatação incorreta. As recomendações são enviadas uma vez por MV. Pode aceder a estas recomendações através da CLI Google Cloud ou da API REST do Recomendador.
Depois de aplicar a recomendação, defina o estado da recomendação como
succeeded.A partir de 20 de janeiro de 2024, o servidor de metadados nega qualquer pedido com um cabeçalho formatado incorretamente.
Seguem-se exemplos de formatos de pedidos de cabeçalho válidos e inválidos.
Não é válido: contém espaços em branco entre o nome do cabeçalho e os dois pontos
Metadata-Flavor : Google
Válido: sem espaços em branco entre o nome do cabeçalho e os dois pontos. O espaço em branco após os dois pontos é ignorado pelo verificador
Metadata-Flavor: Google
Válido: sem espaços em branco no cabeçalho
Metadata-Flavor:Google
Para mais informações sobre como fazer consultas ao servidor de metadados, consulte o artigo Aceda aos metadados da VM.
Resolva problemas de falha na obtenção do token
Pode ver um dos seguintes erros quando consulta o servidor de metadados:
ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
curl: (22) The requested URL returned error: 401
Estes erros podem surgir se a conta de serviço associada à VM estiver desativada. Para resolver estes erros, ative a conta de serviço ou anexe uma conta de serviço diferente.
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-10-19 UTC.
-