Ringkasan pengelolaan traffic lanjutan

Dokumen ini ditujukan bagi administrator mesh atau platform dan developer layanan yang memiliki tingkat pemahaman menengah hingga lanjutan tentang Cloud Service Mesh dan konsep service mesh, serta yang menentukan dan mengonfigurasi cara pengelolaan traffic dalam deployment Cloud Service Mesh.

Cloud Service Mesh menyediakan kemampuan pengelolaan traffic lanjutan yang memberi Anda kontrol terperinci atas cara penanganan traffic. Cloud Service Mesh mendukung kasus penggunaan berikut:

• Perutean traffic permintaan yang terperinci ke satu atau beberapa layanan.
• Pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan.
• Kebijakan duplikasi traffic yang mengirim permintaan ke satu layanan debug dan menyalinnya ke layanan lain. Pencerminan traffic tidak didukung dengan resource TCPRoute atau TLSRoute.
• Distribusi traffic yang disesuaikan di seluruh backend layanan untuk meningkatkan load balancing.

Kemampuan pengelolaan traffic lanjutan ini memungkinkan Anda memenuhi tujuan ketersediaan dan performa. Salah satu manfaat menggunakan Cloud Service Mesh untuk kasus penggunaan ini adalah Anda dapat memperbarui cara pengelolaan traffic tanpa perlu mengubah kode aplikasi.

Pengelolaan traffic di mesh layanan Cloud Service Mesh mengandalkan resource berikut:

• Resource Mesh, yang mengidentifikasi mesh layanan dan merepresentasikan komponen yang bertanggung jawab untuk meneruskan traffic dan menerapkan kebijakan. Resource Mesh juga mengidentifikasi port intersepsi traffic.
• Resource Gateway, yang mengidentifikasi proxy tengah dan merepresentasikan komponen yang memproses daftar pasangan alamat IP:port, meneruskan traffic, dan menerapkan kebijakan.
• Resource Route, yang dapat berupa salah satu dari beberapa jenis, dan yang berisi informasi perutean traffic untuk mesh. Resource Route mengidentifikasi nama host dan port yang dapat digunakan klien untuk merutekan traffic ke layanan backend. Berikut adalah jenis resource Route:
  • HTTPRoute, yang hanya tersedia di mesh yang menggunakan proxy Envoy. Saat Anda menggunakan resource HTTPRoute untuk mengonfigurasi proxy Envoy agar mengirim permintaan HTTP, semua kemampuan dalam dokumen ini tersedia.
  • TCPRoute, yang hanya tersedia di mesh yang menggunakan proxy Envoy.
  • TLSRoute, yang hanya tersedia di mesh yang menggunakan proxy Envoy.
  • GRPCRoute, yang tersedia di mesh menggunakan proxy sidecar Envoy dan gRPC tanpa proxy. Saat Anda menggunakan layanan atau aplikasi gRPC tanpa proxy dengan Cloud Service Mesh, beberapa kemampuan yang dijelaskan dalam dokumen ini tidak tersedia.
• Layanan backend, yang terkait dengan resource Route.

Konfigurasi

Untuk mengonfigurasi pengelolaan traffic lanjutan, Anda menggunakan Route dan resource layanan backend yang sama dengan yang Anda gunakan saat menyiapkan Cloud Service Mesh. Selanjutnya, Cloud Service Mesh mengonfigurasi proxy Envoy dan aplikasi gRPC tanpa proxy untuk menerapkan kebijakan pengelolaan traffic lanjutan yang Anda siapkan.

Pada intinya, Anda perlu melakukan tindakan berikut:

1. Konfigurasi resource Mesh untuk mengidentifikasi mesh layanan.

2. Konfigurasi resource Route untuk melakukan hal berikut, berdasarkan karakteristik permintaan keluar:

   1. Pilih layanan backend tempat permintaan dirutekan.

   2. Secara opsional, lakukan tindakan tambahan.

3. Konfigurasi layanan backend untuk mengontrol cara traffic didistribusikan ke backend dan endpoint setelah layanan tujuan dipilih.

Pemilihan rute dan tindakan traffic

Di Cloud Service Mesh, traffic dirutekan berdasarkan nilai dalam resource Mesh, resource Route, dan resource layanan backend. Semua kemampuan pengelolaan traffic lanjutan yang terkait dengan pemilihan rute dan tindakan dikonfigurasi menggunakan objek Route.

Bagian berikut menjelaskan fitur pengelolaan traffic lanjutan yang dapat Anda siapkan di objek Route.

Penanganan permintaan

Saat klien mengirim permintaan, permintaan tersebut ditangani seperti yang dijelaskan dalam langkah-langkah berikut:

1. Permintaan dicocokkan dengan resource Route tertentu sebagai berikut:

   • Jika Anda menggunakan Envoy:
     • Header host dalam permintaan HTTP dicocokkan dengan kolom hostnames di setiap resource HTTPRoute atau GRPCRoute untuk memilih resource Route yang benar untuk permintaan. Hanya resource HTTPRoute dan GRPCRoute yang memiliki kolom hostnames.
     • Alamat IP dicocokkan untuk merutekan traffic TCP menggunakan TCPPRoute.
     • SNI dan ALPN digunakan untuk TLS passthrough menggunakan TLSRoute.
     • Resource HTTPRoute dan GRPCRoute yang terkait dengan Mesh atau Gateway harus memiliki nama host yang unik. Jika Anda mencoba melampirkan beberapa rute yang memiliki nama host yang bertentangan, konfigurasi akan ditolak.
     • Demikian pula, kolom IP:Port dari TCPRoute harus unik atau konfigurasi ditolak.
     • Demikian pula, SNI dan ALPN harus unik untuk TLSRoute.
     • Jika ada nama host yang tumpang-tindih, seperti a.example.com dan *.example.com, permintaan akan cocok dengan rute yang lebih spesifik.
   • Jika Anda menggunakan gRPC tanpa proxy:
     • Klien gRPC tanpa proxy menggunakan skema resolusi nama xds. Mereka menyelesaikan hostname[:port] di URI target dengan mengirimkan permintaan ke Cloud Service Mesh.
     • Hanya port resource GRPCRoute yang dibandingkan dengan port di URI target (misalnya, xds:///example.hostname:8080). URI target harus sama persis dengan string di kolom hostnames pada GRPCRoute.

2. Resource Route dapat berisi informasi dan aturan perutean lebih lanjut.

3. Setelah layanan backend tujuan dipilih, traffic akan didistribusikan di antara backend atau endpoint untuk layanan backend tujuan tersebut, berdasarkan konfigurasi di resource layanan backend.

Langkah kedua dijelaskan di bagian berikut, Perutean sederhana berdasarkan host dan jalur. Langkah ketiga dibahas dalam Perutean dan tindakan lanjutan.

Perutean sederhana berdasarkan host dan jalur

Cloud Service Mesh mendukung skema pemilihan rute yang disederhanakan dan skema yang lebih canggih. Dalam skema sederhana, Anda menentukan host dan, secara opsional, jalur. Host dan jalur permintaan dievaluasi untuk menentukan layanan backend yang menjadi tujuan perutean permintaan.

• Host permintaan adalah bagian nama domain dari URL—misalnya, bagian host dari URL http://example.com/video/ adalah example.com.
• Jalur permintaan adalah bagian URL yang mengikuti nama host—misalnya, bagian jalur URL http://example.com/video/ adalah /video.

Anda menyiapkan perutean sederhana berdasarkan host dan jalur di peta aturan perutean, yang terdiri dari:

• Mesh global
• HTTPRoute atau GRPCRoute

Sebagian besar konfigurasi dilakukan di HTTPRoute. Setelah membuat peta aturan perutean awal, Anda hanya perlu mengubah resource HTTPRoute.

Aturan paling sederhana adalah aturan default, yang hanya menentukan aturan host wildcard (*) dan pencocok jalur dengan layanan default. Setelah membuat aturan default, Anda dapat menambahkan aturan tambahan yang menentukan host dan jalur yang berbeda. Permintaan keluar dievaluasi berdasarkan aturan ini sebagai berikut:

• Jika host permintaan (seperti example.com) cocok dengan nama host HTTPRoute:

  1. RouteRule dievaluasi berikutnya. RouteRule menentukan cara mencocokkan traffic dan cara merutekan traffic saat traffic cocok.
  2. Setiap RouteRule berisi satu atau beberapa kecocokan rute yang dievaluasi terhadap jalur permintaan.
  3. Jika kecocokan ditemukan, permintaan akan dirutekan ke layanan yang ditentukan dalam RouteAction.

Untuk mengetahui informasi selengkapnya tentang kolom resource HTTPRoute dan cara kerjanya, lihat dokumentasi API layanan jaringan.

Tindakan dan perutean lanjutan

Jika ingin melakukan lebih dari sekadar merutekan permintaan berdasarkan host dan jalur permintaan, Anda dapat menyiapkan aturan lanjutan untuk merutekan permintaan dan melakukan tindakan.

Pada tingkat tinggi, perutean dan tindakan lanjutan berfungsi sebagai berikut:

1. Seperti pemilihan rute sederhana, host permintaan dibandingkan dengan aturan host yang Anda konfigurasi di HTTPRoute atau GRPCRoute. Jika host permintaan cocok dengan nama host, HTTPRoute atau GRPCRoute akan dievaluasi.
2. Setelah rute dipilih, Anda dapat menerapkan tindakan.

Perutean lanjutan

Pemilihan rute lanjutan mirip dengan pemilihan rute sederhana yang dijelaskan sebelumnya, kecuali Anda dapat menentukan kondisi pencocokan tambahan. Misalnya, Anda dapat menentukan bahwa aturan cocok dengan header permintaan jika nama header cocok persis atau hanya sebagian—misalnya, berdasarkan awalan atau akhiran. Aturan dapat cocok berdasarkan evaluasi nama header terhadap ekspresi reguler atau berdasarkan kriteria lain seperti memeriksa keberadaan header.

Untuk mengetahui kondisi dan detail kecocokan tambahan untuk headerMatches dan queryParameterMatches, lihat halaman REST API network services.

Dengan menggabungkan host, jalur, header, dan parameter kueri dengan kondisi kecocokan, Anda dapat membuat aturan yang sangat ekspresif yang sesuai dengan persyaratan pengelolaan traffic Anda. Untuk mengetahui detailnya, lihat tabel berikut.

	Aplikasi berbasis HTTP	Aplikasi berbasis gRPC
Host HTTP versus host gRPC	Host adalah bagian nama domain dari URL yang dipanggil oleh aplikasi. Misalnya, bagian host dari URL http://example.com/video/ adalah example.com.	Host adalah nama yang digunakan klien dalam URI saluran untuk terhubung ke layanan tertentu. Misalnya, bagian host dari URI channel xds:///example.com adalah example.com.
Jalur HTTP versus jalur gRPC	Jalur adalah bagian dari URL yang mengikuti nama host. Misalnya, bagian jalur URL http://example.com/video adalah /video.	Jalur ada di header :path permintaan HTTP/2 dan terlihat seperti /SERVICE_NAME/METHOD_NAME. Misalnya, jika Anda memanggil metode Download di layanan gRPC Example, konten header :path akan terlihat seperti /Example/Download.
Header gRPC lainnya (metadata)		gRPC mendukung pengiriman metadata antara klien gRPC dan server gRPC untuk memberikan informasi tambahan tentang panggilan RPC. Metadata ini berbentuk pasangan nilai kunci yang dibawa sebagai header dalam permintaan HTTP/2.

Tindakan

Cloud Service Mesh memungkinkan Anda menentukan tindakan yang dilakukan oleh proxy Envoy atau aplikasi gRPC tanpa proxy saat menangani permintaan. Tindakan berikut dapat dikonfigurasi menggunakan Cloud Service Mesh.

Tindakan	Nama kolom API	Deskripsi
Pengalihan	redirect [pathredirect?]	Menampilkan kode respons 3xx yang dapat dikonfigurasi. Tindakan ini juga menetapkan header respons Location dengan URI yang sesuai, menggantikan host dan jalur seperti yang ditentukan dalam tindakan pengalihan.
Penulisan ulang URL	urlRewrite	Menulis ulang bagian nama host URL, bagian jalur URL, atau keduanya, sebelum mengirim permintaan ke layanan backend yang dipilih.
Transformasi header	requestHeaderModifier/responseHeaderModifier?	Menambahkan atau menghapus header permintaan sebelum mengirim permintaan ke layanan backend. Juga dapat menambahkan atau menghapus header respons setelah menerima respons dari layanan backend.
Duplikasi traffic	requestMirrorPolicy	Selain meneruskan permintaan ke layanan backend yang dipilih, mengirimkan permintaan yang identik ke layanan backend mirror yang dikonfigurasi berdasarkan fire and forget. Load balancer tidak menunggu respons dari backend yang dikirimkan permintaan yang dicerminkan. Duplikasi berguna untuk menguji versi baru layanan backend. Anda juga dapat menggunakannya untuk men-debug error produksi pada versi debug layanan backend, bukan pada versi produksi.
Pemisahan traffic berbasis bobot	weightDestination.serviceName	Memungkinkan traffic untuk aturan yang cocok didistribusikan ke beberapa layanan backend, secara proporsional dengan bobot yang ditentukan pengguna yang ditetapkan ke setiap layanan backend. Kemampuan ini berguna untuk mengonfigurasi deployment bertahap atau pengujian A/B. Misalnya, tindakan rute dapat dikonfigurasi sehingga 99% traffic dikirim ke layanan yang menjalankan aplikasi versi stabil, sementara 1% traffic dikirim ke layanan terpisah yang menjalankan aplikasi versi yang lebih baru.
Upaya coba lagi	retryPolicy	Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, durasi tunggu load balancer sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan.
Waktu habis	timeout	Menentukan waktu tunggu untuk rute yang dipilih. Waktu tunggu dihitung dari saat permintaan diproses sepenuhnya hingga saat respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang.
Injeksi kesalahan	faultInjectionPolicy	Menimbulkan error saat memproses permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, kelebihan beban layanan, kegagalan layanan, dan partisi jaringan. Fitur ini berguna untuk menguji ketahanan layanan terhadap kesalahan yang disimulasikan.
Kebijakan keamanan	corsPolicy	Kebijakan cross-origin resource sharing (CORS) menangani setelan untuk menerapkan permintaan CORS.

Untuk mengetahui informasi selengkapnya tentang tindakan dan cara kerjanya, lihat halaman Network Services API.

Di setiap aturan rute, Anda dapat menentukan salah satu tindakan rute berikut:

• Mengarahkan traffic ke layanan tunggal (destination.serviceName)
• Membagi traffic di antara beberapa layanan (destination.weight)
• URL pengalihan (redirect)

Selain itu, Anda dapat menggabungkan salah satu tindakan rute yang disebutkan sebelumnya dengan satu atau beberapa tindakan rute berikut (disebut sebagai Tindakan add-on di konsol Google Cloud ):

• Memanipulasi header permintaan atau respons (requestHeaderModifier/responseHeaderModifier)
• Duplikasi traffic (requestMirrorPolicy)
• Menulis ulang host, jalur URL, atau keduanya (urlRewrite)
• Mencoba lagi permintaan yang gagal (retryPolicy)
• Setel waktu tunggu (timeout)
• Membuat kesalahan pada persentase traffic (faultInjectionPolicy)
• Menambahkan kebijakan CORS (corsPolicy)

Karena tindakan dikaitkan dengan aturan tertentu, proxy Envoy atau aplikasi gRPC tanpa proxy dapat menerapkan tindakan yang berbeda berdasarkan permintaan yang ditanganinya.

Mendistribusikan traffic di antara backend layanan

Seperti yang dibahas dalam Penanganan permintaan, saat menangani permintaan keluar, klien akan memilih layanan tujuan terlebih dahulu. Setelah memilih layanan tujuan, ia perlu mencari tahu backend atau endpoint mana yang harus menerima permintaan.

Dalam diagram sebelumnya, Rule telah disederhanakan. Aturan biasanya berupa aturan host, pencocok jalur, dan satu atau beberapa aturan jalur atau rute. Layanan tujuan adalah (Backend) Service. Backend 1, …, dan Backend n menerima dan menangani permintaan. Backend ini mungkin berupa, misalnya, instance virtual machine (VM) Compute Engine yang menghosting kode aplikasi sisi server Anda.

Secara default, klien yang menangani permintaan mengirim permintaan ke backend responsif terdekat yang memiliki kapasitas. Untuk menghindari kelebihan beban pada backend tertentu, load balancer ini menggunakan algoritma load balancing round robin untuk melakukan load balancing pada permintaan berikutnya di seluruh backend lain dari layanan tujuan. Namun, dalam beberapa kasus, Anda mungkin menginginkan kontrol yang lebih terperinci atas perilaku ini.

Load balancing, afinitas sesi, dan melindungi backend

Anda dapat menetapkan kebijakan distribusi traffic berikut di setiap layanan.

Kebijakan	Nama kolom API	Deskripsi
Mode load balancing	balancingMode	Mengontrol cara grup endpoint jaringan (NEG) atau grup instance terkelola (MIG) dipilih setelah layanan tujuan dipilih. Anda dapat mengonfigurasi mode penyeimbangan untuk mendistribusikan beban berdasarkan koneksi serentak dan rasio permintaan.
Kebijakan load balancing	localityLbPolicy	Menetapkan algoritma load balancing yang digunakan untuk mendistribusikan traffic di antara backend dalam NEG atau MIG. Untuk mengoptimalkan performa, Anda dapat memilih dari berbagai algoritma (seperti round robin atau permintaan paling sedikit).
Afinitas sesi	sessionAffinity	Memberikan upaya terbaik untuk mengirim permintaan dari klien tertentu ke backend yang sama selama backend tersebut responsif dan memiliki kapasitas. Cloud Service Mesh mendukung empat opsi afinitas sesi: alamat IP klien, berbasis cookie HTTP, berbasis header HTTP, dan afinitas cookie yang dibuat (yang dibuat oleh Cloud Service Mesh sendiri).
Hash konsisten	consistentHash	Menyediakan afinitas sesi sementara berdasarkan header HTTP, cookie, atau properti lainnya.
Pemutus rangkaian	circuitBreakers	Menetapkan batas atas pada volume koneksi dan permintaan per koneksi ke layanan backend.
Deteksi outlier	outlierDetection	Menentukan kriteria untuk (1) menghapus backend atau endpoint yang tidak responsif dari MIG atau NEG dan (2) menambahkan kembali backend atau endpoint saat dianggap cukup responsif untuk menerima traffic lagi. Health check yang terkait dengan layanan menentukan apakah backend atau endpoint dianggap responsif.

Untuk mengetahui informasi selengkapnya tentang berbagai opsi distribusi traffic dan cara kerjanya, lihat dokumen berikut:

• Halaman backendServices REST API
• Ringkasan layanan backend.

Contoh kasus penggunaan

Pengelolaan traffic lanjutan menangani banyak kasus penggunaan. Bagian ini memberikan beberapa contoh umum.

Anda dapat menemukan contoh lainnya, termasuk contoh kode, di Mengonfigurasi pengelolaan traffic lanjutan dengan Envoy dan Mengonfigurasi pengelolaan traffic lanjutan dengan layanan gRPC tanpa proxy.

Perutean traffic yang mendetail untuk personalisasi

Anda dapat mengarahkan traffic ke layanan berdasarkan parameter permintaan. Misalnya, Anda dapat menggunakan layanan ini untuk memberikan pengalaman yang lebih dipersonalisasi bagi pengguna Android. Dalam diagram berikut, Cloud Service Mesh mengonfigurasi mesh layanan Anda untuk mengirim permintaan dengan header user-agent:Android ke layanan Android Anda, bukan ke layanan generik Anda.

Pemisahan traffic berbasis bobot untuk deployment yang lebih aman

Men-deploy versi baru dari layanan produksi yang ada bisa berisiko. Meskipun pengujian Anda lulus di lingkungan pengujian, Anda mungkin tidak ingin langsung mengarahkan semua pengguna ke versi baru.

Cloud Service Mesh memungkinkan Anda menentukan pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan. Misalnya, Anda dapat mengirim 1% traffic ke versi baru layanan, memantau apakah semuanya berfungsi, lalu secara bertahap meningkatkan proporsi traffic yang menuju ke layanan baru.

Pencerminan traffic untuk proses debug

Saat men-debug masalah, Anda mungkin perlu mengirim salinan traffic produksi ke layanan debug. Cloud Service Mesh memungkinkan Anda menyiapkan kebijakan pencerminan permintaan sehingga permintaan dikirim ke satu layanan dan salinan permintaan tersebut dikirim ke layanan lain.

Load balancing yang disesuaikan untuk performa

Bergantung pada karakteristik aplikasi, Anda mungkin mendapati bahwa Anda dapat meningkatkan performa dan ketersediaan dengan menyesuaikan cara traffic didistribusikan di seluruh backend layanan. Dengan Cloud Service Mesh, Anda dapat menerapkan algoritma load balancing tingkat lanjut sehingga traffic didistribusikan sesuai kebutuhan Anda.

Diagram berikut, berbeda dengan diagram sebelumnya, menunjukkan layanan backend tujuan (Production Service) dan backend untuk layanan backend tersebut (Virtual Machine 1, Virtual Machine 2, Virtual Machine 3). Dengan pengelolaan traffic lanjutan, Anda dapat mengonfigurasi cara layanan backend tujuan dipilih dan cara traffic didistribusikan di antara backend untuk layanan tujuan tersebut.

Untuk mengetahui informasi selengkapnya tentang load balancing dengan Cloud Service Mesh, lihat Ringkasan load balancing lanjutan.

Langkah berikutnya

• Untuk mengarahkan traffic dari luar mesh ke dalam mesh, lihat Traffic masuk untuk mesh Anda.