Traffic masuk untuk mesh Anda
Mesh layanan memfasilitasi komunikasi antara layanan yang berjalan di mesh. Bagaimana Anda memasukkan traffic ke mesh? Anda dapat menggunakan gateway untuk mengarahkan traffic dari luar mesh ke mesh melalui titik entri.
Dokumen ini menjelaskan cara menggunakan Cloud Load Balancing sebagai gateway untuk memasukkan traffic ke mesh Anda, dan mencakup hal berikut:
- Pertimbangan tingkat tinggi untuk gateway Anda.
- Ringkasan opsi saat Anda memilih gateway untuk mesh Anda.
- Rekomendasi arsitektur yang dapat diterapkan di topologi gateway Anda.
Dokumen ini berlaku untuk API perutean layanan Traffic Director. Setelah Anda menyelesaikan langkah-langkah penyiapan persiapan, lihat Penyiapan Traffic Director untuk gateway masuk, yang berisi petunjuk untuk melakukan deployment dengan gateway masuk.
Saat Anda mendesain mesh layanan, pertimbangkan traffic yang berasal dari sumber berikut:
- Traffic yang berasal dari dalam mesh Anda
- Traffic yang berasal dari luar mesh Anda
Traffic yang berasal dari dalam mesh Anda akan berpindah di bidang data mesh layanan untuk menjangkau backend atau endpoint yang terkait dengan layanan tujuan. Namun, traffic yang berasal dari luar mesh Anda harus terlebih dahulu menjangkau bidang data mesh layanan.
Pada contoh traffic yang berasal dari dalam mesh berikut, Traffic Director mengonfigurasi proxy file bantuan Anda. {i>Proxy<i} file bantuan ini membentuk bidang data dari {i>mesh<i} layanan Anda. Jika Layanan A ingin berkomunikasi dengan Layanan B, hal berikut akan terjadi:
- Layanan A membuat permintaan ke Layanan B dengan nama.
- Permintaan ini dicegat dan dialihkan ke proxy file bantuan Layanan A.
- Proxy file bantuan kemudian mengirimkan permintaan ke endpoint yang terkait dengan Layanan B.
Pada contoh berikut, traffic berasal dari luar mesh layanan Anda dan tidak berjalan di sepanjang bidang data mesh layanan.
Dalam contoh ini, klien berada di luar mesh layanan Anda. Karena tidak berpartisipasi langsung dalam mesh, klien tidak tahu endpoint mana yang termasuk dalam layanan di dalam mesh. Dengan kata lain, karena klien tidak menggunakan proxy yang dikonfigurasi Traffic Director untuk mengirim permintaan keluar, klien tidak tahu pasangan port alamat IP mana yang akan digunakan saat mengirim traffic ke Layanan A atau Layanan B. Tanpa informasi tersebut, klien tidak dapat menjangkau layanan di dalam mesh Anda.
Pertimbangan untuk gateway Anda
Bagian ini memberikan ringkasan masalah yang perlu dipertimbangkan saat Anda memilih gateway, termasuk hal berikut:
- Bagaimana cara klien mencapai gateway saya?
- Kebijakan apa yang ingin saya terapkan pada traffic yang mencapai gateway saya?
- Bagaimana cara gateway mendistribusikan traffic ke layanan di mesh saya?
Memungkinkan klien menjangkau gateway ke mesh Anda
Klien, baik di internet publik, di lingkungan lokal Anda, atau dalam Google Cloud, memerlukan cara untuk menjangkau layanan dalam mesh Anda. Menjangkau layanan di mesh Anda biasanya dicapai dengan menggunakan port dan alamat IP yang dapat dirutekan secara publik atau pribadi yang di-resolve ke gateway. Klien di luar mesh Anda menggunakan port dan alamat IP ini untuk mengirim permintaan ke layanan di mesh Anda melalui gateway Anda.
Cloud Load Balancing menyediakan berbagai opsi load balancing yang dapat Anda gunakan sebagai gateway ke mesh Anda. Pertanyaan utama yang diajukan saat Anda memilih load balancer Google Cloud untuk bertindak sebagai gateway Anda adalah sebagai berikut:
- Apakah klien saya berada di internet publik, di lingkungan lokal, atau merupakan bagian dari jaringan Virtual Private Cloud (VPC) saya?
- Protokol komunikasi apa yang digunakan klien saya?
Untuk ringkasan opsi Cloud Load Balancing, bergantung pada lokasi klien dan protokol komunikasi, lihat bagian Memilih gateway untuk mesh Anda.
Menangani traffic di gateway
Karena gateway Anda berada di tepi mesh, yaitu di antara klien yang berada di luar mesh dan layanan yang berada di dalam mesh, gateway adalah tempat yang wajar untuk menerapkan kebijakan saat traffic memasuki mesh Anda. Kebijakan ini mencakup hal-hal berikut:
- Pengelolaan traffic—misalnya, pemilihan rute, pengalihan, dan transformasi permintaan
- Keamanan—misalnya, penghentian TLS dan perlindungan distributed denial of service (DDoS) Google Cloud Armor
- Penyimpanan cache Cloud CDN
Bagian Memilih gateway untuk mesh Anda menyoroti kebijakan yang relevan di tepi mesh Anda.
Mengirim traffic dari gateway ke layanan di mesh Anda
Setelah gateway Anda menerapkan kebijakan ke traffic masuk, gateway tersebut akan memutuskan tujuan pengiriman traffic. Anda menggunakan kebijakan pengelolaan traffic dan load balancing untuk mengonfigurasi hal ini. Gateway mungkin, misalnya, memeriksa header permintaan untuk mengidentifikasi layanan mesh yang harus menerima traffic. Setelah mengidentifikasi layanan, gateway akan mendistribusikan traffic ke backend tertentu sesuai dengan kebijakan load balancing.
Bagian Choose a gateway for your mesh menguraikan backend mana yang menjadi tujuan pengiriman traffic oleh gateway.
Pilih gateway untuk mesh Anda
Google Cloud menawarkan berbagai load balancer yang dapat berfungsi sebagai gateway ke mesh Anda. Bagian ini membahas pemilihan gateway, dengan membandingkan opsi berikut dan dimensi yang relevan dengan pola gateway:
- Load Balancer Aplikasi Internal
- Load Balancer Aplikasi Eksternal
- Load Balancer Network passthrough internal
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Jaringan proxy eksternal
Di bagian ini, kami merujuk ke gateway first-level dan first-level. Istilah ini digunakan untuk menjelaskan penggunaan satu atau dua gateway untuk menangani traffic masuk ke mesh Anda.
Anda mungkin hanya memerlukan satu level, yaitu satu load balancer yang berfungsi sebagai gateway ke mesh. Namun, terkadang masuk akal untuk memiliki beberapa {i>gateway<i}. Dalam konfigurasi ini, satu gateway menangani traffic yang masuk ke Google Cloud, dan gateway level kedua yang lain menangani traffic saat memasuki mesh layanan.
Misalnya, Anda mungkin ingin menerapkan kebijakan keamanan Google Cloud Armor untuk traffic yang masuk ke Google Cloud dan kebijakan pengelolaan traffic lanjutan untuk traffic yang memasuki mesh. Pola penggunaan gateway kedua yang dikonfigurasi Traffic Director dibahas di bagian Menangani traffic masuk menggunakan gateway level kedua di tepi mesh Anda.
Tabel berikut membandingkan kemampuan yang tersedia, bergantung pada opsi gateway yang Anda pilih.
| Gateway | Lokasi klien | Protokol | Kebijakan | Backend/endpoint |
|---|---|---|---|---|
| Load Balancer Aplikasi internal | Klien berbasis Google Cloud di region yang sama dengan load balancer. Klien lokal yang permintaannya tiba di region Google Cloud yang sama dengan load balancer—misalnya, menggunakan Cloud VPN atau Cloud Interconnect. |
HTTP/1.1 HTTP/2 HTTPS |
Pengelolaan traffic lanjutan Penghentian TLS menggunakan sertifikat yang dikelola sendiri |
Backend di region Google Cloud yang sama dengan load balancer, berjalan di:
|
| Load Balancer Aplikasi Eksternal | Klien di internet publik | HTTP/1.1 HTTP/2 HTTPS |
Pengelolaan traffic Cloud CDN (termasuk backend bucket Cloud Storage) Penghentian TLS menggunakan sertifikat yang dikelola sendiri atau Google Kebijakan SSL Google Cloud Armor untuk pencegahan serangan web dan DDoS Dukungan Identity-Aware Proxy (IAP) untuk autentikasi pengguna |
Backend di region Google Cloud mana pun, berjalan di:
|
| Load Balancer Jaringan passthrough internal | Klien berbasis Google Cloud di region mana pun; ini memerlukan akses global jika klien berada di region yang berbeda dari load balancer. Klien lokal yang permintaannya masuk di region Google Cloud mana pun—misalnya, menggunakan Cloud VPN atau Cloud Interconnect. |
TCP | Backend di region Google Cloud yang sama dengan load balancer, yang berjalan di VM di Compute Engine. | |
| Load Balancer Jaringan passthrough eksternal | Klien di internet publik | TCP atau UDP | Backend di region Google Cloud yang sama dengan load balancer, yang berjalan di VM di Compute Engine. | |
| Load Balancer Jaringan proxy eksternal | Klien di internet publik | SSL atau TCP | Penghentian TLS menggunakan sertifikat yang dikelola sendiri atau Google (khusus proxy SSL) Kebijakan SSL (khusus proxy SSL) |
Backend di region Google Cloud mana pun, berjalan di:
|
| Proxy edge (pada instance VM atau container) yang dikonfigurasi oleh Traffic Director |
Klien harus berada di lokasi yang menerapkan salah satu dari hal berikut:
|
HTTP/1.1 HTTP/2 |
Pengelolaan traffic lanjutan (termasuk dukungan regex) |
Backend di region Google Cloud mana pun, berjalan di:
|
Untuk mengetahui perbandingan fitur demi fitur yang mendetail, lihat halaman Fitur load balancer. Untuk ringkasan fitur Traffic Director yang mendetail, lihat halaman fitur Traffic Director.
Men-deploy dan mengonfigurasi gateway
Pertimbangan terakhir dalam memilih gateway Anda adalah pengalaman dan alat developer yang ingin Anda gunakan. Google Cloud menawarkan banyak pendekatan untuk membuat dan mengelola gateway Anda.
Google Cloud CLI dan Compute Engine API
Untuk mengonfigurasi produk load balancing terkelola dan Traffic Director Google Cloud, Anda dapat menggunakan Google Cloud CLI dan Compute Engine API. Gcloud CLI dan API menyediakan mekanisme untuk men-deploy dan mengonfigurasi resource Google Cloud secara imperatif. Untuk mengotomatiskan tugas berulang, Anda dapat membuat skrip.
Konsol Google Cloud
Untuk mengonfigurasi Traffic Director dan load balancer terkelola Google Cloud, Anda dapat menggunakan konsol Google Cloud.
Untuk mengonfigurasi pola gateway, Anda mungkin memerlukan halaman Traffic Director dan halaman Load balancing.
GKE dan Multi Cluster Ingress
Pengontrol jaringan GKE dan GKE Enterprise juga mendukung deployment Cloud Load Balancing untuk integrasi bawaan dengan jaringan container. Solusi ini menyediakan antarmuka deklaratif bergaya Kubernetes untuk men-deploy dan mengonfigurasi gateway. Pengontrol GKE Ingress dan Multi-cluster Ingress mengelola load balancer internal dan eksternal untuk mengirim traffic ke satu cluster atau ke beberapa cluster GKE. Resource Ingress juga dapat dikonfigurasi agar mengarah ke layanan yang dikonfigurasi Traffic Director yang di-deploy di cluster GKE.
Pola arsitektur gateway
Bagian ini menjelaskan pola tingkat tinggi dan menyediakan diagram arsitektur untuk gateway Anda.
Pola yang paling umum melibatkan penggunaan load balancer yang dikelola Google Cloud sebagai gateway:
Klien mengirim traffic ke load balancer yang dikelola Google Cloud yang bertindak sebagai gateway Anda.
- Gateway menerapkan kebijakan.
Gateway mengirimkan traffic ke layanan di mesh Anda.
Pola yang lebih canggih melibatkan gateway di dua level. Gateway berfungsi sebagai berikut:
Klien mengirim traffic ke load balancer yang dikelola Google Cloud yang bertindak sebagai gateway level pertama Anda.
- Gateway menerapkan kebijakan.
Gateway mengirimkan traffic ke proxy edge (atau kumpulan proxy edge) yang dikonfigurasi oleh Traffic Director. Proxy edge ini bertindak sebagai gateway level kedua. Tingkat ini melakukan hal berikut:
Memberikan pemisahan masalah yang jelas di mana, misalnya, satu tim bertanggung jawab atas traffic masuk yang memasuki Google Cloud, sementara tim lain bertanggung jawab atas traffic masuk yang masuk ke mesh tim tersebut.
Memungkinkan Anda menerapkan kebijakan yang mungkin tidak didukung di load balancer yang dikelola Google Cloud.
Gateway level kedua mengirimkan traffic ke layanan di mesh Anda.
Pola masuk berakhir setelah traffic mencapai layanan in-mesh. Kasus umum dan pola lanjutan dijelaskan di bagian berikut.
Mengaktifkan traffic masuk dari internet
Jika klien Anda berada di luar Google Cloud dan perlu menjangkau Google Cloud melalui internet publik, Anda dapat menggunakan salah satu load balancer berikut sebagai gateway:
- Load Balancer Aplikasi Eksternal
- Load Balancer Jaringan passthrough eksternal
- Load Balancer Jaringan proxy eksternal
Dalam pola ini, load balancer yang dikelola Google Cloud berfungsi sebagai gateway Anda. Gateway menangani traffic masuk sebelum meneruskannya ke layanan di mesh Anda.
Misalnya, Anda dapat memilih Load Balancer Aplikasi eksternal sebagai gateway untuk menggunakan hal berikut:
- Alamat IP Anycast global yang dapat dirutekan secara publik, yang meminimalkan latensi dan biaya traversal jaringan.
- Google Cloud Armor dan penghentian TLS untuk mengamankan traffic ke mesh Anda.
- Cloud CDN untuk menayangkan konten web dan video.
- Kemampuan pengelolaan traffic seperti pemilihan rute berbasis host dan berbasis jalur.
Untuk mengetahui informasi selengkapnya guna membantu Anda menentukan gateway yang sesuai, lihat bagian Memilih gateway untuk mesh Anda.
Mengaktifkan traffic masuk dari klien di VPC dan jaringan lokal yang terhubung
Jika klien berada di dalam jaringan VPC, atau jika berada di infrastruktur lokal dan dapat menjangkau layanan Google Cloud menggunakan metode konektivitas pribadi (seperti Cloud VPN atau Cloud Interconnect), Anda dapat menggunakan salah satu load balancer berikut sebagai gateway:
Dalam pola ini, load balancer yang dikelola Google Cloud berfungsi sebagai gateway Anda. Gateway menangani traffic masuk sebelum meneruskannya ke layanan di mesh Anda.
Misalnya, Anda dapat memilih Load Balancer Aplikasi internal sebagai gateway, sehingga Anda dapat menggunakan fitur-fitur berikut:
- Alamat IP beralamat pribadi
- Penghentian TLS untuk mengamankan mesh Anda
- Kemampuan pengelolaan traffic lanjutan seperti pemisahan traffic berbasis bobot
- NEG sebagai backend
Untuk mengetahui informasi selengkapnya guna membantu Anda menentukan gateway yang sesuai, lihat bagian Memilih gateway untuk mesh Anda.
Tangani traffic masuk menggunakan gateway level kedua di tepi mesh Anda
Bergantung pada kebutuhan, Anda dapat mempertimbangkan pola lanjutan yang menambahkan gateway tambahan.
Gateway ini adalah proxy edge yang dikonfigurasi Traffic Director (atau kumpulan proxy) yang berada di belakang load balancer yang dikelola Google Cloud. Anda dapat menghosting gateway level kedua ini di project menggunakan kumpulan VM Compute Engine (grup instance terkelola) atau layanan GKE.
Meskipun pola ini lebih canggih, pola ini memberikan manfaat tambahan:
Load balancer yang dikelola Google Cloud menerapkan serangkaian kebijakan awal—misalnya, perlindungan Google Cloud Armor jika Anda menggunakan Load Balancer Aplikasi eksternal.
Proxy edge yang dikonfigurasi Traffic Director menerapkan rangkaian kebijakan kedua yang mungkin tidak tersedia di load balancer yang dikelola Google Cloud. Kebijakan ini mencakup pengelolaan traffic lanjutan yang menggunakan ekspresi reguler yang diterapkan ke header HTTP dan pemisahan traffic berbasis bobot.
Pola ini dapat disiapkan untuk mencerminkan struktur organisasi Anda. Contoh:
Satu tim mungkin bertanggung jawab menangani traffic masuk ke Google Cloud, sementara tim lain bertanggung jawab menangani traffic masuk ke mesh-nya.
Jika beberapa tim menawarkan layanan pada satu VPC Bersama, dan setiap tim memiliki project layanannya sendiri, tim dapat menggunakan pola ini untuk mengelola dan menerapkan kebijakan di mesh mereka sendiri. Setiap tim dapat mengekspos gateway yang dikonfigurasi Traffic Director dan dapat dijangkau di satu alamat IP dan pasangan port. Selanjutnya, tim dapat secara independen menentukan dan mengelola kebijakan yang diterapkan pada traffic masuk ke mesh tim.
Pola ini dapat diterapkan menggunakan semua load balancer yang dikelola Google Cloud, selama load balancer dapat mengirim traffic ke backend yang menghosting gateway yang dikonfigurasi Traffic Director.
Menggunakan API pemilihan rute layanan untuk traffic masuk
API pemilihan rute layanan menyediakan resource Gateway untuk
mengonfigurasi pengelolaan traffic dan keamanan untuk proxy Envoy yang bertindak sebagai gateway masuk, sehingga memungkinkan klien eksternal terhubung ke mesh layanan (utara-selatan).
Untuk mengetahui informasi selengkapnya, baca ringkasan pemilihan rute layanan dan Menyiapkan gateway masuk.
Langkah selanjutnya
- Untuk mengelompokkan VM dan container yang menjalankan kode Anda sebagai endpoint layanan, lihat penemuan layanan Traffic Director.
- Untuk menggunakan Traffic Director dengan VPC Bersama, lihat Menyiapkan mesh layanan multicluster.
- Untuk mempelajari Traffic Director lebih lanjut, lihat Ringkasan Traffic Director.