Cloud Service Mesh dengan grup endpoint jaringan konektivitas hybrid

Cloud Service Mesh mendukung lingkungan yang melampaui Google Cloud, termasuk pusat data lokal dan cloud publik lainnya yang dapat Anda gunakan konektivitas hybrid untuk dijangkau.

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

  • Load balancer lokal.
  • Aplikasi server pada instance virtual machine (VM) di cloud lain.
  • Tujuan lain yang dapat Anda jangkau dengan konektivitas hibrida dan yang dapat dijangkau dengan alamat IP dan port.

Anda menambahkan alamat IP dan port setiap endpoint ke grup endpoint jaringan (NEG) konektivitas hibrida. NEG dengan konektivitas hybrid memiliki jenis NON_GCP_PRIVATE_IP_PORT.

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

  • Merutekan traffic secara global, termasuk ke endpoint layanan lokal dan multi-cloud.
  • 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 menghadirkan layanan jaringan ke multi-lingkungan. Google Cloud

NEG dengan 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 container di beberapa lingkungan, termasuk:

  • Google Cloud
  • Pusat data lokal
  • Cloud publik lainnya

Merutekan traffic mesh ke lokasi lokal atau cloud lain

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

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

Dalam 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). Kemudian, permintaan akan dikirim melalui Cloud VPN atau Cloud Interconnect ke tujuan yang diinginkan.

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

Memigrasikan layanan lokal yang ada ke Google Cloud

Mengirim traffic ke endpoint non-Google Cloud memungkinkan Anda merutekan traffic ke lingkungan lain. Anda dapat menggabungkan kemampuan ini dengan pengelolaan traffic tingkat lanjut 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 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 mengirim 100% traffic ke layanan cloud, dan Anda dapat menghentikan layanan on-prem.

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

Terakhir, Anda dapat menggabungkan fungsi ini dengan solusi jaringan Google Cloudyang 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 lokal atau multicloud Anda. Yang terbaik, Anda tidak perlu mengekspos layanan lokal atau multicloud ini ke internet publik.

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

Dalam diagram sebelumnya, traffic dari klien di internet publik masuk ke jaringanGoogle Clouddari 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 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 (yang dikonfigurasi oleh Cloud Service Mesh) meneruskan traffic melalui Cloud VPN atau Cloud Interconnect ke layanan lokal Anda.

Google Cloud resource dan arsitektur

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 multicloud 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 tujuan kesederhanaan, diagram tidak menampilkan opsi seperti beberapa layanan backend global.

Resource Compute Engine untuk layanan lokal dan multi-cloud.
Resource Compute Engine untuk layanan lokal dan multicloud (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 multicloud dan lokal seperti layanan lainnya yang dikonfigurasi oleh Cloud Service Mesh. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hibrida 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:portyang valid dan dapat dijangkau oleh klien Anda—misalnya, melalui konektivitas hybrid seperti Cloud VPN atau Cloud Interconnect.

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

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

Saat membuat NEG, konfigurasikan seperti 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 IP tersebut harus dapat dijangkau dari Google Cloud menggunakan konektivitas hybrid, seperti konektivitas yang disediakan oleh Cloud VPN atau Cloud Interconnect.
  • Tentukan Google Cloud zona yang meminimalkan jarak geografis antara Google Cloud dan lingkungan lokal atau multi-cloud Anda. Misalnya, jika Anda menghosting layanan di lingkungan lokal di Frankfurt, Jerman, Anda dapat menentukan zona europe-west3-a Google Cloud 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 health check terpusat Google Cloud, endpoint jaringan NON_GCP_PRIVATE_IP_PORT menggunakan mekanisme health check 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 akan terus beroperasi berdasarkan konfigurasi saat ini.
  • Klien Cloud Service Mesh baru tidak dapat terhubung ke Cloud Service Mesh. Mereka tidak dapat menggunakan service mesh 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 lokal, cloud lain, dan subnet tidak boleh tumpang-tindih. Google Cloud

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 pada 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, yang masing-masing memiliki jenis endpoint yang berbeda.

Peta URL dapat memiliki aturan host yang di-resolve ke layanan backend yang berbeda. Anda mungkin memiliki layanan backend dengan hanya NEG konektivitas hybrid (dengan endpoint lokal) dan layanan backend dengan NEG mandiri (dengan endpoint GKE). Peta URL dapat berisi aturan, misalnya, pemisahan traffic berbasis bobot, yang memisahkan 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, sebaiknya jangan gunakan pola ini karena NEG konektivitas hybrid tidak mendapatkan manfaat dari pemeriksaan kondisi terpusat. Untuk mengetahui penjelasan tentang health check terpusat dan health check terdistribusi, lihat bagian Health check.

Pendaftaran endpoint

Jika Anda 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 (dalam Google Cloud), MIG atau NEG Controller akan otomatis menangani pendaftaran endpoint.

Health check

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

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

Dalam praktiknya, menggunakan NON_GCP_PRIVATE_IP_PORT berarti:

  • Karena setiap klien Cloud Service Mesh menangani health check secara terdistribusi, Anda mungkin melihat peningkatan traffic jaringan karena health check. Peningkatan ini bergantung pada jumlah klien Cloud Service Mesh dan jumlah endpoint yang perlu diperiksa kondisinya oleh setiap klien. Contoh:
    • Saat Anda menambahkan endpoint lain ke NEG dengan konektivitas hybrid, klien Cloud Service Mesh yang ada mungkin mulai melakukan health check pada endpoint di NEG dengan konektivitas hybrid.
    • Saat Anda menambahkan instance lain ke mesh layanan (misalnya, instance VM yang menjalankan kode aplikasi Anda serta klien Cloud Service Mesh), instance baru dapat mulai melakukan pemeriksaan kondisi endpoint di NEG konektivitas hibrida.
    • Traffic jaringan karena health check meningkat pada tingkat kuadratik (O(n^2)).

Jaringan VPC

Service mesh diidentifikasi secara unik berdasarkan 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 dataGoogle Cloud , Anda harus memberikan nama jaringan VPC yang valid dalam konfigurasi bootstrap Anda.

Akun layanan

Dalam 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 dalam bootstrap Envoy. Akun layanan ini harus memiliki izin yang memadai untuk terhubung dengan Cloud Service Mesh API.

Langkah berikutnya