Memecahkan masalah deployment Envoy

Panduan ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi terkait Envoy saat Anda menjalankan Cloud Service Mesh dengan Google API. Sebagai informasi tentang cara menggunakan Client Status Discovery Service (CSDS) API untuk membantu Anda menyelidiki masalah dengan Cloud Service Mesh, Memahami status klien Cloud Service Mesh.

Menentukan versi Envoy yang diinstal pada VM

Gunakan petunjuk ini untuk memverifikasi versi Envoy yang berjalan di menggunakan instance virtual machine (VM).

Untuk memverifikasi atau memeriksa versi Envoy, Anda dapat melakukan salah satu langkah berikut:

Memeriksa atribut tamu VM di bagian jalur gce-service-proxy/proxy-version:

  gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME 
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Memeriksa log instance Cloud Logging dari detail instance VM Halaman logging di Konsol Google Cloud dengan kueri seperti ini:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"
  

Anda menerima respons seperti ini:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }
  

Gunakan SSH untuk terhubung ke VM dan memeriksa versi biner:

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Gunakan SSH untuk terhubung ke VM dan antarmuka admin sebagai root:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }
  

Lokasi log Envoy

Untuk memecahkan beberapa masalah, Anda perlu memeriksa log proxy Envoy.

Anda dapat menggunakan SSH untuk terhubung ke instance VM guna mendapatkan file log. Jalurnya adalah kemungkinan adalah sebagai berikut.

  /var/log/envoy/envoy.err.log
  

Proxy tidak terhubung ke Cloud Service Mesh

Jika proxy Anda tidak terhubung ke Cloud Service Mesh, lakukan hal berikut:

  • Periksa log proxy Envoy untuk menemukan error yang terhubung ke trafficdirector.googleapis.com.

  • Jika Anda menyiapkan netfilter (dengan menggunakan iptables) untuk mengalihkan semua traffic ke {i>proxy<i} Envoy, pastikan bahwa pengguna (UID) yang Anda jalankan {i>proxy<i} tidak akan dikecualikan. Jika tidak, hal ini akan menyebabkan traffic kembali ke {i>proxy<i}.

  • Pastikan Anda telah mengaktifkan Cloud Service Mesh API untuk proyek tersebut. Di bagian APIs & layanan untuk project Anda, cari untuk Cloud Service Mesh API.

  • Pastikan cakupan akses API VM disetel untuk mengizinkan akses penuh ke Google Cloud API dengan menentukan hal berikut saat Anda membuat VM:

    --scopes=https://www.googleapis.com/auth/cloud-platform
    
  • Pastikan akun layanan memiliki izin yang benar. Untuk selengkapnya informasi, lihat Aktifkan akun layanan untuk mengakses Traffic Director API.

  • Konfirmasi bahwa Anda dapat mengakses trafficdirector.googleapis.com:443 dari Pesan Suara. Jika ada masalah dengan akses ini, kemungkinan penyebabnya adalah firewall mencegah akses ke trafficdirector.googleapis.com melalui port TCP 443 atau Masalah resolusi DNS untuk nama host trafficdirector.googleapis.com.

  • Jika Anda menggunakan Envoy untuk proxy file bantuan, pastikan versi Envoy adalah rilis 1.24.9 atau yang lebih baru.

Layanan yang dikonfigurasi dengan Cloud Service Mesh tidak dapat dijangkau

Jika layanan yang dikonfigurasi dengan Cloud Service Mesh tidak dapat dijangkau, pastikan proxy file bantuan berjalan dan dapat terhubung ke Cloud Service Mesh.

Jika Anda menggunakan Envoy sebagai proxy file bantuan, Anda dapat mengonfirmasinya dengan menjalankan perintah berikut:

  1. Dari command line, pastikan proses Envoy sedang berjalan:

    ps aux | grep envoy
    
  2. Memeriksa konfigurasi runtime Envoy untuk mengonfirmasi bahwa Cloud Service Mesh resource dinamis yang dikonfigurasi. Untuk melihat konfigurasi, jalankan perintah ini:

    curl http://localhost:15000/config_dump
    
  3. Pastikan intersepsi traffic untuk proxy file bantuan disiapkan dengan benar. Untuk penyiapan pengalihan dengan iptables, jalankan perintah iptables dan lalu grep output untuk memastikan bahwa aturan Anda tersedia:

    sudo iptables -t nat -S | grep ISTIO
    

    Berikut adalah contoh output untuk iptables yang mengintersepsi alamat IP virtual (VIP) 10.0.0.1/32 dan meneruskannya ke proxy Envoy yang berjalan di port 15001 sebagai UID 1006:

    -N ISTIO_IN_REDIRECT
    -N ISTIO_OUTPUT
    -N ISTIO_REDIRECT
    -A OUTPUT -p tcp -j ISTIO_OUTPUT
    -A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
    -A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
    -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
    -A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
    -A ISTIO_OUTPUT -j RETURN
    

Jika instance VM dibuat melalui Konsol Google Cloud, beberapa instance modul tidak diinstal dan tersedia sebelum dimulai ulang. Hal ini menyebabkan iptables gagal karena dependensi yang hilang. Dalam hal ini, mulai ulang VM dan jalankan kembali proses pengaturan, yang akan memecahkan masalah. VM Compute Engine yang dapat Anda yang dibuat dengan menggunakan Google Cloud CLI tidak akan mengalami masalah ini.

Layanan berhenti dapat dijangkau saat logging akses Envoy dikonfigurasi

Jika Anda menggunakan TRAFFICDIRECTOR_ACCESS_LOG_PATH untuk mengonfigurasi Log akses Envoy seperti yang dijelaskan di Mengonfigurasi atribut bootstrap Envoy untuk Cloud Service Mesh, pastikan pengguna sistem yang menjalankan proxy Envoy memiliki izin untuk menulis lokasi log akses yang ditentukan.

Kegagalan dalam memberikan izin yang diperlukan akan menyebabkan pemroses tidak diprogram pada proxy dan dapat dideteksi dengan memeriksa kesalahan berikut di log proxy Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Untuk mengatasi masalah ini, ubah izin akses file yang dipilih untuk akses tersebut log agar dapat ditulis oleh pengguna Envoy.

Pesan error di log Envoy menunjukkan masalah konfigurasi

Bagian ini berlaku untuk deployment yang menggunakan API load balancing.

Jika mengalami kesulitan dengan konfigurasi Cloud Service Mesh, Anda mungkin melihat salah satu pesan error berikut di log Envoy:

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
    5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
    project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
    5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
    project "PROJECT_NUMBER".
  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
    5, Requested entity was not found.
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
    5, Requested entity was not found.
  • Cloud Service Mesh configuration was not found.

Pesan error terakhir (Traffic Director configuration was not found) umumnya menunjukkan bahwa Envoy meminta konfigurasi dari Cloud Service Mesh, tetapi tidak ada konfigurasi yang cocok yang dapat ditemukan. Saat Envoy terhubung ke Cloud Service Mesh, yang menampilkan nama jaringan VPC (misalnya, my-network). Cloud Service Mesh kemudian mencari aturan penerusan yang memiliki skema load balancing INTERNAL_SELF_MANAGED dan mereferensikan nama jaringan VPC yang sama.

Untuk memperbaiki error ini, lakukan langkah berikut:

  1. Pastikan bahwa ada aturan penerusan di jaringan Anda yang memiliki skema load balancing INTERNAL_SELF_MANAGED. Perhatikan aturan penerusan Nama jaringan VPC.

  2. Jika Anda menggunakan Cloud Service Mesh dengan deployment Envoy otomatis di Compute Engine, pastikan nilai yang diberikan ke tanda --service-proxy:network cocok nama jaringan VPC aturan penerusan.

  3. Jika Anda menggunakan Cloud Service Mesh dengan deployment Envoy manual di Compute Engine, periksa file bootstrap Envoy untuk hal berikut:

    1. Pastikan nilai untuk Variabel TRAFFICDIRECTOR_NETWORK_NAME cocok dengan nama jaringan VPC aturan penerusan.
    2. Pastikan nomor project ditetapkan di Variabel TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
  4. Jika Anda men-deploy di GKE, dan menggunakan injektor otomatis, pastikan nomor project dan nama jaringan VPC dikonfigurasi dengan benar, sesuai dengan petunjuk dalam Penyiapan Cloud Service Mesh untuk Pod GKE dengan injeksi Envoy otomatis.

Pemecahan masalah untuk Compute Engine

Bagian ini memberikan petunjuk untuk memecahkan masalah Envoy deployment untuk Compute Engine.

Proses bootstrap Envoy dan VM serta pengelolaan siklus proses lebih lanjut operasi dapat gagal karena berbagai alasan, termasuk masalah konektivitas sementara, repositori yang rusak, bug dalam skrip {i>bootstrap<i} dan agen on-VM, serta tindakan pengguna yang tidak diharapkan.

Saluran komunikasi untuk pemecahan masalah

Google Cloud menyediakan saluran komunikasi yang dapat Anda gunakan untuk Anda memahami proses {i>bootstrap<i} dan status saat ini dari komponen yang berada di VM Anda.

Logging output port serial virtual

Sistem operasi, BIOS, dan entitas tingkat sistem VM biasanya menulis output ke port serial. {i>Output<i} ini berguna untuk memecahkan masalah sistem macet, proses {i>boot-up<i} yang gagal, masalah saat {i>start-up<i}, dan masalah komputer mati.

Agen bootstrap Compute Engine mencatat semua tindakan yang dilakukan ke serial porta 1. Ini termasuk peristiwa sistem, dimulai dengan penginstalan paket dasar dengan cara mendapatkan data dari server metadata instance, iptables konfigurasi, dan status penginstalan Envoy.

Agen di VM mencatat status kondisi proses Envoy, yang baru ditemukan layanan Mesh Layanan Cloud, dan informasi lain yang mungkin berguna ketika Anda menyelidiki masalah dengan VM.

Logging Cloud Monitoring

Data yang diekspos dalam output port serial juga dicatat ke Monitoring, yang menggunakan perpustakaan Golang dan mengekspor log ke log terpisah untuk mengurangi derau. Karena log ini merupakan log tingkat instance, Anda mungkin menemukan log proxy pada halaman yang sama dengan log instance lainnya.

Atribut tamu VM

Atribut tamu adalah jenis metadata kustom tertentu yang menjadi tujuan penulisan aplikasi Anda saat dijalankan pada instance Anda. Setiap aplikasi atau pengguna pada instance Anda dapat membaca dan menulis data ke nilai metadata atribut tamu ini.

Skrip bootstrap Compute Engine Envoy dan agen di VM mengekspos atribut dengan informasi tentang proses bootstrap dan status Envoy saat ini. Semua atribut tamu ditampilkan di namespace gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Jika Anda menemukan masalah, sebaiknya periksa nilai tamu atribut bootstrap-status dan bootstrap-last-failure. Apa saja Nilai bootstrap-status selain FINISHED menunjukkan bahwa Envoy lingkungan belum dikonfigurasi. Nilai bookstrap-last-failure mungkin menunjukkan masalahnya.

Tidak dapat menjangkau layanan Cloud Service Mesh dari VM yang dibuat menggunakan template instance yang mendukung proxy layanan

Untuk memperbaiki masalah ini, ikuti langkah-langkah berikut:

  1. Penginstalan komponen proxy layanan pada VM mungkin tidak memiliki selesai atau mungkin gagal. Gunakan perintah berikut untuk menentukan apakah semua komponen diinstal dengan benar:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ \
        --zone=ZONE
    

    Atribut tamu bootstrap-status disetel ke salah satu atribut berikut:

    • [none] menunjukkan bahwa penginstalan belum dimulai. VM mungkin masih dalam proses {i>booting<i}. Periksa kembali statusnya dalam beberapa menit.
    • IN PROGRESS menunjukkan bahwa penginstalan dan konfigurasi komponen proxy layanan belum lengkap. Ulangi pemeriksaan status untuk mengetahui perkembangan terbaru.
    • FAILED menunjukkan bahwa penginstalan atau konfigurasi suatu komponen gagal. Periksa pesan error dengan membuat kueri Atribut gce-service-proxy/bootstrap-last-failure1.
    • FINISHED menunjukkan bahwa proses penginstalan dan konfigurasi selesai tanpa ada kesalahan. Gunakan petunjuk berikut untuk memverifikasi intersepsi lalu lintas dan {i>proxy<i} Envoy dikonfigurasi dengan benar.
  2. Intersepsi traffic di VM tidak dikonfigurasi dengan benar untuk Layanan berbasis Mesh Layanan Cloud. Login ke VM dan periksa iptables konfigurasi:

    gcloud compute ssh INSTANCE_NAME \
        --zone=ZONE \
        sudo iptables -L -t nat
    

    Periksa rantai SERVICE_PROXY_SERVICE_CIDRS untuk SERVICE_PROXY_REDIRECT entri seperti berikut:

    Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
    target                   prot opt source         destination ...
    SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
    

    Untuk setiap layanan, harus ada alamat IP atau CIDR yang cocok di Kolom destination. Jika tidak ada entri untuk alamat IP virtual (VIP), maka ada masalah dengan mengisi konfigurasi {i>proxy<i} Envoy dari Cloud Service Mesh, atau agen di VM gagal.

  3. Proxy Envoy belum menerima konfigurasinya dari Cloud Service Mesh . Login ke VM untuk memeriksa konfigurasi proxy Envoy:

    gcloud compute ssh INSTANCE_NAME \
        --zone=ZONE \
        sudo curl localhost:15000/config_dump
    

    Periksa konfigurasi pemroses yang diterima dari Cloud Service Mesh. Misalnya:

    "dynamic_active_listeners": [
      ...
      "filter_chains": [{
        "filter_chain_match": {
          "prefix_ranges": [{
            "address_prefix": "10.7.240.20",
            "prefix_len": 32
          }],
          "destination_port": 80
        },
      ...
        "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
      ...
    ]
    

    address_prefix adalah alamat IP virtual (VIP) dari Cloud Service Mesh layanan. URL tersebut mengarah ke peta URL yang disebut td-routing-rule-1. Memeriksa apakah layanan yang ingin Anda hubungkan sudah disertakan dalam pemroses konfigurasi Anda.

  4. Agen di VM tidak berjalan. Agen di VM secara otomatis mengkonfigurasi intersepsi traffic saat layanan Cloud Service Mesh baru dibuat. Jika agen tidak berjalan, semua lalu lintas ke layanan baru langsung menuju VIP, melewati proxy Envoy, dan waktu habis.

    1. Verifikasi status agen di VM dengan menjalankan perintah berikut:

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
         --query-path=gce-service-proxy/ \
         --zone=ZONE
      
    2. Periksa atribut agen di VM. Nilai atribut Atribut agent-heartbeat memiliki waktu saat agen terakhir kali melakukan tindakan atau pemeriksaan. Jika nilainya lebih dari lima menit, agen macet, dan Anda harus membuat ulang VM dengan menggunakan perintah berikut:

      gcloud compute instance-groups managed recreate-instance
      
    3. Atribut agent-last-failure mengekspos error terakhir yang terjadi di agen. Masalah ini mungkin bersifat sementara dan akan teratasi pada lain waktu agen akan memeriksa—misalnya, jika errornya adalah Cannot reach the Cloud Service Mesh API server—atau mungkin error permanen. Tunggu beberapa menit, lalu periksa kembali error tersebut.

Intersepsi traffic masuk dikonfigurasi ke port workload, tetapi Anda tidak dapat terhubung ke port dari luar VM

Untuk memperbaiki masalah ini, ikuti langkah-langkah berikut:

  1. Penginstalan komponen proxy layanan pada VM mungkin tidak memiliki selesai atau mungkin gagal. Gunakan perintah berikut untuk menentukan apakah semua komponen diinstal dengan benar:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ \
        --zone=ZONE
    

    Atribut tamu bootstrap-status disetel ke salah satu atribut berikut:

    • [none] menunjukkan bahwa penginstalan belum dimulai. VM mungkin masih dalam proses {i>booting<i}. Periksa kembali statusnya dalam beberapa menit.
    • IN PROGRESS menunjukkan bahwa penginstalan dan konfigurasi komponen proxy layanan belum lengkap. Ulangi pemeriksaan status untuk mengetahui perkembangan terbaru.
    • FAILED menunjukkan bahwa penginstalan atau konfigurasi suatu komponen gagal. Periksa pesan error dengan membuat kueri Atribut gce-service-proxy/bootstrap-last-failure1.
    • FINISHED menunjukkan bahwa proses penginstalan dan konfigurasi selesai tanpa ada kesalahan. Gunakan petunjuk berikut untuk memverifikasi intersepsi lalu lintas dan {i>proxy<i} Envoy dikonfigurasi dengan benar.
  2. Intersepsi traffic di VM tidak dikonfigurasi dengan benar untuk traffic masuk. Login ke VM dan periksa konfigurasi iptables:

    gcloud compute ssh INSTANCE_NAME \
        --zone=ZONE \
        sudo iptables -L -t nat
    

    Periksa rantai SERVICE_PROXY_INBOUND untuk SERVICE_PROXY_IN_REDIRECT entri seperti berikut:

    Chain SERVICE_PROXY_INBOUND (1 references)
    target                      prot opt source       destination ...
    SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
    

    Untuk setiap port yang ditentukan dalam service-proxy:serving-ports, harus ada menjadi port yang cocok di kolom destination. Jika tidak ada entri untuk porta, semua lalu lintas masuk menuju ke porta ini secara langsung, melewati Envoy {i>proxy<i}.

    Verifikasi bahwa tidak ada aturan lain yang menurunkan traffic ke port ini atau semuanya porta kecuali satu porta tertentu.

  3. Proxy Envoy belum menerima konfigurasinya untuk port masuk dari Cloud Service Mesh. Login ke VM untuk memeriksa proxy Envoy konfigurasi:

    gcloud compute ssh INSTANCE_NAME \
        --zone=ZONE \
        sudo curl localhost:15000/config_dump
    

    Cari konfigurasi pemroses masuk yang diterima dari Mesh Layanan Cloud:

    "dynamic_active_listeners": [
      ...
      "filter_chains": [{
        "filter_chain_match": {
          "prefix_ranges": [{
            "address_prefix": "10.0.0.1",
            "prefix_len": 32
          }],
          "destination_port": 80
        },
      ...
        "route_config_name": "inbound|default_inbound_config-80"
      ...
    ]
    

    route_config_name, dimulai dengan inbound, menunjukkan spesial yang dibuat untuk tujuan intersepsi lalu lintas masuk. Memeriksa apakah port yang ingin Anda hubungkan sudah disertakan dalam pemroses di bagian destination_port.

Masalah saat koneksi menggunakan protokol yang mengutamakan server

Beberapa aplikasi, seperti MySQL, menggunakan protokol di mana server mengirimkan paket. Ini berarti bahwa setelah koneksi awal, server mengirim yang pertama {i>byte.<i} Protokol dan aplikasi ini tidak didukung oleh Cloud Service Mesh.

Memecahkan masalah kualitas mesh layanan

Panduan ini memberikan informasi untuk membantu Anda me-resolve Cloud Service Mesh masalah konfigurasi.

Perilaku Cloud Service Mesh saat sebagian besar endpoint tidak responsif

Untuk keandalan yang lebih baik, saat 99% endpoint tidak responsif, Cloud Service Mesh mengonfigurasi bidang data untuk mengabaikan kondisi status endpoint tersebut. Sebaliknya, bidang data menyeimbangkan lalu lintas di antara semua endpoint karena porta yang menyalurkan masih dapat berfungsi.

Backend yang tidak responsif menyebabkan distribusi traffic yang kurang optimal

Cloud Service Mesh menggunakan informasi dalam resource HealthCheck terpasang ke layanan backend untuk mengevaluasi kondisi backend Anda. Cloud Service Mesh menggunakan status respons ini untuk merutekan traffic ke backend responsif terdekat. Jika beberapa backend Anda tidak responsif, traffic mungkin terus diproses, tetapi dengan distribusi yang kurang optimal. Misalnya, traffic mungkin mengalir ke wilayah di mana backend yang sehat masih ada, tetapi lebih jauh dari klien, sehingga membuat latensi. Untuk mengidentifikasi dan memantau status respons backend Anda, coba langkah-langkah berikut:

Langkah selanjutnya