このドキュメントでは、Compute Engine メタデータ サーバーの問題を解決する方法について説明します。
Compute Engine VM は、メタデータ サーバーにメタデータを保存します。VM は、追加の承認なしで自動的にメタデータ サーバー API にアクセスできます。ただし、次のいずれかの原因で VM がメタデータ サーバーにアクセスできなくなることがあります。
- メタデータ サーバーのドメイン名を解決できない
- メタデータ サーバーへの接続が、次のいずれかによってブロックされている
- OS レベルのファイアウォール構成
- プロキシの設定
- カスタム ルーティング
VM がメタデータ サーバーにアクセスできない場合、一部のプロセスが失敗する可能性があります。
gke-metadata-server のトラブルシューティングについては、GKE の認証に関する問題のトラブルシューティングをご覧ください。
始める前に
-
まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。
このページのサンプルをどのように使うかに応じて、タブを選択してください。
コンソール
Google Cloud コンソールを使用して Google Cloud サービスと API にアクセスする場合、認証を設定する必要はありません。
gcloud
-
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
- デフォルトのリージョンとゾーンを設定します。
REST
このページの REST API サンプルをローカル開発環境で使用するには、gcloud CLI に指定した認証情報を使用します。
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
-
サーバーエラー
メタデータ サーバーは、次の状況で 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
- 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
- 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
ネットワーク プロキシ使用中にリクエストが失敗した
ネットワーク プロキシ サーバーは、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
- 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
- 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 /m
ヘッダーの形式が正しくない
メタデータ サーバーは、ヘッダーがヘッダーの形式設定ガイドライン RFC 7230 セクション 3.2 に準拠していることを確認するために、形式チェックを行います。ヘッダー形式がこのチェックに失敗すると、次のようになります。
リクエストが受け入れられます。ただし、形式が正しくないヘッダーで VM からメタデータ サーバーへのリクエストが行われると、推奨事項が表示されます。推奨事項は VM ごとに 1 回送信されます。これらの推奨事項にアクセスするには、Google Cloud CLI または Recommender REST API を使用します。
推奨事項を適用したら、推奨事項の状態を
succeededに設定します。2024 年 1 月 20 日以降、メタデータ サーバーは、ヘッダーの形式が正しくないリクエストをすべて拒否します。
有効なヘッダー リクエストと無効なヘッダー リクエストの形式の例を次に示します。
無効: ヘッダー名とコロンの間に空白文字が含まれています。
Metadata-Flavor : Google
有効: ヘッダー名とコロンの間に空白文字はありません。コロンの後の空白はチェッカーには無視されます。
Metadata-Flavor: Google
有効: ヘッダーに空白文字が使用されていません。
Metadata-Flavor:Google
メタデータ サーバーへのクエリの実行の詳細については、VM メタデータにアクセスするをご覧ください。