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. Untuk mengetahui informasi tentang cara menggunakan Client Status Discovery Service (CSDS) API guna membantu Anda menyelidiki masalah terkait Cloud Service Mesh, lihat 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) di aplikasi gRPC:

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

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

    Implementasi bahasa gRPC yang berbeda memiliki cara yang berbeda untuk mengaktifkan logging di runtime gRPC:

    • gRPC di Java: gRPC menggunakan java.util.logging untuk logging. Tetapkan io.grpc.level ke level FINE untuk mengaktifkan logging panjang yang memadai dalam runtime gRPC. Cara umum untuk mengaktifkan logging di Java adalah dengan memuat konfigurasi logging dari file dan memberikan lokasi file ke JVM menggunakan tanda 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 modul xDS, tetapkan io.grpc.xds.level ke FINE. Untuk melihat logging yang lebih mendetail, tetapkan levelnya 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 modul xDS, aktifkan tracer 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 dalam Memecahkan masalah gRPC-JS. Untuk mengaktifkan logging khusus modul xDS, aktifkan tracer berikut 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 di log runtime, masalah Anda mungkin termasuk dalam salah satu kategori berikut.

Tidak dapat terhubung ke Cloud Service Mesh

Untuk memecahkan masalah koneksi, coba langkah berikut:

  • Pastikan nilai server_uri dalam file bootstrap adalah trafficdirector.googleapis.com:443.
  • Pastikan variabel lingkungan GRPC_XDS_BOOTSTRAP ditentukan dan mengarah ke file bootstrap.
  • Pastikan Anda menggunakan skema xds pada URI saat membuat saluran gRPC.
  • Pastikan Anda telah memberikan izin IAM yang diperlukan untuk membuat instance komputasi dan mengubah jaringan dalam sebuah project.
  • Pastikan Anda mengaktifkan Traffic Director API untuk project tersebut. Di bagian Google Cloud Console APIs & services untuk project Anda, cari error di Traffic Director API.
  • Pastikan akun layanan memiliki izin yang benar. Aplikasi gRPC yang berjalan di VM atau Pod menggunakan akun layanan host VM Compute Engine atau instance node Google Kubernetes Engine (GKE).

  • Pastikan cakupan akses API pada VM Compute Engine atau cluster GKE ditetapkan untuk mengizinkan akses penuh ke Compute Engine API. Lakukan hal ini dengan menentukan hal berikut saat Anda membuat VM atau cluster:

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • Konfirmasi bahwa Anda dapat mengakses trafficdirector.googleapis.com:443 dari VM. Jika ada masalah akses, kemungkinan alasannya adalah firewall yang mencegah akses ke trafficdirector.googleapis.com melalui port TCP 443 atau masalah resolusi DNS untuk nama host trafficdirector.googleapis.com.

Nama host yang ditentukan dalam URI tidak dapat di-resolve

Anda mungkin menemukan pesan error seperti berikut di log Anda:

[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:

  • Pastikan Anda menggunakan versi dan bahasa gRPC yang didukung.
  • Pastikan port yang digunakan dalam URI untuk membuat saluran gRPC cocok dengan nilai port di aturan penerusan yang digunakan dalam konfigurasi Anda. Jika port tidak ditentukan dalam URI, nilai 80 akan digunakan untuk cocok dengan 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 * akan diabaikan.

RPC gagal karena layanan tidak tersedia

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

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

    • Di kolom Peta aturan perutean terkait, pastikan peta URL yang benar mereferensikan layanan backend. Klik kolom tersebut untuk memeriksa apakah layanan backend yang ditentukan dalam aturan pencocokan host sudah benar.
    • Di kolom Backend, pastikan backend yang terkait dengan layanan backend Anda responsif.
    • Jika backend tidak responsif, klik layanan backend yang sesuai dan pastikan health check yang benar telah dikonfigurasi. Health check biasanya gagal karena aturan firewall yang salah atau tidak ada, atau ketidakcocokan dalam tag yang ditentukan di VM dan dalam aturan firewall. Untuk mengetahui 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. Jangan gunakan health check HTTP, HTTPS, atau HTTP/2 dengan layanan gRPC.

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

  • Periksa apakah protokol endpoint dikonfigurasi sebagai GRPC.

RPC gagal karena kebijakan load balancing tidak didukung

Anda mungkin melihat pesan error seperti salah satu pesan 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)

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

Konfigurasi keamanan tidak dibuat seperti yang diharapkan

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

Cloud Service Mesh tidak mendukung skenario ketika ada dua atau beberapa resource kebijakan endpoint yang cocok secara setara dengan sebuah endpoint, misalnya, dua kebijakan dengan label dan port yang sama, atau dua kebijakan atau lebih dengan label berbeda yang sama persis dengan label endpoint. Untuk mengetahui informasi selengkapnya tentang cara pencocokan kebijakan endpoint dengan label endpoint, lihat API untuk EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Dalam situasi tersebut, Cloud Service Mesh tidak membuat konfigurasi keamanan dari kebijakan apa pun yang berkonflik.

Memecahkan masalah kondisi mesh layanan

Panduan ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi Cloud Service Mesh.

Perilaku Cloud Service Mesh saat sebagian besar endpoint tidak responsif

Untuk keandalan yang lebih baik, saat 99% endpoint tidak responsif, Cloud Service Mesh akan mengonfigurasi bidang data untuk mengabaikan status respons endpoint. Sebagai gantinya, bidang data akan menyeimbangkan traffic di antara semua endpoint karena port yang mungkin masih berfungsi masih berfungsi.

Backend yang tidak responsif menyebabkan distribusi traffic yang kurang optimal

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

Langkah selanjutnya