Dokumen ini menunjukkan cara menyelesaikan masalah terkait server metadata Compute Engine.
VM Compute Engine menyimpan metadata di server metadata. VM otomatis memiliki akses ke API server metadata tanpa otorisasi tambahan. Namun, terkadang VM mungkin kehilangan akses ke server metadata karena salah satu penyebab berikut:
- Kegagalan dalam me-resolve nama domain server metadata
- Koneksi ke server metadata diblokir oleh salah satu hal berikut:
- Konfigurasi firewall tingkat OS
- Penyiapan proxy
- Pemilihan rute kustom
Jika VM tidak dapat mengakses server metadata, beberapa proses mungkin gagal.
Untuk informasi tentang cara memecahkan masalah gke-metadata-server
, lihat
Memecahkan masalah autentikasi GKE.
Sebelum memulai
-
Jika Anda belum melakukannya, siapkan autentikasi.
Autentikasi adalah
proses verifikasi identitas Anda untuk mengakses layanan dan API Google Cloud.
Untuk menjalankan kode atau contoh dari lingkungan pengembangan lokal, Anda dapat mengautentikasi ke Compute Engine dengan memilih salah satu opsi berikut:
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.
- Server metadata masih melakukan booting
- Server metadata sedang dalam proses migrasi
- Server metadata tidak tersedia untuk sementara
- Mesin host sedang melakukan peristiwa pemeliharaan
- Hubungkan ke VM Linux Anda.
Dari VM Linux, jalankan perintah berikut untuk menguji konektivitas ke server metadata:
Buat kueri Server Nama Domain:
nslookup metadata.google.internal
Output-nya akan terlihat seperti berikut:
Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Pastikan server metadata dapat dijangkau. Untuk memverifikasi, jalankan perintah berikut:
ping -c 3 metadata.google.internal
Output-nya akan terlihat seperti berikut:
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
Output-nya akan terlihat seperti berikut:
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
Jika output perintah sebelumnya cocok dengan output yang disarankan, VM Anda terhubung ke server metadata dan tidak ada tindakan lebih lanjut yang diperlukan. Jika perintah gagal, lakukan hal berikut:
Pastikan server nama dikonfigurasi ke server Metadata:
cat /etc/resolv.conf
Output-nya akan terlihat seperti berikut:
domain ZONE.c.PROJECT_ID.internal search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal. nameserver 169.254.169.254
Jika output tidak memiliki baris sebelumnya, lihat dokumentasi sistem operasi untuk mendapatkan informasi tentang cara mengedit Kebijakan DHCP agar konfigurasi server nama tetap ada di
169.254.169.254
. Hal ini karena perubahan pada/etc/resolv.conf
akan ditimpa dalam satu jam jika setelan DNS zona diterapkan ke VM dalam project Anda. Jika project Anda masih menggunakan DNS global, fileresolv.conf
akan dikembalikan ke DHCP default dalam 24 jam.Pastikan pemetaan antara nama domain server metadata dan alamat IP-nya ada:
cat /etc/hosts
Baris berikut harus ada dalam output:
169.254.169.254 metadata.google.internal # Added by Google
Jika output tidak memiliki baris sebelumnya, jalankan perintah berikut:
echo "169.254.169.254 metadata.google.internal" >> /etc/hosts
- Hubungkan ke VM Windows Anda.
Dari VM Windows Anda, jalankan perintah berikut:
Buat kueri Server Nama Domain:
nslookup metadata.google.internal
Output-nya akan terlihat seperti berikut:
Server: UnKnown Address: 10.128.0.1 Non-authoritative answer: Name: metadata.google.internal Address: 169.254.169.254
Pastikan server metadata dapat dijangkau. Untuk memverifikasi, jalankan perintah berikut:
ping -n 3 metadata.google.internal
Output-nya akan terlihat seperti berikut:
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
Output-nya akan terlihat seperti berikut:
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
Jika output perintah sebelumnya cocok dengan output yang disarankan, VM Anda terhubung ke server metadata dan tidak ada tindakan lebih lanjut yang diperlukan. Jika perintah gagal, lakukan hal berikut:
Pastikan ada rute persisten ke server metadata dengan menjalankan perintah:
route print
Output-nya harus berisi hal berikut:
Persistent Routes: Network Address Netmask Gateway Address Metric 169.254.169.254 255.255.255.255 On-link 1
Jika output tidak memiliki baris sebelumnya, tambahkan rute menggunakan perintah berikut:
$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
Pastikan pemetaan antara nama domain server metadata dan alamat IP-nya ada:
type %WINDIR%\System32\Drivers\Etc\Hosts
Baris berikut harus ada dalam output:
169.254.169.254 metadata.google.internal # Added by Google
Jika output tidak memiliki baris sebelumnya, jalankan perintah berikut:
echo 169.254.169.254 metadata.google.internal >> %WINDIR%\System32\Drivers\Etc\Hosts
- Hubungkan ke VM Linux Anda.
Dari VM Linux, jalankan perintah berikut:
export no_proxy=169.254.169.254,metadata,metadata.google.internal
Untuk menyimpan perubahan, jalankan perintah berikut:
echo no_proxy=169.254.169.254,metadata,metadata.google.internal >> /etc/environment
- Hubungkan ke VM Windows Anda.
Dari VM Windows Anda, jalankan perintah berikut:
set NO_PROXY=169.254.169.254,metadata,metadata.google.internal
Untuk menyimpan perubahan, jalankan perintah berikut:
setx NO_PROXY 169.254.169.254,metadata,metadata.google.internal /m
curl: (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
- Jalur untuk tanda
--cacert
mungkin salah format - Root certificate mungkin tidak ada di trust store
Permintaan diterima. Namun, Anda akan menerima rekomendasi bahwa Anda memiliki VM yang membuat permintaan ke server metadata dengan header yang diformat dengan tidak benar. Rekomendasi dikirim satu kali per VM. Anda dapat mengakses rekomendasi ini menggunakan Google Cloud CLI, atau Recommender REST API.
Setelah Anda menerapkan rekomendasi, tetapkan status rekomendasi ke
succeeded
.Mulai 20 Januari 2024, server metadata akan menolak permintaan apa pun dengan header yang tidak diformat dengan benar.
REST
Untuk menggunakan contoh REST API di halaman ini dalam lingkungan pengembangan lokal, gunakan kredensial yang Anda berikan ke gcloud CLI.
Install the Google Cloud CLI, then initialize it by running the following command:
gcloud init
Untuk informasi selengkapnya, lihat Melakukan autentikasi untuk menggunakan REST dalam dokumentasi autentikasi Google Cloud.
Memecahkan masalah kode server
Kode server berikut ditampilkan saat Anda melakukan panggilan ke server metadata Compute Engine. Tinjau bagian ini untuk melihat cara merespons setiap kode server yang ditampilkan oleh server metadata.
Kode server umum
Kode server ini sering ditampilkan dari server metadata.
Kode server Deskripsi Resolusi 200 OK: permintaan berhasil T/A 400 Permintaan Tidak Valid: status error ini ditampilkan untuk banyak skenario yang berbeda seperti saat permintaan memiliki parameter kueri yang tidak tepat atau persyaratan untuk endpoint tersebut belum terpenuhi. Tinjau pesan error untuk mendapatkan saran tentang cara memperbaiki error 404 Tidak Ditemukan: endpoint yang diminta tidak ada Memperbaiki jalur permintaan 429 Terlalu banyak permintaan: hal ini terjadi karena beberapa endpoint menggunakan pembatasan kapasitas untuk mencegah kelebihan beban pada layanan pendukung Tunggu beberapa detik, lalu coba lagi panggilan 503 Layanan tidak tersedia: server metadata belum siap ditayangkan. Server metadata mungkin menampilkan kode status Error 503
dalam salah satu situasi berikut:Error 503 bersifat sementara dan akan teratasi setelah maksimal beberapa detik. Untuk mengatasinya, tunggu beberapa detik dan coba lagi panggilan. Kode server yang jarang terjadi
Meskipun jarang, kode server ini mungkin juga ditampilkan dari server metadata.
Kode server Deskripsi Resolusi 301 Dipindahkan Secara Permanen: ini disediakan untuk jalur yang memiliki pengalihan Memperbarui jalur permintaan 403 Forbidden: status ini ditampilkan jika server metadata yakin bahwa permintaan tidak aman. Hal ini dapat terjadi jika koneksi TCP Anda ke server ditutup di lapisan jaringan. Memeriksa konfigurasi jaringan Anda 405 Tidak Diizinkan: kode error ini ditampilkan jika metode yang tidak didukung diminta.
Server metadata hanya mendukung operasiGET
, kecuali metadata yang dapat ditulis tamu, yang memungkinkan operasiSET
.Memperbarui metode di jalur permintaan Panduan percobaan ulang
Server metadata secara rutin menampilkan kode error 503 dan 429. Untuk membuat aplikasi Anda tangguh, sebaiknya Anda menerapkan logika percobaan ulang untuk aplikasi yang mengkueri server metadata. Sebaiknya terapkan backoff eksponensial dalam skrip Anda untuk memperhitungkan kemungkinan pembatasan kapasitas.
Memecahkan masalah permintaan yang gagal ke server metadata
Berikut adalah contoh error yang mungkin Anda alami jika VM gagal menjangkau server metadata:
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
Jika VM Anda kehilangan akses ke server metadata, lakukan hal berikut:
Linux
Windows
Memecahkan masalah permintaan yang gagal saat menggunakan proxy jaringan
Server proxy jaringan mencegah akses langsung VM ke Internet. Semua kueri yang dikirim dari dalam VM ditangani oleh server proxy.
Saat menggunakan aplikasi yang mendapatkan kredensial dari server metadata, seperti token autentikasi, VM memerlukan akses langsung ke server metadata. Jika VM berada di belakang proxy, Anda harus menetapkan konfigurasi
NO_PROXY
untuk alamat IP dan Nama Host.Jika tidak menetapkan konfigurasi
NO_PROXY
, Anda mungkin melihat error saat menjalankan perintah Google Cloud CLI atau mengkueri server metadata secara langsung karena panggilan kemetadata.google.internal
akan dikirim ke proxy tanpa me-resolve-nya secara lokal di instance itu sendiri.Berikut adalah contoh error yang mungkin Anda lihat:
ERROR 403 (Forbidden): Your client does not have permission to get URL
Untuk mengatasi masalah proxy ini, tambahkan nama host dan alamat IP server metadata ke variabel lingkungan
NO_PROXY
dengan melakukan hal berikut:Linux
Windows
Memecahkan masalah permintaan yang gagal ke endpoint server metadata HTTPS
Bagian ini membahas beberapa error yang mungkin Anda lihat saat mengkueri endpoint server metadata HTTPS.
Error yang tercantum di bagian ini ditampilkan saat Anda membuat kueri menggunakan alat cURL untuk membuat kueri, tetapi pesan error yang ditampilkan serupa untuk alat lain.
Sertifikat klien salah
Error berikut akan terjadi jika Anda memberikan nilai yang salah untuk flag
-E
.Untuk mengatasi masalah ini, berikan jalur yang benar ke sertifikat identitas klien. Untuk melihat lokasi sertifikat identitas klien, lihat Sertifikat identitas klien.
Nama host salah
Error berikut terjadi jika nama host yang digunakan untuk mengakses server metadata tidak ditemukan di sertifikat.
curl: (60) SSL: no alternative certificate subject name matches target host name
Untuk mengatasi masalah ini, pastikan URL root atau nama host dalam kueri Anda adalah
metadata.google.internal
. Untuk mengetahui informasi selengkapnya tentang URL root untuk server metadata, lihat Bagian-bagian permintaan metadata.Sertifikat root atau klien salah
Anda mungkin melihat error berikut saat membuat kueri endpoint server metadata HTTPS:
curl: (77) error setting certificate verify locations:
Hal ini dapat terjadi dalam skenario berikut:
Untuk mengatasi masalah ini, Anda perlu menentukan sertifikat root dan sertifikat klien saat membuat kueri endpoint https. Untuk mengetahui lokasi sertifikat, lihat Tempat penyimpanan sertifikat.
Misalnya, untuk mengkueri image booting untuk VM, jalankan kueri berikut:
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"
Memecahkan masalah format header yang salah
Server metadata melakukan pemeriksaan pemformatan untuk memastikan header mematuhi panduan pemformatan header RFC 7230 Bagian 3.2. Jika format header gagal dalam pemeriksaan ini, hal berikut akan terjadi:
Berikut adalah contoh format permintaan header yang valid dan tidak valid.
Tidak valid: berisi spasi kosong antara nama header dan titik dua
Metadata-Flavor : Google
Valid: tidak ada spasi kosong di antara nama header dan titik dua, spasi kosong setelah titik dua akan diabaikan oleh pemeriksa
Metadata-Flavor: Google
Valid: tidak ada spasi kosong di header
Metadata-Flavor:Google
Untuk mengetahui informasi selengkapnya tentang cara membuat kueri ke server metadata, lihat Mengakses metadata VM.
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2024-11-27 UTC.
-