Memecahkan masalah deployment gRPC tanpa proxy

Dokumen ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi saat Anda men-deploy layanan gRPC tanpa proxy dengan Cloud Service Mesh. 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.

Memecahkan masalah kegagalan RPC dalam aplikasi gRPC

Ada dua cara umum untuk memecahkan masalah kegagalan panggilan prosedur jarak jauh (RPC) dalam aplikasi gRPC:

  1. Tinjau status yang ditampilkan saat RPC gagal. Biasanya, status berisi cukup informasi untuk membantu Anda memahami penyebab RPC gagal.

  2. Aktifkan logging runtime gRPC. Terkadang Anda perlu meninjau gRPC log runtime untuk memahami kegagalan yang mungkin tidak disebarkan kembali ke Status pengembalian RPC. Misalnya, saat RPC gagal dengan status yang menunjukkan bahwa batas waktu itu telah terlampaui, log dapat membantu Anda memahami kegagalan dasar yang menyebabkan batas waktu terlampaui.

    Implementasi bahasa gRPC yang berbeda memiliki cara yang berbeda logging runtime gRPC:

    • gRPC di Java: gRPC menggunakan java.util.logging untuk logging. Setel io.grpc.level ke level FINE untuk memungkinkan logging panjang yang memadai dalam runtime gRPC. Cara umum untuk mengaktifkan pencatatan di Java adalah dengan memuat konfigurasi logging dari file dan menyediakan lokasi file ke JVM dengan menggunakan penanda command line. Contoh:

      # Create a file called logging.properties with the following contents:
      handlers=java.util.logging.ConsoleHandler
      io.grpc.level=FINE
      io.grpc.xds.level=FINEST
      java.util.logging.ConsoleHandler.level=ALL
      java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
      
      # Pass the location of the file to JVM by using this command-line flag:
      -Djava.util.logging.config.file=logging.properties
      

      Untuk mengaktifkan logging khusus untuk modul xDS, setel io.grpc.xds.level ke FINE. Untuk melihat logging yang lebih mendetail, tetapkan level ke FINER atau FINEST.

    • gRPC di Go: Aktifkan logging dengan menetapkan variabel lingkungan.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info
      
    • gRPC di C++: Untuk mengaktifkan logging dengan gRPC di C++, lihat petunjuk di Memecahkan masalah gRPC. Untuk mengaktifkan logging khusus untuk modul xDS, aktifkan pelacak berikut dengan menggunakan variabel lingkungan GRPC_TRACE untuk xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb, dan lrs_lb.

    • gRPC di Node.js: Untuk mengaktifkan logging dengan gRPC di Node.js, lihat petunjuk di Memecahkan masalah gRPC-JS. Untuk mengaktifkan logging khusus untuk modul xDS, aktifkan pelacak berikut dengan menggunakan variabel lingkungan GRPC_TRACE untuk xds_client, xds_resolver, cds_balancer, eds_balancer, priority, dan weighted_target.

Bergantung pada error dalam status RPC atau dalam log runtime, masalah Anda mungkin termasuk dalam salah satu kategori berikut.

Tidak dapat terhubung ke Cloud Service Mesh

Untuk memecahkan masalah koneksi, coba langkah-langkah berikut ini:

  • Periksa apakah nilai server_uri dalam file bootstrap trafficdirector.googleapis.com:443.
  • Pastikan bahwa variabel lingkungan GRPC_XDS_BOOTSTRAP ditentukan dan yang menunjuk ke file bootstrap.
  • Pastikan Anda menggunakan skema xds di URI saat membuat gRPC saluran TV Anda.
  • Pastikan Anda memenuhi persyaratan Izin IAM untuk membuat instance komputasi dan memodifikasi jaringan dalam sebuah project.
  • Pastikan bahwa Anda Aktifkan akun layanan untuk mengakses Traffic Director API. Di bagian API Konsol Google Cloud & layanan untuk project Anda, cari error di Traffic Director API.
  • Konfirmasi bahwa akun layanan memiliki izin yang benar. Aplikasi gRPC yang berjalan di VM atau Pod menggunakan akun layanan host VM Compute Engine atau node Google Kubernetes Engine (GKE) di instance Compute Engine.
  • Pastikan cakupan akses API dari VM Compute Engine Cluster GKE disetel untuk memberikan akses penuh ke Compute Engine API. Lakukan ini dengan menentukan hal berikut saat membuat VM atau cluster:

    --scopes=https://www.googleapis.com/auth/cloud-platform
    
  • Pastikan Anda dapat mengakses trafficdirector.googleapis.com:443 dari VM. Jika ada masalah akses, alasannya termasuk {i>firewall<i} yang mencegah akses ke trafficdirector.googleapis.com melalui port TCP 443 atau DNS masalah resolusi untuk nama host trafficdirector.googleapis.com.

Nama host yang ditentukan dalam URI tidak dapat diselesaikan

Anda mungkin melihat pesan error seperti berikut di log:

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

Untuk memecahkan masalah resolusi nama host, coba langkah berikut ini:

  • Pastikan Anda menggunakan bahasa dan versi gRPC yang didukung.
  • Pastikan port yang digunakan dalam URI untuk membuat saluran gRPC cocok dengan port di aturan penerusan yang digunakan di konfigurasi Anda. Jika port tidak yang ditentukan dalam URI, nilai 80 akan digunakan untuk mencocokkan aturan penerusan.
  • Pastikan nama host dan port yang digunakan dalam URI untuk membuat saluran gRPC sama persis dengan aturan host di peta URL yang digunakan dalam konfigurasi Anda.
  • Pastikan aturan host yang sama tidak dikonfigurasi di lebih dari satu peta URL.
  • Pastikan tidak ada karakter pengganti yang digunakan. Aturan host yang berisi karakter pengganti * karakter akan diabaikan.

RPC gagal karena layanan tidak tersedia

Untuk memecahkan masalah kegagalan RPC saat layanan tidak tersedia, coba metode berikut ini:

  • Periksa status keseluruhan Cloud Service Mesh dan status layanan backend di Konsol Google Cloud:

    • Di kolom Peta aturan perutean terkait, pastikan URL sudah benar Google Maps mereferensikan layanan backend. Klik kolom untuk memeriksa apakah layanan backend yang ditentukan dalam aturan pencocokan host sudah benar.
    • Di kolom Backends, periksa apakah backend yang terkait dengan layanan backend responsif.
    • Jika backend tidak responsif, klik layanan backend yang sesuai dan memastikan bahwa health check yang benar telah dikonfigurasi. Health check umumnya gagal karena aturan firewall yang salah atau hilang, atau ketidakcocokan dalam yang ditentukan dalam VM dan dalam aturan firewall. Untuk informasi selengkapnya, lihat Membuat health check.
  • Agar health check gRPC berfungsi dengan benar, backend gRPC harus menerapkan Protokol health check gRPC. Jika protokol ini tidak diterapkan, gunakan health check TCP sebagai gantinya. Larangan menggunakan health check HTTP, HTTPS, atau HTTP/2 dengan layanan gRPC.

  • Saat Anda menggunakan grup instance, pastikan port bernama yang ditentukan dalam grup instance Anda cocok dengan port yang digunakan dalam health check. Saat Anda menggunakan jaringan grup endpoint (NEG), pastikan spesifikasi layanan GKE anotasi NEG yang benar, dan health check dikonfigurasi untuk menggunakan NEG porta layanan.

  • Pastikan protokol endpoint dikonfigurasi sebagai GRPC.

RPC gagal karena kebijakan load balancing tidak didukung

Anda mungkin menemukan pesan error seperti salah satu dari yang berikut di log Anda:

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response
error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."
WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

Ini karena RING_HASH tidak didukung oleh bahasa tertentu dan dari klien yang digunakan. Untuk memperbaiki masalah ini, update backend konfigurasi layanan agar hanya menggunakan kebijakan load balancing yang didukung, atau mengupgrade klien ke versi yang didukung. Untuk versi klien yang didukung, lihat Fitur xDS di gRPC.

Konfigurasi keamanan tidak dibuat seperti yang diharapkan

Jika Anda mengkonfigurasi keamanan layanan dan konfigurasi keamanan belum dibuat seperti yang diharapkan, periksa kebijakan endpoint dalam deployment Anda.

Cloud Service Mesh tidak mendukung skenario yang memiliki dua endpoint atau lebih resource kebijakan yang sama persis dengan endpoint, misalnya, dua kebijakan dengan label dan port yang sama, atau dua atau lebih kebijakan dengan label yang sama persis dengan label endpoint. Untuk informasi selengkapnya tentang cara kebijakan endpoint dicocokkan dengan label endpoint, lihat API untuk EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Dalam situasi tersebut, Cloud Service Mesh tidak menghasilkan konfigurasi keamanan dari salah satu kebijakan yang berkonflik.

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