Pertimbangan arsitektur untuk memilih layanan kontainer Azure

Artikel ini menjelaskan cara memilih 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.

Nota

Artikel ini adalah bagian kedua dalam seri. Kami sangat menyarankan Anda membaca bagian pertama untuk mendapatkan konteks untuk pertimbangan arsitektur ini.

Ikhtisar

Pertimbangan dalam artikel ini dibagi menjadi empat kategori berikut:

Pertimbangan arsitektur dan jaringan

  • Dukungan sistem operasi (OS)
  • Ruang alamat jaringan
  • Analisis arus lalu lintas
  • Perencanaan subnet
  • Alamat IP masuk yang tersedia
  • Rute yang ditentukan pengguna (UDR) dan dukungan gateway NAT
  • Integrasi jaringan privat
  • Cakupan protokol
  • Penyeimbangan beban
  • Penemuan layanan
  • Domain kustom dan Keamanan Lapisan Transportasi terkelola (TLS)
  • TLS Bersama (mTLS)
  • Jaringan kontainer tingkat lanjut untuk Azure Kubernetes Service (AKS)
  • Konsep jaringan untuk layanan Azure tertentu

Pertimbangan keamanan

  • Kebijakan jaringan untuk keamanan lalu lintas intra-kluster
  • Kelompok keamanan jaringan (NSG)
  • Integrasi Azure Key Vault
  • Dukungan identitas terkelola
  • Perlindungan ancaman dan penilaian kerentanan dengan Pertahanan Microsoft untuk Kontainer
  • Garis besar keamanan
  • Azure Well-Architected Framework untuk keamanan

Pertimbangan operasional

  • Pembaruan dan patch
  • Pembaruan gambar kontainer
  • Skalabilitas infrastruktur yang berskala vertikal
  • Skalabilitas infrastruktur horizontal
  • Skalabilitas aplikasi
  • Kemampuan Mengamati
  • Kerangka Kerja Arsitektur Tepat untuk Keunggulan Operasional

pertimbangan keandalan

  • Perjanjian tingkat layanan (SLA)
  • Redundansi melalui zona ketersediaan
  • Pemeriksaan kesehatan dan penyembuhan diri
  • Penyebaran aplikasi tanpa waktu henti
  • Batas sumber daya
  • Well-Architected Framework untuk keandalan

Artikel ini berfokus pada subset layanan kontainer Azure yang menyediakan set fitur matang untuk aplikasi web dan API, jaringan, pengamatan, alat pengembang, dan operasi. Layanan ini mencakup AKS, AKS Otomatis, Azure Container Apps, dan Aplikasi Web untuk Kontainer. Untuk daftar lengkap layanan kontainer Azure, lihat Layanan kontainer.

Nota

Beberapa bagian membedakan AKS Standard dari AKS Automatic. Jika tidak ada perbedaan yang disebutkan dalam suatu bagian, Anda dapat berasumsi bahwa ia memiliki fitur yang sama dengan model penyebaran lainnya.

Pertimbangan arsitektur

Bagian ini mencakup keputusan arsitektur yang sulit untuk dibalik atau diperbaiki tanpa pemadaman sistem atau penyebaran ulang yang signifikan. Sangat penting untuk mengevaluasi komponen mendasar dengan hati-hati seperti jaringan dan keamanan sebelum Anda menyelesaikannya.

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

Nota

AKS Automatic mengambil pendekatan yang lebih berpendapat daripada AKS Standard, yang berarti memiliki beberapa fitur bawaan yang tidak dapat dinonaktifkan. Panduan ini tidak menjelaskan fitur-fitur tersebut. Untuk informasi selengkapnya, lihat Perbandingan fitur AKS Otomatis dan Standar.

Dukungan OS

Sebagian besar aplikasi kontainer berjalan dalam kontainer Linux, yang didukung semua layanan kontainer Azure. Namun, opsi lebih terbatas untuk komponen beban kerja yang memerlukan kontainer Windows.

Fitur Container Apps AKS AKS Otomatis Aplikasi Web untuk Kontainer
Dukungan Linux ✅ ✅ ✅ ✅
Dukungan Windows ❌ ✅ ❌ ✅
Dukungan OS campuran ❌ ✅ ❌ ❌*

*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 Anda. Pertimbangkan layanan berikut:

  • Container Apps adalah penawaran platform as a service (PaaS) yang menyediakan fitur jaringan terkelola Azure seperti penemuan layanan, domain terkelola internal, dan kontrol jaringan virtual.

  • AKS adalah yang paling dapat dikonfigurasi dari tiga layanan dan memberikan kontrol paling besar atas alur jaringan. Misalnya, AKS menyediakan pengontrol ingress kustom dan kontrol lalu lintas intra-kluster melalui kebijakan jaringan Kubernetes. Tim beban kerja dapat memanfaatkan berbagai add-on jaringan yang dikelola Azure dan menginstal dan mengoperasikan add-on apa pun dari ekosistem Kubernetes.

  • Web App for Containers adalah sebuah fitur dari App Service. Model jaringannya, terutama untuk integrasi jaringan privat, mengikuti arsitektur App Service. Arsitektur ini akrab dengan tim beban kerja yang menggunakan App Service. Untuk tim tanpa pengalaman App Service sebelumnya yang lebih menyukai integrasi jaringan virtual Azure yang lebih konvensional, kami merekomendasikan Container Apps.

Jaringan adalah lapisan infrastruktur dasar. Seringkali sulit untuk membuat perubahan dalam desain tanpa menyebarkan ulang beban kerja, yang dapat mengakibatkan waktu henti. 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 merencanakan alamat IP untuk memastikan bahwa instans kontainer memiliki cukup. Selama proses ini, alokasikan alamat IP tambahan untuk mengakomodasi pembaruan, penyebaran biru-hijau, dan skenario serupa. Peristiwa ini mungkin untuk sementara menyebarkan instans tambahan yang menggunakan lebih banyak alamat dari biasanya.

Fitur atau persyaratan Container Apps AKS Aplikasi Web untuk Kontainer
Subnet khusus - Paket konsumsi: opsional

- Paket khusus: diperlukan		 Diperlukan Fakultatif
Persyaratan alamat IP - Rencana konsumsi. Lihat Lingkungan khusus konsumsi.

- Rencana khusus. Lihat Profil lingkungan beban kerja.		 Lihat jaringan virtual Azure untuk AKS. Lihat persyaratan subnet App Service.

Persyaratan AKS bergantung pada plug-in jaringan yang Anda pilih. Beberapa plug-in jaringan untuk AKS memerlukan reservasi alamat IP yang lebih luas. Informasi tersebut 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 menjelaskan berbagai batasan jaringan. Batasan ini memengaruhi apakah Anda perlu menyebarkan subnet tambahan, tergantung pada kebutuhan Anda untuk konfigurasi berikut:

  • Beberapa beban kerja yang dikolokasi

  • Akses masuk pribadi, akses masuk publik, atau keduanya

  • Arus lalu lintas timur-barat yang dikontrol akses dalam kluster untuk Container Apps dan AKS, atau dalam jaringan virtual untuk semua layanan kontainer Azure

Perencanaan subnet

Subnet harus memiliki ukuran yang cukup untuk menyertakan instans aplikasi, tetapi kapasitas bukan satu-satunya faktor yang menentukan cakupan jaringan untuk penerapan beban kerja ini.

Capability Container Apps AKS Aplikasi Web untuk Kontainer
Dukungan untuk beban kerja yang dikolokasi dalam subnet* ❌* ✅ Tidak tersedia*

*Praktik terbaik, bukan batasan teknis

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

Setiap lingkungan Container Apps hanya dimaksudkan untuk satu beban kerja di mana aplikasi dependen dikolokasikan. Oleh karena itu, Anda perlu menambahkan perangkat jaringan Azure ekstra untuk penyeimbangan beban masuk jika Anda memerlukan akses publik dan privat. Contohnya termasuk Azure Application Gateway dan Azure Front Door. Jika beberapa beban kerja memerlukan pemisahan, Anda harus menyediakan lingkungan Container Apps tambahan dan mengalokasikan subnet terpisah untuk setiap lingkungan.

AKS menyediakan kontrol aliran jaringan timur-barat terperinci dalam kluster melalui 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 pada jumlah aplikasi yang dapat Anda integrasikan dengan satu subnet jika subnet memiliki kapasitas yang memadai. 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.

Nota

Anda tidak dapat mengubah ukuran subnet yang memiliki sumber daya yang disebarkan di dalamnya. Rencanakan jaringan Anda dengan hati-hati untuk menghindari penyebaran ulang seluruh komponen beban kerja, yang dapat mengakibatkan waktu henti.

Ketersediaan alamat IP Ingress

Tabel berikut menggabungkan bagian perencanaan subnet sebelumnya untuk menentukan jumlah alamat IP yang dapat diekspos. Ini berlaku untuk sejumlah aplikasi yang dihosting dalam satu penyebaran layanan kontainer Azure.

Capability Container Apps AKS Aplikasi Web untuk Kontainer
Jumlah alamat IP masuk Satu Banyak - Lingkungan App Service: Satu

- Tidak Tersedia Lingkungan App Service: Banyak

Container Apps mendukung satu alamat IP untuk setiap lingkungan, baik publik atau privat. AKS mendukung sejumlah alamat IP publik atau privat. Aplikasi Web untuk Kontainer, saat digunakan di luar lingkungan App Service, memungkinkan satu alamat IP publik untuk setiap paket App Service dan beberapa alamat IP privat yang berbeda melalui titik akhir privat Azure.

Perlu diingat bahwa aplikasi web yang diintegrasikan ke dalam lingkungan App Service hanya menerima lalu lintas melalui satu alamat IP ingress yang terkait dengan lingkungan App Service, baik publik maupun privat.

Dukungan UDR dan gateway NAT

Jika beban kerja memerlukan kemampuan UDR dan gateway NAT untuk kontrol jaringan terperinci, Container Apps memerlukan penggunaan profil beban kerja. Kompatibilitas UDR dan NAT gateway tidak didukung dalam paket khusus konsumsi untuk Aplikasi Kontainer.

AKS dan Aplikasi Web untuk Kontainer menerapkan kedua fitur jaringan ini melalui fungsionalitas jaringan virtual standar atau integrasi jaringan virtual. 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. Namun, semua aliran akses keluarnya melalui jaringan virtual, dan aturan yang terkait dengan jaringan tersebut memengaruhi lalu lintas seperti yang diharapkan.

Capability Container Apps 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 lalu lintas masuk dan keluar, Anda harus mempertimbangkan Container Apps, AKS, dan SKU lingkungan App Service penyewa tunggal, tempat beban kerja disebarkan ke dalam jaringan virtual yang dikelola mandiri. Penyebaran ini menyediakan kontrol jaringan privat terperinci yang biasa.

Kemampuan jaringan Container Apps 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 dinonaktifkan ✅ ✅ Lingkungan App Service saja
Jaringan privat dengan Aplikasi Web untuk Kontainer

Aplikasi Web untuk Kontainer menyediakan kemampuan jaringan tambahan yang tidak disajikan dengan cara yang sama seperti layanan Azure lainnya yang tercakup dalam artikel ini. Untuk menerapkan persyaratan jaringan privat yang ketat, tim beban kerja harus terbiasa dengan konsep jaringan ini. Tinjau dengan cermat fitur jaringan berikut:

Jika Anda menginginkan solusi PaaS dan lebih memilih konsep jaringan yang dibagikan di beberapa solusi Azure, pertimbangkan Aplikasi Kontainer.

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 dan hanya mendukung HTTP dan HTTPS. Container Apps juga memungkinkan koneksi Protokol Kontrol Transmisi (TCP) masuk. AKS adalah yang paling fleksibel dan mendukung penggunaan TCP dan Protokol Datagram Pengguna (UDP) yang tidak dibatasi pada port yang dipilih sendiri.

Dukungan jaringan dan protokol Container Apps AKS Aplikasi Web untuk Kontainer
Dukungan protokol dan port - HTTP (port 80)*

- HTTPS (port 443)*

- TCP (port 1 hingga 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 atau HTTPS dapat diekspos pada port apa pun untuk komunikasi intra-kluster. Dalam skenario tersebut, fitur bawaan HTTP Container Apps seperti pembagian sumber daya lintas asal 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. Dalam model ini, 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, seperti add-on perutean aplikasi yang dikelola AKS, Application Gateway untuk Kontainer, atau menyebarkan dan mengelola sendiri pengontrol ingress pilihan Anda.

Penyeimbang beban Container Apps AKS Aplikasi Web untuk Kontainer
Penyeimbang Beban Lapisan 4 Dikelola oleh Azure Tanggung jawab bersama Dikelola oleh Azure
Load balancer Lapisan 7 Dikelola oleh Azure Dibagikan atau dikelola sendiri Dikelola oleh Azure

Layanan Jaringan Kontainer Tingkat Lanjut untuk AKS

Advanced Container Networking Services (ACNS) membekali AKS dengan kemampuan jaringan tingkat lanjut yang melampaui apa yang tersedia di Container Apps atau Web App for Containers. Kemampuan ini memberikan pengamatan yang kuat dan keamanan yang ditingkatkan yang dirancang untuk lingkungan kontainer dinamis.

  • Pengamatan jaringan kontainer:

    ACNS menggunakan sarana kontrol Hubble untuk memberikan wawasan intuitif dan mendalam tentang perilaku jaringan. Dengan metrik tingkat simpul dan tingkat pod yang mudah dikonsumsi dan log alur yang komprehensif, Anda dapat dengan cepat menentukan masalah dan mengoptimalkan performa. Pengamatan bawaan ini mengurangi kebutuhan untuk penyiapan pemantauan eksternal dan menurunkan kurva pembelajaran yang biasanya terkait dengan diagnostik jaringan Kube.

  • Keamanan jaringan kontainer:

    Untuk kluster yang menggunakan Antarmuka Jaringan Kontainer Azure yang didukung oleh Cilium, ACNS menyediakan pemfilteran nama domain yang sepenuhnya memenuhi syarat (FQDN). Alih-alih mengelola kebijakan keamanan berbasis alamat IP statis, Anda dapat menentukan kebijakan berdasarkan nama domain. Pendekatan dinamis ini menyederhanakan manajemen kebijakan dan juga selaras dengan model keamanan modern tanpa kepercayaan. Pendekatan ini memudahkan Anda untuk memberlakukan keamanan yang kuat tanpa pembaruan manual yang konstan.

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

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 FQDN untuk komunikasi yang andal dan konsisten.

Mekanisme penemuan layanan Container Apps AKS Aplikasi Web untuk Kontainer
Penemuan layanan FQDN yang dikelola Azure Kubernetes dapat dikonfigurasi FQDN yang dikelola Azure

Aplikasi Web untuk Kontainer menyediakan FQDN ingress publik (komunikasi utara-selatan) secara default. 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 untuk akses publik. Namun, Container Apps lebih canggih dengan memungkinkan Nama domain lengkap aplikasi untuk diekspos dan membatasi lalu lintas hanya di dalam lingkungan yang sama. Fungsionalitas ini memudahkan pengelolaan komunikasi timur-barat dan mengaktifkan komponen seperti Dapr.

Penyebaran Kubernetes secara inheren tidak dapat ditemukan dari dalam atau di luar kluster. Untuk mengekspos aplikasi ke jaringan dengan cara yang dapat diatasi, Anda harus menentukan dan membuat layanan Kubernetes seperti yang ditentukan oleh API Kubernetes.

Penting

Hanya Container Apps dan AKS yang menyediakan penemuan layanan melalui skema Sistem Nama Domain (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. Mereka bisa sama di seluruh lingkungan 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 bawaan untuk domain kustom dan manajemen sertifikat.

Domain kustom dan dukungan TLS Container Apps AKS Aplikasi Web untuk Kontainer
Mengonfigurasi domain kustom Fitur default Bawa Barang Sendiri (BYO) Fitur default
Manajemen TLS untuk FQDN Azure Fitur default Tidak tersedia Fitur default
TLS terkelola untuk domain kustom Fitur default BYO Fitur default atau BYO

Pengguna AKS bertanggung jawab untuk mengelola DNS, konfigurasi kluster, dan sertifikat TLS untuk domain kustom mereka. AKS tidak menyediakan TLS terkelola, tetapi pelanggan dapat menggunakan perangkat lunak dari ekosistem Kubernetes, seperti cert-manager, untuk mengelola sertifikat TLS.

mTLS

Alternatif lain untuk membatasi lalu lintas masuk adalah mTLS. Protokol keamanan ini 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 header HTTP X-ARR-ClientCert 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.

Anda dapat menerapkan mTLS di AKS melalui service mesh berbasis Istio yang dikelola sebagai add-on. Add-on ini mencakup kemampuan mTLS untuk koneksi klien masuk dan komunikasi intra-kluster 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 paling umum untuk memperhitungkan desain jaringan. Untuk informasi 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 mengakibatkan akses yang tidak sah, pelanggaran data, atau kebocoran informasi sensitif. Kontainer menyediakan lingkungan yang dienkapsulasi untuk aplikasi Anda. Namun, sistem hosting dan overlay jaringan yang mendasar memerlukan pengaman ekstra. 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 menyediakan konfigurasi dan ekstensibilitas terbanyak sebagian dengan memunculkan komponen yang mendasar, yang seringkali dapat diamankan dengan menggunakan opsi konfigurasi. Misalnya, Anda dapat menggunakan opsi konfigurasi untuk menonaktifkan akun lokal ke server API Kubernetes atau mengaktifkan pembaruan otomatis ke simpul yang mendasar.

Kluster Otomatis AKS dilengkapi dengan konfigurasi default yang diperkeras dan memiliki banyak pengaturan keamanan kluster, aplikasi, dan jaringan yang diaktifkan secara default. Konfigurasi awal ini tidak hanya mengurangi waktu penyebaran tetapi juga memberi pengguna konfigurasi standar yang telah divalidasi sebelumnya. Konfigurasi ini memberi pengguna fondasi yang kuat untuk tanggung jawab operasional hari ke-2. Fondasi ini membantu mempersingkat kurva pembelajaran manajemen kluster jangka panjang untuk tim yang baru menggunakan teknologi.

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

Keamanan sarana kontrol Kubernetes

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

Penting

Bagian ini tidak relevan untuk Aplikasi Web untuk Kontainer, yang menggunakan API Resource Manager sebagai sarana kontrolnya.

Keamanan berbasis identitas

Anda bertanggung jawab untuk mengamankan akses berbasis identitas ke API. Kubernetes menyediakan sistem manajemen autentikasi dan otorisasinya sendiri. Sistem ini 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 kontrol akses berbasis peran Azure (Azure RBAC) untuk Kubernetes. Jika Anda menerapkan praktik terbaik ini, administrator tidak perlu melakukan manajemen identitas dan akses di beberapa platform.

Akses API Kubernetes Container Apps AKS
Kontrol akses API Kubernetes Tidak ada akses Akses penuh

Anda tidak memiliki akses ke API Kubernetes jika anda menggunakan Container Apps. 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 jaringan virtual server API tempat server API diintegrasikan ke dalam subnet yang didelegasikan.

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

Kontrol akses API Kubernetes Container Apps AKS
Keamanan jaringan API Kubernetes Tidak dapat dikonfigurasi di PaaS Dapat dikonfigurasi dengan menggunakan alamat IP publik atau privat

ACNS meningkatkan keamanan sarana data di AKS. Untuk kluster yang menggunakan Antarmuka Jaringan Kontainer Azure yang didukung oleh Cilium, ACNS memperkenalkan keamanan jaringan kontainer melalui pemfilteran FQDN. Alih-alih mengelola kebijakan keamanan berbasis alamat IP statis, Anda dapat menentukan kebijakan dinamis berdasarkan FQDN. Pendekatan ini menyederhanakan manajemen kebijakan, mengurangi overhead administratif, dan mendukung model zero trust dengan memastikan bahwa hanya lalu lintas ke domain tepercaya yang diizinkan.

Nota

Fitur keamanan ACNS memerlukan Kubernetes versi 1.29 atau yang lebih baru dan hanya tersedia pada kluster yang menggunakan bidang data Cilium.

Pertimbangan ini tidak berlaku untuk Aplikasi Kontainer. Karena PaaS, Microsoft memaparkan infrastruktur yang dasar.

Keamanan jaringan lapisan data

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

Kebijakan jaringan untuk keamanan lalu lintas intra-kluster

Beberapa postur keamanan memerlukan pemisahan lalu lintas jaringan dalam lingkungan. Misalnya, pemisahan ini sering diperlukan ketika Anda menggunakan lingkungan multipenyewa untuk menghosting beberapa aplikasi atau beberapa tingkat. Dalam skenario ini, pilih AKS dan terapkan kebijakan jaringan, yang merupakan fitur cloud-native yang memungkinkan konfigurasi granular jaringan Layer 4 dalam kluster Kubernetes.

Dukungan kebijakan jaringan Container Apps AKS Aplikasi Web untuk Kontainer
Kebijakan jaringan Rencana penggunaan: ❌

Rencana khusus: ❌		 ✅ ❌

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

Grup Keamanan Jaringan (NSG)

Dalam semua skenario, Anda dapat mengatur komunikasi jaringan dalam jaringan virtual yang lebih luas dengan menggunakan NSG. Pendekatan ini memungkinkan Anda menggunakan aturan lalu lintas Lapisan 4 yang mengatur ingress dan egress di tingkat jaringan virtual.

Dukungan NSG Container Apps AKS Aplikasi Web untuk Kontainer
Grup Keamanan Jaringan (NSG) - Paket konsumsi: ✅

- Rencana khusus: ✅		 ✅ ✅ Aplikasi terintegrasi jaringan virtual, hanya keluar

Pembatasan alamat IP terintegrasi untuk lalu lintas masuk

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer menyediakan pembatasan alamat IP sumber bawaan untuk lalu lintas masuk untuk aplikasi individual. AKS dapat mencapai fungsionalitas yang sama tetapi memerlukan fungsionalitas asli Kubernetes melalui sumber daya api layanan Kubernetes tempat Anda dapat mengatur nilai untuk loadBalancerSourceRanges.

Kontrol akses jaringan dan dampak sumber daya Container Apps AKS Aplikasi Web untuk Kontainer
Pembatasan alamat IP masuk bawaan ✅ ❌ ✅
Pemakaian sumber daya - Mengonsumsi sumber daya kluster -

Nota

AKS mendukung pembatasan alamat IP masuk, tetapi Anda menggunakan fitur asli Kubernetes untuk mengimplementasikan kemampuan ini daripada kontrol asli Azure, tidak seperti layanan Azure lainnya.

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 untuk 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.

Integrasi rahasia Container Apps AKS Aplikasi Web untuk Kontainer
Integrasi Key Vault ✅ ✅ ✅

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Dukungan identitas terkelola

Aplikasi dapat menggunakan identitas terkelola untuk mengautentikasi ke layanan yang dilindungi ID Microsoft Entra tanpa harus menggunakan kunci atau rahasia. Aplikasi Kontainer dan Aplikasi Web untuk Kontainer menyediakan dukungan bawaan asli Azure untuk identitas terkelola tingkat aplikasi. Dukungan identitas terkelola tingkat aplikasi untuk AKS dicapai melalui ID Beban Kerja Microsoft Entra. AKS juga memerlukan identitas terkelola terkait infrastruktur untuk memungkinkan operasi kluster bagi Kubelet, pesawat kontrol, dan berbagai add-on AKS.

Laporan identitas terkelola Container Apps AKS Aplikasi Web untuk Kontainer
Dukungan identitas yang dikelola oleh infrastruktur Tidak tersedia ✅ Tidak tersedia
Dukungan untuk identitas terkelola pada penarikan kontainer ✅ ✅ ✅
Dukungan identitas yang dikelola aplikasi ✅ ✅ ✅

Untuk informasi selengkapnya, lihat sumber daya berikut ini:

Perlindungan ancaman dan penilaian kerentanan dengan Defender untuk Kontainer

Perlindungan terhadap ancaman dan kerentanan juga penting. Ini adalah praktik terbaik untuk menggunakan Defender untuk Container. Penilaian kerentanan didukung di registri kontainer Azure. Akibatnya, layanan kontainer Azure apa pun dapat menggunakannya, tidak hanya yang dijelaskan dalam artikel ini. Namun, perlindungan runtime Defender untuk container hanya tersedia untuk AKS.

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

Fitur keamanan Container Apps AKS Aplikasi Web untuk Kontainer
Perlindungan ancaman runtime ❌ ✅ ❌

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

Penilaian kerentanan citra kontainer bukan pemindaian waktu nyata. Registri kontainer Azure dipindai secara berkala.

Garis besar keamanan

Sebagian besar layanan kontainer Azure biasanya mengintegrasikan penawaran keamanan Azure. Perlu diingat bahwa set fitur keamanan hanyalah bagian kecil dari penerapan keamanan cloud. Untuk informasi selengkapnya tentang cara menerapkan keamanan untuk layanan kontainer, lihat garis besar keamanan khusus layanan berikut:

Nota

Kluster Otomatis AKS dikonfigurasi dengan pengaturan keamanan tertentu. Pastikan pengaturan tersebut selaras dengan kebutuhan beban kerja Anda.

Well-Architected Framework untuk perlindungan keamanan

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

Untuk panduan keamanan yang lebih lengkap tentang AKS, lihat Praktik terbaik AKS.

Pertimbangan operasional

Agar berhasil menjalankan beban kerja dalam produksi, Anda 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, setiap pembaruan menimbulkan risiko kegagalan. Bagian ini dan bagian berikutnya menjelaskan pertimbangan utama untuk tiga layanan kontainer mengenai tanggung jawab bersama antara pelanggan dan platform.

Sebagai layanan Kubernetes terkelola, AKS 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 menggunakan fitur saluran peningkatan otomatis kluster untuk memastikan bahwa kluster Anda up-to-date. Untuk informasi selengkapnya tentang panduan operasi hari kedua AKS, lihat Patch dan memperbarui kluster AKS.

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

Memperbarui tanggung jawab Container Apps AKS AKS Otomatis Aplikasi Web untuk Kontainer
Pembaruan sarana kontrol Plattform Pelanggan Plattform Plattform
Pemutakhiran dan perbaikan host Plattform Pelanggan Plattform Plattform
Pembaruan dan patch citra kontainer Pelanggan Pelanggan Pelanggan Pelanggan

Pembaruan gambar kontainer

Terlepas dari solusi kontainer Azure, Anda bertanggung jawab atas gambar kontainer Anda 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 for Containers untuk kontainer Azure Container Registry.

Skalabilitas

Penskalakan digunakan untuk menyesuaikan kapasitas sumber daya untuk memenuhi permintaan. Ini 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 yang berskala vertikal

Penskalaan vertikal mengacu pada kemampuan untuk meningkatkan atau mengurangi infrastruktur yang ada, seperti CPU komputasi 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. Penawaran ini bervariasi dan dapat memberlakukan batasan tambahan.

Untuk AKS, tinjau ukuran untuk komputer virtual (VM) dalam dokumentasi Azure dan pembatasan AKS untuk setiap wilayah.

Artikel berikut ini memberikan detail tentang penawaran SKU untuk Aplikasi Kontainer dan App Service:

Skalabilitas infrastruktur horizontal

Penskalakan horizontal mengacu pada kemampuan untuk meningkatkan atau mengurangi kapasitas dengan menambahkan atau menghapus komponen infrastruktur, seperti simpul VM. Selama peningkatan atau penurunan skala, tier Konsumsi Aplikasi Kontainer mengabstraksi VM yang mendasarinya. Untuk layanan kontainer Azure yang tersisa, Anda mengelola strategi penskalaan horizontal dengan menggunakan API Resource Manager standar.

Penskalaan keluar dan masuk melibatkan penyeimbangan ulang instance, yang dapat meningkatkan risiko terjadinya downtime. Risikonya lebih kecil daripada risiko terkait dengan penskalaan vertikal. Terlepas dari itu, Anda bertanggung jawab untuk memastikan bahwa aplikasi Anda dapat menangani kegagalan. Anda juga bertanggung jawab untuk menerapkan penyiapan dan penutupan aplikasi yang halus guna mencegah gangguan operasi.

Fleksibilitas infrastruktur Container Apps AKS Aplikasi Web untuk Kontainer
Penyempurnaan dan peluasan skala infrastruktur - Paket konsumsi: Tidak tersedia

- Paket khusus: Dapat dikonfigurasi		 Dapat Dikonfigurasi Dapat Dikonfigurasi
Provisi perangkat keras yang fleksibel - Paket konsumsi: Tidak tersedia

- Paket khusus: Diabstraksi dengan profil beban kerja		 SKU VM apa pun Abstrak, 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

Penyesuaian skala infrastruktur dan aplikasi biasanya didorong oleh konsumsi sumber daya, seperti CPU dan memori. Beberapa solusi kontainer juga dapat menskalakan jumlah instans kontainer berdasarkan metrik khusus aplikasi, seperti permintaan HTTP. Misalnya, AKS dan Container Apps dapat menskalakan instans kontainer berdasarkan antrean pesan melalui penskalaan otomatis berbasis peristiwa (KEDA) Kubernetes 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 Azure. Aplikasi Web untuk Kontainer tidak mendukung konfigurasi penskala kustom seperti KEDA.

Model skalabilitas Container Apps AKS Aplikasi Web untuk Kontainer
Peluasan skala kontainer HTTP, TCP, atau berbasis metrik (CPU, memori, atau berbasis peristiwa) Berbasis metrik (CPU, memori, atau kustom) Manual, berbasis metrik, atau otomatis
Skalabilitas berbasis peristiwa Ya. Dirancang khusus untuk cloud. Ya. Dirancang khusus untuk cloud. Konfigurasi tambahan diperlukan. Ya. Khusus sumber daya Azure.

AKS Otomatis memungkinkan autoscaler pod horizontal, KEDA, dan autoscaler pod vertikal secara default.

Kemampuan Mengamati

Instrumentasi beban kerja

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

  • Instrumentasi otomatis: Tidak diperlukan perubahan kode

  • Instrumentasi manual: Perubahan kode minimal yang diperlukan untuk mengintegrasikan dan mengonfigurasi SDK dan klien

    Metode instrumentasi Container Apps AKS Aplikasi Web untuk Kontainer
    Instrumentasi otomatis melalui platform ❌ ❌ Dukungan parsial*
    Instrumentasi otomatis melalui agen ❌ Dukungan parsial* Tidak tersedia
    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 lebih lanjut, baca artikel berikut:

Instrumentasi dalam kode aplikasi adalah tanggung jawab pengembang aplikasi, sehingga tidak bergantung pada solusi kontainer Azure apa pun. Gunakan OpenTelemetry dengan Application Insights.

Catatan dan metrik

Semua layanan kontainer Azure menyediakan fungsionalitas log dan metrik aplikasi dan platform. Log aplikasi adalah log konsol yang dihasilkan beban kerja Anda. Log platform menangkap peristiwa yang terjadi di tingkat platform, di luar lingkup aplikasi Anda, seperti penskalaan dan penyebaran. Metrik adalah nilai numerik yang menjelaskan beberapa aspek sistem pada titik waktu tertentu. Metrik membantu Anda memantau dan memperingatkan performa dan kesehatan sistem.

Azure Monitor adalah layanan pengelogan dan metrik utama di Azure yang terintegrasi dengan layanan ini. Azure Monitor menggunakan log sumber daya untuk memisahkan log dari sumber yang berbeda ke dalam kategori dan mengumpulkan metrik untuk memberikan wawasan tentang performa sumber daya. Salah satu cara untuk menentukan log dan metrik mana yang tersedia dari setiap layanan Azure adalah dengan meninjau kategori log sumber daya dan metrik yang tersedia untuk setiap layanan.

Fitur pengamatan Container Apps AKS AKS Otomatis Aplikasi Web untuk Kontainer
Dukungan untuk streaming log ✅ ✅ ✅ ✅
Dukungan untuk Azure Monitor ✅ ✅ ✅ ✅
Azure Monitor catatan sumber daya - Konsol

- Sistem		 API Server Kubernetes, Audit, Penjadwal, dan Pengaturan Skala Otomatis Kluster Sama seperti AKS ConsoleLogs, HTTPLogs, dan EnvironmentPlatformLogs
Pengumpulan dan pemantauan metrik Metrik melalui Azure Monitor Metrik kustom melalui metrik Dapr. Metrik melalui Azure Monitor Metrik kustom melalui Prometheus (memerlukan penyiapan manual). Prometheus Terkelola yang telah dikonfigurasi sebelumnya untuk pengumpulan metrik dan Grafana Terkelola untuk visualisasi. Metrik melalui Azure Monitor Metrik melalui Azure Monitor
Prometheus dan Grafana yang telah dikonfigurasi sebelumnya ❌ Memerlukan penyiapan manual. Prometheus yang terkelola dan Grafana yang terkelola dikonfigurasi sebelumnya secara default. ❌

Pertimbangkan metrik dan log untuk layanan berikut:

  • Container Apps mengabstraksi semua log Kubernetes internalnya ke dalam dua kategori: log konsol, yang berisi log kontainer beban kerja, dan log sistem, yang berisi semua log terkait platform. Untuk metrik, Container Apps terintegrasi dengan Azure Monitor untuk mengumpulkan metrik standar dan mendukung metrik kustom melalui integrasi Dapr untuk skenario tingkat lanjut.

  • AKS menyediakan log terkait Kubernetes dan kontrol terperinci atas apa yang dicatat. AKS mempertahankan kompatibilitas penuh dengan alat klien Kubernetes untuk streaming log, seperti kubectl. Untuk metrik, AKS terintegrasi dengan Azure Monitor untuk mengumpulkan metrik kluster dan simpul. Anda dapat mengumpulkan metrik kustom dengan menggunakan Prometheus dan memvisualisasikannya dengan Grafana, tetapi tindakan ini memerlukan penyiapan dan konfigurasi manual.

  • AKS Automatic telah dikonfigurasi sebelumnya dengan alat pemantauan tertentu. Ini menggunakan Managed Prometheus untuk pengumpulan metrik dan Managed Grafana untuk visualisasi. Metrik kluster dan aplikasi dikumpulkan secara otomatis dan dapat divisualisasikan. AKS Otomatis juga terintegrasi dengan Azure Monitor untuk mengumpulkan log dan metrik.

  • Web App for Containers menyediakan beberapa 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 AppServicePlatformLogs kategori log. Kategori penting lainnya adalah AppServiceEnvironmentPlatformLogs, yang mencatat peristiwa seperti penskalakan dan perubahan konfigurasi. Metrik dikumpulkan melalui Azure Monitor, yang memungkinkan Anda memantau performa aplikasi dan penggunaan sumber daya.

Kerangka Kerja Arsitektur Tepat untuk Keunggulan Operasional

Artikel ini berfokus pada perbedaan utama di antara fitur layanan kontainer. Tinjau 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 caching, pemulangan ulang, pola pemutus rangkaian, dan uji kesehatan sistem. Di tingkat infrastruktur, Azure bertanggung jawab untuk menangani kegagalan fisik, seperti kegagalan perangkat keras dan pemadaman listrik, di pusat data. Kegagalan masih dapat 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 SLA dan zona ketersediaan.

SLA

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

Azure menyediakan banyak SLA untuk layanan tertentu. Tidak ada yang namanya ketersediaan layanan total karena kegagalan dapat terjadi dalam perangkat lunak, perangkat keras, atau bahkan peristiwa alam seperti badai dan gempa bumi. SLA bukan jaminan tetapi komitmen yang didukung secara finansial ke tingkat ketersediaan yang ditentukan.

Untuk SLA dan detail, unduh dokumen SLA terbaru untuk layanan online Microsoft. Untuk mempelajari cara menginterpretasikan SLA dan menggunakannya sebagai input teknik, lihat Cara membaca perjanjian tingkat layanan.

Tingkat gratis versus tingkat berbayar

Umumnya, tingkat gratis layanan Azure tidak menyediakan SLA, yang menjadikannya pilihan hemat biaya untuk lingkungan nonproduksi. Namun, ini adalah praktik terbaik bagi lingkungan produksi 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.

  • Lapisan data: Pool node menggunakan SLA yang mendasari untuk SKU VM.

  • Zona ketersediaan: Ada SLA yang berbeda untuk dua tingkat operasional, tergantung apakah kluster AKS mengaktifkan zona ketersediaan dan apakah beberapa instans berjalan di berbagai zona ketersediaan.

Saat Anda menggunakan beberapa layanan Azure, tujuan tingkat layanan komposit mungkin berbeda dari dan lebih rendah dari SLA individual.

Redundansi dengan zona ketersediaan

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

Azure memiliki zona ketersediaan di setiap negara atau 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 Container Apps 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 memanfaatkan sepenuhnya dukungan zona ketersediaan, sebarkan beban kerja yang memiliki setidaknya tiga instans kontainer yang didistribusikan 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. Bagian lainnya adalah mengontrol bagaimana platform hosting merespons ketika kegagalan terjadi.

Untuk lebih memahami jenis pemeriksaan kesehatan Kubernetes, pertimbangkan opsi bawaan berikut:

  • Startup: Memeriksa apakah aplikasi berhasil dimulai

  • Kesiapan: Memeriksa apakah aplikasi siap untuk menangani permintaan masuk

  • Keakuratan: Memeriksa apakah aplikasi berjalan dan responsif

Pertimbangan penting lainnya adalah seberapa sering pemeriksaan kesehatan tersebut diminta dari aplikasi, atau granularitas internalnya. Jika Anda memiliki interval panjang antara permintaan ini, Anda mungkin terus mengelola lalu lintas hingga instance dianggap bermasalah.

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

Kemampuan pemeriksaan kesehatan Aplikasi Kontainer AKS Aplikasi Web untuk Kontainer
Pemeriksaan startup ✅ ✅ Dukungan parsial
Pemeriksaan kesiapan ✅ ✅ ❌
Pemeriksaan keaktifan ✅ ✅ ✅
Interval granularitas Detik Detik 1 menit
Dukungan protokol - HTTP dan HTTPS

-TCP		 - HTTP dan HTTPS

-TCP

- gRPC		 HTTP dan HTTPS

Pemeriksaan kesehatan paling mudah diterapkan di Aplikasi Web untuk Kontainer. Pertimbangkan faktor berikut:

  • Probe startup-nya bawaan 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 pengecekan kesehatan pada interval satu menit. Anda tidak dapat mengubah interval.

  • Ambang minimum yang dapat Anda tetapkan agar instans yang tidak sehat dapat 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.

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

Penyembuhan otomatis

Mengidentifikasi instans kontainer yang buruk dan menghentikan lalu lintas ke instans tersebut hanyalah awal. Langkah selanjutnya adalah menerapkan penyembuhan otomatis. Penyembuhan otomatis adalah proses memulai ulang aplikasi untuk mencoba pulih dari keadaan tidak sehat. Pertimbangkan perbandingan layanan kontainer berikut:

  • 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 baru akan menggantikannya. Penyembuhan otomatis memantau dan menghidupkan ulang instans. Ini tidak terkait langsung dengan pemeriksaan kesehatan. Penyembuhan otomatis 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 tanpa waktu henti

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 tanpa henti tetapi dengan cara yang berbeda.

Strategi penyebaran Container Apps AKS Aplikasi Web untuk Kontainer
Strategi tanpa waktu henti Pembaruan bergulir Pembaruan bergulir, ditambah semua strategi Kubernetes lainnya Penyebaran slot

Arsitektur aplikasi juga harus mendukung penyebaran zero-downtime.

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 menggunakan semua sumber daya dan meninggalkan aplikasi lain dalam keadaan buruk.

Cakupan sumber daya Container Apps AKS Aplikasi Web untuk Kontainer
Batas sumber daya (CPU atau memori) Untuk setiap aplikasi dan kontainer Untuk setiap aplikasi, kontainer, dan namespace Untuk setiap paket 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 gibibyte (GiB) RAM tempat 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 untuk setiap 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 memiliki tujuan yang mirip dengan namespace Kubernetes.

  • AKS: Anda dapat memilih kombinasi vCPU dan memori selama simpul Anda memiliki perangkat keras untuk mendukungnya. Anda juga dapat membatasi sumber daya di tingkat namespace jika Anda ingin menyegmentasi kluster Anda dengan cara itu.

Well-Architected Framework 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 ini:

Kesimpulan

Solusi yang dirancang dengan baik menciptakan fondasi untuk beban kerja yang sukses. Keputusan arsitektur dapat berkembang seiring pertumbuhan beban kerja dan tim berkembang dalam perjalanan cloud mereka. Beberapa pilihan, terutama yang terkait dengan jaringan, sulit untuk dibatalkan tanpa waktu jeda atau penerapan ulang yang signifikan.

Saat Anda membandingkan layanan kontainer Azure, tema yang jelas muncul. AKS memaparkan infrastruktur yang paling mendasar, yang memberikan kontrol dan konfigurasi maksimum. AKS mengontrol keseimbangan dan kesederhanaan secara otomatis dengan mengotomatiskan banyak tugas operasi.

Jumlah overhead operasional dan kompleksitas sangat bervariasi untuk beban kerja AKS. Beberapa tim secara signifikan mengurangi overhead dengan menggunakan add-on, ekstensi, dan fitur peningkatan otomatis yang dikelola Microsoft. Tim lain lebih suka kontrol kluster penuh untuk memanfaatkan ekstensibilitas penuh Kubernetes dan ekosistem CNCF. Misalnya, meskipun Microsoft menyediakan Flux sebagai ekstensi GitOps terkelola, banyak tim memilih untuk menyiapkan dan mengoperasikan ArgoCD sendiri.

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

Aplikasi Kontainer dan Aplikasi Web untuk Kontainer adalah penawaran PaaS yang menyediakan tingkat infrastruktur yang dikelola Microsoft yang serupa. Namun, Container Apps lebih dekat ke Kubernetes dan menyediakan kemampuan cloud-native tambahan untuk penemuan layanan, penskalaan otomatis berbasis peristiwa, dan integrasi Dapr . Teams yang tidak memerlukan fitur ini dan terbiasa dengan model jaringan dan penyebaran App Service mungkin lebih memilih Aplikasi Web untuk Kontainer.

Generalisasi dapat membantu mempersempit daftar layanan kontainer Azure untuk dipertimbangkan. Namun, Anda juga harus memverifikasi pilihan Anda dengan meninjau persyaratan individual secara rinci dan mencocokkannya dengan fitur khusus layanan.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

Kontributor lain:

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

  • Last updated on