Dari edge ke mesh multi-cluster: Aplikasi yang didistribusikan secara global yang diekspos melalui Gateway GKE 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 untuk administrator platform.

Anda dapat meningkatkan ketahanan dan redundansi layanan Anda dengan men-deploy aplikasi secara konsisten di berbagai cluster GKE, di mana setiap cluster menjadi domain gagal tambahan. Misalnya, suatu layanan dengan layanan tujuan tingkat (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 pengguna di mana permintaan masuk akan otomatis diarahkan ke yang paling longgar dan tersedia gateway masuk mesh.

Jika Anda tertarik dengan manfaat mengekspos dengan aplikasi berkemampuan service-mesh yang berjalan pada satu cluster, Dari edge ke mesh: Mengekspos aplikasi mesh layanan 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 aliran data berikut:

  • Dari klien yang berhenti di load balancer Google Cloud menggunakan Sertifikat TLS yang dikelola Google.
  • Dari load balancer Google Cloud ke proxy masuk mesh menggunakan sertifikat TLS yang ditandatangani sendiri.
  • Dari proxy gateway masuk mesh hingga proxy file bantuan workload menggunakan mTLS yang mendukung mesh layanan.

Arsitektur referensi ini berisi dua lapisan masuk berikut:

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

Ketika Anda menggunakan lapisan masuk bersama-sama, ada peran pelengkap untuk setiap lapisan. Untuk mencapai tujuan berikut, Google Cloud mengoptimalkan fitur yang paling tepat dari lapisan traffic masuk cloud dan lapisan masuknya mesh:

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

Traffic masuk cloud

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

  • Perlindungan DDoS
  • {i>Cloud Firewall<i}
  • Autentikasi dan otorisasi
  • Enkripsi

Logika pemilihan rute biasanya mudah dilakukan di lapisan traffic masuk cloud. Namun, untuk multi-cluster dan multi-region lingkungan fleksibel App Engine.

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

Traffic masuk

Jika disambungkan dengan traffic masuk cloud, lapisan traffic masuk mesh memberikan titik masuk agar traffic masuk ke mesh layanan. Lapisan ini juga menyediakan backend mTLS, kebijakan otorisasi, dan pencocokan ekspresi reguler fleksibel.

Men-deploy load balancing aplikasi eksternal di luar mesh dengan mesh lapisan masuk menawarkan keuntungan yang signifikan, terutama untuk traffic internet otomatisasi pengelolaan biaya. Meskipun mesh layanan dan gateway masuk Istio memberikan {i>routing<i} dan manajemen lalu lintas data di {i>mesh<i}, beberapa fungsi dilayani secara lebih baik di tepian jaringan. Memanfaatkan jaringan tepi internet melalui Load Balancer Aplikasi eksternal Google Cloud dapat memberikan performa yang signifikan, keandalan, atau manfaat terkait keamanan dibandingkan ingress berbasis mesh.

Produk dan fitur yang digunakan

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

  • GKE Enterprise: Layanan Kubernetes terkelola yang dapat Anda gunakan untuk men-deploy dan mengoperasikan aplikasi dalam container berskala besar menggunakan infrastruktur Google. Untuk arsitektur referensi ini, masing-masing cluster GKE yang melayani sebuah aplikasi harus berada di perangkat yang sama.
  • Armada dan Gateway multi-cluster: Layanan yang digunakan untuk membuat aplikasi dalam container di perusahaan melakukan penskalaan menggunakan infrastruktur Google dan GKE Enterprise.
  • Google Cloud Armor: Layanan yang membantu Anda melindungi aplikasi dan situs web dari {i>denial of service<i} dan serangan web.
  • Mesh Layanan Cloud: Mesh layanan yang terkelola sepenuhnya berdasarkan Envoy dan Istio
  • Load Balancer Aplikasi: Load balancer L7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan.
  • Pengelola Sertifikat: Layanan yang memungkinkan Anda memperoleh dan mengelola sertifikat TLS untuk digunakan dengan melalui Cloud Load Balancing.

Fleet

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

Menggunakan satu atau beberapa perangkat dapat membantu Anda meningkatkan manajemen dari klaster ke seluruh kelompok klaster. Untuk mengurangi hambatan pengelolaan cluster, menggunakan prinsip fleet kesamaan namespace. Untuk setiap cluster GKE dalam pastikan Anda mengonfigurasi semua gateway masuk mesh dengan cara yang sama.

Selain itu, deploy layanan aplikasi secara konsisten sehingga neraca di akun namespace terkait dengan layanan yang identik di setiap Cluster GKE dalam fleet. Prinsip kesamaan dan kepercayaan yang diasumsikan dalam satu armada memungkinkan Anda menggunakan berbagai macam yang kompatibel dengan fleet di GKE Enterprise dan Google Cloud.

Aturan pemilihan rute timur-barat dalam mesh layanan dan kebijakan traffic ditangani pada lapisan masuk mesh. Lapisan masuk mesh ditempatkan di setiap Cluster GKE dalam fleet. Konfigurasikan setiap gateway masuk mesh dengan cara yang sama sesuai dengan prinsip fleet terkait kesamaan namespace.

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

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

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. {i>Proxy<i} masuk {i>mesh <i}ini memungkinkan Anda mengontrol perilaku eksposur jaringan secara terpisah dari perutean aplikasi perilaku model.

Proxy juga memungkinkan Anda menerapkan perutean dan kebijakan ke traffic eksternal mesh sebelum sampai di file bantuan aplikasi. Mesh ingress menentukan perlakuan saat mencapai node di mesh, tetapi komponen eksternal harus menentukan bagaimana lalu lintas pertama kali tiba di {i>mesh<i}.

Untuk mengelola traffic eksternal, Anda memerlukan load balancer yang berada di luar {i>mesh.<i} Untuk mengotomatiskan deployment, arsitektur referensi ini menggunakan Cloud Load Balancing yang disediakan melalui GKE Resource gateway.

Gateway GKE dan layanan multi-cluster

Ada banyak cara untuk menyediakan akses aplikasi ke klien di luar gugus ini. Gateway GKE adalah implementasi dari Kubernetes Gateway API. Gateway GKE mengembangkan dan meningkatkan resource Ingress.

Saat Anda men-deploy resource Gateway GKE ke Cluster GKE, pengontrol Gateway mengawasi resource Gateway API. Pengontrol merekonsiliasi resource Cloud Load Balancing untuk diimplementasikan perilaku jaringan yang ditentukan oleh sumber daya {i>Gateway<i}.

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

  • Apakah layanan backend berada di 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 Google Cloud Armor.
  • Persyaratan rentang mesh layanan. Mesh layanan dapat menjangkau beberapa cluster GKE atau dapat dimasukkan dalam satu cluster.

Di Gateway, perilaku ini dikontrol dengan menentukan aplikasi yang sesuai GatewayClass baru. Saat merujuk ke kelas {i>Gateway<i}, kelas-kelas yang dapat digunakan di 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 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 balancer Google Cloud dengan dua cara berikut:

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

Multi Cluster Ingress mengandalkan pembuatan MultiClusterService Google Cloud Platform. Gateway Multi-cluster mengandalkan pembuatan ServiceExport sumber daya, dan mengacu pada ServiceImport Google Cloud Platform.

Saat menggunakan Gateway multi-cluster, Anda dapat mengaktifkan kapabilitas load balancer Google Cloud dasar 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 pembuatan skrip lintas situs.

Resource kebijakan ini menargetkan layanan backend di fleet yang terbuka di berbagai klaster. Dalam skenario multi-cluster, semua kebijakan tersebut harus merujuk ke Grup API dan resource 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. Tujuan Gateway GKE memeriksa kondisi traffic masuk mesh {i>proxy<i}, dan {i>mesh<i}, sebagai gantinya, memeriksa respons aplikasi backend.

  • Cloud ingress: Dalam arsitektur referensi ini, Anda mengonfigurasi Load balancer Google Cloud melalui Gateway GKE untuk memeriksa kualitas proxy masuk mesh pada responsnya yang terekspos memeriksa porta. 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, lalu lintas akan dirutekan ke proxy mesh alternatif di cluster atau region GKE yang berbeda.
  • Mesh ingress: Di aplikasi mesh, Anda melakukan health check pada backend secara langsung sehingga Anda dapat menjalankan load balancing dan traffic secara lokal.

Pertimbangan desain

Bagian ini memberikan panduan untuk membantu Anda menggunakan arsitektur referensi ini untuk mengembangkan arsitektur yang memenuhi persyaratan spesifik Anda untuk 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 CA {i>root<i}. Gateway GKE terintegrasi dengan {i>Certificate Manager <i}untuk tujuan keamanan ini.

Klien internet mengotentikasi sertifikat publik dan terhubung ke load balancer eksternal sebagai hop pertama di Virtual Private Cloud (VPC). Anda dapat merujuk ke {i>Certificate Manager<i} CertificateMap dalam definisi Gateway. Hop berikutnya adalah antara Google Front End (GFE) dan proxy masuk mesh. Hop itu adalah 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 TLS enkripsi antara gateway cluster (GFE) dan mesh ingress (envoy instance proxy).

Saat Anda mengaktifkan HTTP/2 dengan enkripsi TLS antara gateway cluster dan terbuka, Anda dapat menggunakan sertifikat yang ditandatangani sendiri atau sertifikat publik untuk kemacetan. Anda dapat menggunakan tanda tangan elektronik atau sertifikat publik karena GFE tidak melakukan otentikasi terhadapnya. Lapisan enkripsi tambahan ini ditunjukkan dalam panduan deployment yang terkait dengan arsitektur referensi ini.

Untuk membantu mencegah kesalahan penanganan sertifikat, jangan gunakan kembali produk publik CA {i>root<i}. Menggunakan sertifikat terpisah untuk setiap load balancer dalam layanan {i>mesh.<i}

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

Jika mesh layanan yang Anda gunakan mewajibkan TLS, semua traffic antara file bantuan {i>proxy<i} dan semua lalu lintas ke masuknya jala dienkripsi. Arsitektur diagram menunjukkan enkripsi HTTPS dari klien ke pemuatan Google Cloud dari load balancer ke proxy masuk mesh, dan dari traffic masuk ke proxy file bantuan.

Keandalan dan ketahanan

Keuntungan utama dari pola edge-to-mesh multi-cluster dan multi-regional adalah dapat menggunakan semua fitur mesh layanan untuk pemuatan timur-barat balancing, seperti lalu lintas antarlayanan aplikasi.

Arsitektur referensi ini menggunakan GKE multi-cluster Gateway untuk mengarahkan traffic masuk cloud yang masuk 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), rute ini dirutekan ke backend yang sesuai melalui jaring layanan.

Pendekatan alternatif untuk menangani lalu lintas timur-barat adalah melalui layanan multi-cluster untuk semua layanan aplikasi yang di-deploy di Cluster GKE. Saat menggunakan layanan multi-cluster di seluruh cluster GKE dalam fleet endpoint layanan dikumpulkan bersama dalam ClusterSet Jika sebuah layanan perlu memanggil layanan lain, maka layanan itu dapat menargetkan layanan endpoint untuk layanan kedua. Karena endpoint dipilih berdasarkan rotasi endpoint yang dipilih mungkin berada di zona lain atau region yang berbeda.

Keuntungan utama penggunaan mesh layanan untuk traffic timur-barat dibandingkan menggunakan layanan multi-cluster adalah bahwa 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 lainnya akan terlebih dulu mencoba menjangkau layanan endpoint di zona yang sama, lalu mencoba di region yang sama dengan untuk memanggil layanan. 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 menyertakan banyak fitur yang memungkinkan Anda dapat mengelola dan mengatur cluster GKE, aplikasi, serta proses lainnya di penskalaan.

Deployment

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

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: