Memecahkan masalah akses server metadata


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

    1. Install the Google Cloud CLI, then initialize it by running the following command:

      gcloud init
    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.

        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:
  • Server metadata masih melakukan booting
  • Server metadata sedang dalam proses migrasi
  • Server metadata tidak tersedia untuk sementara
  • Mesin host sedang melakukan peristiwa pemeliharaan
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 operasi GET, kecuali metadata yang dapat ditulis tamu, yang memungkinkan operasi SET.
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

  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. 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
      
    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 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, file resolv.conf akan dikembalikan ke DHCP default dalam 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. 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
      
    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 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
      2. 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

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 ke metadata.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

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

  • 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, 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:

  • Jalur untuk tanda --cacert mungkin salah format
  • Root certificate mungkin tidak ada di trust store

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:

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

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.