Este documento mostra como resolver problemas com o servidor de metadados do Compute Engine.
As VMs do Compute Engine armazenam metadados em um servidor de metadados. As VMs têm acesso automático à API do servidor de metadados sem qualquer autorização adicional. No entanto, às vezes as VMs podem perder acesso ao servidor de metadados devido a uma das seguintes causas:
- Falha ao resolver o nome de domínio do servidor de metadados
- A conexão com o servidor de metadados é bloqueada por um dos seguintes:
- Configuração de firewall no nível do sistema operacional
- Configuração de proxy
- Roteamento personalizado
Quando as VMs não conseguem acessar o servidor de metadados, alguns processos podem falhar.
Para obter informações sobre como solucionar problemas do gke-metadata-server , consulte Solucionar problemas de autenticação do GKE .
Antes de começar
- Se ainda não o fez, configure a autenticação. Autenticação é o processo pelo qual sua identidade é verificada para acesso a Google Cloud serviços e APIs. Para executar códigos ou amostras em um ambiente de desenvolvimento local, você pode se autenticar 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
-
After installing the Google Cloud CLI, initialize it 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.
- O endpoint solicitado está desabilitado pelas configurações do projeto ou das instâncias
- A solicitação falha nas verificações de segurança. Esse problema pode acontecer se a sua conexão TCP com o servidor tiver sido fechada na camada de rede.
- O servidor de metadados ainda está inicializando
- O servidor de metadados está em processo de migração
- O servidor de metadados está temporariamente indisponível
- A máquina host está realizando um evento de manutenção
- Conecte-se à sua VM Linux.
Na sua VM Linux, execute os seguintes comandos para testar a conectividade com o servidor de metadados:
Consulte o servidor de nomes de domínio:
nslookup metadata.google.internalA saída deve ser semelhante a esta:
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 está acessível. Para verificar, execute os seguintes comandos:
ping -c 3 metadata.google.internalA saída deve ser semelhante a esta:
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.254A saída deve ser semelhante a esta:
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 a saída dos comandos anteriores corresponder à saída sugerida, sua VM estará conectada ao servidor de metadados e nenhuma ação adicional será necessária. Se os comandos falharem, faça o seguinte:
Verifique se o servidor de nomes está configurado para o servidor de metadados:
cat /etc/resolv.confA saída deve ser semelhante a esta:
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 sistema operacional para obter informações sobre como editar a Política DHCP para persistir a configuração do servidor de nomes para
169.254.169.254. Isso ocorre porque as alterações em/etc/resolv.confserão substituídas em uma hora se as configurações de DNS zonal forem aplicadas às VMs do seu projeto. Caso seu projeto ainda utilize DNS global , o arquivoresolv.confserá revertido para o DHCP padrão em 24 horas.Verifique se existe o mapeamento entre o nome de domínio do servidor de metadados e seu endereço IP:
cat /etc/hostsA seguinte linha deve estar na saída:
169.254.169.254 metadata.google.internal # Added by Google
Se a saída não tiver a linha anterior, execute o seguinte comando:
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
- Conecte-se à sua VM do Windows.
Na VM do Windows, execute os seguintes comandos:
Consulte o servidor de nomes de domínio:
nslookup metadata.google.internalA saída deve ser semelhante a esta:
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 está acessível. Para verificar, execute os seguintes comandos:
ping -n 3 metadata.google.internalA saída deve ser semelhante a esta:
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.254A saída deve ser semelhante a esta:
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 a saída dos comandos anteriores corresponder à saída sugerida, sua VM estará conectada ao servidor de metadados e nenhuma ação adicional será necessária. Se os comandos falharem, faça o seguinte:
Verifique se há uma rota persistente para o servidor de metadados executando o comando:
route printA saída deve conter o seguinte:
Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 On-link 1
Se a saída não tiver a linha anterior, adicione a rota usando os 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 de domínio do servidor de metadados e seu endereço IP:
type %WINDIR%\System32\Drivers\Etc\HostsA seguinte linha deve estar na saída:
169.254.169.254 metadata.google.internal # Added by Google
Se a saída não tiver a linha anterior, execute o seguinte comando:
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
- Conecte-se à sua VM Linux.
Na sua VM Linux, execute os seguintes comandos:
export no_proxy=169.254.169.254,metadata,metadata.google.internalPara salvar as alterações, execute o seguinte comando:
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment- Conecte-se à sua VM do Windows.
Na VM do Windows, execute os seguintes comandos:
set NO_PROXY=169.254.169.254,metadata,metadata.google.internalPara salvar as alterações, execute o seguinte comando:
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
- O caminho para o sinalizador
--cacertpode estar malformado - O certificado raiz pode estar faltando no armazenamento confiável
A solicitação é aceita. No entanto, você receberá recomendações de que há VMs fazendo solicitações ao servidor de metadados com cabeçalhos formatados incorretamente. As recomendações são enviadas uma vez por VM. Você pode acessar essas recomendações usando a CLI do Google Cloud ou a 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 negará qualquer solicitação com cabeçalho formatado incorretamente.
REST
Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para gcloud CLI.
After installing the Google Cloud CLI, initialize it 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.
Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud.
Solucionar problemas de códigos de servidor
Os códigos de servidor a seguir são retornados quando você faz chamadas para o servidor de metadados do Compute Engine. Revise esta seção para ver como responder a cada código de servidor retornado pelo servidor de metadados.
Códigos de servidor comuns
Esses códigos de servidor são frequentemente retornados do servidor de metadados.
Código do servidor Descrição Resolução 200 OK : a solicitação foi bem-sucedida N / D 400 Solicitação inválida: esse status de erro é retornado em muitos cenários diferentes, como quando uma solicitação tem parâmetros de consulta inadequados ou requisitos para esse endpoint não foram atendidos. Revise a mensagem de erro para obter sugestões sobre como corrigir o erro 403 Proibido: esse status de erro é retornado nos seguintes cenários: Verifique as configurações do seu projeto e da instância para garantir que o endpoint esteja ativado ou verifique a configuração da sua rede 404 Não encontrado: o endpoint solicitado não existe Corrija o caminho da solicitação 429 Muitas solicitações: isso ocorre porque alguns endpoints usam limitação de taxa para evitar sobrecarga no serviço de apoio. É altamente recomendável tentar novamente com espera exponencial. Para obter mais informações, consulte a lista de endpoints com taxa limitada . Aguarde alguns segundos e tente novamente a chamada 503 Serviço indisponível: o servidor de metadados não está pronto para servir. O servidor de metadados pode retornar o código de status Error 503em qualquer uma das seguintes circunstâncias:Os 503s são transitórios e devem ser resolvidos após, no máximo, alguns segundos. Para resolver, aguarde alguns segundos e tente novamente a chamada . Códigos de servidor raros
Esses códigos de servidor, embora raros, também podem ser retornados do servidor de metadados.
Código do servidor Descrição Resolução 301 Movido permanentemente: isso é fornecido para caminhos que possuem redirecionamentos Atualizar o caminho da solicitação 405 Não permitido: este código de erro é retornado se um método não suportado for solicitado.
O servidor de metadados suporta apenas operaçõesGET, com exceção de metadados graváveis por convidados, que permitem operaçõesSET.Atualize o método no caminho da sua solicitação Códigos de erro de endpoints com taxa limitada
Os endpoints listados a seguir têm taxa limitada e podem retornar códigos de erro. Para lidar com esses códigos de erro retornados, consulte Orientação sobre novas tentativas .
Pontos finais Código de status Descrição oslogin/429Os limites de taxa de login do sistema operacional são compartilhados entre solicitações de usuário, autorização e grupo. instance/service-accounts/identity429,503O ponto final de assinatura de identidade pode retornar códigos de resposta 429ou503para indicar uma resposta com taxa limitada.instance/service-accounts/default/token429Os tokens armazenados em cache no servidor de metadados não têm taxa limitada. Os tokens não armazenados em cache estão sujeitos a limitação de taxa. instance/guest-attributes/429,503As solicitações de atributos de convidado poderão ser limitadas se você exceder 3 QPS ou 10 QPM. Se ocorrer limitação, os códigos de erro 429ou503serão retornados.Tentar novamente a orientação
O servidor de metadados retorna rotineiramente os códigos de erro 503 e 429. Para tornar seus aplicativos resilientes, recomendamos que você implemente uma lógica de repetição para aplicativos que consultam o servidor de metadados. Sugerimos também que você implemente uma espera exponencial em seus scripts para levar em conta qualquer possível limitação de taxa.
Solucionar problemas de solicitações com falha para o servidor de metadados
A seguir estão exemplos de erros que você poderá encontrar se sua VM não conseguir acessar o 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 perdeu acesso ao servidor de metadados, faça o seguinte:
Linux
Windows
Solucionar problemas de solicitações com falha ao usar um proxy de rede
Um servidor proxy de rede impede o acesso direto da VM à Internet. Todas as consultas enviadas de dentro de uma VM são tratadas pelo servidor proxy.
Ao usar um aplicativo que obtém 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, você deverá definir a configuração
NO_PROXYpara o endereço IP e o nome do host.Se você não definir a configuração
NO_PROXY, poderá ver erros ao executar comandos da CLI do Google Cloud ou consultar diretamente o servidor de metadados, pois as chamadas parametadata.google.internalserão enviadas ao proxy sem que sejam resolvidas localmente na própria instância.Veja a seguir um exemplo de erro que você pode ver:
ERROR 403 (Forbidden): Your client does not have permission to get URL
Para resolver esse problema de proxy, adicione o nome do host e o endereço IP do servidor de metadados à variável de ambiente
NO_PROXYfazendo o seguinte:Linux
Windows
Solucionar problemas de solicitações com falha para o endpoint do servidor de metadados HTTPS
Esta seção aborda alguns dos erros que você pode ver ao consultar o endpoint do servidor de metadados HTTPS .
Os erros listados nesta seção são retornados quando você consulta usando a ferramenta cURL para consultar, porém a mensagem de erro retornada é semelhante para outras ferramentas.
Certificado de cliente incorreto
Os erros a seguir ocorrerão se você fornecer um valor incorreto para o sinalizador
-E.Para resolver esse problema, forneça o caminho correto para o certificado de identidade do cliente. Para visualizar o local dos certificados de identidade do cliente, consulte Certificados de identidade do cliente .
Nome de host incorreto
O erro a seguir ocorre se o nome do host usado para acessar o servidor de metadados não for encontrado no certificado.
curl: (60) SSL: no alternative certificate subject name matches target host name
Para resolver esse problema, verifique se o URL raiz ou nome do host na sua consulta é
metadata.google.internal. Para obter mais informações sobre a URL raiz do servidor de metadados, consulte Partes de uma solicitação de metadados .Raiz ou certificado de cliente incorreto
Você poderá ver o seguinte erro ao consultar o endpoint do servidor de metadados HTTPS:
curl: (77) error setting certificate verify locations:
Isso pode acontecer nos seguintes cenários:
Para resolver esse problema, você precisa especificar o certificado raiz e o certificado do cliente ao consultar o endpoint https. Para locais de certificados, consulte Onde os certificados são armazenados .
Por exemplo, para consultar a imagem de inicialização 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"Solucionar problemas de formato de cabeçalho incorreto
O servidor de metadados realiza verificações de formatação para garantir que os cabeçalhos estejam em conformidade com a diretriz de formatação de cabeçalho RFC 7230 Seção 3.2 . Se o formato do cabeçalho falhar nessas verificações, ocorrerá o seguinte:
Veja a seguir exemplos de formatos de solicitação de cabeçalho válidos e inválidos.
Inválido : contém espaços em branco entre o nome do cabeçalho e dois pontos
Metadata-Flavor : Google
Válido : nenhum espaço 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 obter mais informações sobre como fazer consultas ao servidor de metadados, consulte Acessar metadados da VM .
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-04-21 UTC.
-