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 dijangkau dengan konektivitas hybrid.

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

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

Tambahkan alamat IP dan port setiap endpoint ke grup endpoint jaringan konektivitas hybrid (NEG). NEG konektivitas hybrid adalah jenis NON_GCP_PRIVATE_IP_PORT.

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

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

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

Kasus penggunaan

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

  • Google Cloud
  • Pusat data lokal
  • Cloud publik lainnya

Merutekan traffic mesh ke lokasi lokal atau cloud lainnya

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

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

Pada diagram sebelumnya, saat aplikasi Anda mengirim permintaan ke layanan on-prem, klien Mesh Layanan Cloud 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 akan diteruskan melalui Cloud VPN atau Cloud Interconnect ke tujuan yang dimaksud.

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 mengirimkan 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 dapat mengonfigurasi Cloud Service Mesh untuk menggunakan pemisahan traffic berbasis bobot untuk membagi traffic di dua layanan.

Pemisahan traffic memungkinkan Anda memulai dengan mengirimkan 0% traffic ke layanan cloud dan 100% ke layanan on-prem. Anda kemudian dapat secara bertahap meningkatkan proporsi traffic yang dikirim ke layanan cloud. Terakhir, Anda 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 fungsionalitas ini dengan solusi jaringan Google Cloud yang sudah ada. Google Cloud menawarkan berbagai layanan jaringan, seperti load balancing eksternal global dengan Google Cloud Armor untuk perlindungan distributed denial of service (DDoS), yang dapat Anda gunakan dengan Cloud Service Mesh untuk menghadirkan kemampuan baru ke layanan lokal atau multi-cloud Anda. Yang paling penting, Anda tidak perlu mengekspos layanan lokal atau multi-cloud 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 memasuki 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 lebih lanjut, lihat Layanan edge jaringan untuk deployment multi-lingkungan.

Setelah layanan ini diterapkan, traffic akan berhenti sementara di Google Cloud, tempat aplikasi atau proxy mandiri (dikonfigurasi oleh Cloud Service Mesh) meneruskan traffic di 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 utamanya adalah NEG dan endpoint jaringannya. Resource lainnya adalah resource yang Anda konfigurasi sebagai bagian dari penyiapan Cloud Service Mesh standar. Agar lebih praktis, 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 multi-cloud (klik untuk memperbesar)

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

  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 lokal dan multi-cloud sama seperti layanan lain yang dikonfigurasi Cloud Service Mesh. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint layanan ini. NEG ini memiliki jenis endpoint jaringan 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 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 dari jenis yang sama. Jenis ini menentukan hal berikut:

  • Tujuan yang dapat menjadi tujuan layanan Anda dapat mengirimkan traffic.
  • Perilaku health check.

Saat membuat NEG, konfigurasikan sebagai berikut sehingga 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 dengan menggunakan konektivitas campuran, seperti konektivitas yang disediakan oleh Cloud VPN atau Cloud Interconnect.
  • Tentukan zona Google Cloud yang meminimalkan jarak geografis antara Google Cloud dan lingkungan lokal atau multi-cloud Anda. Misalnya, jika 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. Sementara 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 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 konektivitas ke bidang kontrol Cloud Service Mesh hilang, hal berikut akan terjadi:

  • Klien Cloud Service Mesh yang sudah ada tidak dapat menerima update konfigurasi dari Cloud Service Mesh. API tersebut akan terus beroperasi berdasarkan konfigurasinya 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 ketersediaan tinggi yang diaktifkan oleh Cloud VPN atau Cloud Interconnect.

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

Batasan dan pertimbangan lainnya

Berikut adalah batasan penggunaan NEG konektivitas hybrid.

Setelan proxyBind

Anda hanya dapat menetapkan nilai proxyBind saat membuat targetHttpProxy. Anda tidak dapat memperbarui targetHttpProxy yang sudah 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, masing-masing dengan jenis endpoint yang berbeda.

Peta URL dapat memiliki aturan host yang di-resolve ke layanan backend yang berbeda. Anda mungkin memiliki layanan backend dengan 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 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 hybrid tidak mendapatkan manfaat dari pemeriksaan kesehatan 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. Tindakan ini dapat dilakukan secara manual, atau dapat diotomatiskan dengan menggunakan Google Cloud NEG REST API atau Google Cloud CLI.

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

Health check

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

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

Dalam praktiknya, menggunakan NON_GCP_PRIVATE_IP_PORT berarti hal berikut:

  • Karena setiap klien Cloud Service Mesh menangani health check secara terdistribusi, Anda mungkin melihat peningkatan traffic jaringan akibat health check. Peningkatan ini bergantung pada jumlah klien Mesh Layanan Cloud dan jumlah endpoint yang perlu dilakukan health check oleh setiap klien. Contoh:
    • Saat Anda menambahkan endpoint lain ke NEG konektivitas hybrid, klien Cloud Service Mesh yang sudah ada dapat mulai melakukan health check endpoint dalam NEG 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 health check pada endpoint dalam NEG konektivitas hybrid.
    • Traffic jaringan karena health check meningkat pada rasio kuadrat (O(n^2)).

Jaringan VPC

Mesh layanan 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 data Google Cloud, Anda harus memberikan nama jaringan VPC yang valid dalam konfigurasi bootstrap.

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 secara eksplisit menentukan akun layanan, nama jaringan, dan nomor project di bootstrap Envoy Anda. Akun layanan ini harus memiliki izin yang memadai untuk terhubung dengan Cloud Service Mesh API.

Langkah selanjutnya