Memecahkan masalah deployment gRPC tanpa proxy

Dokumen ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi saat men-deploy layanan gRPC tanpa proxy dengan Cloud Service Mesh. Untuk mengetahui informasi tentang cara menggunakan Client Status Discovery Service (CSDS) API untuk membantu Anda menyelidiki masalah terkait Cloud Service Mesh, lihat Memahami status klien Cloud Service Mesh.

Memecahkan masalah kegagalan RPC di aplikasi gRPC

Ada dua cara umum untuk memecahkan masalah kegagalan remote procedure call (RPC) dalam 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 di-propagate kembali ke status return RPC. Misalnya, saat RPC gagal dengan status yang menunjukkan bahwa batas waktu telah terlampaui, log dapat membantu Anda memahami kegagalan yang mendasarinya 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 tingkat 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 flag 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, tetapkan 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:

  • 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 di URI saat membuat saluran gRPC.
  • Pastikan Anda telah memberikan izin IAM yang diperlukan untuk membuat instance komputasi dan mengubah jaringan dalam project.
  • Pastikan Anda Mengaktifkan akun layanan untuk mengakses Traffic Director API. Di bagian API & layanan Konsol Google Cloud 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 VM Compute Engine atau cluster GKE disetel 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

  • Pastikan Anda dapat mengakses trafficdirector.googleapis.com:443 dari VM. Jika ada masalah akses, kemungkinan alasannya termasuk 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 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-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 dalam aturan penerusan yang digunakan dalam konfigurasi Anda. Jika port tidak ditentukan dalam URI, nilai 80 akan digunakan untuk mencocokkan aturan penerusan.
  • Pastikan nama host dan port yang digunakan dalam URI untuk membuat saluran gRPC cocok 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 langkah-langkah berikut:

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

    • Di kolom Peta aturan pemilihan rute terkait, pastikan peta URL yang benar mereferensikan layanan backend. Klik kolom untuk memeriksa apakah layanan backend yang ditentukan dalam aturan pencocokan host sudah benar.
    • Di kolom Backends, 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 di 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. 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 penayangan NEG.

  • Pastikan protokol endpoint dikonfigurasi sebagai GRPC.

RPC gagal karena kebijakan load balancing tidak didukung

Anda mungkin melihat pesan error seperti salah satu berikut di log:

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 klien tertentu yang digunakan. Untuk memperbaiki masalah ini, perbarui 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 saat ada dua atau beberapa resource kebijakan endpoint yang cocok dengan endpoint, misalnya, dua kebijakan dengan label dan port yang sama, atau dua atau beberapa kebijakan dengan label yang berbeda yang cocok dengan label endpoint. Untuk informasi selengkapnya tentang cara kebijakan endpoint dicocokkan dengan label endpoint, lihat API untuk EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Dalam situasi seperti itu, Cloud Service Mesh tidak menghasilkan konfigurasi keamanan dari kebijakan yang bertentangan.

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 sehat

Untuk keandalan yang lebih baik, saat 99% endpoint tidak sehat, Cloud Service Mesh mengonfigurasi bidang data untuk mengabaikan status kesehatan endpoint. Sebagai gantinya, bidang data menyeimbangkan traffic di antara semua endpoint karena port penayangan mungkin 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 kondisi ini untuk merutekan traffic ke backend terdekat yang berfungsi dengan baik. Jika beberapa backend Anda tidak responsif, traffic mungkin 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 kesehatan backend Anda, coba langkah-langkah berikut:

Langkah selanjutnya