Bagikan melalui

Pertimbangan arsitektur umum untuk memilih layanan kontainer Azure

  • Artikel

Artikel ini memandu Anda melalui proses pemilihan layanan kontainer Azure. Ini memberikan gambaran umum pertimbangan tingkat fitur yang umum dan penting untuk beberapa beban kerja. Ini dapat membantu Anda membuat keputusan untuk memastikan bahwa beban kerja Anda memenuhi persyaratan untuk keandalan, keamanan, pengoptimalan biaya, keunggulan operasional, dan efisiensi performa.

Catatan

Artikel ini adalah bagian kedua dalam seri yang dimulai dengan Pilih layanan kontainer Azure. Kami sangat menyarankan Anda membaca artikel gambaran umum tersebut terlebih dahulu untuk mendapatkan konteks untuk pertimbangan arsitektur ini.

Gambaran Umum

Pertimbangan dalam artikel ini dibagi menjadi empat kategori:

Pertimbangan arsitektur dan jaringan

  • Dukungan sistem operasi
  • Ruang alamat jaringan
  • Memahami arus lalu lintas
  • Merencanakan subnet
  • Jumlah IP ingress yang tersedia
  • Rute yang ditentukan pengguna dan dukungan gateway NAT
  • Integrasi jaringan privat
  • Cakupan protokol
  • Penyeimbangan Beban
  • Penemuan layanan
  • Domain kustom dan TLS terkelola
  • TLS Bersama
  • Konsep jaringan untuk layanan Azure tertentu

Pertimbangan keamanan

  • Memberikan keamanan untuk lalu lintas intra-kluster dengan menggunakan kebijakan jaringan
  • Grup keamanan jaringan
  • Integrasi Azure Key Vault
  • Dukungan identitas terkelola
  • Perlindungan ancaman dan penilaian kerentanan dengan Defender untuk Kontainer
  • Garis besar keamanan
  • Azure Well-Architected Framework for Security

Pertimbangan operasional

  • Pembaruan dan patch
  • Pembaruan gambar kontainer
  • Skalabilitas infrastruktur vertikal
  • Skalabilitas infrastruktur horizontal
  • Skalabilitas aplikasi
  • Observabilitas
  • Kerangka Kerja Yang Dirancang Dengan Baik untuk Keunggulan Operasional

Pertimbangan keandalan

  • Perjanjian tingkat layanan
  • Redundansi melalui zona ketersediaan
  • Pemeriksaan kesehatan dan penyembuhan diri
  • Penyebaran aplikasi zero-downtime
  • Batas Sumber Daya
  • Kerangka Kerja Yang Dirancang dengan Baik untuk Keandalan

Perhatikan bahwa artikel ini berfokus pada subset layanan kontainer Azure yang menawarkan set fitur matang untuk aplikasi web dan API, jaringan, pengamatan, alat pengembang, dan operasi: Azure Kubernetes Service (AKS), Azure Container Apps, dan Web App for Containers. Untuk daftar lengkap semua layanan kontainer Azure, lihat halaman kategori produk layanan kontainer.

Catatan

Dalam panduan ini, istilah beban kerja mengacu pada kumpulan sumber daya aplikasi yang mendukung tujuan bisnis atau eksekusi proses bisnis. Beban kerja menggunakan beberapa komponen, seperti API dan penyimpanan data, yang bekerja sama untuk memberikan fungsionalitas end-to-end tertentu.

Pertimbangan arsitektur

Bagian ini menjelaskan keputusan arsitektur yang sulit dibalik atau benar tanpa memerlukan waktu henti atau penyebaran ulang yang signifikan. Sangat penting untuk mengingat pertimbangan ini untuk komponen mendasar seperti jaringan dan keamanan.

Pertimbangan ini tidak spesifik untuk pilar Well-Architected Framework. Namun, mereka layak mendapatkan pengamatan dan evaluasi ekstra terhadap persyaratan bisnis saat Anda memilih layanan kontainer Azure.

Dukungan sistem operasi

Sebagian besar aplikasi kontainer berjalan di kontainer Linux, yang didukung oleh semua layanan kontainer Azure. Opsi Anda lebih terbatas untuk komponen beban kerja yang memerlukan kontainer Windows.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan Linux ✅ ✅ ✅
Dukungan Windows ❌ ✅ ✅
Dukungan OS campuran ❌ ✅ ❌*

*Dukungan OS campuran untuk Aplikasi Web untuk Kontainer memerlukan paket Azure App Service terpisah untuk Windows dan Linux.

Pertimbangan jaringan

Penting untuk memahami desain jaringan di awal proses perencanaan Anda karena kendala keamanan dan kepatuhan dan pedoman yang diberlakukan. Secara umum, perbedaan utama di antara layanan Azure yang tercakup dalam panduan ini bergantung pada preferensi:

  • Container Apps adalah penawaran PaaS yang menyediakan banyak fitur jaringan yang dikelola Azure, seperti penemuan layanan dan domain terkelola internal. Tim beban kerja yang membutuhkan lebih banyak konfigurasi dapat menggunakan beban kerja/profil khusus sebelum mempertimbangkan alternatif untuk memaksimalkan opsi jaringan mereka.
  • AKS adalah yang paling dapat dikonfigurasi dari tiga layanan dan memberikan kontrol paling besar atas aliran jaringan. Misalnya, ini menyediakan pengontrol ingress kustom dan kontrol lalu lintas intra-kluster melalui kebijakan jaringan Kubernetes. Tim beban kerja dapat memanfaatkan berbagai add-on jaringan terkelola Azure, serta menginstal dan mengoperasikan add-on apa pun dari ekosistem Kubernetes yang lebih luas.
  • Aplikasi Web untuk Kontainer adalah fitur App Service. Dengan demikian, konsep jaringan, terutama integrasi jaringan privat, sangat spesifik untuk App Service. Layanan ini akan terbiasa dengan tim beban kerja yang sudah menggunakan App Service. Teams yang tidak memiliki pengalaman dengan App Service dan yang menginginkan integrasi jaringan virtual Azure yang lebih akrab didorong untuk mempertimbangkan Container Apps.

Perlu diingat bahwa jaringan adalah lapisan infrastruktur dasar. Seringkali sulit untuk membuat perubahan dalam desain tanpa menyebarkan kembali beban kerja, yang dapat menyebabkan waktu henti. Oleh karena itu, jika beban kerja Anda memiliki persyaratan jaringan tertentu, tinjau bagian ini dengan cermat sebelum Anda mempersempit pilihan layanan kontainer Azure Anda.

Ruang alamat jaringan

Saat mengintegrasikan aplikasi ke dalam jaringan virtual, Anda perlu melakukan beberapa perencanaan alamat IP untuk memastikan bahwa alamat IP yang cukup tersedia untuk instans kontainer. Selama proses ini, rencanakan alamat tambahan untuk pembaruan, penyebaran biru/hijau, dan situasi serupa di mana instans tambahan disebarkan, yang menggunakan alamat IP tambahan.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Subnet khusus Paket konsumsi: opsional
Paket khusus: diperlukan		 Wajib Opsional
Persyaratan alamat IP Paket konsumsi: Lihat Lingkungan khusus konsumsi.
Paket khusus: Lihat Lingkungan profil beban kerja.		 Lihat Jaringan virtual Azure untuk AKS. Lihat Persyaratan subnet App Service.

Perhatikan bahwa persyaratan AKS bergantung pada plug-in jaringan yang dipilih. Beberapa plug-in jaringan untuk AKS memerlukan reservasi IP yang lebih luas. Detail berada di luar cakupan artikel ini. Untuk informasi selengkapnya, lihat Konsep jaringan untuk AKS.

Memahami arus lalu lintas

Jenis arus lalu lintas yang diperlukan untuk solusi dapat memengaruhi desain jaringan.

Bagian berikut ini menyediakan informasi tentang berbagai batasan jaringan. Batasan ini memengaruhi kebutuhan Anda untuk menyebarkan subnet tambahan, tergantung pada apakah Anda memerlukan:

  • Beberapa beban kerja yang dikolokasi.
  • Ingress privat dan/atau publik.
  • Alur lalu lintas timur-barat yang dikontrol akses dalam kluster (untuk Aplikasi Kontainer dan AKS) atau dalam jaringan virtual (untuk semua layanan kontainer Azure).

Perencanaan subnet

Memastikan bahwa Anda memiliki subnet yang cukup besar untuk menyertakan instans aplikasi untuk beban kerja Anda bukanlah satu-satunya faktor yang menentukan jejak jaringan tempat aplikasi ini disebarkan.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan untuk beban kerja yang dikolokasi dalam subnet* ❌* ✅ T/A*

*Ini menjelaskan praktik terbaik, bukan batasan teknis.

Untuk Aplikasi Kontainer, integrasi subnet hanya berlaku untuk satu lingkungan Aplikasi Kontainer. Setiap lingkungan Container Apps dibatasi untuk satu IP ingress, publik atau privat.

Setiap lingkungan Container Apps hanya dimaksudkan untuk satu beban kerja di mana aplikasi dependen dikolokasikan. Oleh karena itu, Anda perlu memperkenalkan appliance jaringan Azure tambahan untuk penyeimbangan beban masuk jika Anda memerlukan ingress publik dan privat. Contohnya termasuk Azure Application Gateway dan Azure Front Door. Selain itu, jika Anda memiliki beberapa beban kerja yang perlu dipisahkan, lingkungan Container Apps tambahan diperlukan, sehingga subnet tambahan harus dialokasikan untuk setiap lingkungan.

AKS menyediakan kontrol aliran jaringan timur-barat terperinci dalam kluster dalam bentuk kebijakan jaringan Kubernetes. Kontrol alur ini memungkinkan Anda untuk mensegmentasi beberapa beban kerja dengan batas keamanan jaringan yang berbeda dalam kluster yang sama.

Untuk Aplikasi Web untuk Kontainer, tidak ada batasan tentang berapa banyak aplikasi yang dapat Anda integrasikan dengan satu subnet, selama subnet cukup besar. Tidak ada praktik terbaik untuk kontrol akses antara aplikasi web di jaringan virtual yang sama. Setiap aplikasi web secara independen mengelola kontrol akses untuk lalu lintas timur-barat atau utara-selatan dari jaringan virtual atau internet, masing-masing.

Catatan

Anda tidak dapat mengubah ukuran subnet yang memiliki sumber daya yang disebarkan di dalamnya. Berhati-hatilah saat Anda merencanakan jaringan untuk menghindari perlunya menyebarkan ulang seluruh komponen beban kerja, yang dapat menyebabkan waktu henti.

Jumlah IP ingress yang tersedia

Tabel berikut mempertimbangkan bagian perencanaan subnet sebelumnya untuk menentukan berapa banyak IP yang dapat diekspos untuk jumlah aplikasi sewenang-wenang yang dihosting dalam satu penyebaran layanan kontainer Azure.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Jumlah IP ingress Satu Banyak Lingkungan App Service: Satu
Tidak Ada Lingkungan App Service: Banyak

Aplikasi Kontainer memungkinkan satu IP per lingkungan, publik atau privat. AKS memungkinkan sejumlah IP, publik, atau privat. Aplikasi Web untuk Kontainer, di luar Lingkungan App Service, memungkinkan satu IP publik untuk semua aplikasi dalam paket App Service dan beberapa IP privat berbeda yang menggunakan titik akhir privat Azure.

Penting untuk dicatat bahwa aplikasi web yang diintegrasikan ke dalam Lingkungan App Service hanya menerima lalu lintas melalui IP ingress tunggal yang terkait dengan Lingkungan App Service, baik publik maupun privat.

Rute yang ditentukan pengguna dan dukungan gateway NAT

Jika beban kerja memerlukan kemampuan rute yang ditentukan pengguna (UDR) dan gateway NAT untuk kontrol jaringan terperinci, Container Apps memerlukan penggunaan profil beban kerja. Kompatibilitas gateway UDR dan NAT tidak tersedia dalam paket khusus konsumsi untuk ACA.

AKS dan Aplikasi Web untuk Kontainer menerapkan kedua fitur jaringan ini melalui fungsionalitas jaringan virtual standar atau integrasi jaringan virtual. Untuk menguraikan, kumpulan simpul AKS dan Aplikasi Web untuk Kontainer di Lingkungan App Service sudah menjadi sumber daya jaringan virtual langsung. Aplikasi Web untuk Kontainer yang tidak berada di Lingkungan App Service mendukung UDR dan gateway NAT melalui integrasi jaringan virtual. Dengan integrasi jaringan virtual, sumber daya secara teknis tidak berada langsung di jaringan virtual, tetapi semua alur akses keluarnya melalui jaringan virtual, dan aturan terkait jaringan memengaruhi lalu lintas seperti yang diharapkan.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan UDR Paket khusus konsumsi: ❌
Rencana profil beban kerja: ✅		 ✅ ✅
Dukungan gateway NAT Paket khusus konsumsi: ❌
Rencana profil beban kerja: ✅		 ✅ ✅

Integrasi jaringan privat

Untuk beban kerja yang memerlukan jaringan privat Lapisan 4 yang ketat untuk ingress dan egress, Anda harus mempertimbangkan Container Apps, AKS, dan App Service Environment SKU penyewa tunggal, di mana beban kerja disebarkan ke dalam jaringan virtual yang dikelola sendiri, menyediakan kontrol jaringan privat terperinci kustom.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Masuk privat ke jaringan virtual ✅ ✅ Melalui titik akhir privat
Keluar privat dari jaringan virtual ✅ ✅ Melalui integrasi jaringan virtual
Titik akhir publik yang sepenuhnya ditekan ✅ ✅ Hanya Lingkungan App Service
Jaringan privat dengan Aplikasi Web untuk Kontainer

Aplikasi Web untuk Kontainer menyediakan fitur jaringan tambahan yang tidak muncul dengan cara yang sama oleh layanan Azure lainnya yang dijelaskan dalam artikel ini. Untuk menerapkan persyaratan jaringan privat yang ketat, tim beban kerja perlu membiasakan diri dengan konsep jaringan ini. Tinjau fitur jaringan ini dengan hati-hati:

Jika Anda menginginkan solusi PaaS dan lebih memilih konsep jaringan yang dibagikan di beberapa solusi Azure, Anda harus mempertimbangkan Container Apps.

Cakupan protokol

Pertimbangan penting untuk platform hosting adalah protokol jaringan yang didukung untuk permintaan aplikasi masuk (ingress). Aplikasi Web untuk Kontainer adalah opsi paling ketat, hanya mendukung HTTP dan HTTPS. Container Apps juga memungkinkan koneksi TCP masuk. AKS adalah yang paling fleksibel, mendukung penggunaan TCP dan UDP yang tidak dibatasi pada port yang dipilih sendiri.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan protokol dan port HTTP (port 80)*
HTTPS (port 443)*
TCP (port 1-65535, kecuali 80 dan 443)		 TCP (port apa pun)
UDP (port apa pun)		 HTTP (port 80)
HTTPS (port 443)
Dukungan WebSocket ✅ ✅ ✅
Dukungan HTTP/2 ✅ ✅ ✅

*Di lingkungan Aplikasi Kontainer, HTTP/S dapat diekspos pada port apa pun untuk komunikasi intra-kluster. Dalam skenario itu, fitur HTTP Aplikasi Kontainer bawaan seperti CORS dan afinitas sesi tidak berlaku.

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer mendukung TLS 1.2 untuk ingress HTTPS bawaan mereka.

Penyeimbangan Beban

Dengan Aplikasi Kontainer dan Aplikasi Web untuk Kontainer, Azure sepenuhnya mengabstraksi penyeimbang muatan Lapisan 4 dan Lapisan 7.

Sebaliknya AKS menggunakan model tanggung jawab bersama di mana Azure mengelola infrastruktur Azure yang mendasari yang dikonfigurasi tim beban kerja dengan berinteraksi dengan API Kubernetes. Untuk penyeimbangan beban Lapisan 7 di AKS, Anda dapat memilih opsi yang dikelola Azure, misalnya add-on perutean aplikasi terkelola AKS atau Application Gateway untuk Kontainer, atau menyebarkan dan mengelola sendiri pengontrol ingress pilihan Anda.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Load balancer Lapisan 4 Dikelola Azure Tanggung jawab bersama Dikelola Azure
Load balancer Lapisan 7 Dikelola Azure Dibagikan atau dikelola sendiri Dikelola Azure

Penemuan layanan

Dalam arsitektur cloud, runtime dapat dihapus dan dibuat ulang kapan saja untuk menyeimbangkan kembali sumber daya, sehingga alamat IP instans berubah secara teratur. Arsitektur ini menggunakan nama domain yang sepenuhnya memenuhi syarat (FQDN) untuk komunikasi yang andal dan konsisten.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Penemuan layanan FQDN yang dikelola Azure Kubernetes dapat dikonfigurasi FQDN yang dikelola Azure

Web Apps for Containers menyediakan FQDN ingress publik (komunikasi utara-selatan) di luar kotak. Tidak diperlukan konfigurasi DNS tambahan. Namun, tidak ada mekanisme bawaan untuk memfasilitasi atau membatasi lalu lintas antara aplikasi lain (komunikasi timur-barat).

Aplikasi Kontainer juga menyediakan FQDN ingress publik. Namun, Container Apps melaju lebih jauh dengan memungkinkan FQDN aplikasi untuk diekspos dan membatasi lalu lintas hanya dalam lingkungan. Fungsionalitas ini memudahkan pengelolaan komunikasi timur-barat dan mengaktifkan komponen seperti Dapr.

Penyebaran Kubernetes awalnya tidak dapat ditemukan di dalam atau dari luar kluster. Anda harus membuat layanan Kubernetes seperti yang didefinisikan oleh API Kubernetes, yang kemudian mengekspos aplikasi ke jaringan dengan cara yang dapat diatasi.

Penting

Hanya Container Apps dan AKS yang menyediakan penemuan layanan melalui skema DNS internal dalam lingkungan masing-masing. Fungsionalitas ini dapat menyederhanakan konfigurasi DNS di seluruh lingkungan dev/test dan produksi. Misalnya, Anda dapat membuat lingkungan ini dengan nama layanan arbitrer yang harus unik hanya dalam lingkungan atau kluster, sehingga lingkungan tersebut dapat sama di seluruh dev/test dan produksi. Dengan Aplikasi Web untuk Kontainer, nama layanan harus unik di berbagai lingkungan untuk menghindari konflik dengan Azure DNS.

Domain kustom dan TLS terkelola

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer menyediakan solusi siap pakai untuk domain kustom dan manajemen sertifikat.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Mengonfigurasi domain kustom Secara langsung BYO Secara langsung
TLS terkelola untuk Azure FQDN Secara langsung T/A Secara langsung
TLS terkelola untuk domain kustom Dalam pratinjau BYO Di luar kotak atau BYO

Pengguna AKS bertanggung jawab untuk mengelola DNS, konfigurasi kluster, dan sertifikat TLS untuk domain kustom mereka. Meskipun AKS tidak menawarkan TLS terkelola, pelanggan dapat memanfaatkan perangkat lunak dari ekosistem Kubernetes, misalnya cert-manager populer untuk mengelola sertifikat TLS.

TLS Bersama

Alternatif lain untuk membatasi lalu lintas masuk adalah TLS bersama (mTLS). TLS timbul adalah protokol keamanan yang memastikan bahwa klien dan server dalam komunikasi diautentikasi. Untuk mencapai autentikasi, kedua belah pihak bertukar dan memverifikasi sertifikat sebelum data apa pun dikirimkan.

Aplikasi Web untuk Kontainer memiliki dukungan mTLS bawaan untuk koneksi klien masuk. Namun, aplikasi perlu memvalidasi sertifikat dengan mengakses X-ARR-ClientCert header HTTP yang diteruskan oleh platform App Service.

Container Apps juga memiliki dukungan bawaan untuk mTLS. Ini meneruskan sertifikat klien ke aplikasi di header HTTP X-Forwarded-Client-Cert. Anda juga dapat dengan mudah mengaktifkan mTLS otomatis untuk komunikasi internal antar aplikasi dalam satu lingkungan.

TLS bersama di AKS dapat diimplementasikan melalui jala layanan berbasis Istio sebagai add-on terkelola, yang mencakup kemampuan mTLS untuk koneksi klien masuk dan komunikasi kluster intra antar layanan. Tim beban kerja juga dapat memilih untuk menginstal dan mengelola penawaran jala layanan lain dari ekosistem Kubernetes. Opsi ini membuat implementasi mTLS di Kubernetes menjadi yang paling fleksibel.

Konsep jaringan khusus layanan

Bagian sebelumnya menjelaskan beberapa pertimbangan yang paling umum untuk diperhitungkan. Untuk detail selengkapnya dan untuk mempelajari selengkapnya tentang fitur jaringan yang khusus untuk layanan kontainer Azure individual, lihat artikel berikut ini:

Bagian sebelumnya berfokus pada desain jaringan. Lanjutkan ke bagian berikutnya untuk mempelajari selengkapnya tentang keamanan jaringan dan mengamankan lalu lintas jaringan.

Pertimbangan keamanan

Kegagalan untuk mengatasi risiko keamanan dapat menyebabkan akses yang tidak sah, pelanggaran data, atau kebocoran informasi sensitif. Kontainer menawarkan lingkungan yang dienkapsulasi untuk aplikasi Anda. Sistem hosting dan overlay jaringan yang mendasar, namun, memerlukan pagar pembatas tambahan. Pilihan layanan kontainer Azure Anda perlu mendukung persyaratan spesifik Anda untuk mengamankan setiap aplikasi satu per satu dan memberikan langkah-langkah keamanan yang tepat untuk mencegah akses yang tidak sah dan mengurangi risiko serangan.

Gambaran umum perbandingan keamanan

Sebagian besar layanan Azure, termasuk Aplikasi Kontainer, AKS, dan Aplikasi Web untuk Kontainer, terintegrasi dengan penawaran keamanan utama, termasuk Key Vault dan identitas terkelola.

Dari layanan dalam panduan ini, AKS menawarkan konfigurasi dan ekstensibilitas paling banyak sebagian dengan memunculkan komponen yang mendasar, yang seringkali dapat diamankan melalui opsi konfigurasi. Misalnya, pelanggan dapat menonaktifkan akun lokal ke server API Kubernetes atau mengaktifkan pembaruan otomatis ke simpul yang mendasar melalui opsi konfigurasi.

Untuk perbandingan terperinci, tinjau pertimbangan berikut dengan cermat untuk memastikan bahwa persyaratan keamanan beban kerja Anda dapat terpenuhi.

Keamanan sarana kontrol Kubernetes

AKS menawarkan fleksibilitas terbanyak dari tiga opsi yang dipertimbangkan dalam artikel ini, menyediakan akses penuh ke API Kubernetes sehingga Anda dapat menyesuaikan orkestrasi kontainer. Namun, akses ke API Kubernetes ini juga mewakili permukaan serangan yang signifikan, dan Anda perlu mengamankannya.

Penting

Perhatikan bahwa bagian ini tidak relevan untuk Aplikasi Web untuk Kontainer, yang menggunakan API Azure Resource Manager sebagai sarana kontrolnya.

Keamanan berbasis identitas

Pelanggan bertanggung jawab untuk mengamankan akses berbasis identitas ke API. Di luar kotak, Kubernetes menyediakan sistem manajemen autentikasi dan otorisasinya sendiri, yang juga perlu diamankan dengan kontrol akses.

Untuk memanfaatkan satu bidang kaca untuk manajemen identitas dan akses di Azure, ini adalah praktik terbaik untuk menonaktifkan akun lokal khusus Kubernetes dan sebaliknya menerapkan integrasi Microsoft Entra yang dikelola AKS bersama dengan Azure RBAC untuk Kubernetes. Jika Anda menerapkan praktik terbaik ini, administrator tidak perlu melakukan manajemen identitas dan akses di beberapa platform.

Aplikasi Kontainer AKS
Kontrol akses API Kubernetes Tidak ada akses Akses penuh

Pelanggan yang menggunakan Container Apps tidak memiliki akses ke API Kubernetes. Microsoft menyediakan keamanan untuk API ini.

Keamanan berbasis jaringan

Jika Anda ingin membatasi akses jaringan ke sarana kontrol Kubernetes, Anda perlu menggunakan AKS, yang menyediakan dua opsi. Opsi pertama adalah menggunakan kluster AKS privat, yang menggunakan Azure Private Link antara jaringan privat server API dan jaringan privat kluster AKS. Opsi kedua adalah integrasi API Server VNet (pratinjau), di mana server API diintegrasikan ke dalam subnet yang didelegasikan. Lihat dokumentasi untuk mempelajari selengkapnya.

Ada konsekuensi untuk menerapkan akses yang dibatasi jaringan ke API Kubernetes. Terutama, manajemen hanya dapat dilakukan dari dalam jaringan privat. Biasanya ini berarti Anda perlu menyebarkan agen yang dihost sendiri untuk Azure DevOps atau GitHub Actions. Untuk mempelajari tentang batasan lain, lihat dokumentasi khusus produk.

Aplikasi Kontainer AKS
Keamanan jaringan API Kubernetes Tidak dapat dikonfigurasi di PaaS Dapat dikonfigurasi: IP publik atau IP privat

Pertimbangan ini tidak berlaku untuk Aplikasi Kontainer. Karena paaS, Microsoft mengabstraksi infrastruktur yang mendasar.

Keamanan jaringan sarana data

Fitur jaringan berikut dapat digunakan untuk mengontrol akses ke, dari, dan dalam beban kerja.

Menggunakan kebijakan jaringan untuk memberikan keamanan untuk lalu lintas intra-kluster

Beberapa postur keamanan memerlukan pemisahan lalu lintas jaringan dalam lingkungan, misalnya saat Anda menggunakan lingkungan multipenyewa untuk menghosting beberapa aplikasi atau multitingkat. Dalam skenario ini, Anda harus memilih AKS dan menerapkan kebijakan jaringan, teknologi cloud-native yang memungkinkan konfigurasi terperinci jaringan Layer 4 dalam kluster Kubernetes.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Kebijakan Jaringan Paket konsumsi: ❌
Paket khusus: ❌		 ✅ ❌

Dari tiga layanan Azure yang dijelaskan dalam artikel ini, AKS adalah satu-satunya yang mendukung isolasi beban kerja lebih lanjut dalam kluster. Kebijakan jaringan tidak didukung di Aplikasi Kontainer atau Aplikasi Web untuk Kontainer.

Grup keamanan jaringan

Dalam semua skenario, Anda dapat mengatur komunikasi jaringan dalam jaringan virtual yang lebih luas dengan menggunakan kelompok keamanan jaringan, yang memungkinkan Anda menggunakan aturan lalu lintas Lapisan 4 yang mengatur masuk dan keluar di tingkat jaringan virtual.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Grup keamanan jaringan Paket konsumsi: ✅
Paket khusus: ✅		 ✅ ✅ Aplikasi terintegrasi VNet: egress saja

Pembatasan IP untuk ingress

Biasanya pembatasan lalu lintas jaringan diterapkan melalui aturan Lapisan 4 yang dijelaskan di atas. Namun, dalam skenario PaaS aplikasi tanpa integrasi jaringan virtual, dapat berguna untuk membatasi lalu lintas pada lapisan aplikasi.

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer menyediakan pembatasan IP sumber bawaan untuk lalu lintas masuk pada aplikasi individual.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Pembatasan IP Ingress pada lapisan aplikasi Secara langsung Dikelola sendiri atau melalui add-on terkelola Secara langsung
Konsumsi sumber daya - Mengonsumsi sumber daya kluster -

Untuk beban kerja AKS, implementasi tergantung pada pengontrol ingress yang dipilih. Add-on perutean aplikasi yang dikelola sendiri dan aplikasi terkelola Azure menggunakan sumber daya kluster.

Keamanan tingkat aplikasi

Anda perlu mengamankan beban kerja tidak hanya di tingkat jaringan dan infrastruktur, tetapi juga pada tingkat beban kerja dan aplikasi. Solusi kontainer Azure terintegrasi dengan penawaran keamanan Azure untuk membantu menstandarkan implementasi dan kontrol keamanan untuk aplikasi Anda.

Integrasi Key Vault

Ini adalah praktik terbaik untuk menyimpan dan mengelola rahasia, kunci, dan sertifikat dalam solusi manajemen kunci seperti Key Vault, yang memberikan keamanan yang ditingkatkan untuk komponen-komponen ini. Alih-alih menyimpan dan mengonfigurasi rahasia dalam kode atau dalam layanan komputasi Azure, semua aplikasi harus berintegrasi dengan Key Vault.

Integrasi Key Vault memungkinkan pengembang aplikasi untuk fokus pada kode aplikasi mereka. Ketiga layanan kontainer Azure yang dijelaskan dalam artikel ini dapat secara otomatis menyinkronkan rahasia dari layanan Key Vault dan menyediakannya ke aplikasi, biasanya sebagai variabel lingkungan atau file yang dipasang.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Integrasi Key Vault ✅ ✅ ✅

Untuk informasi selengkapnya, lihat:

Dukungan identitas terkelola

Aplikasi dengan identitas terkelola yang ditetapkan dapat mengakses sumber daya Azure tanpa kata sandi. Semua layanan kontainer yang disebutkan dalam panduan ini mendukung identitas terkelola.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan identitas terkelola ✅ ✅ ✅

Untuk informasi selengkapnya, lihat:

Perlindungan ancaman dan penilaian kerentanan dengan Defender untuk Kontainer

Perlindungan ancaman terhadap kerentanan juga penting. Ini adalah praktik terbaik untuk menggunakan Defender untuk Kontainer. Penilaian kerentanan didukung di registri kontainer Azure, sehingga dapat digunakan oleh layanan kontainer Azure apa pun, bukan hanya yang dijelaskan dalam artikel ini. Namun, perlindungan runtime Defender untuk Kontainer hanya tersedia untuk AKS.

Saat AKS mengekspos API Kubernetes asli, keamanan kluster juga dapat dievaluasi dengan alat keamanan khusus Kubernetes dari ekosistem Kubernetes.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Perlindungan ancaman runtime ❌ ✅ ❌

Untuk informasi selengkapnya, lihat Matriks dukungan kontainer di Defender untuk Cloud.

Perhatikan bahwa penilaian kerentanan gambar kontainer bukan pemindaian real time. Registri kontainer Azure dipindai secara berkala.

Garis besar keamanan

Secara umum, sebagian besar layanan kontainer Azure mengintegrasikan penawaran keamanan Azure. Secara keseluruhan, perlu diingat bahwa set fitur keamanan hanyalah bagian kecil dari penerapan keamanan cloud. Untuk informasi selengkapnya tentang menerapkan keamanan untuk layanan kontainer, lihat garis besar keamanan khusus layanan berikut ini:

Garis besar keamanan mencakup integrasi Azure lainnya, termasuk enkripsi dan pengelogan perangkat keras, yang berada di luar cakupan untuk artikel ini.

Kerangka Kerja Yang Dirancang dengan Baik untuk Keamanan

Artikel ini berfokus pada perbedaan utama di antara fitur layanan kontainer yang dijelaskan di sini.

Untuk panduan keamanan yang lebih lengkap tentang AKS, lihat Ulasan Kerangka Kerja Well-Architected - AKS.

Pertimbangan operasional

Agar berhasil menjalankan beban kerja dalam produksi, tim perlu menerapkan praktik keunggulan operasional, termasuk pengelogan terpusat, pemantauan, skalabilitas, pembaruan dan patching reguler, dan manajemen gambar.

Pembaruan dan patch

Penting bahwa OS yang mendasar aplikasi diperbarui dan di-patch secara teratur. Namun, perlu diingat bahwa dengan setiap pembaruan ada risiko kegagalan. Bagian ini dan yang berikutnya menjelaskan pertimbangan utama untuk tiga layanan kontainer sehubungan dengan tanggung jawab bersama antara pelanggan dan platform.

Sebagai layanan Kubernetes terkelola, AKS akan menyediakan gambar yang diperbarui untuk OS node dan komponen sarana kontrol. Tetapi tim beban kerja bertanggung jawab untuk menerapkan pembaruan ke kluster mereka. Anda dapat memicu pembaruan secara manual atau memanfaatkan fitur saluran peningkatan otomatis kluster untuk memastikan kluster Anda sudah diperbarui. Lihat panduan operasi AKS hari-2 untuk mempelajari tentang patching dan peningkatan kluster AKS.

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer adalah solusi PaaS. Azure bertanggung jawab untuk mengelola pembaruan dan patch, sehingga pelanggan dapat menghindari kompleksitas manajemen peningkatan AKS.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Pembaruan sarana kontrol Platform Pelanggan Platform
Pembaruan dan patch host Platform Pelanggan Platform
Pembaruan dan patch gambar kontainer Pelanggan Pelanggan Pelanggan

Pembaruan gambar kontainer

Terlepas dari solusi kontainer Azure, pelanggan selalu bertanggung jawab atas gambar kontainer mereka sendiri. Jika ada patch keamanan untuk gambar dasar kontainer, Anda bertanggung jawab untuk membangun kembali gambar Anda. Untuk mendapatkan pemberitahuan tentang kerentanan ini, gunakan Defender untuk Kontainer untuk kontainer yang dihosting di Container Registry.

Skalabilitas

Penskalakan digunakan untuk menyesuaikan kapasitas sumber daya untuk memenuhi permintaan, menambahkan lebih banyak kapasitas untuk memastikan performa dan menghapus kapasitas yang tidak digunakan untuk menghemat uang. Saat Anda memilih solusi kontainer, Anda perlu mempertimbangkan batasan infrastruktur dan strategi penskalakan.

Skalabilitas infrastruktur vertikal

Penskalaan vertikal mengacu pada kemampuan untuk meningkatkan atau mengurangi infrastruktur yang ada, yaitu komputasi CPU dan memori. Beban kerja yang berbeda memerlukan jumlah sumber daya komputasi yang berbeda. Saat Anda memilih solusi kontainer Azure, Anda perlu mengetahui penawaran SKU perangkat keras yang tersedia untuk layanan Azure tertentu. Mereka bervariasi dan dapat memberlakukan batasan tambahan.

Untuk AKS, tinjau ukuran untuk komputer virtual dalam dokumentasi Azure dan pembatasan AKS per wilayah.

Artikel ini memberikan detail tentang penawaran SKU untuk dua layanan lainnya:

Skalabilitas infrastruktur horizontal

Penskalakan horizontal mengacu pada kemampuan untuk meningkatkan atau mengurangi kapasitas melalui infrastruktur baru, seperti simpul VM. Selama peningkatan atau penurunan skala, tingkat konsumsi Container Apps mengabstraksi komputer virtual yang mendasar. Untuk layanan kontainer Azure yang tersisa, Anda mengelola strategi penskalaan horizontal dengan menggunakan API Azure Resource Manager standar.

Perhatikan bahwa penskalaan keluar dan termasuk penyeimbangan ulang instans, sehingga juga menciptakan risiko waktu henti. Risikonya lebih kecil dari risiko yang sesuai dengan penskalakan vertikal. Namun demikian, tim beban kerja selalu bertanggung jawab untuk memastikan bahwa aplikasi mereka dapat menangani kegagalan dan untuk menerapkan startup dan pematian aplikasi yang anggun untuk menghindari waktu henti.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Skala infrastruktur masuk dan keluar Paket konsumsi: N/A
Paket khusus: dapat dikonfigurasi		 Dapat dikonfigurasi Dapat dikonfigurasi
Provisi perangkat keras yang fleksibel Paket konsumsi: N/A
Paket khusus: diabstraksi dengan profil beban kerja		 SKU VM apa pun Disarikan. Lihat Paket App Service.

Penting

Opsi provisi perangkat keras yang tersedia melalui paket Container Apps Dedicated (profil beban kerja) dan Aplikasi Web untuk Kontainer (paket App Service) tidak fleksibel seperti AKS. Anda perlu membiasakan diri dengan SKU yang tersedia di setiap layanan untuk memastikan bahwa kebutuhan Anda terpenuhi.

Skalabilitas aplikasi

Ukuran umum untuk memicu penskalaan infrastruktur dan aplikasi adalah konsumsi sumber daya: CPU dan memori. Beberapa solusi kontainer dapat menskalakan jumlah instans kontainer pada metrik dengan konteks khusus aplikasi, seperti permintaan HTTP. Misalnya, AKS dan Container Apps dapat menskalakan instans kontainer berdasarkan antrean pesan melalui KEDA dan banyak metrik lainnya melalui scaler-nya. Kemampuan ini memberikan fleksibilitas saat Anda memilih strategi skalabilitas untuk aplikasi Anda. Aplikasi Web untuk Kontainer bergantung pada opsi skalabilitas yang disediakan oleh Azure. (Lihat tabel berikut.) Aplikasi Web untuk Kontainer tidak mendukung konfigurasi penskala kustom seperti KEDA.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Peluasan skala kontainer HTTP, TCP, atau berbasis metrik (CPU, memori, berbasis peristiwa). Berbasis metrik (CPU, memori, atau kustom). Manual, berbasis metrik, atau otomatis (pratinjau).
Skalabilitas berbasis peristiwa Ya. Cloud asli. Ya. Cloud asli. Konfigurasi tambahan diperlukan. Ya. Khusus sumber daya Azure.

Observabilitas

Instrumentasi beban kerja

Mengumpulkan metrik untuk aplikasi kompleks atau multitingkat bisa menjadi tantangan. Untuk mendapatkan metrik, Anda dapat mengintegrasikan beban kerja dalam kontainer dengan Azure Monitor dengan dua cara:

  • Instrumentasi otomatis. Tidak perlu perubahan kode.
  • Instrumentasi manual. Perubahan kode minimal yang diperlukan untuk mengintegrasikan dan mengonfigurasi SDK dan/atau klien.
Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Instrumentasi otomatis melalui platform ❌ ❌ Dukungan parsial*
Instrumentasi otomatis melalui agen ❌ Dukungan parsial* T/A
Instrumentasi manual Melalui SDK atau OpenTelemetry Melalui SDK atau OpenTelemetry Melalui SDK atau OpenTelemetry

*AKS dan Aplikasi Web untuk Kontainer mendukung instrumentasi otomatis untuk konfigurasi beban kerja Linux dan Windows tertentu, tergantung pada bahasa aplikasi. Untuk informasi selengkapnya, lihat artikel berikut ini:

Instrumentasi dalam kode aplikasi adalah tanggung jawab pengembang aplikasi, sehingga tidak bergantung pada solusi kontainer Azure apa pun. Beban kerja Anda dapat menggunakan solusi seperti:

Log

Semua layanan kontainer Azure menyediakan fungsionalitas log aplikasi dan platform. Log aplikasi adalah log konsol yang dihasilkan oleh beban kerja Anda. Log platform menangkap peristiwa yang terjadi di tingkat platform, di luar lingkup aplikasi Anda, seperti penskalaan dan penyebaran.

Perbedaan utama di antara fungsionalitas pengelogan untuk layanan kontainer berkaitan dengan pencatatan platform: apa yang dicatat dan bagaimana log diatur secara internal. Azure Monitor adalah layanan pengelogan utama di Azure yang terintegrasi dengan layanan ini. Monitor menggunakan log sumber daya untuk memisahkan log yang berasal dari sumber yang berbeda ke dalam kategori. Salah satu cara untuk menentukan log mana yang tersedia dari setiap layanan Azure adalah dengan melihat kategori log sumber daya yang tersedia untuk setiap layanan.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan untuk streaming log (streaming real-time) ✅ ✅ ✅
Dukungan untuk Azure Monitor ✅ ✅ ✅
Log sumber daya Azure Monitor Konsol dan sistem Server API Kubernetes, Audit, Penjadwal, Autoscaler Kluster, dan banyak lagi ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs, dan banyak lagi

Untuk deskripsi terperinci tentang setiap log sumber daya dalam tabel, pilih tautan dalam tabel.

Berikut adalah ringkasan singkat kemampuan pengelogan layanan kontainer:

  • Container Apps mengabstraksi semua log Kubernetes internalnya ke dalam dua kategori. Satu, yang disebut log Konsol , berisi log kontainer beban kerja. Kategori Sistem kedua berisi semua log terkait platform.
  • AKS menyediakan semua log terkait Kubernetes dan kontrol terperinci atas apa yang dapat dicatat. Ini juga mempertahankan kompatibilitas penuh dengan alat klien Kubernetes untuk streaming log, seperti kubectl.
  • Aplikasi Web untuk Kontainer menyediakan banyak kategori log sumber daya karena platformnya (App Service) tidak khusus untuk beban kerja kontainer. Untuk operasi khusus kontainer yang mengelola platform Docker internalnya, ia menyediakan kategori log AppServicePlatformLogs. Kategori penting lainnya adalah AppServiceEnvironmentPlatformLogs, yang mencatat peristiwa seperti penskalaan dan perubahan konfigurasi.

Kerangka Kerja Yang Dirancang Dengan Baik untuk Keunggulan Operasional

Artikel ini berfokus pada perbedaan utama di antara fitur layanan kontainer yang dijelaskan di sini. Lihat artikel ini untuk meninjau panduan Keunggulan Operasional lengkap untuk layanan berikut:

Keandalan

Keandalan mengacu pada kemampuan sistem untuk bereaksi terhadap kegagalan dan tetap berfungsi penuh. Pada tingkat perangkat lunak aplikasi, beban kerja harus menerapkan praktik terbaik seperti penembolokan, coba lagi, pola pemutus sirkuit, dan pemeriksaan kesehatan. Di tingkat infrastruktur, Azure bertanggung jawab untuk menangani kegagalan fisik, seperti kegagalan perangkat keras dan pemadaman listrik, di pusat data. Kegagalan masih bisa terjadi. Tim beban kerja harus memilih tingkat layanan Azure yang sesuai dan menerapkan konfigurasi instans minimum yang diperlukan untuk menerapkan failover otomatis antar zona ketersediaan.

Untuk memilih tingkat layanan yang sesuai, Anda perlu memahami cara kerja perjanjian tingkat layanan (SLA) dan zona ketersediaan.

Perjanjian tingkat layanan

Keandalan biasanya diukur oleh metrik berbasis bisnis seperti SLA atau metrik pemulihan seperti tujuan waktu pemulihan (RTO).

Azure memiliki banyak SLA untuk layanan tertentu. Tidak ada yang namanya tingkat layanan 100%, karena kegagalan selalu dapat terjadi di perangkat lunak dan perangkat keras, dan di alam, misalnya, badai dan gempa bumi. SLA bukan jaminan melainkan perjanjian ketersediaan layanan yang didukung secara finansial.

Untuk SLA dan detail terbaru, unduh dokumen SLA terbaru untuk Microsoft Online Services dari situs web lisensi Microsoft.

Tingkat gratis vs. berbayar

Umumnya, tingkat gratis layanan Azure tidak menawarkan SLA, yang menjadikannya pilihan hemat biaya untuk lingkungan non-produksi. Namun, untuk lingkungan produksi, ini adalah praktik terbaik untuk memilih tingkat berbayar yang memiliki SLA.

Faktor tambahan untuk AKS

AKS memiliki SLA yang berbeda untuk komponen dan konfigurasi yang berbeda:

  • Sarana kontrol. Server API Kubernetes memiliki SLA terpisah.
  • Bidang data. Kumpulan simpul menggunakan SLA SKU VM yang mendasar.
  • Zona ketersediaan. Ada SLA yang berbeda untuk dua bidang, tergantung pada apakah kluster AKS mengaktifkan zona ketersediaan dan menjalankan beberapa instans di seluruh zona ketersediaan.

Perhatikan bahwa saat Anda menggunakan beberapa layanan Azure, SLA komposit mungkin berbeda dari dan lebih rendah dari SLA layanan individual.

Redundansi dengan zona ketersediaan

Zona ketersediaan adalah pusat data berbeda yang memiliki daya listrik independen, pendinginan, dan sebagainya, dalam satu wilayah. Redundansi yang dihasilkan meningkatkan toleransi kegagalan tanpa mengharuskan Anda menerapkan arsitektur multi-wilayah.

Azure memiliki zona ketersediaan di setiap negara/wilayah tempat Azure mengoperasikan wilayah pusat data. Untuk memungkinkan beberapa instans kontainer melintasi zona ketersediaan, pastikan untuk memilih SKU, tingkat layanan, dan wilayah yang menyediakan dukungan zona ketersediaan.

Fitur Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Dukungan zona ketersediaan Penuh Penuh Penuh

Misalnya, aplikasi atau infrastruktur yang dikonfigurasi untuk menjalankan satu instans menjadi tidak tersedia jika masalah terjadi di zona ketersediaan tempat perangkat keras dihosting. Untuk sepenuhnya menggunakan dukungan zona ketersediaan, Anda harus menyebarkan beban kerja dengan konfigurasi minimum tiga instans kontainer, yang tersebar di seluruh zona.

Pemeriksaan kesehatan dan penyembuhan diri

Titik akhir pemeriksaan kesehatan sangat penting untuk beban kerja yang andal. Tetapi membangun titik akhir tersebut hanya setengah dari solusi. Setengah lainnya adalah mengontrol apa yang dilakukan platform hosting, dan bagaimana, ketika ada kegagalan.

Untuk lebih membedakan antara jenis pemeriksaan kesehatan, lihat jenis pemeriksaan bawaan dari Kubernetes:

  • Startup. Memeriksa apakah aplikasi berhasil dimulai.
  • Kesiapan. Memeriksa apakah aplikasi siap untuk menangani permintaan masuk.
  • Keakrapan. Memeriksa apakah aplikasi masih berjalan dan responsif.

Pertimbangan penting lainnya adalah seberapa sering pemeriksaan kesehatan tersebut diminta dari aplikasi (granularitas internal). Jika Anda memiliki interval panjang antara permintaan ini, Anda mungkin terus melayani lalu lintas hingga instans dianggap tidak sehat.

Sebagian besar aplikasi mendukung pemeriksaan kesehatan melalui protokol HTTP(S). Namun, beberapa mungkin memerlukan protokol lain, seperti TCP atau gRPC, untuk melakukan pemeriksaan tersebut. Ingatlah hal ini saat Anda merancang sistem pemeriksaan kesehatan Anda.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Pemeriksaan startup ✅ ✅ Dukungan parsial
Pemeriksaan kesiapan ✅ ✅ ❌
Pemeriksaan keaktifan ✅ ✅ ✅
Granularitas interval Detik Detik 1 menit
Dukungan protokol HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

Pemeriksaan kesehatan paling mudah diterapkan di Aplikasi Web untuk Kontainer. Ada beberapa pertimbangan penting:

  • Pemeriksaan startup-nya dibangun dan tidak dapat diubah. Ini mengirimkan permintaan HTTP ke port awal kontainer Anda. Respons apa pun dari aplikasi Anda dianggap sebagai awal yang sukses.
  • Ini tidak mendukung pemeriksaan kesiapan. Jika pemeriksaan startup berhasil, instans kontainer ditambahkan ke kumpulan instans sehat.
  • Ini mengirimkan pemeriksaan kesehatan pada interval satu menit. Anda tidak dapat mengubah interval.
  • Ambang minimum yang dapat Anda tetapkan untuk instans yang tidak sehat untuk dihapus dari mekanisme penyeimbangan beban internal adalah dua menit. Instans yang tidak sehat mendapatkan lalu lintas setidaknya selama dua menit setelah gagal pemeriksaan kesehatan. Nilai default untuk pengaturan ini adalah 10 menit.

Aplikasi Kontainer dan AKS, di sisi lain, jauh lebih fleksibel dan menawarkan opsi serupa. Dalam hal perbedaan tertentu, AKS menyediakan opsi berikut untuk melakukan pemeriksaan kesehatan, yang tidak tersedia di Container Apps:

Perbaikan otomatis

Untuk mengidentifikasi instans kontainer yang buruk dan berhenti mengirim lalu lintas ke instans tersebut adalah permulaan. Langkah selanjutnya adalah menerapkan penyembuhan otomatis. Penyembuhan otomatis adalah proses menghidupkan ulang aplikasi dalam upaya untuk pulih dari keadaan tidak sehat. Berikut perbandingan ketiga layanan kontainer:

  • Di Aplikasi Web untuk Kontainer, tidak ada opsi untuk memulai ulang instans kontainer segera setelah pemeriksaan kesehatan gagal. Jika instans terus gagal selama satu jam, instans akan digantikan oleh instans baru. Ada fitur lain, yang disebut penyembuhan otomatis, yang memantau dan memulai ulang instans. Ini tidak terkait langsung dengan pemeriksaan kesehatan. Ini menggunakan berbagai metrik aplikasi, seperti batas memori, durasi permintaan HTTP, dan kode status.
  • Container Apps dan AKS secara otomatis mencoba memulai ulang instans kontainer jika pemeriksaan keaktifan mencapai ambang kegagalan yang ditentukan.

Penyebaran aplikasi zero-downtime

Kemampuan untuk menyebarkan dan mengganti aplikasi tanpa menyebabkan waktu henti bagi pengguna sangat penting untuk beban kerja yang andal. Ketiga layanan kontainer yang dijelaskan dalam artikel ini mendukung penyebaran waktu henti nol, tetapi dengan cara yang berbeda.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Strategi waktu henti nol Pembaruan bergulir Pembaruan bergulir, ditambah semua strategi Kubernetes lainnya Slot Penyebaran

Harap dicatat bahwa arsitektur aplikasi juga harus mendukung penyebaran waktu henti nol. Lihat Azure Well-Architected Framework untuk panduan.

Batas Sumber Daya

Komponen penting lainnya dari lingkungan bersama yang andal adalah kontrol Anda atas penggunaan sumber daya (seperti CPU atau memori) kontainer Anda. Anda perlu menghindari skenario di mana satu aplikasi mengambil semua sumber daya dan meninggalkan aplikasi lain dalam keadaan buruk.

Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Batas sumber daya (CPU atau memori) Per aplikasi/kontainer Per aplikasi/kontainer
Per namespace layanan		 Paket Per App Service
  • Aplikasi Web untuk Kontainer: Anda dapat menghosting beberapa aplikasi (kontainer) dalam satu paket App Service. Misalnya, Anda dapat mengalokasikan paket dengan dua inti CPU dan 4 GiB RAM di mana Anda dapat menjalankan beberapa aplikasi web dalam kontainer. Namun, Anda tidak dapat membatasi salah satu aplikasi ke sejumlah CPU atau memori tertentu. Mereka semua bersaing untuk sumber daya paket App Service yang sama. Jika Anda ingin mengisolasi sumber daya aplikasi, Anda perlu membuat paket App Service tambahan.
  • Aplikasi Kontainer: Anda dapat mengatur batas CPU dan memori per aplikasi di lingkungan Anda. Namun, Anda dibatasi untuk serangkaian kombinasi CPU dan memori yang diizinkan. Misalnya, Anda tidak dapat mengonfigurasi satu vCPU dan memori 1 GiB, tetapi Anda dapat mengonfigurasi satu vCPU dan memori 2 GiB. Lingkungan Container Apps dianalogikan dengan namespace Layanan Kubernetes.
  • AKS: Anda dapat memilih kombinasi vCPU dan memori apa pun, selama simpul Anda memiliki perangkat keras untuk mendukungnya. Anda juga dapat membatasi sumber daya di tingkat namespace layanan jika Anda ingin menyegmentasi kluster Anda dengan cara itu.

Kerangka Kerja Yang Dirancang dengan Baik untuk Keandalan

Artikel ini berfokus pada perbedaan utama di antara fitur layanan kontainer di Azure. Jika Anda ingin meninjau panduan keandalan lengkap untuk layanan tertentu, lihat artikel berikut:

Kesimpulan

Solusi yang dirancang dengan baik menetapkan fondasi untuk beban kerja yang sukses. Meskipun arsitektur dapat disesuaikan saat beban kerja tumbuh dan tim berkembang dalam perjalanan cloud mereka, beberapa keputusan, terutama seputar jaringan, sulit untuk dibalik tanpa waktu henti atau penyebaran ulang yang signifikan.

Secara umum, ketika Anda membandingkan layanan kontainer Azure, tema muncul: AKS menampilkan infrastruktur yang paling mendasar, sehingga menawarkan konfigurasi dan ekstensibilitas terbesar. Jumlah overhead operasional dan kompleksitas sangat bervariasi untuk beban kerja AKS. Beberapa tim dapat sangat mengurangi overhead operasional dengan menggunakan add-on dan ekstensi terkelola Microsoft, serta fitur peningkatan otomatis. Pelanggan lain mungkin lebih suka kontrol penuh kluster untuk memanfaatkan ekstensibilitas penuh Kube dan ekosistem CNCF. Misalnya, meskipun Microsoft menawarkan Flux sebagai ekstensi GitOps terkelola, banyak tim memilih untuk menyiapkan dan mengoperasikan ArgoCD sendiri.

Tim beban kerja yang, misalnya, tidak memerlukan aplikasi CNCF, memiliki lebih sedikit pengalaman operasi atau lebih suka fokus pada fitur aplikasi mungkin lebih suka penawaran PaaS. Kami menyarankan agar mereka mempertimbangkan Aplikasi Kontainer terlebih dahulu.

Meskipun Container Apps dan Web App for Containers adalah penawaran PaaS yang menyediakan tingkat infrastruktur yang dikelola Microsoft yang serupa, perbedaan utamanya adalah Bahwa Container Apps lebih dekat ke Kubernetes dan menyediakan kemampuan cloud-native tambahan untuk penemuan layanan, penskalaan otomatis berbasis peristiwa, integrasi Dapr , dan banyak lagi. Namun, tim yang tidak memerlukan kemampuan ini dan terbiasa dengan model jaringan dan penyebaran App Service mungkin lebih suka Aplikasi Web untuk Kontainer.

Generalisasi dapat membantu Anda mempersempit daftar layanan kontainer Azure untuk dipertimbangkan. Tetapi perlu diingat bahwa Anda juga perlu memverifikasi pilihan Anda dengan memeriksa persyaratan individual secara rinci dan mencocokkannya dengan set fitur khusus layanan.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lain:

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya