Cloud Service Mesh dengan grup endpoint jaringan konektivitas hybrid

Cloud Service Mesh mendukung lingkungan yang meluas di luar Google Cloud, termasuk pusat data lokal dan cloud publik lainnya yang dapat Anda gunakan konektivitas hybrid untuk menjangkaunya.

Anda mengonfigurasi Cloud Service Mesh agar mesh layanan dapat mengirim traffic ke endpoint yang berada di luar Google Cloud. Endpoint ini mencakup hal berikut:

  • Load balancer on-premise.
  • Aplikasi server di instance virtual machine (VM) di cloud lain.
  • Tujuan lain yang dapat Anda jangkau dengan konektivitas campuran dan dapat dijangkau dengan alamat IP dan port.

Anda menambahkan alamat IP dan port setiap endpoint ke grup endpoint jaringan konektivitas campuran (NEG). NEG dengan konektivitas hybrid berjenis NON_GCP_PRIVATE_IP_PORT.

Dukungan Cloud Service Mesh untuk layanan multi-cloud dan lokal memungkinkan Anda melakukan hal berikut:

  • Rutekan traffic secara global, termasuk ke endpoint layanan multi-cloud dan lokal.
  • Dapatkan manfaat Cloud Service Mesh dan service mesh—termasuk kemampuan seperti penemuan layanan dan pengelolaan traffic lanjutan—untuk layanan yang berjalan di infrastruktur yang ada di luar Google Cloud.
  • Gabungkan kemampuan Cloud Service Mesh dengan Cloud Load Balancing untuk menawarkan layanan jaringan Google Cloud ke multi-lingkungan.

NEG konektivitas hybrid (NEG NON_GCP_PRIVATE_IP_PORT) tidak didukung dengan klien gRPC tanpa proxy.

Kasus penggunaan

Cloud Service Mesh dapat mengonfigurasi jaringan antara layanan berbasis VM dan berbasis penampung di beberapa lingkungan, termasuk:

  • Google Cloud
  • Pusat data lokal
  • Cloud publik lainnya

Me-route traffic mesh ke lokasi lokal atau cloud lainnya

Kasus penggunaan paling sederhana untuk fitur ini adalah pemilihan rute traffic. Aplikasi Anda menjalankan proxy Envoy Cloud Service Mesh . Cloud Service Mesh memberi tahu klien tentang layanan Anda dan endpoint setiap layanan.

Me-routing traffic mesh ke lokasi lokal atau cloud lain.
Merutekan traffic mesh ke lokasi lokal atau cloud lain (klik untuk memperbesar)

Pada diagram sebelumnya, saat aplikasi Anda mengirim permintaan ke layanan on-prem, klien Cloud Service Mesh akan memeriksa permintaan keluar dan memperbarui tujuannya. Tujuan ditetapkan ke endpoint yang terkait dengan layanan on-prem (dalam hal ini, 10.2.0.1). Permintaan kemudian dikirim melalui Cloud VPN atau Cloud Interconnect ke tujuan yang diinginkan.

Jika perlu menambahkan lebih banyak endpoint, Anda dapat mengupdate Cloud Service Mesh untuk menambahkannya ke layanan Anda. Anda tidak perlu mengubah kode aplikasi.

Memigrasikan layanan lokal yang ada ke Google Cloud

Dengan mengirim traffic ke endpoint non-Google Cloud, Anda dapat merutekan traffic ke lingkungan lain. Anda dapat menggabungkan kemampuan ini dengan pengelolaan traffic lanjutan untuk memigrasikan layanan antar-lingkungan.

Bermigrasi dari lokasi lokal ke Google Cloud.
Bermigrasi dari lokasi lokal ke Google Cloud (klik untuk memperbesar)

Diagram sebelumnya memperluas pola sebelumnya. Daripada mengonfigurasi Cloud Service Mesh untuk mengirim semua traffic ke layanan on-prem, Anda mengonfigurasi Cloud Service Mesh untuk menggunakan pembagian traffic berbasis bobot guna membagi traffic di antara dua layanan.

Pembagian traffic memungkinkan Anda memulai dengan mengirimkan 0% traffic ke layanan cloud dan 100% ke layanan on-prem. Kemudian, Anda dapat secara bertahap meningkatkan proporsi traffic yang dikirim ke layanan cloud. Pada akhirnya, Anda akan mengirim 100% traffic ke layanan cloud, dan Anda dapat menghentikan layanan on-prem.

Layanan edge jaringan Google Cloud untuk deployment lokal dan multi-cloud

Terakhir, Anda dapat menggabungkan fungsi ini dengan solusi jaringan Google Cloud yang ada. Google Cloud menawarkan berbagai layanan jaringan, seperti load balancing eksternal global dengan Google Cloud Armor untuk perlindungan terhadap Distributed Denial of Service (DDoS), yang dapat Anda gunakan dengan Cloud Service Mesh untuk menghadirkan kemampuan baru ke layanan multi-cloud atau layanan di infrastruktur lokal Anda. Yang terbaik, Anda tidak perlu mengekspos layanan multi-cloud atau lokal ini ke internet publik.

Deployment yang mencakup beberapa lingkungan.
Deployment yang mencakup beberapa lingkungan (klik untuk memperbesar)

Pada diagram sebelumnya, traffic dari klien di internet publik masuk ke jaringan Google Cloud dari load balancer Google Cloud, seperti Load Balancer Aplikasi eksternal global kami. Saat traffic mencapai load balancer, Anda dapat menerapkan layanan edge jaringan seperti perlindungan DDoS Google Cloud Armor atau autentikasi pengguna Identity-Aware Proxy (IAP). Untuk mengetahui informasi selengkapnya, lihat Layanan edge jaringan untuk deployment multi-lingkungan.

Setelah Anda menerapkan layanan ini, traffic akan berhenti sejenak di Google Cloud, tempat aplikasi atau proxy mandiri (dikonfigurasi oleh Cloud Service Mesh) meneruskan traffic melalui Cloud VPN atau Cloud Interconnect ke layanan lokal Anda.

Resource dan arsitektur Google Cloud

Bagian ini memberikan informasi latar belakang tentang resource Google Cloud yang dapat Anda gunakan untuk menyediakan mesh layanan yang dikelola Cloud Service Mesh untuk lingkungan lokal dan multi-cloud.

Diagram berikut menggambarkan resource Google Cloud yang memungkinkan dukungan layanan lokal dan multi-cloud untuk Cloud Service Mesh. Resource utama adalah NEG dan endpoint jaringannya. Resource lainnya adalah resource yang Anda konfigurasi sebagai bagian dari penyiapan Cloud Service Mesh standar. Untuk memudahkan, diagram tidak menampilkan opsi seperti beberapa layanan backend global.

Resource Compute Engine untuk layanan lokal dan multi-cloud.
Resource Compute Engine untuk layanan multi-cloud dan lokal (klik untuk memperbesar)

Saat mengonfigurasi Cloud Service Mesh, Anda menggunakan resource API layanan backend global untuk membuat layanan. Layanan adalah konstruksi logis yang menggabungkan hal berikut:

  1. Kebijakan yang akan diterapkan saat klien mencoba mengirim traffic ke layanan.
  2. Satu atau beberapa backend atau endpoint yang menangani traffic yang ditujukan untuk layanan.

Layanan multi-cloud dan layanan lokal seperti layanan lainnya yang dikonfigurasi Cloud Service Mesh. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas campuran untuk mengonfigurasi endpoint layanan ini. NEG ini memiliki network endpoint type yang ditetapkan ke NON_GCP_PRIVATE_IP_PORT. Endpoint yang Anda tambahkan ke NEG konektivitas hybrid harus berupa kombinasi IP:port yang valid dan dapat dijangkau klien Anda—misalnya, melalui konektivitas hybrid seperti Cloud VPN atau Cloud Interconnect.

Setiap NEG memiliki jenis endpoint jaringan dan hanya dapat berisi endpoint jaringan dari jenis yang sama. Jenis ini menentukan hal berikut:

  • Tujuan tempat layanan Anda dapat mengirim traffic.
  • Perilaku health check.

Saat membuat NEG, konfigurasikan sebagai berikut agar Anda dapat mengirim traffic ke tujuan lokal atau multi-cloud.

  • Tetapkan jenis endpoint jaringan ke NON_GCP_PRIVATE_IP_PORT. Ini mewakili alamat IP yang dapat dijangkau. Jika alamat IP ini berada di infrastruktur lokal atau di penyedia cloud lain, alamat tersebut harus dapat dijangkau dari Google Cloud menggunakan konektivitas hybrid, seperti konektivitas yang disediakan oleh Cloud VPN atau Cloud Interconnect.
  • Tentukan zona Google Cloud yang meminimalkan jarak geografis antara Google Cloud dan lingkungan multicloud atau lokal Anda. Misalnya, jika Anda menghosting layanan di lingkungan lokal di Frankfurt, Jerman, Anda dapat menentukan zona Google Cloud europe-west3-a saat membuat NEG.

Perilaku health check untuk endpoint jaringan jenis ini berbeda dengan perilaku health check untuk jenis endpoint jaringan lainnya. Meskipun jenis endpoint jaringan lainnya menggunakan sistem pemeriksaan kondisi terpusat Google Cloud, endpoint jaringan NON_GCP_PRIVATE_IP_PORT menggunakan mekanisme pemeriksaan kondisi terdistribusi Envoy. Untuk mengetahui detail selengkapnya, lihat bagian Batasan dan pertimbangan lainnya.

Pertimbangan konektivitas dan jaringan

Klien Cloud Service Mesh Anda, seperti proxy Envoy, harus dapat terhubung ke Cloud Service Mesh di trafficdirector.googleapis.com:443. Jika Anda kehilangan konektivitas ke bidang kontrol Cloud Service Mesh, hal berikut akan terjadi:

  • Klien Cloud Service Mesh yang ada tidak dapat menerima update konfigurasi dari Cloud Service Mesh. Perangkat tersebut akan terus beroperasi berdasarkan konfigurasi saat ini.
  • Klien Cloud Service Mesh baru tidak dapat terhubung ke Cloud Service Mesh. Mereka tidak dapat menggunakan mesh layanan hingga konektivitas terhubung kembali.

Jika Anda ingin mengirim traffic antara Google Cloud dan lingkungan lokal atau multi-cloud, lingkungan tersebut harus terhubung melalui konektivitas hybrid. Sebaiknya gunakan koneksi dengan ketersediaan tinggi yang diaktifkan oleh Cloud VPN atau Cloud Interconnect.

Alamat IP dan rentang alamat IP subnet lokal, cloud lain, dan Google Cloud tidak boleh tumpang-tindih.

Keterbatasan dan pertimbangan lain

Berikut adalah batasan penggunaan NEG dengan konektivitas hybrid.

Setelan proxyBind

Anda hanya dapat menetapkan nilai proxyBind saat membuat targetHttpProxy. Anda tidak dapat memperbarui targetHttpProxy yang ada.

Konektivitas dan gangguan konektivitas

Untuk mengetahui detail tentang persyaratan dan batasan konektivitas, lihat bagian Pertimbangan konektivitas dan jaringan.

Jenis backend campuran

Layanan backend dapat memiliki backend VM atau NEG. Jika layanan backend memiliki backend NEG, semua NEG harus berisi jenis endpoint jaringan yang sama. Anda tidak dapat memiliki layanan backend dengan beberapa NEG, masing-masing dengan jenis endpoint yang berbeda.

Peta URL dapat memiliki aturan host yang me-resolve ke layanan backend yang berbeda. Anda mungkin memiliki layanan backend dengan NEG konektivitas hybrid saja (dengan endpoint on-premise) dan layanan backend dengan NEG mandiri (dengan endpoint GKE). Peta URL dapat berisi aturan, misalnya, pembagian traffic berbasis bobot, yang membagi traffic di setiap layanan backend ini.

Menggunakan NEG dengan endpoint jenis NON_GCP_PRIVATE_IP_PORT dengan backend Google Cloud

Anda dapat membuat layanan backend dengan NEG konektivitas hybrid yang mengarah ke backend di Google Cloud. Namun, kami tidak merekomendasikan pola ini karena NEG konektivitas campuran tidak mendapatkan manfaat dari pemeriksaan status terpusat. Untuk penjelasan tentang health check terpusat dan health check terdistribusi, lihat bagian Health check.

Pendaftaran endpoint

Jika ingin menambahkan endpoint ke NEG, Anda harus memperbarui NEG. Hal ini dapat dilakukan secara manual, atau dapat diotomatiskan menggunakan Google Cloud NEG REST API atau Google Cloud CLI.

Saat instance baru layanan dimulai, Anda dapat menggunakan Google Cloud API untuk mendaftarkan instance dengan NEG yang Anda konfigurasi. Saat menggunakan grup instance terkelola (MIG) Compute Engine atau GKE (di Google Cloud), pengontrol MIG atau NEG akan otomatis menangani pendaftaran endpoint.

Health check

Saat Anda menggunakan NEG konektivitas campuran, perilaku health check akan berbeda dengan perilaku health check terpusat standar dengan cara berikut:

  • Untuk endpoint jaringan jenis NON_GCP_PRIVATE_IP_PORT, Cloud Service Mesh mengonfigurasi kliennya untuk menggunakan bidang data guna menangani pemeriksaan kondisi. Untuk menghindari pengiriman permintaan ke backend yang tidak responsif, instance Envoy melakukan health check sendiri dan menggunakan mekanismenya sendiri.
  • Karena bidang data menangani pemeriksaan kesehatan, Anda tidak dapat menggunakan konsol Google Cloud, API, atau Google Cloud CLI untuk mengambil status pemeriksaan kesehatan.

Dalam praktiknya, penggunaan NON_GCP_PRIVATE_IP_PORT berarti hal berikut:

  • Karena setiap klien Cloud Service Mesh menangani pemeriksaan kesehatan secara terdistribusi, Anda mungkin melihat peningkatan traffic jaringan karena pemeriksaan kesehatan. Peningkatan ini bergantung pada jumlah klien Cloud Service Mesh dan jumlah endpoint yang diperlukan setiap klien untuk melakukan health check. Contoh:
    • Saat Anda menambahkan endpoint lain ke NEG konektivitas campuran, klien Cloud Service Mesh yang ada mungkin mulai melakukan pemeriksaan kesehatan endpoint di NEG konektivitas campuran.
    • Saat Anda menambahkan instance lain ke mesh layanan (misalnya, instance VM yang menjalankan kode aplikasi serta klien Cloud Service Mesh), instance baru mungkin mulai memeriksa kesehatan endpoint dalam NEG konektivitas campuran.
    • Traffic jaringan karena health check meningkat dengan kecepatan kuadratik (O(n^2)).

Jaringan VPC

Mesh layanan diidentifikasi secara unik oleh nama jaringan Virtual Private Cloud (VPC)-nya. Klien Cloud Service Mesh menerima konfigurasi dari Cloud Service Mesh berdasarkan jaringan VPC yang ditentukan dalam konfigurasi bootstrap. Oleh karena itu, meskipun mesh Anda sepenuhnya berada di luar pusat data Google Cloud, Anda harus memberikan nama jaringan VPC yang valid dalam konfigurasi bootstrap.

Akun layanan

Di Google Cloud, bootstrap Envoy default dikonfigurasi untuk membaca informasi akun layanan dari salah satu atau kedua lingkungan deployment Compute Engine dan GKE. Saat berjalan di luar Google Cloud, Anda harus menentukan akun layanan, nama jaringan, dan nomor project secara eksplisit di bootstrap Envoy. Akun layanan ini harus memiliki izin yang memadai untuk terhubung dengan Cloud Service Mesh API.

Langkah selanjutnya