Memecahkan masalah akses server metadata

Dokumen ini menunjukkan cara menyelesaikan masalah pada 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:

  • Gagal menyelesaikan 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 mengetahui informasi tentang cara memecahkan masalah gke-metadata-server, lihat Memecahkan masalah autentikasi GKE.

Sebelum memulai

  • Jika Anda belum melakukannya, siapkan autentikasi. Autentikasi adalah proses yang digunakan untuk memverifikasi identitas Anda untuk mengakses Google Cloud layanan dan API. Untuk menjalankan kode atau sampel dari lingkungan pengembangan lokal, Anda dapat melakukan autentikasi 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

      1. After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      2. Set a default region and zone.

        3. REST

        Untuk menggunakan contoh REST API di halaman ini dalam lingkungan pengembangan lokal, gunakan kredensial yang Anda berikan ke gcloud CLI.

          After installing the Google Cloud CLI, initialize it by running the following command: 

          gcloud init

          If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

        Untuk mengetahui 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 Buruk: status error ini ditampilkan untuk banyak skenario 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
403 Dilarang: status error ini ditampilkan dalam skenario berikut:
  • Endpoint yang diminta dinonaktifkan oleh setelan project atau instance
  • Permintaan gagal dalam pemeriksaan keamanan. Masalah ini dapat terjadi jika koneksi TCP Anda ke server ditutup di lapisan jaringan.
 Periksa setelan project dan instance Anda untuk memastikan endpoint diaktifkan, atau periksa konfigurasi jaringan Anda
404 Tidak Ditemukan: endpoint yang diminta tidak ada Perbaiki jalur permintaan
429 Terlalu banyak permintaan: hal ini terjadi karena beberapa endpoint menggunakan pembatasan kapasitas untuk mencegah kelebihan beban pada layanan pendukung. Mencoba lagi dengan backoff eksponensial sangat disarankan. Untuk mengetahui informasi selengkapnya, lihat daftar endpoint yang dibatasi kecepatan panggilannya. Tunggu beberapa detik dan coba lagi panggilan
503 Layanan tidak tersedia: server metadata belum siap untuk menayangkan. Server metadata mungkin menampilkan kode status Error 503 dalam salah satu keadaan berikut:
  • Server metadata masih melakukan booting
  • Server metadata sedang dalam proses migrasi
  • Server metadata tidak tersedia untuk sementara
  • Mesin host sedang melakukan peristiwa pemeliharaan
  • Server metadata mungkin menampilkan 503 saat membatasi kecepatan beberapa endpoint.
 Error 503 bersifat sementara dan akan teratasi setelah paling lama beberapa detik. Untuk mengatasinya, tunggu beberapa detik dan coba lagi panggilan.

Kode server yang jarang terjadi

Kode server ini, meskipun jarang, juga dapat ditampilkan dari server metadata.

Kode server Deskripsi Resolusi
301 Moved Permanently: ini disediakan untuk jalur yang memiliki pengalihan Memperbarui jalur permintaan
405 Tidak Diizinkan: kode error ini ditampilkan jika metode yang tidak didukung diminta.

Server metadata hanya mendukung operasi GET, dengan pengecualian metadata yang dapat ditulis tamu, yang memungkinkan operasi SET.		 Perbarui metode di jalur permintaan Anda

Kode error endpoint yang dibatasi kapasitasnya

Endpoint berikut dibatasi lajunya dan mungkin menampilkan kode error. Untuk menangani kode error yang ditampilkan ini, lihat Panduan Coba Lagi.

Endpoint Kode Status Deskripsi
oslogin/ 429 Pembatasan kapasitas Login OS digunakan bersama untuk permintaan pengguna, otorisasi, dan grup.
instance/service-accounts/identity 503 Endpoint penandatanganan identitas dapat menampilkan kode respons 429 atau 503 untuk menunjukkan respons yang dibatasi lajunya.
instance/service-accounts/default/token 429 Token yang di-cache di server metadata tidak dibatasi kecepatan. Token yang tidak di-cache tunduk pada pembatasan kapasitas.
instance/guest-attributes/ 429, 503 Permintaan atribut tamu mungkin di-throttle jika Anda melebihi 3 QPS atau 10 QPM. Jika terjadi pembatasan, kode error 429 atau 503 akan ditampilkan.

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 penundaan eksponensial dalam skrip Anda untuk memperhitungkan kemungkinan pembatasan kecepatan.

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

  1. Hubungkan ke VM Linux Anda.

  2. Dari VM Linux, jalankan perintah berikut untuk menguji konektivitas ke server metadata:

    1. 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

    2. Periksa apakah 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

    3. 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:

      1. 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 Anda untuk mengetahui 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, file resolv.conf akan dikembalikan ke DHCP default dalam waktu 24 jam.

      2. 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

Windows

  1. Hubungkan ke VM Windows Anda.

  2. Dari VM Windows Anda, jalankan perintah berikut:

    1. 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

    2. Periksa apakah 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

    3. 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:

      1. Periksa apakah ada rute persisten ke server metadata dengan menjalankan perintah:

        route print

        Output-nya harus berisi yang 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

      2. Periksa apakah 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

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 Anda tidak menyetel konfigurasi NO_PROXY, Anda mungkin melihat error saat menjalankan perintah Google Cloud CLI atau membuat kueri server metadata secara langsung karena panggilan ke metadata.google.internal akan dikirim ke proxy tanpa diselesaikan 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

  1. Hubungkan ke VM Linux Anda.

  2. 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

Windows

  1. Hubungkan ke VM Windows Anda.

  2. 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

Memecahkan masalah permintaan yang gagal ke endpoint server metadata HTTPS

Bagian ini membahas beberapa error yang mungkin Anda lihat saat mengirim kueri ke 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 lainnya.

Sertifikat klien salah

Error berikut terjadi jika Anda memberikan nilai yang salah untuk tanda -E.

  • 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

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, verifikasi bahwa 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 klien atau root salah

Anda mungkin melihat error berikut saat membuat kueri ke endpoint server metadata HTTPS:

curl: (77) error setting certificate verify locations:

Hal ini dapat terjadi dalam skenario berikut:

  • Jalur untuk tanda --cacert mungkin salah format
  • Root certificate mungkin tidak ada di penyimpanan tepercaya

Untuk mengatasi masalah ini, Anda harus menentukan sertifikat root dan sertifikat klien saat membuat kueri endpoint https. Untuk lokasi sertifikat, lihat Di mana sertifikat disimpan.

Misalnya, untuk mengkueri boot image 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 format untuk memastikan bahwa header mematuhi pedoman format header RFC 7230 Bagian 3.2. Jika format header gagal dalam pemeriksaan ini, hal berikut akan terjadi:

  • Permintaan diterima. Namun, Anda akan menerima rekomendasi bahwa Anda memiliki VM yang membuat permintaan ke server metadata dengan header yang diformat secara 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 menjadi succeeded.

  • Mulai 20 Januari 2024, server metadata akan menolak setiap permintaan dengan header yang diformat secara salah.

Berikut menunjukkan contoh format permintaan header yang valid dan tidak valid.

Tidak valid: berisi spasi di 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 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 artikel Mengakses metadata VM.

Memecahkan masalah kegagalan mendapatkan token

Anda mungkin melihat salah satu error berikut saat Anda membuat kueri server metadata:

  • ERROR: gcloud crashed (MetadataServerException): HTTP Error 401: Unauthorized
  • curl: (22) The requested URL returned error: 401

Error ini mungkin muncul jika akun layanan yang terlampir ke VM dalam keadaan dinonaktifkan. Untuk mengatasi error ini, aktifkan akun layanan atau lampirkan akun layanan lain.