Merancang ulang aplikasi web AWS EKS untuk Azure Kubernetes Service (AKS)

2025-04-08

Sekarang setelah Anda memiliki pemahaman yang lebih baik tentang perbedaan platform antara AWS dan Azure, mari kita periksa arsitektur aplikasi web di AWS dan modifikasi yang diperlukan untuk membuatnya kompatibel dengan Azure Kubernetes Service (AKS).

Arsitektur aplikasi Yelb

Aplikasi web sampel Yelb terdiri dari komponen front-end yang disebut yelb-ui dan komponen aplikasi yang disebut yelb-appserver.

Diagram arsitektur aplikasi web Yelb.

yelb-ui menyediakan kode JavaScript untuk browser. Kode ini dikompilasi dari aplikasi Angular . Komponen yelb-ui mungkin juga menyertakan nginx proksi tergantung pada model penyebaran. yelb-appserver adalah aplikasi Sinatra yang berinteraksi dengan server cache (redis-server) dan database back-end Postgres (yelb-db). Redis Cache menyimpan jumlah tampilan halaman, sementara PostgreSQL mempertahankan suara. Kedua layanan disebarkan di Kubernetes tanpa menggunakan layanan terkelola apa pun untuk menyimpan data di AWS atau Azure.

Aplikasi Yelb asli mandiri dan tidak bergantung pada layanan eksternal, sehingga Anda dapat memigrasikannya dari AWS ke Azure tanpa perubahan kode apa pun. Di Azure, Anda dapat menggunakan Azure Cache for Redis dan Azure Database for PostgreSQL sebagai pengganti layanan Redis Cache dan PostgreSQL yang disebarkan di AKS.

Contoh aplikasi Yelb memungkinkan pengguna untuk memilih sekumpulan alternatif (restoran) dan memperbarui bagan pai secara dinamis berdasarkan jumlah suara yang diterima. Aplikasi ini juga melacak jumlah tampilan halaman dan menampilkan nama yelb-appserver host instans yang melayani permintaan API setelah pemungutan suara atau refresh halaman. Fitur ini memungkinkan Anda untuk mendemosikan aplikasi secara independen atau kolaboratif.

Cuplikan layar antarmuka layanan Yelb.

Arsitektur di AWS

Untuk membantu melindungi aplikasi web dan API dari eksploitasi web umum, AWS menawarkan AWS Web Application Firewall (WAF) dan AWS Firewall Manager.

Memetakan layanan AWS ke layanan Azure

Untuk membuat ulang beban kerja AWS di Azure dengan perubahan minimal, gunakan Azure yang setara untuk setiap layanan AWS. Tabel berikut ini meringkas pemetaan layanan:

Pemetaan layanan	Layanan AWS	Layanan Azure
Firewall Pengakses Web	AWS Web Application Firewall (WAF)	Azure Web Application Firewall (WAF)
Penyeimbangan beban aplikasi	Application Load Balancer (ALB)	< c0>Gerbang Aplikasi AzureGerbang Aplikasi untuk Kontainer (AGC)
Jaringan pengiriman konten	Amazon CloudFront	Azure Front Door (AFD)
Orkestrasi	Elastic Kubernetes Service (EKS)	Azure Kubernetes Service (AKS)
Tempat penyimpanan rahasia	AWS Key Management Service (KMS)	Azure Key Vault
Registri kontainer	Amazon Elastic Container Registry (ECR)	Azure Container Registry (ACR)
Sistem Nama Domain (DNS)	Amazon Route 53	Azure DNS
Penggunaan Cache	Amazon ElastiCache	Azure Cache for Redis
NoSQL	Amazon DynamoDB	Azure Database untuk PostgreSQL

Untuk perbandingan komprehensif antara layanan Azure dan AWS, lihat Perbandingan layanan AWS dengan Azure.

Arsitektur di Azure

Dalam solusi ini, aplikasi Yelb disebarkan ke kluster AKS dan diekspos melalui pengontrol ingress seperti pengontrol ingress NGINX. Layanan pengontrol ingress diekspos melalui load balancer internal (atau privat). Untuk informasi selengkapnya tentang cara menggunakan load balancer internal untuk membatasi akses ke aplikasi Anda di AKS, lihat Menggunakan load balancer internal dengan Azure Kubernetes Service (AKS).

Sampel ini mendukung penginstalan pengontrol ingress NGINX terkelola dengan add-on perutean aplikasi atau pengontrol ingress NGINX yang tidak dikelola menggunakan Helm chart. Add-on pengontrol ingress NGINX untuk routing aplikasi menyediakan fitur-fitur berikut:

Konfigurasi mudah untuk pengontrol ingress NGINX terkelola yang didasarkan pada pengontrol ingress Kubernetes NGINX.
Integrasi dengan Azure DNS untuk manajemen zona publik dan privat.
Penghentian SSL dengan sertifikat yang disimpan di Azure Key Vault.

Untuk konfigurasi lain, lihat artikel berikut ini:

Aplikasi Yelb diamankan dengan sumber daya Azure Application Gateway yang disebarkan di subnet khusus dalam jaringan virtual yang sama dengan kluster AKS atau di jaringan virtual yang di-peering. Anda dapat mengamankan akses ke aplikasi Yelb menggunakan Azure Web Application Firewall (WAF), yang memberikan perlindungan terpusat aplikasi web dari eksploitasi dan kerentanan umum.

Desain arsitektur solusi

Diagram berikut menunjukkan arsitektur yang direkomendasikan di Azure:

Arsitektur solusi terdiri dari yang berikut:

Application Gateway menangani penghentian TLS dan berkomunikasi dengan aplikasi backend melalui HTTPS.
Listener Application Gateway menggunakan sertifikat SSL yang diperoleh dari Azure Key Vault.
Kebijakan Azure WAF yang terkait dengan Listener menjalankan aturan OWASP dan aturan kustom terhadap permintaan masuk dan memblokir serangan berbahaya.
Pengaturan HTTP Backend Application Gateway memanggil aplikasi Yelb melalui HTTPS pada port 443.
Backend Pool pada Application Gateway dan Probe Kesehatan memanggil pengendali ingress NGINX melalui load balancer internal AKS menggunakan HTTPS.
Pengontrol ingress NGINX menggunakan penyeimbang beban internal AKS.
Kluster AKS dikonfigurasikan dengan Azure Key Vault provider untuk add-on CSI Driver Secrets Store agar dapat mengambil rahasia, sertifikat, dan kunci dari Azure Key Vault melalui volume CSI.
SecretProviderClass mengambil sertifikat yang sama dengan yang digunakan oleh Application Gateway dari Azure Key Vault.
Objek ingress Kubernetes menggunakan pengontrol ingress NGINX untuk mengekspos aplikasi melalui HTTPS melalui load balancer internal AKS.
Layanan Yelb berjenis ClusterIP dan diekspos melalui pengontrol ingress NGINX.

Untuk instruksi komprehensif tentang penyebaran aplikasi Yelb di AKS menggunakan arsitektur ini, lihat sampel pendamping.

Solusi alternatif

Azure menawarkan beberapa opsi untuk menyebarkan aplikasi web pada kluster AKS dan mengamankannya dengan firewall aplikasi web:

Application Gateway Ingress Controller (AGIC) adalah aplikasi Kubernetes, sehingga Anda dapat memanfaatkan load-balancer Application Gateway L7 asli Azure untuk mengekspos perangkat lunak cloud ke Internet untuk beban kerja Azure Kubernetes Service (AKS). AGIC memantau kluster Kubernetes yang dihosting dan terus memperbarui Application Gateway sehingga layanan yang dipilih terekspos ke Internet.

Pengontrol Ingress beroperasi di podnya sendiri pada kluster AKS. AGIC memantau subset Sumber Daya Kubernetes untuk perubahan, menerjemahkan status kluster ke konfigurasi spesifik Application Gateway, dan menerapkannya ke Azure Resource Manager (ARM). Untuk informasi lebih lanjut, lihat Apa itu Pengontrol Ingress Application Gateway?.

Tabel berikut menguraikan kelebihan dan kekurangan Application Gateway Ingress Controller (AGIC):

Keuntungan	Kelemahan
* Integrasi asli: AGIC menyediakan integrasi asli dengan layanan Azure, khususnya Azure Application Gateway, yang memungkinkan perutean lalu lintas yang lancar dan efisien ke layanan yang berjalan di AKS. * Penyebaran yang disederhanakan: Menyebarkan AGIC sebagai add-on AKS mudah dan lebih sederhana dibandingkan dengan metode lain. Ini memungkinkan penyiapan yang cepat dan mudah dari Application Gateway dan kluster AKS dengan AGIC diaktifkan. * Layanan yang dikelola sepenuhnya: AGIC sebagai add-on adalah layanan yang dikelola sepenuhnya, memberikan manfaat seperti pembaruan otomatis dan peningkatan dukungan dari Microsoft. Ini memastikan Pengontrol Ingress tetap up-to-date dan menambahkan lapisan dukungan tambahan.	* Pendekatan cloud tunggal: AGIC terutama diadopsi oleh pelanggan yang mengadopsi pendekatan cloud tunggal. Ini mungkin bukan pilihan terbaik jika Anda memerlukan arsitektur multicloud di mana penyebaran di berbagai platform cloud adalah persyaratan. Dalam hal ini, Anda disarankan menggunakan pengontrol ingress yang tidak tergantung pada penyedia cloud tertentu, seperti NGINX, Traefik, atau HAProxy, untuk menghindari masalah vendor lock-in.

Keuntungan

Kelemahan

* Integrasi asli: AGIC menyediakan integrasi asli dengan layanan Azure, khususnya Azure Application Gateway, yang memungkinkan perutean lalu lintas yang lancar dan efisien ke layanan yang berjalan di AKS.
* Penyebaran yang disederhanakan: Menyebarkan AGIC sebagai add-on AKS mudah dan lebih sederhana dibandingkan dengan metode lain. Ini memungkinkan penyiapan yang cepat dan mudah dari Application Gateway dan kluster AKS dengan AGIC diaktifkan.
* Layanan yang dikelola sepenuhnya: AGIC sebagai add-on adalah layanan yang dikelola sepenuhnya, memberikan manfaat seperti pembaruan otomatis dan peningkatan dukungan dari Microsoft. Ini memastikan Pengontrol Ingress tetap up-to-date dan menambahkan lapisan dukungan tambahan.

* Pendekatan cloud tunggal: AGIC terutama diadopsi oleh pelanggan yang mengadopsi pendekatan cloud tunggal. Ini mungkin bukan pilihan terbaik jika Anda memerlukan arsitektur multicloud di mana penyebaran di berbagai platform cloud adalah persyaratan. Dalam hal ini, Anda disarankan menggunakan pengontrol ingress yang tidak tergantung pada penyedia cloud tertentu, seperti NGINX, Traefik, atau HAProxy, untuk menghindari masalah vendor lock-in.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Azure Application Gateway untuk Kontainer menyediakan penyeimbangan beban dan manajemen lalu lintas dinamis untuk aplikasi di kluster Kubernetes.

Fitur utama

Azure Application Gateway untuk Kontainer dibangun berdasarkan kemampuan Application Gateway Ingress Controller (AGIC) dan memungkinkan Anda menggunakan load balancer Application Gateway asli Azure. Fitur utama meliputi:

Penyeimbangan beban: Mendistribusikan lalu lintas masuk secara efisien di beberapa kontainer untuk performa dan skalabilitas yang optimal.
Implementasi GATEWAY API: Mendukung API Gateway, memungkinkan Anda menentukan aturan perutean dan kebijakan dengan cara asli Kubernetes.
Pemeriksaan kesehatan khusus: Tentukan pemeriksaan kesehatan khusus untuk memantau kesehatan kontainer dan secara otomatis mengalihkan lalu lintas dari instance yang tidak sehat.
Afinitas Sesi: Menyediakan afinitas sesi, mengalihkan permintaan berikutnya dari klien yang sama ke kontainer yang sama untuk pengalaman pengguna yang konsisten.
Kebijakan TLS: Mendukung penghentian TLS, memungkinkan enkripsi dan dekripsi SSL/TLS dilepaskan ke gateway.
Penulisan ulang header: Menulis ulang header HTTP permintaan klien dan respons dari target backend menggunakan IngressExtension definisi sumber daya kustom. Untuk informasi selengkapnya, lihat Ingress API dan Gateway API.
Penulisan ulang URL: Ubah URL permintaan klien, termasuk nama host dan/atau jalur, dan sertakan URL yang baru ditulis ulang saat memulai permintaan ke target backend. Untuk informasi selengkapnya, lihat Ingress API dan Gateway API.

Keterbatasan

Saat ini, Azure Application Gateway untuk Kontainer tidak mendukung fitur berikut:

Azure Web Application Firewall
Overlay Azure CNI
WebSocket
Antarmuka depan privat

Untuk informasi selengkapnya, lihat Menyebarkan Kluster Azure Kubernetes Service (AKS) dengan Application Gateway untuk Kontainer.

Azure Front Door adalah load balancer lapisan 7 global yang mengekspos dan melindungi beban kerja yang berjalan di AKS dengan aman menggunakan Azure Web Application Firewall dan layanan Azure Private Link .

Solusi ini menggunakan Azure Front Door Premium, enkripsi TLS end-to-end, Azure Web Application Firewall, dan layanan Private Link untuk mengekspos dan melindungi beban kerja yang berjalan di AKS dengan aman.

Kemampuan Azure Front Door untuk melakukan offload TLS dan Secure Sockets Layer (SSL) guna mengakhiri koneksi TLS dan mendekripsi lalu lintas masuk pada Azure Front Door. Azure Front Door mendekripsi ulang lalu lintas masuk sebelum meneruskannya ke aplikasi web yang dihosting AKS. Praktik ini memberlakukan enkripsi TLS end-to-end untuk seluruh proses permintaan, dari klien ke asal. Untuk informasi selengkapnya, lihat Mengamankan asal Anda dengan Private Link di Azure Front Door Premium.

NGINX ingress controller menyediakan akses ke aplikasi web yang dihosting di AKS. Ini dikonfigurasi untuk menggunakan alamat IP privat sebagai konfigurasi IP front-end dari kubernetes-internal di load balancer internal, dan menggunakan HTTPS sebagai protokol komunikasi untuk membuka akses aplikasi web. Untuk informasi selengkapnya, lihat Membuat pengontrol ingress dengan menggunakan alamat IP internal.

Kami merekomendasikan solusi ini untuk skenario di mana Anda menyebarkan aplikasi web yang sama di beberapa kluster AKS regional untuk kelangsungan bisnis dan pemulihan bencana, atau bahkan di beberapa platform cloud atau instalasi lokal. Dalam hal ini, Front Door dapat meneruskan panggilan masuk ke salah satu backend (juga dikenal sebagai asal) menggunakan salah satu metode perutean berikut:

Latensi: Perutean berbasis latensi memastikan bahwa permintaan dikirim ke asal latensi terendah yang dapat diterima dalam rentang sensitivitas. Dengan kata lain, permintaan dikirim ke kumpulan asal terdekat dalam hal latensi jaringan.
Prioritas: Anda dapat mengatur prioritas ke asal saat Anda ingin mengonfigurasi asal utama untuk melayani semua lalu lintas. Asal sekunder dapat menjadi cadangan jika asal utama menjadi tidak tersedia.
Tertimbang: Anda dapat menetapkan bobot ke sumber Anda ketika Anda ingin mendistribusikan lalu lintas di antara sekumpulan sumber secara merata atau berdasarkan koefisien bobot. Lalu lintas didistribusikan berdasarkan bobot nilai jika latensi sumber berada dalam rentang sensitivitas latensi yang dapat diterima di grup sumber.
Afinitas sesi: Anda dapat mengonfigurasi afinitas sesi untuk host atau domain frontend Anda untuk memastikan permintaan dari pengguna akhir yang sama dikirim ke asal yang sama.

Untuk informasi selengkapnya, lihat Menggunakan Azure Front Door untuk mengamankan beban kerja AKS.

Bagikan melalui