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

Last reviewed 2023-10-24 UTC

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

Anthos Service Mesh adalah sebuah mesh layanan terkelola, yang didasarkan pada Istio, yang menyediakan lapisan keamanan yang ditingkatkan, dapat diamati, dan terstandar untuk aplikasi. Mesh layanan menyediakan platform komunikasi holistik untuk klien yang berkomunikasi dalam 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 Anthos Service Mesh, tetapi juga dapat digunakan untuk Istio pada 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 masuk mesh ini memungkinkan Anda mengontrol perilaku eksposur jaringan secara terpisah dari perilaku pemilihan rute aplikasi.

Proxy juga memungkinkan Anda menerapkan pemilihan rute dan kebijakan ke traffic eksternal mesh sebelum sampai di bantuan 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. Arsitektur referensi ini menggunakan Google Cloud Load Balancing yang disediakan melalui resource Gateway GKE untuk mengotomatiskan deployment.

Untuk Google Cloud, contoh kanonis 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.

Gateway dan Layanan GKE

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

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

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

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

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

Meskipun load balancer default untuk Anthos Service Mesh adalah Load Balancer Jaringan, arsitektur referensi 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 dua lapisan load balancing HTTP.

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 Anthos 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 ingress cloud dan traffic masuk mesh menggunakan kemampuan pelengkap infrastruktur Google Cloud dan mesh. Diagram berikut menggambarkan cara menggabungkan cloud ingress (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 masuk cloud mengambil traffic dari luar mesh layanan dan mengarahkan traffic tersebut ke lapisan ingress 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 mengekspos aplikasi mesh layanan melalui load balancer L4, bukan load balancer L7, Anda harus menghentikan TLS klien pada lapisan masuk mesh di 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:

  • Cloud ingress: Dalam arsitektur referensi ini, Anda mengonfigurasi load balancer Google Cloud melalui Gateway untuk memeriksa kondisi proxy ingress 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. Gateway GKE terintegrasi dengan sertifikat yang dikelola Google. Anda dapat melihat Pengelola Sertifikat CertificateMap di definisi Gateway. Klien internet mengautentikasi 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, Anda dapat mengaktifkan enkripsi HTTP/2 dengan TLS antara gateway cluster (GFE) dan traffic masuk mesh (instance proxy envoy). Saat mengaktifkan HTTP/2 dengan enkripsi TLS untuk jalur ini, Anda dapat menggunakan sertifikat publik atau yang ditandatangani sendiri untuk mengenkripsi traffic karena GFE tidak melakukan autentikasi terhadap traffic tersebut. 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 ingress mesh, dan dari proxy ingress 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 Gateway GKE.

Langkah selanjutnya