Mengonfigurasi pengelolaan traffic lanjutan dengan layanan gRPC tanpa proxy

Konfigurasi ini didukung untuk pelanggan Pratinjau tetapi kami tidak merekomendasikan untuk pengguna Cloud Service Mesh baru. Untuk informasi selengkapnya, lihat Ringkasan perutean layanan Cloud Service Mesh.

Dokumen ini memberikan petunjuk untuk mengonfigurasi Cloud Service Mesh dengan fitur pengelolaan traffic berikut:

• Pencocokan rute
• Pemisahan traffic
• Pemutusan sirkuit
• Injeksi kesalahan
• Durasi streaming maksimum
• Coba lagi
• Afinitas sesi
• Deteksi outlier
• Load balancing lokalitas

Meskipun dokumen ini berfokus pada penyiapan pengelolaan traffic lanjutan dengan tanpa proxy di Compute Engine, pengelolaan traffic lanjutan juga didukung saat Anda menggunakan gRPC tanpa proxy di Google Kubernetes Engine (GKE).

Sebelum memulai

Sebelum mengonfigurasi pengelolaan traffic lanjutan, tinjau persyaratan di Persiapan untuk menyiapkan Cloud Service Mesh dengan layanan gRPC tanpa proxy. Anda tidak dapat mengonfigurasi pengelolaan traffic lanjutan, kecuali jika semua persyaratan terpenuhi.

Untuk informasi konseptual tentang fitur ini, lihat Pengelolaan traffic lanjutan.

Tentang contoh gRPC Wallet

Untuk mengilustrasikan fitur ini, Anda men-deploy contoh gRPC Wallet. Dalam contoh ini, ada tiga layanan gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats, dan grpc.examples.wallet.account.Account, yang di-deploy sebagai tiga aplikasi terpisah.

Seperti yang ditunjukkan di bawah ini diagram, Anda akan membuat klien gRPC yang memanggil layanan Wallet untuk mendapatkan saldo rekening dan memanggil layanan Stats untuk mendapatkan harga koin. Layanan Wallet memanggil layanan Stats dan Account untuk menghitung saldonya. Layanan Stats juga memanggil Account untuk mendapatkan informasi pengguna.

Dalam contoh ini, Anda men-deploy dua versi implementasi Wallet dan Stats untuk menggambarkan perutean permintaan berdasarkan aturan yang Anda konfigurasikan. Untuk menyimulasikan membangun dan men-deploy berbagai versi layanan, Anda menggunakan server untuk mengubah perilaku biner yang Anda bangun sekali saja.

• Flag --port menentukan port tempat layanan berada pada instance VM mendengarkan.
• Flag --hostname_suffix menentukan nilai yang ditambahkan ke nama host dari instance VM yang merespons permintaan. Nilai yang dihasilkan akan ditambahkan sebagai metadata hostname dalam respons. Hal ini membantu Anda mengidentifikasi dalam grup instance yang merespons permintaan klien.
• Flag --premium_only dengan nilai true menentukan bahwa layanan tersebut versi premium dari layanan stats.
• Flag --v1_behavior dengan nilai true menentukan bahwa dompet biner berperilaku sebagai versi v1.

Tabel berikut menunjukkan nilai flag ini untuk setiap instance VM yang menjalankan salah satu layanan gRPC, jumlah instance dalam satu instance grup, dan layanan backend yang mencakup grup instance tersebut.

Setelah men-deploy layanan ini, Anda mengonfigurasi Cloud Service Mesh untuk merutekan permintaan ke layanan backend ini dari klien pengujian, berdasarkan aturan pada tabel berikut. Klien terhubung ke nama {i>host<i} virtual dari seperti yang terlihat di kolom {i>Host<i}.

Contoh ini menggunakan pembagian traffic 70/30 antara dua layanan yang ada. Jika Anda adalah membagi traffic ke layanan baru yang belum direferensikan oleh peta URL sebelumnya, tambahkan layanan baru ke weightedBackendServices terlebih dahulu, lalu beri bobot 0. Kemudian, secara bertahap tingkatkan bobot yang layanan.

Klien pengujian memiliki opsi berikut yang memungkinkan Anda membuat permintaan yang sesuai untuk menunjukkan fitur pengelolaan lalu lintas.

Menyiapkan lingkungan lokal Anda

Untuk menyiapkan lingkungan lokal bagi contoh-contoh ini, jalankan perintah berikut berikut:

1. Perbarui biner gcloud untuk memastikan bahwa Anda memiliki versi terbaru:

   gcloud components update
   

2. Download repositori contoh:

   sudo apt-get install git -y
   

3. Clone repositori yang benar untuk contoh:

   export EXAMPLES_VERSION=v1.1.x
   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
     https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   

Membuat dan mengonfigurasi instance Cloud Router

Di bagian ini, Anda akan membuat instance Cloud Router di setiap region dan mengonfigurasinya untuk Cloud NAT. VM yang dibuat oleh contoh ini tidak memiliki alamat IP eksternal, tetapi harus memiliki akses ke internet. Mengonfigurasi Cloud Router dengan Cloud NAT menyediakan akses yang diperlukan.

Membuat aturan firewall dan health check gRPC

Di bagian ini, Anda akan membuat health check gRPC dan aturan firewall untuk mengizinkan Permintaan health check gRPC untuk menjangkau jaringan Anda. Selanjutnya, health check gRPC dikaitkan dengan layanan backend sehingga dapat memeriksa respons ke instance backend dari layanan backend tersebut.

Membuat template instance

Di bagian ini, Anda akan membuat template instance untuk men-deploy gRPC account yang diekspos pada port 50053.

Membuat grup instance terkelola

Grup instance terkelola (MIG) menggunakan penskalaan otomatis untuk membuat instance VM baru diperlukan. Di bagian ini, Anda akan membuat MIG dengan menggunakan template instance yang telah Anda buat di bagian sebelumnya.

Mengonfigurasi port bernama

Di bagian ini, Anda akan mengonfigurasi port bernama untuk layanan gRPC. Nama porta adalah porta tempat layanan gRPC memproses permintaan. Di sini contoh, port yang dinamai adalah port 50053.

Membuat layanan backend

Di bagian ini, Anda akan membuat layanan backend dengan skema load balancing INTERNAL_SELF_MANAGED dan protokol GRPC. Kemudian, Anda akan mengaitkan health check dan grup instance dengan layanan backend. Dalam contoh ini, Anda menggunakan MIG yang Anda buat di Buat grup instance terkelola. MIG ini menjalankan account gRPC. Port dalam flag --port-name adalah port bernama yang Anda dibuat di Konfigurasi port bernama.

Langkah-langkah untuk membuat layanan backend yang tersisa yang digunakan di gRPC Wallet mirip dengan langkah-langkah sebelumnya. Anda membuat layanan yang tersisa dengan menjalankan skrip shell. Skrip ini men-deploy layanan backend berikut:

• stats
• stats-premium
• wallet-v1
• wallet-v1-affinity
• wallet-v2

Jalankan skrip shell yang membuat layanan backend tambahan:

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"'

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true'

# This command creates wallet-v1 and wallet-v1-affinity backend services.
traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true'

traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'

Membuat aturan pemilihan rute

Di bagian ini, Anda akan membuat peta URL yang digunakan untuk mendemonstrasikan berbagai fitur pengelolaan traffic. Peta URL menentukan nama host virtual layanan dalam contoh ini dan aturan {i>routing<i} yang terkait. Untuk selengkapnya informasi selengkapnya, lihat Peta aturan pemilihan rute.

Di peta URL, hostRules menentukan nama host virtual properti dalam contoh ini. Ini adalah nama-nama yang digunakan klien dalam saluran URI untuk terhubung ke layanan tertentu. Misalnya, untuk mengirim permintaan ke Layanan account, klien menggunakan xds:///account.grpcwallet.io di saluran URI. Di hostRules, konfigurasi entri hosts dengan nilai account.grpcwallet.io.

pathMatcher yang terkait dengan entri hosts menentukan nama pathMatcher yang berisi semua aturan pemilihan rute untuk host virtual tersebut. J pathMatcher konfigurasi terdiri dari aturan pencocokan dan tindakan yang sesuai seperti yang dijelaskan dalam Tentang contoh gRPC Wallet.

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet

gcloud compute url-maps import grpcwallet-url-map << EOF
name: grpcwallet-url-map
defaultService: $BS_PREFIX-account-service

hostRules:
- hosts:
  - account.grpcwallet.io
  pathMatcher: grpcwallet-account-path-matcher
- hosts:
  - stats.grpcwallet.io
  pathMatcher: grpcwallet-stats-path-matcher
- hosts:
  - wallet.grpcwallet.io
  pathMatcher: grpcwallet-wallet-path-matcher

pathMatchers:
- name: grpcwallet-account-path-matcher
  defaultService: $BS_PREFIX-account-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: account-fault
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-account-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 30

- name: grpcwallet-stats-path-matcher
  defaultService: $BS_PREFIX-stats-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 0
    service: $BS_PREFIX-stats-premium-service

- name: grpcwallet-wallet-path-matcher
  defaultService: $BS_PREFIX-wallet-v1-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: session_id
        presentMatch: true
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-affinity-service
        weight: 100

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: timeout
    priority: 1
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      maxStreamDuration:
        seconds: 5

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: fault
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 50

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 3
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 100
      retryPolicy:
        retryConditions:
          - unavailable
        numRetries: 3

  - matchRules:
    - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance
    priority: 4
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 70
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 30

  - matchRules:
    - prefixMatch: /grpc.examples.wallet.Wallet/
    priority: 5
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
EOF

Membuat proxy dan aturan penerusan target

Di bagian ini, Anda akan membuat proxy gRPC target dan aturan penerusan.

Proxy gRPC target merujuk pada peta URL yang Anda buat di langkah sebelumnya. Flag --validate-for-proxyless akan mengaktifkan pemeriksaan konfigurasi sehingga Anda tidak secara tidak sengaja mengaktifkan fitur yang tidak kompatibel dengan gRPC tanpa proxy deployment.

Aturan penerusan merujuk ke proxy gRPC target yang Anda buat. Tujuan skema load balancing ditetapkan ke INTERNAL_SELF_MANAGED untuk menunjukkan bahwa aturan penerusan digunakan oleh Cloud Service Mesh. Ini harus berupa aturan penerusan. Alamat IP disetel ke 0.0.0.0 karena gRPC tanpa proxy yang me-resolve hostname:port di URI target dengan mengirimkan LDS ke Cloud Service Mesh, bukan melakukan pencarian DNS. Untuk selengkapnya informasi selengkapnya, lihat Skema resolusi nama.

Jika port tidak ditentukan dalam URI target, nilai defaultnya adalah 80. Sebagai contoh, URI target xds:///foo.myservice:8080 cocok dengan aturan penerusan yang dikonfigurasi dengan port 8080. Dalam contoh ini, aturan penerusannya dikonfigurasi dengan port 80.

Memverifikasi konfigurasi

Setelah proses konfigurasi selesai, pastikan layanan backend yang Anda konfigurasi tersedia dengan memeriksa Halaman Cloud Service Mesh di Google Cloud Console. Memastikan bahwa layanan backend dan backend terkait dilaporkan sebagai sehat. Proses ini mungkin perlu waktu beberapa menit.

Memverifikasi konfigurasi pemilihan rute

Di bagian ini, Anda akan memverifikasi bahwa konfigurasi pemilihan rute berfungsi dengan benar. Anda menggunakan alat grpcurl untuk menguji konfigurasi.

Untuk mengakses layanan tanpa proxy file bantuan, klien gRPC harus menggunakan Skema resolusi nama xds. Skema ini memberi tahu library gRPC yang digunakan di untuk menggunakan server xDS untuk me-resolve nama {i>host<i}. Untuk melakukan ini, sebuah {i>bootstrap<i} konfigurasi yang diperlukan.

Skrip startup di bagian sebelumnya menetapkan Variabel lingkungan GRPC_XDS_BOOTSTRAP dan menggunakan skrip helper untuk membuat file {i>bootstrap<i}. Nilai untuk TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME, dan zona dalam file bootstrap yang dihasilkan yang diperoleh dari server {i>metadata <i}yang mengetahui detail tentang di seluruh instance VM Compute Engine. Anda dapat memberikan nilai ini ke skrip helper secara manual menggunakan opsi -gcp-project-number dan -vpc-network-name.

Memverifikasi konfigurasi menggunakan alat grpcurl

Jalankan perintah berikut di shell SSH untuk memverifikasi bahwa wallet-service, stats-service, dan account-service sedang berjalan:

./grpcurl -plaintext xds:///account.grpcwallet.io list
./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance

Anda akan melihat hasil berikut:

grpc.examples.wallet.account.Account
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection

{
  "name": "Alice",
  "membership": "PREMIUM"
}

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Verifikasi dengan grpc-wallet klien

Gunakan petunjuk spesifik per bahasa berikut untuk memverifikasi konfigurasi. Perintah mengirim beberapa RPC, beberapa dengan metadata tambahan, untuk menampilkan permintaan dirutekan ke layanan backend berdasarkan aturan yang cocok dari peta URL. Perintah tersebut juga mencetak nama host instance VM untuk setiap respons ke menunjukkan ke instance VM mana permintaan diarahkan.

Mengonfigurasi opsi lanjutan lainnya

Anda dapat mengonfigurasi opsi pemilihan rute traffic lanjutan tambahan menggunakan petunjuk di bagian berikut.

Pemutusan sirkuit

Jeda sirkuit memungkinkan Anda menetapkan batas kegagalan untuk mencegah permintaan klien agar layanan backend Anda tidak kelebihan beban. Setelah sejumlah permintaan yang belum diproses mencapai batas yang Anda tetapkan, klien akan berhenti mengirim permintaan tambahan, memberi layanan backend Anda waktu untuk pulih.

Pemecahan sirkuit mencegah kegagalan beruntun dengan menampilkan error ke klien, alih-alih membebani layanan backend. Hal ini memungkinkan beberapa lalu lintas data ke dilayani sambil menyediakan waktu untuk mengelola situasi kelebihan beban, seperti menangani lonjakan traffic dengan meningkatkan kapasitas melalui penskalaan otomatis.

Saat Anda membuat layanan backend untuk stats-service, metode Skrip create_service.sh menyertakan baris berikut dalam konfigurasinya:

circuitBreakers:
  maxRequests: 1

Setelan ini membatasi klien ke satu permintaan yang tertunda ke stats-service dengan baik. Karena hanya ada satu layanan wallet-v2, menjalankan dua layanan secara serentak Operasi WatchBalance klien dompet menunjukkan kegagalan dari detik di instance Compute Engine.

Injeksi kesalahan

Injeksi kesalahan menimbulkan kesalahan saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, kelebihan beban layanan, kegagalan layanan, dan jaringan pembuatan partisi. Fitur ini berguna untuk menguji ketahanan layanan terhadap simulasi kesalahan.

Saat membuat peta URL sebelumnya, Anda menyetel kebijakan injeksi kesalahan ke menggagalkan 50% RPC yang dikirim ke wallet.grpcwallet.io dengan route=fault {i>header<i}.

Untuk mendemonstrasikan injeksi kesalahan, gunakan kode dalam bahasa berikut.

Durasi streaming maksimum

Durasi streaming maksimum memungkinkan waktu tunggu maksimum untuk diterapkan ke semua RPC. Ini mencegah klien yang lupa untuk menetapkan tenggat waktu, atau menetapkan mengurangi waktu, karena memboroskan sumber daya server.

Jika membuat peta URL sebelumnya, Anda menetapkan durasi streaming maksimal selama 5 detik untuk RPC yang dikirim ke wallet.grpcwallet.io dengan header route=timeout.

Untuk menunjukkan waktu tunggu, kita akan menghentikan layanan wallet-v2 terlebih dahulu.

gcloud compute instance-groups managed resize \
    --size=0 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Perintah berikut akan berhenti berfungsi selamanya, karena tidak ada backend untuk menanganinya, dan aplikasi tidak menetapkan tenggat waktu.

Namun, perintah berikut yang menggunakan rute timeout gagal setelah 5 detik karena setelan maxStreamDuration.

Mulai ulang layanan wallet-v2.

gcloud compute instance-groups managed resize \
    --size=1 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Coba lagi

Percobaan ulang membantu Anda meningkatkan ketersediaan layanan dengan mengaktifkan gRPC aplikasi untuk mencoba kembali permintaan keluar sesuai dengan kebijakan percobaan ulang. Sedang dicoba Anda dapat mengkonfigurasi kondisi di mana permintaan yang gagal dan jumlah maksimum percobaan ulang—misalnya, saat permintaan gagal dengan kode respons tertentu.

Saat membuat peta URL sebelumnya, Anda menetapkan kebijakan percobaan ulang untuk RPC ke FetchBalance dengan atribut Header membership=premium. Kebijakan ini mencoba ulang RPC yang gagal dengan status kode unavailable maksimal 3 kali. Anda juga menetapkan injeksi kesalahan kebijakan RPC ke account.grpcwallet.io dengan route=account-fault header yang menggagalkan 30% RPC dari layanan Wallet ke Account layanan. Hasilnya, 30% RPC dari klien pengujian dengan Header membership=normal gagal, sedangkan tingkat kegagalan untuk RPC dengan Header membership=premium kurang dari 1%.

Untuk mendemonstrasikan percobaan ulang, gunakan kode dalam bahasa berikut.

cd ~/traffic-director-grpc-examples/java
# 30% of the requests fail because Bob is a normal user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

cd ~/traffic-director-grpc-examples/go/wallet_client
# 30% of the requests fail because Bob is a normal user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

cd ~/traffic-director-grpc-examples/cpp
# 30% of the requests fail because Bob is a normal user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Afinitas sesi

Afinitas sesi memberikan upaya upaya terbaik untuk mengirim permintaan dengan karakteristik tertentu (header HTTP) ke instance yang sama selama instance responsif dan memiliki kapasitas. Hal ini berguna untuk stateful server aplikasi yang mendapat manfaat dari peningkatan kinerja dan efisiensi ketika permintaan dari klien tertentu dikirim ke {i> instance<i} yang sama, bukan, misalnya, distribusi round-robin ke berbagai instance.

Saat Anda membuat layanan backend grpcwallet-wallet-v1-affinity-service, di skrip create_service.sh, localityLbPolicy disetel ke ROUND_ROBIN. Dalam contoh ini, Anda akan menerapkan konfigurasi berikut ke ubah localityLbPolicy menjadi RING_HASH.

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

Untuk menunjukkan afinitas sesi, gunakan kode dalam bahasa berikut. Dengan flag --affinity=true, klien menyisipkan header session-id dengan nilai unik untuk setiap pengguna. Hash nilai ini digunakan untuk mengirim permintaan ke instance tertentu dalam grup instance layanan backend grpcwallet-wallet-v1-affinity-service.

cd ~/traffic-director-grpc-examples/java
# Without affinity, requests are sent to both instances.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

cd ~/traffic-director-grpc-examples/go/wallet_client
# Without affinity, requests are sent to both instances.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

cd ~/traffic-director-grpc-examples/cpp
# Without affinity, requests are sent to both instances.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Pulihkan konfigurasi layanan backend grpcwallet-wallet-v1-affinity-service.

gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \
  --source=bs_config.yaml \
  --global

Deteksi outlier

Untuk meningkatkan ketersediaan layanan, konfigurasi deteksi pencilan. Fitur ini memungkinkan Anda mengidentifikasi dan mengeluarkan host yang tidak responsif untuk sementara dari load balancing kolam renang. Host yang tidak responsif ini disebut outlier.

gRPC mengevaluasi host berdasarkan tingkat keberhasilan—frekuensi di mana {i>host<i} berhasil menangani permintaan. Tarif ini dipengaruhi oleh seperti error gRPC, error HTTP, waktu tunggu, dan masalah lainnya.

Saat mengonfigurasi deteksi pencilan melalui Cloud Service Mesh, Anda dapat meningkatkan cara gRPC menilai host dan cara menangani pencilan. Sebagai contoh, Anda dapat menentukan kriteria seperti berikut:

• Jumlah permintaan yang harus diterima host sebelum gRPC menganalisisnya untuk mengetahui kemungkinan status {i>outlier<i}.

• Sejauh mana host dapat menyimpang dari tingkat keberhasilan rata-rata sebelum dianggap sebagai {i>outlier<i}.

• Persentase maksimum host yang dapat dikeluarkan pada satu waktu dari kumpulan load balancing.

• Jumlah waktu saat pencilan dikecualikan dari proses load balancing kolam renang.

Untuk informasi selengkapnya tentang parameter yang tersedia, lihat REST Resource: backendServices alamat IP internal. Namun, ada beberapa batasan untuk gRPC, seperti yang dijelaskan dalam bagian berikutnya.

Batasan

Kolom berikut tidak didukung untuk klien gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Siapkan deteksi pencilan

Prosedur berikut menunjukkan cara mengonfigurasi deteksi pencilan untuk suatu layanan yang menggunakan satu grup instance sebagai backend-nya. Prosedur ini menetapkan konfigurasi berikut:

• Analisis deteksi pencilan berjalan setiap detik. Anda mengonfigurasi ini perilaku model dengan menggunakan kolom interval.
• Pencilan dikeluarkan dari kumpulan load balancing untuk kelipatan 30 detik, sebagai berikut:
  • Jika belum pernah dikeluarkan, host akan dikeluarkan hanya selama 30 detik.
  • Jika {i>host<i} sebelumnya telah dikeluarkan, waktu akan bertambah 30 detik untuk setiap pengecualian sebelumnya. Misalnya, saat host dikeluarkan untuk selama 90 detik, Anda mengonfigurasi perilaku ini menggunakan kolom baseEjectionTime.
• Suatu host dianggap tidak responsif jika tingkat keberhasilannya adalah satu deviasi standar di bawah rata-rata selama interval waktu yang dipilih (dalam hal ini, 1 detik). Anda Anda akan mengonfigurasi standar deviasi maksimum menggunakan Kolom successRateStdevFactor.

Untuk mengonfigurasi deteksi pencilan dengan cara ini, gunakan langkah-langkah berikut.

Load balancing lokalitas

Untuk mengoptimalkan penggunaan resource Anda, konfigurasikan pemuatan lokalitas balancing. Fitur ini membantu Anda menghemat sumber daya dengan mendistribusikan secara merata permintaan klien di backend Anda.

Saat mengonfigurasi load balancing lokalitas, Anda dapat menggunakan opsi yang dijelaskan pada tabel berikut. Semua opsi mengharuskan Anda mengonfigurasi Referensi backendServices.

Anda dapat menggunakan kombinasi apa pun dari opsi sebelumnya. Namun, jika Anda mengonfigurasi localityLbPolicy dan localityLbPolicies, gRPC akan terlebih dahulu mencoba untuk menggunakan konfigurasi localityLbPolicies.

Jika Anda tidak mengonfigurasi load balancing lokalitas, Cloud Service Mesh menggunakan kebijakan ROUND_ROBIN.

Untuk informasi tentang ROUND_ROBIN dan kebijakan bawaan lainnya, lihat deskripsi localityLbPolicy pada Halaman backendServices.

Menggunakan kebijakan bawaan

Jika ingin semua klien menggunakan satu kebijakan bawaan, Anda dapat memilih dengan mengonfigurasi kolom localityLbPolicy.

Saat mengonfigurasi kolom ini, Anda dapat memilih dari kebijakan berikut:

• LEAST_REQUEST (khusus klien Java)
• RING_HASH
• ROUND_ROBIN

Jika tidak semua klien Anda dapat menggunakan kebijakan yang sama, lihat Tentukan daftar kebijakan pilihan.

Menggunakan kebijakan kustom

Jika sesuai, Anda dapat menggunakan kebijakan load balancing kustom yang Anda buat dan yang di-deploy dengan gRPC. Fitur ini tersedia untuk klien Java yang menggunakan gRPC versi 1.47 atau yang lebih baru. Gunakan hanya di mesh yang menyertakan semua klien gRPC.

Saat membuat kebijakan kustom, dokumentasi berikut mungkin dapat membantu:

• Untuk membuat kebijakan khusus lebih canggih, Anda dapat menggunakan Open Request API Agregasi Biaya (ORCA). API ini memungkinkan Anda merekam metrik biaya kueri dan penggunaan server. Penggunaan API ini memerlukan gRPC versi 1.48.1 atau yang lebih baru. Untuk informasi selengkapnya, lihat Contoh gRPC ORCA.

• Untuk mengetahui informasi tentang cara konfigurasi load balancing kustom yang dikirim ke gRPC oleh xDS, lihat Konfigurasi Load Balancer Kustom gRPC xDS.

Untuk mengonfigurasi Cloud Service Mesh agar menggunakan kebijakan kustom Anda, identifikasi kebijakan tersebut menggunakan kolom localityLbPolicies.

Langkah-langkah berikut menunjukkan proses ini. Dalam prosedur ini, Anda akan memperbarui konfigurasi backend grpcwallet-wallet-v2-service sehingga klien yang terhubung menggunakan kebijakan khusus yang disebut example.ExampleLoadBalancer.

Menentukan daftar kebijakan pilihan

Jika Anda memiliki beberapa klien yang tidak semuanya mendukung load balancing tunggal Anda, buat daftar kebijakan yang dapat digunakan klien Anda. Dengan opsi ini, jika kebijakan pilihan pertama Anda tidak dapat digunakan oleh klien tertentu, gRPC akan kembali ke kebijakan berikutnya dalam daftar.

Saat Anda membuat daftar kebijakan pilihan, opsi yang valid mencakup kebijakan khusus, ROUND_ROBIN, dan, untuk klien Java, LEAST_REQUEST. Anda dapat mencantumkan hingga 10 kebijakan.

Fitur ini hanya tersedia untuk klien Java yang menggunakan gRPC versi 1.47 atau nanti. Gunakan hanya di mesh yang menyertakan semua klien gRPC.

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

Membersihkan sumber daya

Untuk membersihkan resource, jalankan perintah berikut dari sistem lokal Anda:

traffic-director-grpc-examples/scripts/cleanup.sh

Memblokir traffic antarlayanan

Jika Anda ingin memblokir traffic antara Layanan A dan Layanan B, dan deployment Anda aktif di GKE, menyiapkan keamanan layanan, dan menggunakan kebijakan untuk memblokir lalu lintas antar layanan. Untuk petunjuk selengkapnya, lihat Keamanan layanan Cloud Service Mesh dan petunjuk penyiapan dengan Envoy dan gRPC tanpa proxy.

Langkah selanjutnya

• Untuk membantu Anda menyelesaikan masalah konfigurasi Cloud Service Mesh, lihat Memecahkan masalah deployment yang menggunakan gRPC tanpa proxy.