Integrasi Cloud Service Mesh dengan Direktori Layanan

Dokumen ini memberikan ringkasan tentang cara menggunakan Direktori Layanan registry layanan dengan Cloud Service Mesh, yang memungkinkan Cloud Service Mesh merutekan traffic dan menerapkan kebijakan traffic ke layanan yang terdaftar di Direktori Layanan. Dokumen ini ditujukan untuk developer Cloud Service Mesh yang ingin mengintegrasikan aplikasi dengan layanan lain di Google Cloud.

Direktori Layanan adalah registry layanan yang menyimpan informasi tentang layanan jaringan yang terdaftar di dalamnya, termasuk nama, lokasi, dan atribut mereka. Anda dapat mendaftarkan layanan Anda secara otomatis, mencatat semua detail, dan semua layanan dapat didaftarkan, terlepas dari infrastruktur mereka.

Registry tidak hanya dapat berisi layanan Google Cloud, tetapi juga layanan hybrid dan layanan yang berjalan di infrastruktur lokal atau di cloud publik lainnya. Untuk memahami dengan baik informasi dalam dokumen ini, sebaiknya Anda memahami dasar-dasar operasi Direktori Layanan.

Saat Anda menggunakan registry layanan Direktori Layanan dengan Cloud Service Mesh, integrasi ini membuat layanan dalam registry layanan yang tersedia untuk aplikasi di mesh Anda dan ke gateway yang dikonfigurasi oleh dan Cloud Service Mesh. Integrasi Cloud Service Mesh dengan Direktori Layanan didukung, dengan Envoy dan dengan proxy tanpa proxy gRPC, untuk integrasi Direktori Layanan dengan Load Balancer Jaringan passthrough internal, Load Balancer Aplikasi internal, dan L4 Private Service Connect.

Untuk mengintegrasikan layanan, Anda mendaftarkan layanan dengan Direktori Layanan, lalu mengikat layanan ke Cloud Service Mesh layanan backend. Setelah binding dibuat, kueri Cloud Service Mesh Direktori Layanan untuk mendapatkan informasi tentang dan bagaimana layanan itu dapat dicapai. Cloud Service Mesh juga melacak perubahan pada layanan. Penggunaan integrasi ini memungkinkan mesh layanan dan kemampuan mandiri gateway terkelola untuk mengirim traffic ke layanan ini. Hal ini juga memungkinkan Anda menerapkan kebijakan—misalnya, kebijakan pengelolaan traffic lanjutan—yang dikonfigurasi di Cloud Service Mesh.

Saat Anda menggunakan integrasi ini, service binding bertindak sebagai backend, terlepas dari jenis backend yang digunakan oleh layanan itu sendiri. Integrasi ini menyederhanakan deployment Cloud Service Mesh, karena Cloud Service Mesh dapat mengirim traffic ke layanan tanpa memperhatikan jenis backend.

Saat layanan didaftarkan ke Direktori Layanan, Anda tidak mengonfigurasi grup instance atau jenis grup endpoint jaringan yang berbeda (NEG) untuk mendapatkan akses ke layanan yang Anda butuhkan. Anda dapat mendaftar secara otomatis Google Kubernetes Engine, load balancer internal, dan Private Service Connect ke Direktori Layanan, yang lebih menyederhanakan akses ke layanan tersebut.

Resource yang digunakan oleh integrasi

Integrasi antara Cloud Service Mesh dan Direktori Layanan yang menggunakan resource berikut.

Layanan Direktori Layanan

Direktori Layanan adalah registry layanan. Direktori Layanan memungkinkan Anda mendaftarkan berbagai jenis layanan, termasuk layanan yang berbasis di Google Cloud atau lingkungan lainnya (untuk misalnya, pusat data lokal). Setiap layanan terdiri dari nama unik dan nol atau beberapa endpoint layanan. Titik akhir layanan terdiri dari alamat, porta, properti, dan {i>metadata<i}. Jika tidak ada endpoint,Anda tidak dapat merutekan traffic ke layanan.

Pengikatan layanan

Binding layanan adalah resource yang mencakup nama domain yang sepenuhnya memenuhi syarat (FQDN) dari layanan Direktori Layanan. Misalnya, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service adalah FQDN untuk layanan Direktori Layanan.

Layanan backend

Layanan backend adalah sumber daya konfigurasi yang menyediakan informasi Cloud Service Mesh, termasuk backend, seperti grup instance terkelola, untuk di mana layanan backend merutekan traffic. Layanan backend yang mereferensikan binding layanan tidak boleh memiliki backend. Untuk menggunakan integrasi Cloud Service Mesh dengan Direktori Layanan, Anda membuat layanan backend baru untuk binding layanan referensi.

Layanan backend dapat memiliki beberapa binding layanan. Konfigurasi ini berguna dalam situasi di mana Anda memiliki deployment regional jaringan aplikasi. Anda dapat mendaftarkan setiap deployment regional ke instance regional Direktori Layanan, sebagai layanan regional 1 dan layanan regional 2. Setiap layanan Direktori Layanan regional ini kemudian dapat yang terkait dengan layanan backend yang sama, menggunakan dua binding layanan. Global pengikatan layanan 1 akan dikaitkan dengan layanan regional 1 di wilayah A dan pengikatan layanan global 2 akan dikaitkan dengan layanan regional 2 di region B.

Kasus penggunaan

Mengintegrasikan deployment Cloud Service Mesh dengan Direktori Layanan memungkinkan kasus penggunaan baru yang membantu saat Anda bergantung pada layanan yang dimiliki atau dipublikasikan oleh tim atau organisasi.

Menjadikan layanan yang ada tersedia untuk Cloud Service Mesh

Direktori Layanan terintegrasi dengan produk Google Cloud seperti GKE, Load Balancer Jaringan passthrough internal, dan Load Balancer Aplikasi internal. Saat produsen layanan membuat layanan GKE atau load balancer, mereka dapat mendaftarkannya di Direktori Layanan.

Setelah layanan didaftarkan ke Direktori Layanan, Anda dapat mengonfigurasi Cloud Service Mesh untuk berkomunikasi dengan layanan tersebut. Mesh Layanan Cloud klien dapat berkomunikasi dengan layanan yang berjalan di belakang Load Balancer Jaringan passthrough internal dan Load Balancer Aplikasi internal.

Meningkatkan koordinasi antara produsen layanan dan konsumen

Perusahaan besar memiliki banyak tim developer independen. Tim-tim ini menjadikan layanan yang tersedia untuk tim lain sehingga lebih banyak tim yang dapat menggunakan kemampuan yang disediakan oleh layanan bersama. Hal ini menciptakan ketergantungan lintas tim. Meskipun dependensi ini memungkinkan tim untuk berbagi upaya mereka, dependensi juga menciptakan overhead koordinasi.

Saat Anda menggunakan Direktori Layanan, satu tim (produser) mendaftarkan layanan yang ingin disediakan untuk tim lain atau organisasi (konsumen). Produser membagikan referensi ke layanan ini dengan konsumen. Konsumen dapat menggunakan referensi ini untuk mencari layanan di Direktori Layanan dan menemukan endpoint. Misalnya, endpoint mungkin berupa alamat IP virtual (VIP) di yang diharapkan oleh layanan produsen untuk menerima lalu lintas.

Integrasi Cloud Service Mesh dengan Direktori Layanan memungkinkan Anda mengotomatiskan proses dengan mengikat layanan Direktori Layanan ke sebuah Layanan backend Cloud Service Mesh, yang memiliki keuntungan berikut:

  • Cloud Service Mesh secara otomatis me-resolve endpoint layanan dengan menyinkronkannya dari Direktori Layanan. Jika Endpoint layanan Direktori Layanan diperbarui, Cloud Service Mesh menyinkronkan perubahan ini secara otomatis.
  • Anda dapat menetapkan berbagai kebijakan pemilihan rute dan pengelolaan traffic, seperti untuk waktu tunggu, di Cloud Service Mesh. Kebijakan ini memungkinkan Anda mengatur aplikasi mengeluarkan permintaan ke layanan Direktori Layanan. Sebagai informasi tentang pemilihan rute dan pengelolaan traffic di Cloud Service Mesh, lihat Pengelolaan traffic lanjutan.
  • Cloud Service Mesh menggunakan kemampuan pengelolaan traffic seperti load balancing berbasis kedekatan untuk mengarahkan traffic secara optimal dari aplikasi ke endpoint—misalnya, dengan meminimalkan waktu round-trip.
Menggunakan Direktori Layanan untuk penemuan layanan.
Menggunakan Direktori Layanan untuk penemuan layanan (klik untuk memperbesar)

Saat Anda, sebagai konsumen, menggunakan Cloud Service Mesh dan melampirkan layanan backend ke layanan Direktori Layanan, overhead koordinasi lintas tim berkurang.

  • Anda melampirkan layanan, Payments, berdasarkan nama.

  • Cloud Service Mesh membagikan informasi tentang layanan Payments ke dengan klien besar.

    • Misalnya, proxy file bantuan yang berjalan di mesh layanan Anda sekarang ketahui endpoint (misalnya 10.0.0.1:80) tempat layanan yang dapat dicapai.

  • Aplikasi Anda dapat memanggil layanan ini berdasarkan nama tanpa Anda atau aplikasi Anda perlu mengetahui apa pun tentang metode layanan eksternal endpoint. Dalam diagram, layanannya adalah layanan Payments.

  • Saat produsen layanan mengupdate layanan eksternal (misalnya, mengubah endpoint-nya), Cloud Service Mesh mengambil update dan membagikannya kepada kliennya.

Mengakses layanan di dalam perimeter menggunakan titik masuk

Tim mungkin mengelompokkan sekumpulan layanan dalam Kontrol Layanan VPC perimeter dan mengekspos layanan tersebut melalui satu titik masuk. Ini titik masuk dapat didaftarkan ke Direktori Layanan dan dibuat yang tersedia untuk pengguna yang ingin mengakses layanan dalam perimeter. Sebagai informasi selengkapnya tentang perimeter Kontrol Layanan VPC, lihat Layanan detail dan konfigurasi perimeter.

Misalnya, tim membuat gateway masuk dengan menggunakan Load Balancer Aplikasi internal yang mendistribusikan permintaan ke kumpulan layanan Kubernetes dalam sebuah cluster. Ini {i>ingress gateway<i} secara otomatis didaftarkan sebagai layanan untuk Direktori Layanan. Konsumen yang ingin mengakses Kubernetes layanan Google Cloud dapat mencari gateway masuk ini di Direktori Layanan. Konsumen kemudian dapat mengonfigurasi mesh Cloud Service Mesh untuk mengakses layanan di dalam perimeter melalui gateway.

Menghubungkan layanan di seluruh domain

Anda mungkin memiliki layanan di domain berbeda yang perlu dihubungkan.

Menghubungkan layanan di seluruh organisasi

Anda mungkin menginginkan akses ke layanan yang dimiliki oleh organisasi lain, seperti Google API (misalnya, Cloud SQL) atau layanan terkelola pihak ketiga.

Direktori Layanan mendukung Private Service Connect. Saat Anda membuat endpoint Private Service Connect di jaringan, endpoint dapat didaftarkan sebagai layanan dengan Direktori Layanan. Anda kemudian dapat melampirkan layanan ini ke Cloud Service Mesh, agar klien mesh, seperti klien Envoy dan gRPC, serta gateway yang dikelola sendiri, seperti Apigee, dapat memanggil layanan ini.

Menggunakan Direktori Layanan untuk penemuan layanan dengan Private Service Connect.
Menggunakan Direktori Layanan untuk penemuan layanan dengan Private Service Connect (klik untuk memperbesar)

Contoh sebelumnya, dengan menggunakan Cloud Storage, menggambarkan bagaimana Anda dapat menggunakan Private Service Connect untuk memanggil Google API menggunakan endpoint di ke jaringan Virtual Private Cloud Anda.

Menghubungkan layanan di seluruh jaringan VPC

Beberapa perusahaan menggunakan beberapa jaringan VPC sebagai bagian dari Deployment Google Cloud. Dalam kasus tersebut, layanan di satu Jaringan VPC mungkin perlu mengakses layanan dalam Jaringan VPC. Anda dapat mengonfigurasi peering VPC untuk mengakses layanan di jaringan VPC yang berbeda, tapi akan menimbulkan masalah ketika ada alamat IP yang tumpang tindih yang berbeda di antara jaringan yang di-peering.

Private Service Connect dapat membuat layanan secara aman dan pribadi di satu jaringan VPC yang dapat diakses oleh layanan di jaringan lain Jaringan VPC, menggunakan endpoint IP:port tunggal.

Tampilan mendetail tentang penggunaan Direktori Layanan untuk penemuan layanan dengan Private Service Connect.
Tampilan mendetail tentang penggunaan Direktori Layanan untuk penemuan layanan dengan Private Service Connect (klik untuk memperbesar)

Contoh tambahan di seluruh domain

Dua contoh sebelumnya menggambarkan kasus di mana Anda mungkin perlu domain, tetapi ada banyak contoh tambahan. Misalnya, Anda membuat yang berada di persimpangan dua region Google Cloud. Layanan di satu region dapat menjangkau layanan di region lain melalui gateway ini. Anda mendaftarkan gateway sebagai layanan di Direktori Layanan, lalu gunakan gateway dengan Cloud Service Mesh seperti yang dijelaskan dalam dokumen ini.

Menerapkan kebijakan saat layanan diakses

Cloud Service Mesh mendukung kemampuan seperti pengelolaan traffic lanjutan yang dapat dikonfigurasi menggunakan kebijakan. Misalnya, Anda dapat menyetel pencerminan traffic sehingga setiap kali klien mengirim permintaan ke layanan backend tertentu, lalu lintas juga dikirim ke layanan backend kedua.

Saat Anda mengikat layanan Direktori Layanan ke Cloud Service Mesh layanan backend, Anda dapat mengonfigurasi jenis kebijakan ini di Cloud Service Mesh. Proxy file bantuan, proxy tengah atau edge, serta klien tanpa proxy akan mempelajari kebijakan ini dan menegakkannya.

Beberapa contohnya:

  • Pemisahan traffic berdasarkan bobot—misalnya, antara dua Layanan Direktori Layanan
  • Pencerminan traffic—misalnya, ke layanan audit
Permintaan untuk layanan `users` diduplikasi ke layanan `audit`
Permintaan untuk layanan users dicerminkan ke layanan audit (klik untuk memperbesar)

Dukungan untuk Cloud Service Mesh dan klien yang sudah ada

Bahkan ketika Cloud Service Mesh di-deploy di organisasi Anda, Anda mungkin memiliki klien yang tidak menggunakan Cloud Service Mesh. Misalnya, Anda mungkin perlu mengakses layanan dari mesin virtual yang bukan bagian dari mesh layanan.

Saat Anda mengikat layanan Direktori Layanan ke Cloud Service Mesh layanan backend, klien Cloud Service Mesh otomatis mendapatkan informasi tentang layanan tersebut. Klien Anda yang tidak menggunakan Cloud Service Mesh dapat mencari dan menggunakan informasi layanan di Direktori Layanan.

Batasan

Cloud Service Mesh tidak mendukung NEG FQDN (INTERNET_FQDN_PORT NEG) di Integrasi Direktori Layanan.

Langkah selanjutnya