Ringkasan pengelolaan traffic lanjutan
Dokumen ini ditujukan bagi administrator platform atau mesh dan developer layanan yang memiliki pemahaman tingkat menengah hingga lanjutan terhadap konsep Cloud Service Mesh dan mesh layanan, serta untuk menentukan dan mengonfigurasi cara traffic dikelola dalam deployment Cloud Service Mesh.
Cloud Service Mesh memberikan kemampuan pengelolaan traffic lanjutan yang memberi Anda kontrol terperinci atas cara penanganan traffic. Cloud Service Mesh mendukung kasus penggunaan berikut:
- Perutean traffic permintaan yang mendetail ke satu atau beberapa layanan.
- Pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan.
- Kebijakan pencerminan traffic yang mengirim permintaan ke satu layanan proses debug dan
disalin ke layanan lainnya. Pencerminan traffic tidak didukung dengan resource
TCPRoute
atauTLSRoute
. - Menyesuaikan distribusi traffic 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 bergantung pada resource berikut:
- Resource
Mesh
, yang mengidentifikasi mesh layanan dan mewakili komponen yang bertanggung jawab untuk meneruskan traffic dan menerapkan kebijakan. ResourceMesh
juga mengidentifikasi port intersepsi traffic. - Resource
Gateway
, yang mengidentifikasi proxy tengah dan mewakili komponen yang memproses daftar alamat IP:pasangan port, meneruskan traffic, dan menerapkan kebijakan. - Resource
Route
, yang dapat berupa salah satu dari beberapa jenis resource, dan berisi informasi pemilihan rute traffic untuk mesh. ResourceRoute
mengidentifikasi nama host dan port yang dapat digunakan klien untuk mengarahkan traffic ke layanan backend. Berikut adalah jenis resourceRoute
:HTTPRoute
, yang hanya tersedia di mesh menggunakan proxy Envoy. Saat Anda menggunakan resourceHTTPRoute
untuk mengonfigurasi proxy Envoy guna mengirim permintaan HTTP, semua kemampuan dalam dokumen ini akan tersedia.TCPRoute
, yang hanya tersedia di mesh menggunakan proxy Envoy.TLSRoute
, yang hanya tersedia di mesh menggunakan proxy Envoy.GRPCRoute
, yang tersedia di mesh menggunakan proxy file bantuan 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 akan tersedia.
- Layanan backend, yang terkait dengan resource
Route
.
Konfigurasi
Untuk mengonfigurasi pengelolaan traffic lanjutan, gunakan resource layanan backend dan Route
yang sama dengan yang Anda gunakan saat menyiapkan Cloud Service Mesh.
Cloud Service Mesh kemudian akan mengonfigurasi proxy Envoy dan aplikasi gRPC tanpa proxy untuk menerapkan kebijakan pengelolaan traffic lanjutan yang Anda siapkan.
Pada intinya, Anda perlu melakukan tindakan berikut:
- Konfigurasi resource
Mesh
untuk mengidentifikasi mesh layanan. Konfigurasikan resource
Route
untuk melakukan hal berikut, berdasarkan karakteristik permintaan keluar:Pilih layanan backend yang permintaannya dirutekan.
Jika ingin, lakukan tindakan tambahan.
Konfigurasi layanan backend untuk mengontrol cara traffic didistribusikan ke backend dan endpoint setelah layanan tujuan dipilih.
Tindakan dan pemilihan rute 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 perutean 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 akan ditangani seperti yang dijelaskan dalam langkah-langkah berikut:
Permintaan ini dicocokkan dengan resource
Route
tertentu seperti berikut:- Jika Anda menggunakan Envoy:
- Header host dalam permintaan HTTP dicocokkan dengan kolom
hostnames
di setiap resourceHTTPRoute
atauGRPCRoute
untuk memilih resourceRoute
yang benar untuk permintaan tersebut. Hanya resourceHTTPRoute
danGRPCRoute
yang memiliki kolomhostnames
. - Alamat IP cocok untuk merutekan traffic TCP menggunakan
TCPPRoute
. - SNI dan ALPN digunakan untuk passthrough TLS menggunakan
TLSRoute
. - Resource
HTTPRoute
danGRPCRoute
yang dikaitkan denganMesh
atauGateway
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
dariTCPRoute
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.
- Header host dalam permintaan HTTP dicocokkan dengan kolom
- Jika Anda menggunakan gRPC tanpa proxy:
- Klien gRPC tanpa proxy menggunakan skema resolusi nama
xds
. Metode tersebut menyelesaikanhostname[:port]
dalam URI target dengan mengirim 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 kolomhostnames
GRPCRoute
.
- Klien gRPC tanpa proxy menggunakan skema resolusi nama
- Jika Anda menggunakan Envoy:
Resource
Route
dapat berisi aturan dan informasi pemilihan rute lebih lanjut.Setelah layanan backend tujuan dipilih, traffic didistribusikan di antara backend atau endpoint untuk layanan backend tujuan tersebut, berdasarkan konfigurasi di resource layanan backend.
Langkah kedua dijelaskan di bagian berikut, Pemilihan rute sederhana berdasarkan host dan jalur. Langkah ketiga dibahas di Pemilihan rute dan tindakan lanjutan.
Perutean sederhana berdasarkan host dan jalur
Cloud Service Mesh mendukung skema perutean 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 URL
http://example.com/video/
adalahexample.com
. - Jalur permintaan adalah bagian dari URL yang mengikuti nama host. Misalnya, bagian jalur URL
http://example.com/video/
adalah/video
.
Anda dapat menyiapkan perutean sederhana berdasarkan host dan jalur di peta aturan perutean, yang terdiri dari berikut ini:
Mesh
globalHTTPRoute
atauGRPCRoute
Sebagian besar konfigurasi dilakukan di HTTPRoute
. Setelah membuat peta aturan perutean awal, Anda hanya perlu mengubah resource HTTPRoute
.
Aturan yang paling sederhana adalah aturan default, yang mengharuskan Anda hanya menentukan aturan host karakter pengganti (*
) dan pencocok jalur dengan layanan default. Setelah membuat aturan default, Anda dapat menambahkan aturan lain yang menentukan host dan jalur yang berbeda. Permintaan keluar dievaluasi berdasarkan aturan berikut:
Jika host permintaan (seperti
example.com
) cocok dengan nama hostHTTPRoute
:- Selanjutnya,
RouteRule
akan dievaluasi.RouteRule
menentukan cara mencocokkan lalu lintas dan cara merutekan lalu lintas saat lalu lintas dicocokkan. - Setiap
RouteRule
berisi satu atau beberapa kecocokan rute yang dievaluasi terhadap jalur permintaan. - Jika ditemukan kecocokan, permintaan akan dirutekan ke layanan yang ditentukan dalam
RouteAction
.
- Selanjutnya,
Untuk mengetahui informasi selengkapnya tentang kolom resource HTTPRoute
dan cara kerjanya,
lihat dokumentasi API layanan jaringan.
Tindakan dan pemilihan rute lanjutan
Jika Anda 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, pemilihan rute dan tindakan lanjutan berfungsi sebagai berikut:
- Seperti pada pemilihan rute sederhana, host permintaan dibandingkan dengan aturan host yang Anda konfigurasi di
HTTPRoute
atauGRPCRoute
. Jika host permintaan cocok dengan nama host,HTTPRoute
atauGRPCRoute
akan dievaluasi. - Setelah rute dipilih, Anda dapat menerapkan tindakan.
Pemilihan rute lanjutan
Perutean lanjutan mirip dengan perutean sederhana yang dijelaskan sebelumnya, kecuali bahwa Anda dapat menentukan kondisi pencocokan tambahan. Misalnya, Anda dapat menentukan bahwa aturan cocok dengan header permintaan jika nama header sama persis atau hanya sebagian—misalnya, berdasarkan awalan atau akhiran. Aturan dapat mencocokkan berdasarkan evaluasi nama header terhadap ekspresi reguler atau berdasarkan kriteria lain seperti memeriksa keberadaan header.
Guna mengetahui detail dan kondisi pencocokan tambahan untuk headerMatches
dan queryParameterMatches
, lihat halaman REST API network services
.
Dengan menggabungkan parameter host, jalur, header, dan kueri dengan kondisi pencocokan, Anda dapat membuat aturan yang sangat ekspresif yang sesuai dengan persyaratan pengelolaan traffic yang tepat. 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 menjadi tujuan panggilan aplikasi. Misalnya, bagian host dari URL
|
Host adalah nama yang digunakan klien dalam URI saluran untuk terhubung ke layanan tertentu. Misalnya, bagian host URI saluran
|
Jalur HTTP versus jalur gRPC | Jalur adalah bagian dari URL yang mengikuti nama host. Misalnya, bagian jalur URL
|
Jalur ini ada di header Misalnya, jika Anda memanggil metode |
Header gRPC (metadata) lainnya | gRPC mendukung pengiriman metadata antara klien gRPC dan server gRPC untuk memberikan informasi tambahan tentang panggilan RPC. Metadata ini berbentuk key-value pair yang dibawa sebagai header dalam permintaan HTTP/2. |
Tindakan
Cloud Service Mesh dapat Anda gunakan untuk menentukan tindakan yang dilakukan dengan 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 |
Menampilkan kode respons 3xx yang dapat dikonfigurasi. Kode 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. |
Pencerminan traffic | requestMirrorPolicy |
Selain meneruskan permintaan ke layanan backend yang dipilih, kirimkan permintaan yang identik ke layanan backend duplikasi yang dikonfigurasi secara aktifkan dan lupakan. Load balancer tidak menunggu respons dari backend yang akan dikirimi permintaan yang dicerminkan. Pencerminan 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 | weiDestination.serviceNameght |
Mengizinkan traffic untuk aturan yang cocok didistribusikan ke beberapa layanan backend, sebanding dengan bobot yang ditentukan pengguna yang ditetapkan ke masing-masing layanan backend. Kemampuan ini berguna untuk mengonfigurasi deployment bertahap atau pengujian A/B. Misalnya, tindakan rute dapat dikonfigurasi sedemikian rupa sehingga 99% traffic dikirim ke layanan yang menjalankan versi stabil dari sebuah aplikasi, sementara 1% traffic dikirim ke layanan terpisah yang menjalankan versi lebih baru dari aplikasi tersebut. |
Upaya coba lagi | retryPolicy |
Mengonfigurasi kondisi saat load balancer mencoba ulang permintaan yang gagal, lama waktu load balancer menunggu sebelum mencoba ulang, dan jumlah maksimum percobaan ulang yang diizinkan. |
Timeout | timeout |
Menentukan waktu tunggu untuk rute yang dipilih. Waktu tunggu dihitung sejak permintaan diproses sepenuhnya hingga respons diproses sepenuhnya. Waktu tunggu mencakup semua percobaan ulang. |
Injeksi kesalahan | faultInjectionPolicy |
Memberikan error saat melayani permintaan untuk menyimulasikan kegagalan, termasuk latensi tinggi, overload 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 API layanan jaringan.
Di setiap aturan rute, Anda dapat menentukan salah satu tindakan rute berikut:
- Rutekan traffic ke satu layanan (
destination.serviceName
) - Memisahkan 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 URL, jalur, atau keduanya (
urlRewrite
) - Coba lagi permintaan yang gagal (
retryPolicy
) - Setel waktu tunggu (
timeout
) - Membuat kesalahan pada persentase traffic (
faultInjectionPolicy
) - Tambahkan kebijakan CORS (
corsPolicy
)
Karena tindakan dikaitkan dengan aturan tertentu, proxy Envoy atau aplikasi gRPC tanpa proxy dapat menerapkan tindakan yang berbeda berdasarkan permintaan yang ditangani.
Mendistribusikan traffic di antara backend layanan
Seperti yang dibahas dalam Penanganan permintaan, saat klien menangani permintaan keluar, klien akan memilih layanan tujuan terlebih dahulu. Setelah memilih layanan tujuan, layanan perlu mencari tahu backend atau endpoint yang harus menerima permintaan.
Dalam diagram sebelumnya, Aturan telah disederhanakan. Aturan biasanya berupa aturan host, pencocok jalur, dan satu atau beberapa aturan jalur atau rute. Layanan tujuan adalah Layanan(Backend). Backend 1, ..., dan Backend n menerima dan menangani permintaan. Backend ini dapat berupa, misalnya, instance virtual machine (VM) Compute Engine yang menghosting kode aplikasi sisi server Anda.
Secara default, klien yang menangani permintaan akan mengirim permintaan ke backend responsif terdekat yang memiliki kapasitas. Untuk menghindari kelebihan beban pada backend tertentu, pengujian ini menggunakan algoritma load-balancing round robin untuk melakukan load balancing pada permintaan berikutnya di backend lain dari layanan tujuan. Namun, dalam beberapa kasus, Anda mungkin menginginkan kontrol yang lebih mendetail atas perilaku ini.
Load balancing, afinitas sesi, dan perlindungan 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 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 dihasilkan (yang dihasilkan oleh Cloud Service Mesh sendiri). |
Hash konsisten | consistentHash |
Memberikan afinitas sesi ringan berdasarkan header HTTP, cookie, atau properti lainnya. |
Pemutus rangkaian | circuitBreakers |
Menetapkan batas atas 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 jika dianggap cukup sehat untuk menerima traffic lagi. Health check yang terkait dengan layanan menentukan apakah backend atau endpoint dianggap responsif. |
Untuk informasi selengkapnya tentang berbagai opsi distribusi traffic dan cara kerjanya, lihat dokumen berikut:
Contoh kasus penggunaan
Pengelolaan traffic lanjutan menangani banyak kasus penggunaan. Bagian ini memberikan beberapa contoh tingkat tinggi.
Anda dapat menemukan contoh lainnya, termasuk kode contoh, di Mengonfigurasi pengelolaan traffic lanjutan dengan Envoy dan Mengonfigurasi pengelolaan traffic lanjutan dengan layanan gRPC tanpa proxy.
Pemilihan rute 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.
Pemisahan traffic berbasis bobot untuk deployment yang lebih aman
Men-deploy versi baru dari layanan produksi yang ada dapat berisiko. Meskipun pengujian telah lulus di lingkungan pengujian, Anda mungkin tidak ingin langsung mengarahkan semua pengguna ke versi baru.
Cloud Service Mesh dapat Anda gunakan untuk menentukan pemisahan traffic berbasis bobot untuk mendistribusikan traffic di beberapa layanan. Misalnya, Anda dapat mengirim 1% traffic ke versi baru layanan, memantau bahwa semuanya berfungsi, lalu secara bertahap meningkatkan proporsi traffic yang menuju ke layanan baru.
Pencerminan traffic untuk proses debug
Saat Anda men-debug masalah, sebaiknya kirim salinan traffic produksi ke layanan proses debug. Dengan Cloud Service Mesh, Anda dapat 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 dapat meningkatkan performa dan ketersediaan dengan menyesuaikan cara traffic didistribusikan di seluruh backend layanan. Dengan Cloud Service Mesh, Anda dapat menerapkan algoritma load balancing lanjutan sehingga traffic didistribusikan sesuai dengan kebutuhan Anda.
Diagram berikut, berbeda dengan diagram sebelumnya, menampilkan layanan backend tujuan (Layanan Produksi) 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, baca Ringkasan load balancing lanjutan.
Langkah selanjutnya
- Untuk mengarahkan traffic dari luar mesh ke mesh, lihat Traffic masuk untuk mesh Anda.