Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui GKE Gateway

Last reviewed 2023-10-24 UTC

Referensi arsitektur ini menunjukkan cara menggabungkan Cloud Service Mesh dengan Cloud Load Balancing untuk mengekspos aplikasi dalam mesh layanan ke klien internet.

Cloud Service Mesh adalah mesh layanan terkelola, yang didasarkan pada Istio, yang menyediakan lapisan komunikasi yang ditingkatkan keamanannya, dapat diamati, dan terstandar untuk aplikasi. Mesh layanan menyediakan platform komunikasi menyeluruh untuk klien yang berkomunikasi di mesh. Namun, tantangan tetap ada terkait petunjuk menghubungkan klien yang berada di luar mesh ke aplikasi yang dihosting di dalam mesh.

Anda dapat mengekspos aplikasi kepada klien dengan berbagai cara, bergantung pada lokasi klien. Referensi arsitektur ini ditujukan untuk praktisi tingkat lanjut yang menjalankan Cloud Service Mesh, tetapi juga dapat digunakan untuk Istio di Google Kubernetes Engine (GKE).

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 menerapkan 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 ini, Anda memerlukan load balancer yang berada di luar mesh. Referensi arsitektur ini menggunakan Google Cloud Load Balancing yang disediakan melalui resource GKE Gateway untuk mengotomatiskan deployment.

Untuk Google Cloud, contoh kanonis dari penyiapan ini adalah layanan load balancing eksternal yang men-deploy load balancer jaringan publik (L4). Load balancer tersebut mengarah kepada NodePorts klaster GKE. NodePort ini mengekspos Pod gateway traffic masuk Istio, yang mengarahkan traffic ke proxy sidecar mesh downstream.

Arsitektur

Diagram berikut mengilustrasikan topologi ini. Load balancing untuk traffic pribadi internal terlihat mirip dengan arsitektur ini, kecuali Anda men-deploy Network Load Balancer passthrough internal sebagai gantinya.

Load balancer eksternal mengarahkan klien eksternal ke mesh melalui proxy gateway traffic masuk.

Diagram sebelumnya menunjukkan bahwa penggunaan load balancing transparan L4 dengan gateway traffic masuk mesh menawarkan keuntungan berikut:

  • Penyiapan ini menyederhanakan penerapan load balancer.
  • Load balancer menyediakan alamat IP virtual (VIP), health check,dan distribusi traffic yang andal saat terjadi perubahan cluster, gangguan node, atau terjadi gangguan proses.
  • Seluruh aturan perutean, penghentian TLS, dan kebijakan traffic ditangani di satu lokasi di gateway traffic masuk mesh.

GKE Gateway dan Layanan

Anda dapat memberikan akses ke aplikasi untuk klien yang berada di luar klaster dengan berbagai cara. GKE Gateway adalah implementasi Kubernetes Gateway API. GKE Gateway mengembangkan resource Ingress dan meningkatkannya.

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

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

  • Status klien (eksternal atau internal).
  • Kemampuan load balancer yang diperlukan, termasuk kemampuan untuk berintegrasi dengan kebijakan keamanan Google Cloud Armor.
  • Persyaratan cakupan mesh layanan. Mesh layanan dapat mencakup beberapa cluster GKE atau dapat ditempatkan dalam satu cluster.

Di GKE Gateway, perilaku ini dikontrol dengan menentukan GatewayClass yang sesuai.

Meskipun load balancer default untuk Cloud Service Mesh adalah Network Load Balancer, referensi arsitektur ini berfokus pada Load Balancer Aplikasi (L7) eksternal. Load Balancer Aplikasi eksternal menyediakan integrasi dengan layanan edge seperti Identity-Aware Proxy dan Google Cloud Armor, pengalihan dan penulisan ulang URL, serta jaringan proxy edge yang didistribusikan secara global. Bagian berikutnya menjelaskan arsitektur dan keuntungan penggunaan load balancing HTTP dua lapisan.

Traffic masuk cloud dan mesh

Men-deploy load balancing L7 eksternal di luar mesh bersama dengan lapisan traffic masuk mesh menawarkan keuntungan yang signifikan, terutama untuk traffic internet. Meskipun gateway traffic masuk Cloud Service Mesh dan Istio menyediakan perutean dan pengelolaan traffic tingkat lanjut di mesh, beberapa fungsi ditayangkan dengan lebih baik di edge network. Memanfaatkan network internet-edge melalui Load Balancer Aplikasi eksternal Google Cloud dapat memberikan performa, keandalan, atau manfaat terkait keamanan yang signifikan dibandingkan traffic masuk berbasis mesh. Manfaat tersebut mencakup:

Lapisan eksternal load balancing L7 ini disebut sebagai traffic masuk cloud karena lapisan ini dibuat di load balancer yang dikelola cloud, bukan proxy yang dihosting sendiri dan digunakan oleh traffic masuk mesh. Kombinasi traffic masuk cloud dan mesh menggunakan kemampuan pelengkap infrastruktur Google Cloud dan mesh. Diagram berikut mengilustrasikan cara menggabungkan traffic masuk cloud (melalui gateway GKE) dan traffic masuk mesh agar berfungsi sebagai dua lapisan load balancing untuk traffic internet.

Traffic masuk cloud berfungsi sebagai gateway untuk traffic eksternal ke mesh melalui network VPC.

Dalam topologi diagram sebelumnya, lapisan traffic masuk cloud mengambil traffic dari luar mesh layanan dan mengarahkan traffic tersebut ke lapisan traffic masuk mesh. Lapisan traffic masuk mesh kemudian mengarahkan traffic ke backend aplikasi yang dihosting mesh.

Topologi traffic masuk cloud dan mesh

Section ini menjelaskan peran pelengkap yang dipenuhi oleh setiap lapisan traffic masuk saat Anda menggunakannya bersama-sama. Peran-peran tersebut bukan aturan yang konkret, melainkan pedoman yang memanfaatkan keuntungan dari setiap lapisan. Pola ini kemungkinan akan bervariasi, bergantung pada kasus penggunaan Anda.

  • Cloud traffic masuk: 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 produk perlindungan DDoS, firewall cloud, autentikasi, dan enkripsi di edge, lapisan ini unggul dalam menjalankan layanan tersebut di luar mesh. Logika perutean biasanya mudah pada lapisan ini, tetapi logikanya 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 infrastruktur yang memiliki kontrol eksklusif atas cara aplikasi diekspos dan diamankan di internet. Kontrol ini juga membuat lapisan ini kurang fleksibel dan dinamis dibandingkan infrastruktur berbasis developer, sebuah pertimbangan yang dapat memengaruhi siapa dan bagaimana Anda menyediakan akses administratif ke lapisan ini.
  • Traffic masuk mesh: Jika dipasangkan dengan traffic masuk cloud, lapisan traffic masuk mesh menyediakan perutean fleksibel yang dekat dengan aplikasi. Karena fleksibilitas ini, traffic masuk mesh lebih baik dibanding traffic masuk cloud untuk logika perutean yang kompleks dan visibilitas tingkat aplikasi. Pemisahan antara lapisan traffic masuk juga memudahkan pemilik aplikasi untuk mengontrol lapisan ini secara langsung tanpa memengaruhi tim lain. Untuk membantu mengamankan aplikasi Saat Anda mengekspos aplikasi mesh layanan melalui load balancer L4, bukan load balancer L7, Anda harus menghentikan klien TLS di lapisan traffic masuk mesh ke dalam mesh.

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 guna memastikan bahwa lapisan berikutnya dapat menerima traffic. Topologi dalam diagram berikut menunjukkan cara traffic masuk cloud memeriksa kondisi proxy traffic masuk mesh, dan mesh, sebagai gantinya, memeriksa kondisi backend aplikasi.

Traffic masuk cloud memeriksa kondisi traffic masuk mesh, dan traffic masuk mesh akan memeriksa kondisi backend aplikasi.

Topologi sebelumnya memiliki pertimbangan berikut:

  • Traffic masuk cloud: Dalam referensi arsitektur ini, Anda akan mengonfigurasi load balancer Google Cloud melalui 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.
  • Traffic masuk mesh: Dalam aplikasi mesh, Anda menjalankan health check secara langsung pada backend agar dapat menyetujui load balancing dan pengelolaan traffic secara lokal.

Keamanan

Topologi sebelumnya juga melibatkan beberapa elemen keamanan. Salah satu elemen yang paling penting adalah cara Anda mengonfigurasi enkripsi dan men-deploy sertifikat. GKE Gateway terintegrasi dengan sertifikat yang dikelola Google. Anda dapat merujuk ke CertificateMap Certificate Manager dalam definisi Gateway. Klien internet melakukan autentikasi terhadap sertifikat publik dan terhubung ke load balancer eksternal sebagai hop pertama di Virtual Private Cloud (VPC).

Hop berikutnya, yang berada di antara Google Front End (GFE) dan proxy traffic masuk mesh, dienkripsi secara default. Enkripsi tingkat network antara GFE dan backend-nya diterapkan secara otomatis. Namun, jika persyaratan keamanan Anda menentukan bahwa pemilik platform mempertahankan kepemilikan kunci enkripsi, selanjutnya 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 untuk jalur ini, Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat publik untuk mengenkripsi traffic karena GFE tidak melakukan autentikasi terhadapnya. Lapisan enkripsi tambahan ini ditunjukkan di bagian yang terkait dengan panduan deployment. Untuk membantu mencegah kesalahan penanganan sertifikat, jangan gunakan sertifikat publik untuk load balancer publik di tempat lain. Sebagai gantinya, kami merekomendasikan Anda menggunakan sertifikat terpisah di mesh layanan.

Jika mesh layanan mewajibkan TLS, semua traffic dienkripsi antara proxy sidecar dan ke traffic masuk mesh. Diagram berikut mengilustrasikan enkripsi HTTPS dari klien ke load balancer Google Cloud, dari load balancer ke proxy traffic masuk mesh, dan dari proxy traffic masuk ke proxy sidecar.

Keamanan diimplementasikan menggunakan sertifikat terkelola di luar mesh dan sertifikat internal di dalam mesh.

Pengoptimalan biaya

Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:

Deployment

Untuk men-deploy arsitektur ini, lihat Dari edge ke mesh: Men-deploy aplikasi mesh layanan melalui GKE Gateway.

Langkah selanjutnya