このドキュメントでは、Compute Engine メタデータ サーバーの問題を解決する方法について説明します。
Compute Engine VM は、メタデータ サーバーにメタデータを保存します。VM は、追加の承認なしで自動的にメタデータ サーバー API にアクセスできます。ただし、次のいずれかの原因で VM がメタデータ サーバーにアクセスできなくなることがあります。
- メタデータ サーバーのドメイン名を解決できない
- メタデータ サーバーへの接続が、次のいずれかによってブロックされている
- OS レベルのファイアウォール構成
- プロキシの設定
- カスタム ルーティング
VM がメタデータ サーバーにアクセスできない場合、一部のプロセスが失敗する可能性があります。
gke-metadata-server のトラブルシューティングについては、GKE の認証に関する問題のトラブルシューティングをご覧ください。
始める前に
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。
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.
- サーバーが一時的に利用できない
- ホストがメンテナンス イベントを実行している
- Linux VM に接続します。
Linux VM から、次のコマンドを実行してメタデータ サーバーへの接続性をテストします。
ドメイン ネームサーバーに対してクエリを実行します。
nslookup metadata.google.internal出力は次のようになります。
Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
メタデータ サーバーに到達可能であることを確認します。これを確認するには、次のコマンドを実行します。
ping -c 3 metadata.google.internal出力は次のようになります。
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.254出力は次のようになります。
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
上記のコマンドの出力が推奨出力と一致する場合、VM はメタデータ サーバーに接続されるため、それ以上の操作は必要ありません。コマンドが失敗した場合は、次の操作を行います。
ネームサーバーがメタデータ サーバーに構成されていることを確認します。
cat /etc/resolv.conf出力は次のようになります。
domain ZONE.c.PROJECT_ID.internal search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal. nameserver 169.254.169.254
出力に上記の行がない場合、DHCP ポリシーを編集してネームサーバー構成を
169.254.169.254に保持する方法についてオペレーティング システムのドキュメントをご覧ください。これは、ゾーン DNS 設定がプロジェクト内の VM に適用されている場合、/etc/resolv.confへの変更が 1 時間以内に上書きされるためです。プロジェクトでまだグローバル DNS を使用している場合、resolv.confファイルは 24 時間以内にデフォルトの DHCP に戻されます。メタデータ サーバーのドメイン名とその IP アドレス間のマッピングが存在することを確認します。
cat /etc/hosts出力に次の行があります。
169.254.169.254 metadata.google.internal # Added by Google
出力に上記の行がない場合は、次のコマンドを実行します。
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
- Windows VM に接続します。
Windows VM から、次のコマンドを実行します。
ドメイン ネームサーバーに対してクエリを実行します。
nslookup metadata.google.internal出力は次のようになります。
Server: UnKnown Address: 10.128.0.1 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
メタデータ サーバーに到達可能であることを確認します。これを確認するには、次のコマンドを実行します。
ping -n 3 metadata.google.internal出力は次のようになります。
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.254出力は次のようになります。
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
上記のコマンドの出力が推奨出力と一致する場合、VM はメタデータ サーバーに接続されるため、それ以上の操作は必要ありません。コマンドが失敗した場合は、次の操作を行います。
次のコマンドを実行して、メタデータ サーバーへの永続的なルートがあることを確認します。
route print出力に次の内容が含まれているはずです。
Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 On-link 1
出力に上記の行がない場合は、次のコマンドを使用してルートを追加します。
$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 1メタデータ サーバーのドメイン名とその IP アドレス間のマッピングが存在することを確認します。
type %WINDIR%\System32\Drivers\Etc\Hosts出力に次の行があります。
169.254.169.254 metadata.google.internal # Added by Google
出力に上記の行がない場合は、次のコマンドを実行します。
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
- Linux VM に接続します。
Linux VM から、次のコマンドを実行します。
export no_proxy=169.254.169.254,metadata,metadata.google.internal変更を保存するには、次のコマンドを実行します。
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment- Windows VM に接続します。
Windows VM から、次のコマンドを実行します。
set NO_PROXY=169.254.169.254,metadata,metadata.google.internal変更を保存するには、次のコマンドを実行します。
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
--cacertフラグのパスが正しい形式でない- ルート証明書が信頼ストアにない
リクエストが受け入れられます。ただし、形式が正しくないヘッダーで VM からメタデータ サーバーへのリクエストが行われると、推奨事項が表示されます。推奨事項は VM ごとに 1 回送信されます。これらの推奨事項にアクセスするには、Google Cloud CLI または Recommender REST API を使用します。
推奨事項を適用したら、推奨事項の状態を
succeededに設定します。2024 年 1 月 20 日以降、メタデータ サーバーは、ヘッダーの形式が正しくないリクエストをすべて拒否します。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init詳細については、Google Cloud 認証ドキュメントの REST を使用して認証するをご覧ください。
サーバーエラー
メタデータ サーバーは、次の状況で
Error 503ステータス コードを返すことがあります。アプリケーションが 503 エラーコードを受け取った場合は、リクエストを再試行してください。
メタデータ サーバーへのリクエストが失敗した
VM がメタデータ サーバーに到達できない場合に発生するエラーの例を次に示します。
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
メタデータ サーバーへのリクエストに失敗した場合のトラブルシューティング
VM がメタデータ サーバーにアクセスできなくなった場合は、次の操作を行います。
Linux
Windows
ネットワーク プロキシ使用中にリクエストが失敗した
ネットワーク プロキシ サーバーは、VM がインターネットに直接アクセスできないようにします。VM 内から送信されるクエリはすべてプロキシ サーバーによって処理されます。
認証トークンなど、メタデータ サーバーから認証情報を取得するアプリケーションを使用する場合、VM はメタデータ サーバーに直接アクセスする必要があります。VM がプロキシの背後にある場合は、IP アドレスとホスト名の両方に
NO_PROXY構成を設定する必要があります。NO_PROXY構成を設定しない場合、Google Cloud CLI コマンドを実行したり、メタデータ サーバーに対して直接クエリを実行すると、エラーが表示されることがあります。metadata.google.internalの呼び出しが、インスタンス上でローカルに解決されることなく、プロキシに送信されるためです。次のようなエラーが表示される場合があります。
ERROR 403 (Forbidden): Your client does not have permission to get URL
このプロキシの問題を解決するには、メタデータ サーバーのホスト名と IP アドレスを環境変数
NO_PROXYに追加します。手順は次のとおりです。Linux
Windows
HTTPS メタデータ サーバー エンドポイントへのリクエストに失敗した場合のトラブルシューティング
このセクションでは、HTTPS メタデータ サーバー エンドポイントをクエリする際に発生する可能性のあるエラーについて説明します。
このセクションに記載されているエラーは、cURL ツールを使用してクエリを実行したときに返されますが、返されるエラー メッセージの内容は他のツールでも同様です。
クライアント証明書が正しくない
-Eフラグに誤った値を指定すると、次のエラーが発生します。この問題を解決するには、クライアント ID 証明書の正しいパスを指定します。クライアント ID 証明書の場所を確認するには、クライアント ID 証明書をご覧ください。
ホスト名が正しくない
メタデータ サーバーにアクセスするために使用されるホスト名が証明書にない場合、次のエラーが発生します。
curl: (60) SSL: no alternative certificate subject name matches target host name
この問題を解決するには、クエリのルート URL またはホスト名が
metadata.google.internalであることを確認します。メタデータ サーバーのルート URL の詳細については、メタデータ リクエストの部分をご覧ください。ルート証明書またはクライアント証明書が正しくない
HTTPS メタデータ サーバー エンドポイントにクエリを実行すると、次のエラーが表示されることがあります。
curl: (77) error setting certificate verify locations:
これは、次のような場合に発生する可能性があります。
この問題を解決するには、https エンドポイントをクエリするときに、ルート証明書とクライアント証明書の両方を指定します。証明書の場所については、証明書の保存場所をご覧ください。
たとえば、VM のブートイメージにクエリを実行するには、次のクエリを実行します。
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"ヘッダーの形式が正しくない
メタデータ サーバーは、ヘッダーがヘッダーの形式設定ガイドライン RFC 7230 セクション 3.2 に準拠していることを確認するために、形式チェックを行います。ヘッダー形式がこのチェックに失敗すると、次のようになります。
有効なヘッダー リクエストと無効なヘッダー リクエストの形式の例を次に示します。
無効: ヘッダー名とコロンの間に空白文字が含まれています。
Metadata-Flavor : Google
有効: ヘッダー名とコロンの間に空白文字はありません。コロンの後の空白はチェッカーには無視されます。
Metadata-Flavor: Google
有効: ヘッダーに空白文字が使用されていません。
Metadata-Flavor:Google
メタデータ サーバーへのクエリの実行の詳細については、VM メタデータにアクセスするをご覧ください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2024-11-21 UTC。
-