Dari edge ke mesh multi-cluster: Aplikasi yang didistribusikan secara global yang diekspos melalui GKE Gateway dan Cloud Service Mesh

Last reviewed 2024-06-30 UTC

Arsitektur referensi ini menjelaskan manfaat mengekspos aplikasi secara eksternal melalui Gateway Google Kubernetes Engine (GKE) yang berjalan di beberapa cluster GKE dalam mesh layanan. Panduan ini ditujukan bagi administrator platform.

Anda dapat meningkatkan ketahanan dan redundansi layanan dengan men-deploy aplikasi secara konsisten di beberapa cluster GKE, di mana setiap cluster menjadi domain kegagalan tambahan. Misalnya, infrastruktur komputasi layanan dengan tujuan tingkat layanan (SLO) sebesar 99,9% saat di-deploy di satu cluster GKE mencapai SLO sebesar 99,9999% saat di-deploy di dua cluster GKE (1 - (0,001)2). Anda juga dapat memberikan pengalaman kepada pengguna di mana permintaan masuk secara otomatis diarahkan ke gateway ingress mesh yang memiliki latensi paling rendah dan tersedia.

Jika Anda tertarik dengan manfaat mengekspos aplikasi yang kompatibel dengan service mesh yang berjalan di satu cluster, lihat Dari edge ke mesh: Mengekspos aplikasi service mesh melalui Gateway GKE.

Arsitektur

Diagram arsitektur berikut menunjukkan cara data mengalir melalui traffic masuk cloud dan traffic masuk mesh:

Enkripsi TLS dari klien, load balancer, dan dari mesh.

Diagram sebelumnya menunjukkan skenario alur data berikut:

  • Dari klien yang dihentikan di load balancer menggunakan sertifikat TLS yang dikelola Google miliknya sendiri. Google Cloud
  • Dari load balancer Google Cloud ke proxy ingress mesh menggunakan sertifikat TLS yang ditandatangani sendiri.
  • Dari proxy gateway masuk mesh ke proxy sidecar beban kerja menggunakan mTLS yang kompatibel dengan mesh layanan.

Arsitektur referensi ini berisi dua lapisan ingress berikut:

  • Cloud ingress: dalam arsitektur referensi ini, Anda menggunakan Kubernetes Gateway API (dan pengontrol Gateway GKE) untuk memprogram lapisan load balancing HTTP(S) multi-cluster eksternal. Load balancer memeriksa proxy traffic masuk mesh di beberapa region, mengirim permintaan ke cluster responsif terdekat. Load balancer ini juga menerapkan kebijakan keamanan Google Cloud Armor.
  • Traffic masuk mesh: Dalam mesh, Anda menjalankan health check secara langsung pada backend agar dapat menjalankan load balancing dan pengelolaan traffic secara lokal.

Saat Anda menggunakan lapisan traffic masuk bersama-sama, ada peran pelengkap untuk setiap lapisan. Untuk mencapai sasaran berikut, Google Cloud mengoptimalkan fitur yang paling sesuai dari lapisan ingress cloud dan lapisan ingress mesh:

  • Menyediakan latensi rendah.
  • Meningkatkan ketersediaan.
  • Gunakan fitur keamanan lapisan ingress cloud.
  • Gunakan fitur keamanan, otorisasi, dan kemampuan observasi lapisan ingress mesh.

Traffic masuk cloud

Jika dipasangkan dengan traffic masuk mesh, lapisan traffic masuk cloud paling baik digunakan untuk keamanan edge dan load balancing global. Karena lapisan traffic masuk cloud terintegrasi dengan layanan berikut, lapisan ini unggul dalam menjalankan layanan tersebut di edge, di luar mesh:

  • Perlindungan DDoS
  • Firewall cloud
  • Autentikasi dan otorisasi
  • Enkripsi

Logika perutean biasanya mudah di lapisan masuk cloud. Namun, hal ini bisa lebih kompleks untuk lingkungan multi-cluster dan multi-region.

Karena fungsi penting load balancer yang terhubung ke internet, lapisan traffic masuk cloud kemungkinan akan dikelola oleh tim platform yang memiliki kontrol eksklusif atas cara aplikasi diekspos dan diamankan di internet. Kontrol ini membuat lapisan ini kurang fleksibel dan dinamis dibandingkan infrastruktur berbasis developer. Pertimbangkan faktor-faktor ini saat menentukan hak akses administratif ke lapisan ini dan cara Anda memberikan akses tersebut.

Traffic masuk mesh

Jika dipasangkan dengan traffic masuk cloud, lapisan traffic masuk mesh menyediakan titik entri bagi traffic untuk memasuki mesh layanan. Lapisan ini juga menyediakan mTLS backend, kebijakan otorisasi, dan pencocokan regex yang fleksibel.

Men-deploy load balancing aplikasi eksternal di luar mesh dengan lapisan traffic masuk mesh menawarkan keuntungan yang signifikan, terutama untuk pengelolaan traffic internet. Meskipun service mesh dan gateway traffic masuk Istio menyediakan perutean dan pengelolaan traffic tingkat lanjut di mesh, beberapa fungsi ditayangkan dengan lebih baik di edge network. Memanfaatkan jaringan internet-edge melalui Load Balancer Aplikasi eksternalGoogle Clouddapat memberikan performa, keandalan, atau manfaat terkait keamanan yang signifikan dibandingkan traffic masuk berbasis mesh.

Produk dan fitur yang digunakan

Daftar berikut merangkum semua produk dan fitur Google Cloud yang digunakan oleh arsitektur referensi ini:

  • GKE Enterprise: Layanan Kubernetes terkelola yang dapat Anda gunakan untuk men-deploy dan mengoperasikan aplikasi dalam container dalam skala besar menggunakan infrastruktur Google. Untuk tujuan arsitektur referensi ini, setiap cluster GKE yang melayani aplikasi harus berada dalam fleet yang sama.
  • Fleet dan Gateway multi-cluster: Layanan yang digunakan untuk membuat aplikasi dalam container dalam skala perusahaan menggunakan infrastruktur Google dan GKE Enterprise.
  • Google Cloud Armor: Layanan yang membantu Anda melindungi aplikasi dan situs Anda dari denial of service dan serangan web.
  • Cloud Service Mesh: Mesh layanan yang terkelola sepenuhnya berdasarkan Envoy dan Istio
  • Load Balancer Aplikasi: Load balancer L7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan.
  • Certificate Manager: Layanan yang memungkinkan Anda memperoleh dan mengelola sertifikat TLS untuk digunakan dengan Cloud Load Balancing.

Fleet

Untuk mengelola deployment multi-cluster, GKE Enterprise dan Google Cloud menggunakan fleet untuk mengelompokkan dan menormalisasi cluster Kubernetes secara logis.

Menggunakan satu atau beberapa fleet dapat membantu Anda meningkatkan pengelolaan dari tiap-tiap cluster ke seluruh grup cluster. Untuk mengurangi gesekan pengelolaan cluster, gunakan prinsip kesamaan namespace fleet. Untuk setiap cluster GKE dalam kumpulan, pastikan Anda mengonfigurasi semua gateway ingress mesh dengan cara yang sama.

Selain itu, deploy layanan aplikasi secara konsisten sehingga pembaca saldo layanan di akun namespace terkait dengan layanan yang identik di setiap cluster GKE dalam fleet. Prinsip kesamaan dan kepercayaan yang diasumsikan dalam fleet adalah hal yang memungkinkan Anda menggunakan berbagai fitur berkemampuan fleet di GKE Enterprise dan Google Cloud.

Aturan perutean timur-barat dalam mesh layanan dan kebijakan traffic ditangani di lapisan traffic masuk mesh. Lapisan ingress mesh di-deploy di setiap cluster GKE dalam fleet. Konfigurasi setiap gateway ingress mesh dengan cara yang sama, dengan mematuhi prinsip kesamaan namespace fleet.

Meskipun hanya ada satu cluster konfigurasi untuk GKE Gateway, Anda harus menyinkronkan konfigurasi GKE Gateway di semua cluster GKE dalam fleet.

Jika Anda perlu menunjuk cluster konfigurasi baru, gunakan ConfigSync. ConfigSync membantu memastikan bahwa semua konfigurasi tersebut disinkronkan di semua cluster GKE dalam fleet dan membantu menghindari rekonsiliasi dengan konfigurasi yang tidak berlaku.

Gateway traffic masuk mesh

Istio 0.8 memperkenalkan gateway traffic masuk mesh. Gateway menyediakan serangkaian proxy khusus yang port-nya diekspos agar traffic muncul dari luar mesh layanan. Proxy traffic masuk mesh ini memungkinkan Anda mengontrol perilaku eksposur jaringan secara terpisah dari perilaku perutean aplikasi.

Proxy juga memungkinkan Anda menggunakan perutean dan kebijakan ke traffic eksternal mesh sebelum sampai pada sidecar aplikasi. Traffic masuk mesh menentukan perlakuan traffic saat mencapai node di mesh, tetapi komponen eksternal harus menentukan cara traffic pertama kali muncul di mesh.

Untuk mengelola traffic eksternal, Anda memerlukan load balancer yang berada di luar mesh. Untuk mengotomatiskan deployment, arsitektur referensi ini menggunakan Cloud Load Balancing, yang disediakan melalui resource Gateway GKE.

GKE Gateway dan layanan multi-cluster

Ada banyak cara untuk memberikan akses aplikasi kepada klien yang berada di luar cluster. GKE Gateway adalah implementasi dari Kubernetes Gateway API. GKE Gateway mengembangkan dan meningkatkan kualitas resource Ingress.

Saat Anda men-deploy resource GKE Gateway ke cluster GKE, pengontrol Gateway akan memantau resource Gateway API. Pengontrol merekonsiliasi resource Cloud Load Balancing untuk menerapkan perilaku jaringan yang ditentukan oleh resource Gateway.

Saat menggunakan Gateway GKE, jenis load balancer yang Anda gunakan untuk mengekspos aplikasi ke klien sangat bergantung pada faktor-faktor berikut:

  • Apakah layanan backend berada dalam satu cluster GKE atau didistribusikan di beberapa cluster GKE (dalam fleet yang sama).
  • Status klien (eksternal atau internal).
  • Kemampuan load balancer yang diperlukan, termasuk kemampuan untuk berintegrasi dengan kebijakan keamanan Cloud Armor.
  • Persyaratan rentang mesh layanan. Service mesh dapat mencakup beberapa cluster GKE atau dapat dimuat dalam satu cluster.

Di Gateway, perilaku ini dikontrol dengan menentukan GatewayClass yang sesuai. Saat merujuk ke class Gateway, class yang dapat digunakan dalam skenario multi-cluster memiliki nama class yang berakhiran -mc.

Arsitektur referensi ini membahas cara mengekspos layanan aplikasi secara eksternal melalui Load Balancer Aplikasi eksternal. Namun, saat menggunakan Gateway, Anda juga dapat membuat Load Balancer Aplikasi internal regional multi-cluster.

Untuk men-deploy layanan aplikasi dalam skenario multi-cluster, Anda dapat menentukan komponen load balancerGoogle Cloud dengan dua cara berikut:

Untuk mengetahui informasi selengkapnya tentang dua pendekatan ini untuk men-deploy layanan aplikasi, lihat Memilih API load balancing multi-cluster Anda untuk GKE.

Multi Cluster Ingress mengandalkan pembuatan resource MultiClusterService. Gateway multi-cluster mengandalkan pembuatan resource ServiceExport dan merujuk ke resource ServiceImport.

Saat menggunakan Gateway multi-cluster, Anda dapat mengaktifkan kemampuan tambahan load balancer Google Cloud yang mendasarinya dengan membuat Kebijakan. Panduan deployment yang terkait dengan arsitektur referensi ini menunjukkan cara mengonfigurasi kebijakan keamanan Google Cloud Armor untuk membantu melindungi layanan backend dari cross-site scripting.

Resource kebijakan ini menargetkan layanan backend dalam fleet yang diekspos di beberapa cluster. Dalam skenario multi-cluster, semua kebijakan tersebut harus mereferensikan resource dan grup API ServiceImport.

Health check

Salah satu kompleksitas penggunaan dua lapisan load balancing L7 adalah health check. Anda harus mengonfigurasi setiap load balancer untuk memeriksa kondisi lapisan berikutnya. GKE Gateway memeriksa kondisi proxy traffic masuk mesh, dan mesh, sebagai gantinya, memeriksa kondisi backend aplikasi.

  • Traffic masuk cloud: Dalam arsitektur referensi ini, Anda akan mengonfigurasi load balancerGoogle Cloud melalui GKE Gateway untuk memeriksa kondisi proxy traffic masuk mesh pada port health check yang terekspos. Jika proxy mesh tidak aktif, atau jika cluster, mesh, atau region tidak tersedia, load balancer Google Cloud mendeteksi kondisi ini dan tidak mengirim traffic ke proxy mesh. Dalam hal ini, traffic akan dirutekan ke proxy mesh alternatif di cluster atau region GKE yang berbeda.
  • Traffic masuk mesh: Dalam aplikasi mesh, Anda menjalankan health check secara langsung pada backend agar dapat menjalankan load balancing dan pengelolaan traffic secara lokal.

Pertimbangan desain

Bagian ini memberikan panduan untuk membantu Anda menggunakan arsitektur referensi ini guna mengembangkan arsitektur yang memenuhi persyaratan spesifik Anda dalam hal keamanan dan kepatuhan, keandalan, dan biaya.

Keamanan, privasi, dan kepatuhan

Diagram arsitektur dalam dokumen ini berisi beberapa elemen keamanan. Elemen yang paling penting adalah cara Anda mengonfigurasi enkripsi dan men-deploy sertifikat. Gateway GKE terintegrasi dengan Certificate Manager untuk tujuan keamanan ini.

Klien internet melakukan autentikasi terhadap sertifikat publik dan terhubung ke load balancer eksternal sebagai hop pertama di Virtual Private Cloud (VPC). Anda dapat merujuk ke CertificateMap Certificate Manager dalam definisi Gateway. Hop berikutnya berada di antara Google Front End (GFE) dan proxy traffic masuk mesh. Hop tersebut dienkripsi secara default.

Enkripsi tingkat network antara GFE dan backend-nya diterapkan secara otomatis. Jika persyaratan keamanan Anda menentukan bahwa pemilik platform mempertahankan kepemilikan kunci enkripsi, Anda dapat mengaktifkan HTTP/2 dengan enkripsi TLS antara gateway cluster (GFE) dan traffic masuk mesh (proxy envoy).

Saat mengaktifkan HTTP/2 dengan enkripsi TLS antara gateway cluster dan ingress mesh, Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat publik untuk mengenkripsi traffic. Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat publik karena GFE tidak melakukan autentikasi terhadapnya. Lapisan enkripsi tambahan ini ditunjukkan dalam panduan deployment yang terkait dengan arsitektur referensi ini.

Untuk membantu mencegah kesalahan penanganan sertifikat, jangan gunakan kembali sertifikat publik. Gunakan sertifikat terpisah untuk setiap load balancer di mesh layanan.

Untuk membantu membuat entri DNS eksternal dan sertifikat TLS, panduan deployment untuk arsitektur referensi ini menggunakan Cloud Endpoints. Dengan Cloud Endpoints, Anda dapat membuat subdomain yang tersedia secara eksternal.cloud.goog Dalam skenario tingkat perusahaan, gunakan nama domain yang lebih sesuai, dan buat data A yang mengarah ke alamat IP Application Load Balancer global di penyedia layanan DNS Anda.

Jika mesh layanan yang Anda gunakan mewajibkan TLS, semua traffic antara proxy sidecar dan semua traffic ke traffic masuk mesh akan dienkripsi. Diagram arsitektur menunjukkan enkripsi HTTPS dari klien ke Google Cloud load balancer, dari load balancer ke proxy traffic masuk mesh, dan dari proxy traffic masuk ke proxy sidecar.

Keandalan dan ketahanan

Keunggulan utama pola edge-to-mesh multi-cluster dan multi-regional adalah pola ini dapat menggunakan semua fitur mesh layanan untuk load balancing east-west, seperti traffic antar-layanan aplikasi.

Arsitektur referensi ini menggunakan Gateway GKE multi-cluster untuk merutekan traffic masuk cloud-ingress ke cluster GKE. Sistem memilih cluster GKE berdasarkan kedekatannya dengan pengguna (berdasarkan latensi), serta ketersediaan dan kondisinya. Saat traffic mencapai gateway masuk Istio (traffic masuk mesh), traffic tersebut dirutekan ke backend yang sesuai melalui mesh layanan.

Pendekatan alternatif untuk menangani traffic east-west adalah melalui layanan multi-cluster untuk semua layanan aplikasi yang di-deploy di seluruh cluster GKE. Saat menggunakan layanan multi-cluster di seluruh cluster GKE dalam fleet, endpoint layanan dikumpulkan bersama dalam ClusterSet. Jika perlu memanggil layanan lain, layanan dapat menargetkan endpoint yang berfungsi baik untuk layanan kedua. Karena endpoint dipilih secara bergilir, endpoint yang dipilih dapat berada di zona atau region yang berbeda.

Keunggulan utama menggunakan mesh layanan untuk traffic east-west daripada menggunakan layanan multi-cluster adalah mesh layanan dapat menggunakan load balancing lokalitas. Load balancing lokalitas bukan fitur layanan multi-cluster, tetapi Anda dapat mengonfigurasinya melalui DestinationRule.

Setelah dikonfigurasi, panggilan dari satu layanan ke layanan lain akan mencoba menjangkau endpoint layanan di zona yang sama terlebih dahulu, lalu mencoba di region yang sama dengan layanan yang memanggil. Terakhir, panggilan hanya menargetkan endpoint di region lain jika endpoint layanan di zona yang sama atau region yang sama tidak tersedia.

Pengoptimalan biaya

Saat mengadopsi arsitektur multi-cluster ini secara luas di seluruh perusahaan, Cloud Service Mesh dan Gateway multi-cluster disertakan dalam edisi Google Kubernetes Engine (GKE) Enterprise. Selain itu, GKE Enterprise mencakup banyak fitur yang memungkinkan Anda mengelola dan mengatur cluster GKE, aplikasi, dan proses lainnya dalam skala besar.

Deployment

Untuk men-deploy arsitektur ini, lihat Dari edge ke mesh multi-cluster: Men-deploy aplikasi yang didistribusikan secara global melalui GKE Gateway dan Cloud Service Mesh.

Langkah berikutnya

Kontributor

Penulis:

Kontributor lainnya: