Menggunakan Pengontrol Ingress Application Gateway dengan kluster Azure Kubernetes Service multipenyewa

Azure Application Gateway

Azure Key Vault

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Bastion

Solusi ini menggunakan Azure Web Application Firewall (WAF) untuk membantu memberikan perlindungan terpusat untuk aplikasi web yang Anda sebarkan pada kluster Azure Kubernetes Service (AKS) multipenyewa. WAF membantu melindungi dari eksploitasi dan kerentanan umum.

Anda dapat menggunakan kebijakan WAF di Azure Application Gateway untuk membantu melindungi aplikasi web dari serangan berbahaya, seperti injeksi SQL dan pembuatan skrip lintas situs. Metode ini membantu melindungi aplikasi web yang berjalan pada kluster AKS dan diekspos melalui Application Gateway Ingress Controller (AGIC). Kebijakan WAF pada Application Gateway telah dikonfigurasi sebelumnya dengan Set Aturan Inti Open Worldwide Application Security Project (OWASP) (CRS) dan mendukung versi CRS OWASP lainnya. Anda juga dapat membuat aturan kustom.

Sistem

Unduh file Visio arsitektur ini.

Alur kerja

• Arsitektur ini menggunakan templat Azure Resource Manager pendamping (templat ARM) untuk menyebarkan jaringan virtual baru yang memiliki empat subnet:

  • AksSubnet menghosting kluster AKS.
  • VmSubnet menghosting komputer virtual jumpbox (VM) dan titik akhir privat.
  • AppGatewaySubnet menghosting tingkat APPLICATION Gateway WAF2.
  • AzureBastionSubnet menghosting Azure Bastion.

• Kluster AKS menggunakan identitas terkelola yang ditentukan pengguna untuk membuat lebih banyak sumber daya, seperti load balancer dan disk terkelola, di Azure. Anda dapat menggunakan templat ARM untuk menyebarkan kluster AKS yang memiliki fitur berikut:

  • Driver Container Storage Interface (CSI) untuk disk Azure dan Azure Files
  • Integrasi Microsoft Entra yang dikelola AKS
  • Kontrol akses berbasis peran Azure (RBAC) untuk Otorisasi Kubernetes
  • Identitas terkelola sebagai pengganti perwakilan layanan
  • ID Beban Kerja Microsoft Entra
  • Kebijakan jaringan Azure
  • Add-on wawasan kontainer Azure Monitor
  • Add-on AGIC
  • Alokasi dinamis alamat IP dan dukungan subnet yang ditingkatkan

• Kluster AKS memiliki kumpulan simpul berikut:

  • Kumpulan simpul sistem hanya menghosting pod dan layanan sistem penting. Simpul pekerja memiliki taint simpul yang mencegah pod aplikasi dijadwalkan pada kumpulan simpul ini.
  • Kumpulan simpul pengguna menghosting beban kerja dan artefak pengguna.

• VM disebarkan di jaringan virtual yang sama yang menghosting kluster AKS. Saat Anda menyebarkan AKS sebagai kluster privat, administrator sistem dapat menggunakan VM ini untuk mengelola kluster melalui alat baris perintah Kubernetes. Log diagnostik boot VM disimpan di akun Azure Storage.

• Host Azure Bastion menyediakan konektivitas Secure Shell (SSH) yang aman dan mulus ke VM jumpbox, langsung di portal Azure melalui Secure Sockets Layer (SSL). Solusi ini menggunakan Azure Container Registry untuk membangun, menyimpan, dan mengelola gambar dan artefak kontainer, seperti bagan Helm.

• Arsitektur mencakup gateway aplikasi yang digunakan pengontrol ingress. Gateway aplikasi disebarkan ke subnet khusus dan diekspos ke internet publik melalui alamat IP publik yang dibagikan semua beban kerja penyewa. Kebijakan WAF membantu melindungi beban kerja penyewa dari serangan berbahaya.

  Kebijakan WAF dikaitkan dengan gateway aplikasi di tingkat akar dan di tingkat pendengar HTTP. Kebijakan dikonfigurasi dalam mode pencegahan dan menggunakan OWASP 3.1 untuk memblokir intrusi dan serangan yang dideteksi aturan. Penyerang menerima 403 pengecualian akses tidak sah, dan koneksi ditutup. Mode pencegahan mencatat serangan-serangan tersebut di log WAF.

• Beban kerja yang berjalan di AKS menggunakan brankas kunci sebagai penyimpanan rahasia untuk mengambil kunci, sertifikat, dan rahasia melalui pustaka klien, Secrets Store CSI Driver, atau Dapr. Azure Private Link memungkinkan beban kerja AKS mengakses solusi platform as a service (PaaS) Azure, seperti Azure Key Vault, melalui titik akhir privat di jaringan virtual.

• Arsitektur ini mencakup titik akhir privat ke komponen berikut:

  • Akun Azure Blob Storage
  • Registri Kontainer
  • Gudang Kunci
  • Server API kluster Kubernetes, jika Anda menggunakan kluster AKS privat

• Arsitektur ini juga mencakup zona DNS privat untuk menyelesaikan nama domain yang sepenuhnya memenuhi syarat (FQDN) dari layanan PaaS ke alamat IP privat dari titik akhir privat terkait. Arsitektur ini mencakup zona DNS privat untuk menyelesaikan titik akhir privat ke komponen berikut:

  • Akun Blob Storage
  • Registri Kontainer
  • Gudang Kunci
  • API Server Kubernetes, jika Anda menyebarkan kluster sebagai privat

• Tautan jaringan virtual ada antara jaringan virtual yang menghosting kluster AKS dan zona DNS privat sebelumnya. Ruang kerja Analitik Log mengumpulkan log dan metrik diagnostik dari sumber berikut:

  • Kluster AKS
  • The jumpbox VM
  • Application Gateway
  • Gudang Kunci
  • Kelompok keamanan jaringan Azure

Komponen

• Container Registry adalah layanan registri Docker privat terkelola yang didasarkan pada Docker Registry 2.0 sumber terbuka. Anda dapat menggunakan registri kontainer Azure dengan alur pengembangan dan penyebaran kontainer yang ada. Atau gunakan tugas Container Registry untuk membuat gambar kontainer di Azure. Anda dapat membangun sesuai permintaan atau mengotomatiskan build sepenuhnya dengan pemicu, seperti penerapan kode sumber dan pembaruan gambar dasar.

• AKS menyederhanakan penyebaran kluster Kubernetes terkelola di Azure dengan membongkar overhead operasional ke Azure. Sebagai layanan Kube yang dihosting, Azure menangani tugas-tugas penting, seperti pemantauan dan pemeliharaan kesehatan. Azure mengelola simpul sarana kontrol Kubernetes, sehingga Anda hanya mengelola dan memelihara simpul agen.

• Key Vault membantu menyimpan dan mengontrol akses ke rahasia dengan aman, seperti kunci API, kata sandi, sertifikat, dan kunci kriptografi. Anda dapat menggunakan Key Vault untuk menyediakan, mengelola, dan menyebarkan sertifikat Keamanan Lapisan Transportasi (TLS) atau SSL publik dan privat dengan mudah, dan menggunakannya dengan Azure dan sumber daya internal Anda yang terhubung.

• Application Gateway adalah penyeimbang beban lalu lintas web yang dapat Anda gunakan untuk mengelola lalu lintas masuk yang masuk ke aplikasi web hilir dan REST API. Penyeimbang beban tradisional beroperasi pada lapisan transportasi, yaitu Open Systems Interconnection (OSI) lapisan 4, untuk menangani lalu lintas yang menggunakan Protokol Kontrol Transmisi (TCP) dan Protokol Datagram Pengguna (UDP). Mereka merutekan lalu lintas berdasarkan alamat IP sumber dan port ke alamat IP dan port tujuan. Gateway aplikasi adalah penyeimbang beban di lapisan aplikasi, yaitu OSI lapisan 7.

• WAF adalah layanan yang membantu memberikan perlindungan terpusat aplikasi web dari eksploitasi dan kerentanan umum. WAF didasarkan pada aturan dari OWASP CRS. Anda dapat menggunakan WAF untuk membuat aturan kustom yang dievaluasi untuk setiap permintaan yang melewati kebijakan. Aturan ini memiliki prioritas yang lebih tinggi daripada aturan lainnya dalam kumpulan aturan terkelola. Aturan kustom berisi nama aturan, prioritas aturan, dan array kondisi pencocokan. Jika permintaan memenuhi kondisi ini, WAF mengizinkan atau memblokir permintaan berdasarkan aturan.

• Azure Bastion adalah PaaS yang dikelola penuh yang Anda sediakan di dalam jaringan virtual. Azure Bastion membantu menyediakan konektivitas Remote Desktop Protocol (RDP) dan SSH yang aman dan lancar ke VM di jaringan virtual Anda, langsung dari portal Azure melalui TLS.

• Azure Virtual Machines menyediakan sumber daya komputasi sesuai permintaan dan dapat diskalakan yang memberi Anda fleksibilitas virtualisasi tanpa harus membeli dan memelihara perangkat keras fisik.

• Azure Virtual Network adalah blok bangunan dasar untuk jaringan privat di Azure. Dengan Virtual Network, sumber daya Azure, seperti VM, dapat berkomunikasi satu sama lain, internet, dan jaringan lokal dengan cara yang lebih aman. Jaringan virtual Azure mirip dengan jaringan tradisional lokal, tetapi mencakup manfaat infrastruktur Azure, seperti skalabilitas, ketersediaan, dan isolasi.

• Antarmuka jaringan virtual membantu membangun komunikasi antara Azure VM dan internet, Azure, dan sumber daya lokal. Anda dapat menambahkan beberapa kartu antarmuka jaringan ke satu Azure VM sehingga VM anak dapat memiliki perangkat antarmuka jaringan khusus dan alamat IP mereka sendiri.

• Disk terkelola Azure adalah volume penyimpanan tingkat blok yang dikelola Azure di Azure VM. Jenis disk termasuk Azure Ultra Disk Storage, Azure Premium SSD, Azure Standard SSD, dan Azure Standard HDD.

• Blob Storage adalah solusi penyimpanan objek Microsoft untuk cloud. Blob Storage dioptimalkan untuk menyimpan data tidak terstruktur dalam jumlah besar. Data yang tidak terstruktur adalah data yang tidak mematuhi model atau definisi data tertentu, seperti data teks atau data biner.

• Private Link menyediakan titik akhir privat di jaringan virtual Anda sehingga Anda dapat mengakses layanan Azure PaaS, seperti Blob Storage dan Key Vault, dan mengakses layanan milik pelanggan yang dihosting Azure atau layanan mitra.

Alternatif

Saat Anda mengekspos beban kerja yang Anda host di kluster AKS, Anda memiliki beberapa solusi yang perlu dipertimbangkan. Alih-alih menggunakan AGIC, Anda dapat menggunakan Application Gateway untuk Kontainer atau ingress NGINX terkelola dengan add-on perutean aplikasi. Alternatif ini menyediakan kemampuan yang berbeda untuk membantu mengelola dan mengamankan lalu lintas ke kluster AKS Anda.

Arsitektur ini menginstal AGIC melalui add-on AGIC untuk AKS. Anda juga dapat menginstal AGIC melalui bagan Helm. Saat membuat penyiapan baru, Anda dapat menggunakan satu baris di Azure CLI untuk menyebarkan gateway aplikasi baru dan kluster AKS baru. Metode ini memungkinkan AGIC sebagai add-on. Add-on adalah layanan terkelola penuh, yang memberikan manfaat tambahan, seperti pembaruan otomatis dan peningkatan dukungan. Ini juga dianggap sebagai add-on kelas satu, yang menyediakan integrasi yang lebih baik dengan AKS. Microsoft mendukung kedua metode penyebaran untuk AGIC.

Add-on AGIC disebarkan sebagai pod di kluster AKS Anda. Tetapi ada beberapa perbedaan antara versi penyebaran Helm dan versi add-on AGIC. Daftar berikut mencakup perbedaan antara kedua versi tersebut:

• Anda tidak dapat memodifikasi nilai penyebaran Helm pada add-on AKS:

  • Properti usePrivateIp diatur ke false secara default. Anda tidak dapat menimpa nilai ini melalui use-private-ip anotasi.
  • Add-on tidak mendukung shared opsi konfigurasi.

• AGIC yang disebarkan Helm mendukung ProhibitedTargets, yang berarti bahwa AGIC dapat mengonfigurasi gateway aplikasi khusus untuk kluster AKS tanpa memengaruhi ujung belakang lain yang ada.

• Add-on AGIC adalah layanan terkelola, sehingga secara otomatis diperbarui ke versi terbaru. Jika Anda menyebarkan AGIC melalui Helm, Anda harus memperbarui AGIC secara manual.

• Anda hanya dapat menyebarkan satu add-on AGIC untuk setiap kluster AKS. Setiap add-on AGIC hanya dapat menargetkan satu instans Application Gateway. Untuk penyebaran yang memerlukan lebih dari satu AGIC untuk setiap kluster, atau beberapa AGIC yang menargetkan satu instans Application Gateway, Anda dapat menggunakan AGIC yang disebarkan Helm.

Satu instans AGIC dapat menyerap peristiwa dari beberapa namespace Layanan Kubernetes. Jika administrator AKS menggunakan gateway aplikasi sebagai ingress, semua namespace menggunakan instans Application Gateway yang sama. Satu instalasi AGIC memantau namespace yang dapat diakses dan mengonfigurasi gateway aplikasi yang terkait dengannya. Untuk informasi selengkapnya, lihat Mengaktifkan dukungan multi-namespace dalam kluster AKS dengan AGIC.

Untuk mengaktifkan dukungan beberapa namespace layanan, lakukan langkah-langkah berikut:

1. Ubah file helm-config.yaml dengan salah satu cara berikut:

• watchNamespace Hapus kunci sepenuhnya dari file helm-config.yaml untuk membiarkan AGIC mengamati semua namespace.
• Atur watchNamespace ke string kosong untuk memungkinkan AGIC mengamati semua namespace.
• Tambahkan beberapa namespace yang dipisahkan oleh koma, seperti watchNamespace: default,secondNamespace, untuk membiarkan AGIC mengamati namespace ini secara eksklusif.

2. Terapkan perubahan templat Helm dengan skrip ini: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Setelah Anda menyebarkan AGIC dengan kemampuan untuk mengamati beberapa namespace, AGIC melakukan tindakan berikut:

1. Mencantumkan sumber daya ingress dari semua namespace yang dapat diakses
2. Memfilter sumber daya ingress yang dianotasi dengan kubernetes.io/ingress.class: azure/application-gateway
3. Menyusun konfigurasi Application Gateway gabungan
4. Menerapkan konfigurasi ke gateway aplikasi terkait melalui Azure Resource Manager

Detail skenario

Arsitektur ini berbagi kluster Kubernetes multipenyewa di antara beberapa pengguna dan beban kerja yang umumnya disebut sebagai penyewa. Definisi ini mencakup tim atau divisi yang berbeda dalam organisasi yang berbagi kluster Kubernetes. Ini juga termasuk kluster yang dibagikan oleh instans per pelanggan dari aplikasi perangkat lunak sebagai layanan (SaaS). Kluster multi-tenant adalah alternatif untuk mengelola sejumlah kluster yang dikhususkan bagi single-tenant. Operator kluster Kubernetes multipenyewa harus mengisolasi penyewa satu sama lain. Isolasi ini meminimalkan kerusakan yang dapat dilakukan penyewa yang disusupi atau berbahaya ke kluster dan penyewa lain. Ketika beberapa pengguna atau tim berbagi kluster yang sama yang memiliki jumlah simpul tetap, satu tim mungkin menggunakan lebih banyak sumber daya daripada yang mereka butuhkan. Administrator dapat menggunakan kuota sumber daya untuk mengatasi masalah ini.

Ketika Anda berencana untuk membangun kluster AKS multipenyewa, Anda harus mempertimbangkan lapisan isolasi sumber daya yang disediakan Kubernetes, termasuk kluster, namespace, node, pod, dan isolasi kontainer. Anda juga harus mempertimbangkan implikasi keamanan yang timbul dari membagikan berbagai jenis sumber daya di antara beberapa penyewa. Misalnya, jika Anda menjadwalkan pod dari penyewa yang berbeda pada simpul yang sama, Anda dapat mengurangi jumlah komputer yang Anda butuhkan di kluster. Di sisi lain, Anda mungkin perlu mencegah terjadinya kolokasi pada beban kerja tertentu. Misalnya, Anda mungkin tidak mengizinkan kode yang tidak tepercaya dari luar organisasi Anda untuk berjalan pada node yang sama dengan kontainer yang memproses informasi sensitif. Anda dapat menggunakan Azure Policy sehingga hanya registri tepercaya yang dapat disebarkan ke AKS.

Kubernetes tidak dapat menjamin isolasi yang sangat aman antara penyewa, tetapi menawarkan fitur yang memberikan keamanan yang memadai untuk kasus penggunaan tertentu. Sebagai praktik terbaik, Anda harus memisahkan setiap penyewa dan sumber daya Kubernetes mereka ke dalam ruang nama tersendiri. Anda kemudian dapat menggunakan RBAC Kubernetes dan kebijakan jaringan untuk membantu memberlakukan isolasi penyewa. Misalnya, diagram berikut menunjukkan model penyedia SaaS khas yang menghosting beberapa instans aplikasi yang sama pada kluster yang sama, satu untuk setiap penyewa. Setiap aplikasi berada di namespace terpisah. Ketika penyewa membutuhkan tingkat isolasi fisik yang lebih tinggi dan performa yang dijamin, beban kerja mereka dapat disebarkan ke sekumpulan node khusus, kumpulan khusus, atau bahkan kluster khusus.

AGIC adalah aplikasi Kubernetes, sehingga pelanggan AKS dapat menggunakan gateway aplikasi untuk mengekspos aplikasi kontainer mereka ke internet. AGIC memantau kluster Kubernetes yang dihosting dan terus memperbarui gateway aplikasi sehingga layanan yang dipilih terekspos ke internet. AGIC berjalan dalam podnya sendiri pada instans AKS pelanggan. AGIC memantau subset sumber daya Kubernetes untuk perubahan. Status kluster AKS diterjemahkan ke konfigurasi khusus Application Gateway dan diterapkan ke Resource Manager. Arsitektur ini menjelaskan praktik yang terbukti untuk menyebarkan kluster AKS publik atau privat melalui gateway aplikasi dan add-on AGIC.

Satu instans AGIC dapat menyerap peristiwa dari dan mengamati beberapa namespace layanan. Jika administrator AKS menggunakan Application Gateway sebagai ingress, semua namespace menggunakan instans Application Gateway yang sama. Satu instalasi AGIC memantau namespace yang dapat diakses dan mengonfigurasi gateway aplikasi yang terkait dengannya.

Kemungkinan kasus penggunaan

Gunakan AGIC untuk mengekspos dan melindungi beban kerja yang menghadap internet yang berjalan pada kluster AKS di lingkungan multipenyewa.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Beberapa pertimbangan ini tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini. Pertimbangan ini mencakup panduan keamanan, performa, ketersediaan, keandalan, penyimpanan, penjadwal, jala layanan, dan pemantauan.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

Pertimbangan ketersediaan dan keandalan ini tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini. Pertimbangkan beberapa cara berikut untuk mengoptimalkan ketersediaan untuk kluster dan beban kerja AKS Anda.

Kontainer

• Gunakan probe kesehatan Kubernetes untuk memeriksa apakah kontainer Anda aktif dan sehat:

  • Probe liveness mengindikasikan apakah kontainer sedang berjalan. Jika pemeriksaan keaktifan gagal, kubelet mengakhiri kontainer, dan kontainer tunduk pada kebijakan hidupkan ulang.

  • Probe readiness mengindikasikan apakah kontainer siap untuk menanggapi permintaan. Jika pemeriksaan kesiapan gagal, pengontrol titik akhir akan menghapus alamat IP pod dari titik akhir semua layanan yang cocok dengan pod. Status default kesiapan sebelum penundaan awal adalah kegagalan.

  • StartupProbe menunjukkan apakah aplikasi dalam kontainer dimulai. Jika Anda memiliki pemeriksaan startup, semua pemeriksaan lainnya dinonaktifkan hingga pemeriksaan startup berhasil. Jika pemeriksaan startup gagal, kubelet menghentikan kontainer, dan kontainer tunduk pada kebijakan hidupkan ulang.

• Ketidaksesuaian sumber daya dapat memengaruhi ketersediaan layanan. Menetapkan batasan sumber daya kontainer sehingga tidak ada satu kontainer pun yang dapat membanjiri memori kluster dan sumber daya CPU. Anda dapat menggunakan diagnostik AKS untuk mengidentifikasi masalah apa pun dalam kluster.

• Gunakan batas sumber daya untuk membatasi total sumber daya yang dialokasikan ke kontainer sehingga satu kontainer tidak dapat menghilangkan yang lain.

Registri Kontainer

• Simpan gambar kontainer di Container Registry. Gunakan replikasi geografis Container Registry untuk mereplikasi registri secara geografis ke setiap wilayah AKS. Geo-replikasi adalah fitur Premium SKU Container Registry.

• Pindai citra kontainer Anda untuk kerentanan. Hanya sebarkan gambar yang lulus validasi. Perbarui gambar dasar dan durasi aplikasi secara teratur, lalu pindahkan kembali beban kerja di kluster AKS.

• Batasi registri gambar yang dapat digunakan oleh pod dan penyebaran. Batasi akses ke registri tepercaya tempat Anda dapat memvalidasi dan mengontrol gambar yang tersedia.

• Pindai gambar kontainer untuk kerentanan sebagai bagian dari alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) sebelum Anda menerbitkan gambar ke Container Registry. Saat Anda menggunakan gambar dasar untuk gambar aplikasi, gunakan otomatisasi untuk membangun gambar baru saat Anda memperbarui gambar dasar. Gambar dasar biasanya mencakup perbaikan keamanan, jadi Anda harus memperbarui gambar kontainer aplikasi hilir apa pun. Kami menyarankan agar Anda mengintegrasikan Pertahanan Microsoft untuk Kontainer ke dalam alur kerja CI/CD. Untuk informasi selengkapnya, lihat Mengotomatiskan build gambar kontainer.

• Gunakan tugas Container Registry untuk mengotomatiskan OS dan patching kerangka kerja untuk kontainer Docker Anda. Tugas Container Registry mendukung proses build otomatis saat Anda memperbarui gambar dasar kontainer. Misalnya, Anda dapat menambal OS atau kerangka kerja aplikasi di salah satu gambar dasar Anda.

Ketahanan intrawilayah

• Pertimbangkan untuk menyebarkan kumpulan simpul kluster AKS Anda di semua zona ketersediaan dalam suatu wilayah. Gunakan Azure Standard Load Balancer atau Application Gateway di depan kumpulan simpul Anda. Topologi ini memberikan ketahanan yang lebih baik jika terjadi pemadaman pusat data tunggal. Metode ini mendistribusikan node kluster di beberapa pusat data yang berada di tiga zona ketersediaan terpisah dalam suatu wilayah.

• Aktifkan redundansi zona di Container Registry untuk ketahanan intra-wilayah dan ketersediaan tinggi.

• Gunakan batasan penyebaran topologi pod untuk mengontrol cara Anda menyebarkan pod di seluruh kluster AKS di antara domain kegagalan, seperti wilayah, zona ketersediaan, dan simpul.

• Pertimbangkan untuk menggunakan perjanjian tingkat layanan waktu aktif (SLA) untuk kluster AKS yang menghosting beban kerja misi penting. SLA waktu aktif adalah fitur opsional untuk mengaktifkan SLA yang didukung secara finansial dan lebih tinggi untuk kluster. Waktu aktif SLA menjamin ketersediaan 99,95% dari titik akhir server API Kubernetes untuk kluster yang menggunakan zona ketersediaan. Ini menjamin ketersediaan 99,90% untuk kluster yang tidak menggunakan zona ketersediaan. AKS menggunakan replika simpul sarana kontrol di seluruh domain pembaruan dan kesalahan untuk membantu memenuhi persyaratan SLA.

Pemulihan bencana dan keberlangsungan bisnis

• Pertimbangkan untuk menerapkan solusi Anda ke setidaknya dua wilayah Azure berpasangan dalam sebuah geografi. Anda juga harus mengadopsi load balancer global, seperti Azure Traffic Manager atau Azure Front Door. Gabungkan load balancer dengan metode perutean aktif/aktif atau aktif/pasif untuk membantu menjamin kelangsungan bisnis dan pemulihan bencana.

• Skrip, dokumen, dan uji secara berkala setiap proses failover regional di lingkungan jaminan kualitas. Proses failover membantu menghindari masalah yang tidak dapat diprediksi jika pemadaman di wilayah utama memengaruhi layanan inti.

• Gunakan pengujian proses failover untuk memverifikasi apakah pendekatan pemulihan bencana memenuhi target tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Sertakan proses dan intervensi manual dalam verifikasi Anda.

• Uji prosedur fail-back untuk memastikan bahwa prosedur tersebut berfungsi seperti yang diharapkan.

• Simpan gambar kontainer Anda di Container Registry. Replikasi geografis registri ke setiap wilayah AKS. Untuk informasi selengkapnya, lihat Replikasi geografis di Container Registry.

• Hindari menyimpan status layanan di dalam kontainer, jika memungkinkan. Sebagai gantinya, gunakan Azure PaaS yang mendukung replikasi multiregion.

• Siapkan dan uji cara memigrasikan penyimpanan Anda dari wilayah utama ke wilayah cadangan jika Anda menggunakan Azure Storage.

• Pertimbangkan untuk menggunakan GitOps untuk menyebarkan konfigurasi kluster. GitOps memberikan keseragaman antara kluster pemulihan primer dan bencana dan juga menyediakan cara cepat untuk membangun kembali kluster baru jika Anda kehilangan kluster.

• Pertimbangkan pencadangan dan pemulihan konfigurasi kluster dengan menggunakan alat, seperti cadangan AKS atau Velero.

Lapisan infrastruktur manajemen komunikasi antar layanan (service mesh)

• Pertimbangkan untuk menggunakan jala layanan sumber terbuka, seperti Istio, Linkerd, atau Consul, di kluster AKS Anda. Jala layanan menggunakan TLS bersama untuk membantu meningkatkan pengamatan, keandalan, dan keamanan untuk layanan mikro Anda. Anda juga dapat menerapkan strategi pemisahan lalu lintas, penyebaran biru/hijau dan penyebaran kenari. Jala layanan adalah lapisan infrastruktur khusus yang membantu membuat komunikasi layanan-ke-layanan lebih aman, cepat, dan andal. Untuk informasi selengkapnya, lihat Add-on AKS mesh layanan Istio.

• Pertimbangkan untuk mengadopsi Dapr untuk membangun aplikasi berbasis layanan mikro yang tangguh, baik tanpa status maupun stateful. Anda dapat menggunakan bahasa pemrograman dan kerangka kerja pengembang apa saja.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.

Pertimbangan keamanan tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini.

Multitenant

• Desain kluster AKS untuk multi-tenant. Kubernetes menyediakan fitur yang dapat Anda gunakan untuk mengisolasi tim dan beban kerja secara logis di kluster yang sama. Berikan jumlah hak istimewa paling sedikit untuk sumber daya yang dibutuhkan setiap tim. Namespace di Kubernetes membuat batas isolasi logis.

• Gunakan isolasi logis untuk memisahkan tim dan proyek. Minimalkan jumlah kluster AKS fisik yang Anda sebarkan untuk mengisolasi tim atau aplikasi. Pemisahan kluster yang logis biasanya memberikan kepadatan pod yang lebih tinggi daripada kluster yang terisolasi secara fisik.

• Gunakan kumpulan node khusus, atau kluster AKS khusus setiap kali Anda perlu menerapkan isolasi fisik yang ketat. Misalnya, Anda dapat mendedikasikan kumpulan simpul pekerja atau seluruh kluster untuk tim atau penyewa di lingkungan multipenyewa.

  Gunakan kombinasi taint dan toleransi untuk mengontrol penyebaran pod ke kumpulan simpul tertentu. Anda hanya dapat memberi taint node di AKS pada saat pembuatan kumpulan simpul. Atau, Anda dapat menggunakan label dan pemilih nodePool untuk menyebarkan beban kerja ke kumpulan simpul tertentu saja.

Keamanan jaringan

• Buat titik akhir privat untuk layanan PaaS apa pun yang digunakan beban kerja AKS Anda, seperti Key Vault, Azure Bus Layanan, atau Azure SQL Database. Titik akhir privat membantu memastikan bahwa lalu lintas antara aplikasi dan layanan ini tidak terekspos ke internet publik. Untuk informasi selengkapnya, lihat Apa itu Private Link.

• Konfigurasikan sumber daya ingress Kubernetes Anda untuk mengekspos beban kerja melalui HTTPS. Gunakan subdomain terpisah dan sertifikat digital untuk setiap penyewa. AGIC secara otomatis mengonfigurasi listener Application Gateway untuk penghentian SSL.

• Konfigurasikan Application Gateway untuk menggunakan kebijakan WAF untuk membantu melindungi beban kerja yang menghadap publik yang berjalan pada AKS dari serangan berbahaya.

• Gunakan jaringan Azure CNI di AKS untuk berintegrasi dengan jaringan virtual atau jaringan lokal yang ada. Model jaringan ini memungkinkan pemisahan sumber daya dan kontrol yang lebih besar di lingkungan perusahaan.

• Gunakan kebijakan jaringan untuk memisahkan dan mengamankan komunikasi intralayanan dengan mengendalikan komponen mana yang dapat berkomunikasi satu sama lain. Secara default, semua pod dalam kluster Kubernetes dapat mengirim dan menerima traffic tanpa batasan. Untuk meningkatkan keamanan, Anda dapat menggunakan kebijakan jaringan Azure atau kebijakan jaringan Calico untuk menentukan aturan yang mengontrol arus lalu lintas antara berbagai layanan mikro. Untuk informasi selengkapnya, lihat Kebijakan jaringan.

• Jangan mengekspos konektivitas jarak jauh ke node AKS Anda. Buat host bastion, atau jumpbox, di jaringan virtual manajemen. Gunakan host bastion untuk merutekan lalu lintas ke klaster AKS Anda dengan aman ke tugas manajemen jarak jauh.

• Pertimbangkan untuk menggunakan rentang alamat IP resmi di AKS untuk membuat kluster AKS privat di lingkungan produksi Anda. Jika Anda tidak dapat menggunakan kluster AKS privat, setidaknya akses aman ke server API.

• Gabungkan Azure DDoS Protection dengan praktik terbaik desain aplikasi untuk menyediakan fitur mitigasi DDoS yang ditingkatkan dan pertahanan ekstra terhadap serangan DDoS. Aktifkan DDoS Protection pada jaringan virtual perimeter.

Autentikasi dan otorisasi

• Sebarkan kluster AKS dengan integrasi Microsoft Entra. Untuk informasi selengkapnya, lihat Integrasi Microsoft Entra yang dikelola AKS. MICROSOFT Entra ID mempusatkan komponen manajemen identitas.

• Gunakan Kubernetes RBAC untuk menentukan izin yang dimiliki pengguna atau grup ke sumber daya dalam kluster. Gunakan peran atau ClusterRoles dan pengikatan untuk mencakup pengguna atau grup ke jumlah izin paling sedikit yang diperlukan. Integrasikan RBAC Kubernetes dengan MICROSOFT Entra ID sehingga setiap perubahan status pengguna atau keanggotaan grup secara otomatis memperbarui akses ke sumber daya kluster. Untuk informasi selengkapnya, lihat RBAC Kubernetes.

• Gunakan RBAC Azure untuk menentukan izin minimum yang diperlukan yang dimiliki pengguna dan grup untuk sumber daya AKS dalam satu atau beberapa langganan. Untuk informasi selengkapnya, lihat Menggunakan Azure RBAC untuk Otorisasi Kubernetes.

• Gunakan ID Beban Kerja Microsoft Entra untuk menetapkan identitas terkelola ke layanan mikro individual untuk akses sumber daya Azure. Layanan mikro kemudian dapat mengakses sumber daya terkelola, seperti Key Vault, SQL Database, Bus Layanan, dan Azure Cosmos DB. Layanan mikro tidak perlu menyimpan dan mengambil string koneksi atau kredensial dari rahasia Kubernetes.

• Gunakan Driver Secrets Store CSI untuk Key Vault untuk mengakses rahasia, seperti kredensial dan string koneksi, dari Key Vault daripada dari rahasia Kubernetes.

• Gabungkan blok penyusun penyimpanan rahasia Dapr dengan penyimpanan Key Vault dan identitas terkelola di Kubernetes untuk mengambil rahasia, seperti kredensial dan string koneksi, dari Key Vault.

Beban kerja dan kluster

• Amankan akses ke server API Kubernetes untuk membantu mengamankan kluster Anda. Integrasikan RBAC Kubernetes dengan MICROSOFT Entra ID untuk mengontrol akses ke server API. Gunakan kontrol ini untuk membantu mengamankan AKS dengan cara yang sama seperti yang Anda lakukan untuk akses langganan Azure.

• Batasi akses ke tindakan yang dapat dilakukan kontainer. Gunakan fitur Penerimaan Keamanan Pod untuk mengaktifkan otorisasi terperinci dari pembuatan dan pembaruan pod. Berikan jumlah izin paling sedikit, dan hindari penggunaan root atau eskalasi istimewa. Untuk informasi selengkapnya, lihat Mengamankan akses pod ke sumber daya.

• Hindari menjalankan kontainer sebagai pengguna root jika memungkinkan.

• Gunakan modul keamanan kernel AppArmor Linux untuk membatasi tindakan yang dapat dilakukan oleh kontainer.

• Tingkatkan kluster AKS Anda ke versi Kubernetes terbaru secara teratur untuk memanfaatkan fitur baru dan perbaikan bug.

• Gunakan daemonset kured untuk mengawasi reboot, cordon, dan simpul pengurasan yang tertunda, dan terapkan pembaruan. Meskipun AKS dapat mengunduh dan menginstal perbaikan keamanan pada setiap node Linux secara otomatis, tetapi AKS tidak dapat me-reboot node secara otomatis ketika diperlukan. Untuk node Windows Server, lakukan operasi peningkatan AKS secara teratur untuk menutup dan menguras Pod dengan aman, serta menyebarkan node yang termutakhir.

• Pertimbangkan untuk menggunakan protokol transportasi aman HTTPS dan gRPC untuk semua komunikasi intra-pod. Dan gunakan mekanisme autentikasi yang lebih canggih yang tidak mengharuskan Anda mengirim kredensial biasa pada setiap permintaan, seperti Open Authorization (OAuth) atau JSON Web Tokens (JWT). Buat komunikasi intra-layanan yang lebih aman dengan menggunakan jala layanan, seperti Istio, Linkerd, atau Consul. Atau Anda dapat menggunakan Dapr.

Registri Kontainer

Pindai gambar kontainer Anda untuk kerentanan, dan hanya sebarkan gambar yang lulus validasi. Perbarui citra dasar dan runtime aplikasi secara teratur. Kemudian sebarkan ulang beban kerja di kluster AKS. Alur kerja penyebaran CI/CD Anda harus menyertakan proses untuk memindai gambar kontainer. Anda dapat menggunakan keamanan Pertahanan Microsoft untuk DevOps untuk memindai kode kerentanan dalam alur otomatis Anda selama fase build dan penyebaran. Atau, Anda dapat menggunakan alat seperti Prisma Cloud atau Aqua untuk memindai dan hanya mengizinkan gambar terverifikasi untuk disebarkan.

Pengoptimalan Biaya

Pengoptimalan Biaya adalah tentang melihat cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Biaya arsitektur ini tergantung pada aspek konfigurasi, seperti komponen berikut:

• Tingkat layanan
• Skalabilitas, atau jumlah instans yang dialokasikan layanan secara dinamis untuk mendukung permintaan tertentu
• Skrip Automation
• Tingkat pemulihan bencana Anda

Setelah Anda menilai aspek-aspek ini, gunakan kalkulator harga Azure untuk memperkirakan biaya Anda. Untuk informasi selengkapnya, lihat prinsip-prinsip Well-Architected Framework dari Pengoptimalan Biaya.

Keunggulan Operasional

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.

Penyimpanan

• Pertimbangkan untuk menyebarkan kluster AKS Anda dengan disk OS ephemeral yang memberikan latensi baca dan tulis yang lebih rendah, bersama dengan penskalaan simpul dan peningkatan kluster yang lebih cepat.

• Pahami kebutuhan aplikasi Anda untuk memilih penyimpanan yang tepat. Gunakan penyimpanan berkinerja tinggi yang didukung SSD untuk beban kerja produksi. Rencanakan sistem penyimpanan berbasis jaringan, seperti Azure Files, ketika beberapa pod perlu mengakses file yang sama secara bersamaan. Untuk informasi selengkapnya, lihat Opsi Microsoft Azure Storage untuk aplikasi di AKS.

• Rencanakan permintaan aplikasi Anda sehingga Anda menyebarkan ukuran simpul yang sesuai. Setiap ukuran simpul mendukung jumlah maksimum disk. Ukuran simpul yang berbeda juga menyediakan jumlah penyimpanan lokal dan bandwidth jaringan yang berbeda.

• Gunakan penyediaan dinamis. Untuk mengurangi overhead manajemen dan mengaktifkan penskalakan, jangan buat dan tetapkan volume persisten secara statis. Di kelas penyimpanan Anda, tentukan kebijakan klaim ulang yang sesuai untuk meminimalkan biaya penyimpanan yang tidak perlu setelah Anda menghapus pod.

DevOps

• Gunakan sistem DevOps, seperti GitHub Actions atau Azure DevOps, untuk menyebarkan beban kerja Anda ke AKS melalui bagan Helm di alur CI/CD. Untuk informasi selengkapnya, lihat Membangun dan menyebarkan ke AKS.

• Perkenalkan pengujian A/B dan penyebaran kenari dalam manajemen siklus hidup aplikasi Anda untuk menguji aplikasi dengan benar sebelum Anda memperkenalkannya kepada semua pengguna. Ada beberapa teknik yang dapat digunakan untuk membagi lalu lintas di berbagai versi layanan yang sama.

• Sebagai alternatif, Anda dapat menggunakan kemampuan manajemen lalu lintas yang disediakan oleh jala layanan. Untuk informasi selengkapnya, lihat Manajemen lalu lintas Istio.

• Gunakan Container Registry atau penyimpanan registri lain, seperti Docker Hub, untuk membuat katalog dan melayani gambar Docker privat yang Anda sebarkan ke kluster. AKS dapat menggunakan identitas Microsoft Entra-nya untuk mengautentikasi dengan Container Registry.

• Jika Anda perlu mengubah pengaturan pada Application Gateway, lakukan perubahan dengan menggunakan konfigurasi yang diekspos pada pengontrol ingress atau objek Kubernetes lainnya, seperti menggunakan anotasi yang didukung. Setelah Anda menautkan gateway aplikasi ke AGIC, pengontrol ingress menyinkronkan dan mengontrol hampir semua konfigurasi gateway tersebut. Jika Anda langsung mengonfigurasi Application Gateway secara imperatif atau melalui infrastruktur sebagai kode, pengontrol ingress akhirnya menimpa perubahan tersebut.

Pemantauan

• Pertimbangkan opsi pemantauan terintegrasi Azure untuk memantau status kesehatan kluster AKS dan beban kerja.

• Konfigurasikan semua layanan PaaS, seperti Container Registry dan Key Vault, untuk mengumpulkan log dan metrik diagnostik dan mengirimkannya ke Analitik Log.

Efisiensi Performa

Efisiensi Performa adalah kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan yang ditempatkan di atasnya oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Performa.

Pertimbangan performa tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini:

• Untuk beban kerja latensi rendah, pertimbangkan untuk menyebarkan kumpulan simpul khusus dalam grup penempatan kedekatan. Saat Anda menyebarkan aplikasi di Azure, instans VM yang tersebar di seluruh wilayah atau zona ketersediaan membuat latensi jaringan, yang dapat memengaruhi performa keseluruhan aplikasi Anda. Grup penempatan kedekatan adalah pengelompokan logis yang dapat Anda gunakan untuk memastikan sumber daya komputasi Azure secara fisik terletak dekat satu sama lain. Beberapa kasus penggunaan, seperti game, simulasi rekayasa, dan perdagangan frekuensi tinggi, memerlukan latensi rendah dan tugas yang selesai dengan cepat. Untuk skenario komputasi berkinerja tinggi seperti ini, pertimbangkan untuk menggunakan grup penempatan kedekatan untuk kumpulan simpul kluster Anda.

• Selalu gunakan gambar kontainer yang lebih kecil karena Anda dapat membuat build yang lebih cepat. Gambar yang lebih kecil juga kurang rentan terhadap serangan vektor karena permukaan serangan yang berkurang.

• Gunakan penskalaan otomatis Kubernetes untuk menskalakan jumlah simpul pekerja secara dinamis dalam kluster AKS saat lalu lintas meningkat. Dengan Autoscaler Pod Horizontal dan autoscaler kluster, volume simpul dan pod disesuaikan secara dinamis secara real time agar sesuai dengan kondisi lalu lintas dan untuk menghindari waktu henti yang menyebabkan masalah kapasitas. Untuk informasi selengkapnya, lihat Menggunakan autoscaler kluster di AKS.

Penjadwal

• Tinjau dan terapkan praktik terbaik bagi operator kluster dan pengembang aplikasi untuk membangun dan menjalankan aplikasi dengan sukses di AKS.

• Rencanakan dan terapkan kuota sumber daya di tingkat namespace untuk semua namespace. Jika Pod tidak menentukan permintaan dan batasan sumber daya, maka tolak penyebaran. Pantau penggunaan sumber daya, lalu sesuaikan kuota sesuai kebutuhan. Ketika beberapa tim atau penyewa berbagi kluster AKS yang memiliki jumlah simpul tetap, Anda dapat menggunakan kuota sumber daya untuk menetapkan berbagi sumber daya yang adil untuk setiap tim atau penyewa.

• Mengadopsi rentang batas untuk membatasi alokasi sumber daya ke pod atau kontainer dalam namespace layanan, dalam hal CPU dan memori.

• Tentukan permintaan dan batas sumber daya secara eksplisit untuk penggunaan CPU dan memori untuk pod Anda dalam manifes YAML atau bagan Helm yang Anda gunakan untuk menyebarkan aplikasi. Saat Anda menentukan permintaan sumber daya untuk kontainer dalam pod, penjadwal Kubernetes menggunakan informasi ini untuk memutuskan di node mana pod harus diletakkan. Saat Anda menentukan batas sumber daya untuk kontainer, seperti CPU atau memori, kubelet memberlakukan batas tersebut sehingga kontainer yang sedang berjalan tidak dapat menggunakan lebih banyak sumber daya tersebut daripada batas yang Anda tetapkan.

• Pertahankan ketersediaan aplikasi dengan menentukan anggaran gangguan pod untuk memastikan bahwa jumlah minimum pod tersedia di kluster.

• Gunakan kelas prioritas untuk menunjukkan pentingnya pod. Jika penjadwal tidak dapat menjadwalkan pod, penjadwal mencoba untuk mendahului, atau mengeluarkan pod berprioritas lebih rendah sehingga dapat menjadwalkan pod yang tertunda.

• Gunakan taint dan toleransi Kubernetes untuk menempatkan aplikasi intensif sumber daya pada simpul tertentu dan untuk menghindari masalah tetangga yang bising . Jaga agar sumber daya node tetap tersedia untuk beban kerja yang memerlukannya. Jangan izinkan beban kerja lain dijadwalkan pada simpul.

• Gunakan pemilih simpul, afinitas simpul, atau afinitas antar pod untuk mengontrol penjadwalan pod pada simpul. Gunakan pengaturan afinitas antar-pod dan anti-afinitas untuk mengumpulkan pod yang memiliki komunikasi yang cerewet, untuk menempatkan pod pada node yang berbeda, dan untuk menghindari menjalankan beberapa instans dari jenis pod yang sama pada node yang sama.

Menyebarkan skenario ini

Kode sumber untuk sampel ini tersedia di GitHub. Diagram berikut menunjukkan aplikasi demo yang dapat Anda temukan di repositori AKS multitenant AGIC GitHub.

Unduh file Visio arsitektur ini.

Prasyarat

Untuk penyebaran online, Anda harus memiliki akun Azure terlebih dahulu. Jika Anda tidak memilikinya, buat akun Azure gratis sebelum Memulai.

Sebarkan ke Azure

1. Pastikan Anda memiliki informasi tentang berlangganan Azure.

2. Kloning repositori GitHub workbench:

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. Ikuti petunjuk yang diberikan di file GETSTARTED.md.

Kontributor

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

Penulis utama:

• Paolo Salvatori | Teknisi Layanan Utama

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Praktik terbaik kluster AKS
• Praktik terbaik untuk fitur penjadwal dasar di AKS
• Membuat kluster AKS privat
• Membuat kebijakan WAF untuk Application Gateway
• Perbedaan antara penyebaran Helm dan add-on AKS
• Cara kerja gateway aplikasi

Sumber daya terkait

• Arsitektur garis besar untuk kluster AKS

Solusi ini menggunakan Azure Web Application Firewall (WAF) untuk membantu memberikan perlindungan terpusat untuk aplikasi web yang Anda sebarkan pada kluster Azure Kubernetes Service (AKS) multipenyewa. WAF membantu melindungi dari eksploitasi dan kerentanan umum.

Anda dapat menggunakan kebijakan WAF di Azure Application Gateway untuk membantu melindungi aplikasi web dari serangan berbahaya, seperti injeksi SQL dan pembuatan skrip lintas situs. Metode ini membantu melindungi aplikasi web yang berjalan pada kluster AKS dan diekspos melalui Application Gateway Ingress Controller (AGIC). Kebijakan WAF pada Application Gateway telah dikonfigurasi sebelumnya dengan Set Aturan Inti Open Worldwide Application Security Project (OWASP) (CRS) dan mendukung versi CRS OWASP lainnya. Anda juga dapat membuat aturan kustom.

Sistem

Unduh file Visio arsitektur ini.

Alur kerja

• Arsitektur ini menggunakan templat Azure Resource Manager pendamping (templat ARM) untuk menyebarkan jaringan virtual baru yang memiliki empat subnet:

  • AksSubnet menghosting kluster AKS.
  • VmSubnet menghosting komputer virtual jumpbox (VM) dan titik akhir privat.
  • AppGatewaySubnet menghosting tingkat APPLICATION Gateway WAF2.
  • AzureBastionSubnet menghosting Azure Bastion.

• Kluster AKS menggunakan identitas terkelola yang ditentukan pengguna untuk membuat lebih banyak sumber daya, seperti load balancer dan disk terkelola, di Azure. Anda dapat menggunakan templat ARM untuk menyebarkan kluster AKS yang memiliki fitur berikut:

  • Driver Container Storage Interface (CSI) untuk disk Azure dan Azure Files
  • Integrasi Microsoft Entra yang dikelola AKS
  • Kontrol akses berbasis peran Azure (RBAC) untuk Otorisasi Kubernetes
  • Identitas terkelola sebagai pengganti perwakilan layanan
  • ID Beban Kerja Microsoft Entra
  • Kebijakan jaringan Azure
  • Add-on wawasan kontainer Azure Monitor
  • Add-on AGIC
  • Alokasi dinamis alamat IP dan dukungan subnet yang ditingkatkan

• Kluster AKS memiliki kumpulan simpul berikut:

  • Kumpulan simpul sistem hanya menghosting pod dan layanan sistem penting. Simpul pekerja memiliki taint simpul yang mencegah pod aplikasi dijadwalkan pada kumpulan simpul ini.
  • Kumpulan simpul pengguna menghosting beban kerja dan artefak pengguna.

• VM disebarkan di jaringan virtual yang sama yang menghosting kluster AKS. Saat Anda menyebarkan AKS sebagai kluster privat, administrator sistem dapat menggunakan VM ini untuk mengelola kluster melalui alat baris perintah Kubernetes. Log diagnostik boot VM disimpan di akun Azure Storage.

• Host Azure Bastion menyediakan konektivitas Secure Shell (SSH) yang aman dan mulus ke VM jumpbox, langsung di portal Azure melalui Secure Sockets Layer (SSL). Solusi ini menggunakan Azure Container Registry untuk membangun, menyimpan, dan mengelola gambar dan artefak kontainer, seperti bagan Helm.

• Arsitektur mencakup gateway aplikasi yang digunakan pengontrol ingress. Gateway aplikasi disebarkan ke subnet khusus dan diekspos ke internet publik melalui alamat IP publik yang dibagikan semua beban kerja penyewa. Kebijakan WAF membantu melindungi beban kerja penyewa dari serangan berbahaya.

  Kebijakan WAF dikaitkan dengan gateway aplikasi di tingkat akar dan di tingkat pendengar HTTP. Kebijakan dikonfigurasi dalam mode pencegahan dan menggunakan OWASP 3.1 untuk memblokir intrusi dan serangan yang dideteksi aturan. Penyerang menerima 403 pengecualian akses tidak sah, dan koneksi ditutup. Mode pencegahan mencatat serangan-serangan tersebut di log WAF.

• Beban kerja yang berjalan di AKS menggunakan brankas kunci sebagai penyimpanan rahasia untuk mengambil kunci, sertifikat, dan rahasia melalui pustaka klien, Secrets Store CSI Driver, atau Dapr. Azure Private Link memungkinkan beban kerja AKS mengakses solusi platform as a service (PaaS) Azure, seperti Azure Key Vault, melalui titik akhir privat di jaringan virtual.

• Arsitektur ini mencakup titik akhir privat ke komponen berikut:

  • Akun Azure Blob Storage
  • Registri Kontainer
  • Gudang Kunci
  • Server API kluster Kubernetes, jika Anda menggunakan kluster AKS privat

• Arsitektur ini juga mencakup zona DNS privat untuk menyelesaikan nama domain yang sepenuhnya memenuhi syarat (FQDN) dari layanan PaaS ke alamat IP privat dari titik akhir privat terkait. Arsitektur ini mencakup zona DNS privat untuk menyelesaikan titik akhir privat ke komponen berikut:

  • Akun Blob Storage
  • Registri Kontainer
  • Gudang Kunci
  • API Server Kubernetes, jika Anda menyebarkan kluster sebagai privat

• Tautan jaringan virtual ada antara jaringan virtual yang menghosting kluster AKS dan zona DNS privat sebelumnya. Ruang kerja Analitik Log mengumpulkan log dan metrik diagnostik dari sumber berikut:

  • Kluster AKS
  • The jumpbox VM
  • Application Gateway
  • Gudang Kunci
  • Kelompok keamanan jaringan Azure

Komponen

• Container Registry adalah layanan registri Docker privat terkelola yang didasarkan pada Docker Registry 2.0 sumber terbuka. Anda dapat menggunakan registri kontainer Azure dengan alur pengembangan dan penyebaran kontainer yang ada. Atau gunakan tugas Container Registry untuk membuat gambar kontainer di Azure. Anda dapat membangun sesuai permintaan atau mengotomatiskan build sepenuhnya dengan pemicu, seperti penerapan kode sumber dan pembaruan gambar dasar.

• AKS menyederhanakan penyebaran kluster Kubernetes terkelola di Azure dengan membongkar overhead operasional ke Azure. Sebagai layanan Kube yang dihosting, Azure menangani tugas-tugas penting, seperti pemantauan dan pemeliharaan kesehatan. Azure mengelola simpul sarana kontrol Kubernetes, sehingga Anda hanya mengelola dan memelihara simpul agen.

• Key Vault membantu menyimpan dan mengontrol akses ke rahasia dengan aman, seperti kunci API, kata sandi, sertifikat, dan kunci kriptografi. Anda dapat menggunakan Key Vault untuk menyediakan, mengelola, dan menyebarkan sertifikat Keamanan Lapisan Transportasi (TLS) atau SSL publik dan privat dengan mudah, dan menggunakannya dengan Azure dan sumber daya internal Anda yang terhubung.

• Application Gateway adalah penyeimbang beban lalu lintas web yang dapat Anda gunakan untuk mengelola lalu lintas masuk yang masuk ke aplikasi web hilir dan REST API. Penyeimbang beban tradisional beroperasi pada lapisan transportasi, yaitu Open Systems Interconnection (OSI) lapisan 4, untuk menangani lalu lintas yang menggunakan Protokol Kontrol Transmisi (TCP) dan Protokol Datagram Pengguna (UDP). Mereka merutekan lalu lintas berdasarkan alamat IP sumber dan port ke alamat IP dan port tujuan. Gateway aplikasi adalah penyeimbang beban di lapisan aplikasi, yaitu OSI lapisan 7.

• WAF adalah layanan yang membantu memberikan perlindungan terpusat aplikasi web dari eksploitasi dan kerentanan umum. WAF didasarkan pada aturan dari OWASP CRS. Anda dapat menggunakan WAF untuk membuat aturan kustom yang dievaluasi untuk setiap permintaan yang melewati kebijakan. Aturan ini memiliki prioritas yang lebih tinggi daripada aturan lainnya dalam kumpulan aturan terkelola. Aturan kustom berisi nama aturan, prioritas aturan, dan array kondisi pencocokan. Jika permintaan memenuhi kondisi ini, WAF mengizinkan atau memblokir permintaan berdasarkan aturan.

• Azure Bastion adalah PaaS yang dikelola penuh yang Anda sediakan di dalam jaringan virtual. Azure Bastion membantu menyediakan konektivitas Remote Desktop Protocol (RDP) dan SSH yang aman dan lancar ke VM di jaringan virtual Anda, langsung dari portal Azure melalui TLS.

• Azure Virtual Machines menyediakan sumber daya komputasi sesuai permintaan dan dapat diskalakan yang memberi Anda fleksibilitas virtualisasi tanpa harus membeli dan memelihara perangkat keras fisik.

• Azure Virtual Network adalah blok bangunan dasar untuk jaringan privat di Azure. Dengan Virtual Network, sumber daya Azure, seperti VM, dapat berkomunikasi satu sama lain, internet, dan jaringan lokal dengan cara yang lebih aman. Jaringan virtual Azure mirip dengan jaringan tradisional lokal, tetapi mencakup manfaat infrastruktur Azure, seperti skalabilitas, ketersediaan, dan isolasi.

• Antarmuka jaringan virtual membantu membangun komunikasi antara Azure VM dan internet, Azure, dan sumber daya lokal. Anda dapat menambahkan beberapa kartu antarmuka jaringan ke satu Azure VM sehingga VM anak dapat memiliki perangkat antarmuka jaringan khusus dan alamat IP mereka sendiri.

• Disk terkelola Azure adalah volume penyimpanan tingkat blok yang dikelola Azure di Azure VM. Jenis disk termasuk Azure Ultra Disk Storage, Azure Premium SSD, Azure Standard SSD, dan Azure Standard HDD.

• Blob Storage adalah solusi penyimpanan objek Microsoft untuk cloud. Blob Storage dioptimalkan untuk menyimpan data tidak terstruktur dalam jumlah besar. Data yang tidak terstruktur adalah data yang tidak mematuhi model atau definisi data tertentu, seperti data teks atau data biner.

• Private Link menyediakan titik akhir privat di jaringan virtual Anda sehingga Anda dapat mengakses layanan Azure PaaS, seperti Blob Storage dan Key Vault, dan mengakses layanan milik pelanggan yang dihosting Azure atau layanan mitra.

Alternatif

Saat Anda mengekspos beban kerja yang Anda host di kluster AKS, Anda memiliki beberapa solusi yang perlu dipertimbangkan. Alih-alih menggunakan AGIC, Anda dapat menggunakan Application Gateway untuk Kontainer atau ingress NGINX terkelola dengan add-on perutean aplikasi. Alternatif ini menyediakan kemampuan yang berbeda untuk membantu mengelola dan mengamankan lalu lintas ke kluster AKS Anda.

Arsitektur ini menginstal AGIC melalui add-on AGIC untuk AKS. Anda juga dapat menginstal AGIC melalui bagan Helm. Saat membuat penyiapan baru, Anda dapat menggunakan satu baris di Azure CLI untuk menyebarkan gateway aplikasi baru dan kluster AKS baru. Metode ini memungkinkan AGIC sebagai add-on. Add-on adalah layanan terkelola penuh, yang memberikan manfaat tambahan, seperti pembaruan otomatis dan peningkatan dukungan. Ini juga dianggap sebagai add-on kelas satu, yang menyediakan integrasi yang lebih baik dengan AKS. Microsoft mendukung kedua metode penyebaran untuk AGIC.

Add-on AGIC disebarkan sebagai pod di kluster AKS Anda. Tetapi ada beberapa perbedaan antara versi penyebaran Helm dan versi add-on AGIC. Daftar berikut mencakup perbedaan antara kedua versi tersebut:

• Anda tidak dapat memodifikasi nilai penyebaran Helm pada add-on AKS:

  • Properti usePrivateIp diatur ke false secara default. Anda tidak dapat menimpa nilai ini melalui use-private-ip anotasi.
  • Add-on tidak mendukung shared opsi konfigurasi.

• AGIC yang disebarkan Helm mendukung ProhibitedTargets, yang berarti bahwa AGIC dapat mengonfigurasi gateway aplikasi khusus untuk kluster AKS tanpa memengaruhi ujung belakang lain yang ada.

• Add-on AGIC adalah layanan terkelola, sehingga secara otomatis diperbarui ke versi terbaru. Jika Anda menyebarkan AGIC melalui Helm, Anda harus memperbarui AGIC secara manual.

• Anda hanya dapat menyebarkan satu add-on AGIC untuk setiap kluster AKS. Setiap add-on AGIC hanya dapat menargetkan satu instans Application Gateway. Untuk penyebaran yang memerlukan lebih dari satu AGIC untuk setiap kluster, atau beberapa AGIC yang menargetkan satu instans Application Gateway, Anda dapat menggunakan AGIC yang disebarkan Helm.

Satu instans AGIC dapat menyerap peristiwa dari beberapa namespace Layanan Kubernetes. Jika administrator AKS menggunakan gateway aplikasi sebagai ingress, semua namespace menggunakan instans Application Gateway yang sama. Satu instalasi AGIC memantau namespace yang dapat diakses dan mengonfigurasi gateway aplikasi yang terkait dengannya. Untuk informasi selengkapnya, lihat Mengaktifkan dukungan multi-namespace dalam kluster AKS dengan AGIC.

Untuk mengaktifkan dukungan beberapa namespace layanan, lakukan langkah-langkah berikut:

1. Ubah file helm-config.yaml dengan salah satu cara berikut:

• watchNamespace Hapus kunci sepenuhnya dari file helm-config.yaml untuk membiarkan AGIC mengamati semua namespace.
• Atur watchNamespace ke string kosong untuk memungkinkan AGIC mengamati semua namespace.
• Tambahkan beberapa namespace yang dipisahkan oleh koma, seperti watchNamespace: default,secondNamespace, untuk membiarkan AGIC mengamati namespace ini secara eksklusif.

2. Terapkan perubahan templat Helm dengan skrip ini: helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure.

Setelah Anda menyebarkan AGIC dengan kemampuan untuk mengamati beberapa namespace, AGIC melakukan tindakan berikut:

1. Mencantumkan sumber daya ingress dari semua namespace yang dapat diakses
2. Memfilter sumber daya ingress yang dianotasi dengan kubernetes.io/ingress.class: azure/application-gateway
3. Menyusun konfigurasi Application Gateway gabungan
4. Menerapkan konfigurasi ke gateway aplikasi terkait melalui Azure Resource Manager

Detail skenario

Arsitektur ini berbagi kluster Kubernetes multipenyewa di antara beberapa pengguna dan beban kerja yang umumnya disebut sebagai penyewa. Definisi ini mencakup tim atau divisi yang berbeda dalam organisasi yang berbagi kluster Kubernetes. Ini juga termasuk kluster yang dibagikan oleh instans per pelanggan dari aplikasi perangkat lunak sebagai layanan (SaaS). Kluster multi-tenant adalah alternatif untuk mengelola sejumlah kluster yang dikhususkan bagi single-tenant. Operator kluster Kubernetes multipenyewa harus mengisolasi penyewa satu sama lain. Isolasi ini meminimalkan kerusakan yang dapat dilakukan penyewa yang disusupi atau berbahaya ke kluster dan penyewa lain. Ketika beberapa pengguna atau tim berbagi kluster yang sama yang memiliki jumlah simpul tetap, satu tim mungkin menggunakan lebih banyak sumber daya daripada yang mereka butuhkan. Administrator dapat menggunakan kuota sumber daya untuk mengatasi masalah ini.

Ketika Anda berencana untuk membangun kluster AKS multipenyewa, Anda harus mempertimbangkan lapisan isolasi sumber daya yang disediakan Kubernetes, termasuk kluster, namespace, node, pod, dan isolasi kontainer. Anda juga harus mempertimbangkan implikasi keamanan yang timbul dari membagikan berbagai jenis sumber daya di antara beberapa penyewa. Misalnya, jika Anda menjadwalkan pod dari penyewa yang berbeda pada simpul yang sama, Anda dapat mengurangi jumlah komputer yang Anda butuhkan di kluster. Di sisi lain, Anda mungkin perlu mencegah terjadinya kolokasi pada beban kerja tertentu. Misalnya, Anda mungkin tidak mengizinkan kode yang tidak tepercaya dari luar organisasi Anda untuk berjalan pada node yang sama dengan kontainer yang memproses informasi sensitif. Anda dapat menggunakan Azure Policy sehingga hanya registri tepercaya yang dapat disebarkan ke AKS.

Kubernetes tidak dapat menjamin isolasi yang sangat aman antara penyewa, tetapi menawarkan fitur yang memberikan keamanan yang memadai untuk kasus penggunaan tertentu. Sebagai praktik terbaik, Anda harus memisahkan setiap penyewa dan sumber daya Kubernetes mereka ke dalam ruang nama tersendiri. Anda kemudian dapat menggunakan RBAC Kubernetes dan kebijakan jaringan untuk membantu memberlakukan isolasi penyewa. Misalnya, diagram berikut menunjukkan model penyedia SaaS khas yang menghosting beberapa instans aplikasi yang sama pada kluster yang sama, satu untuk setiap penyewa. Setiap aplikasi berada di namespace terpisah. Ketika penyewa membutuhkan tingkat isolasi fisik yang lebih tinggi dan performa yang dijamin, beban kerja mereka dapat disebarkan ke sekumpulan node khusus, kumpulan khusus, atau bahkan kluster khusus.

AGIC adalah aplikasi Kubernetes, sehingga pelanggan AKS dapat menggunakan gateway aplikasi untuk mengekspos aplikasi kontainer mereka ke internet. AGIC memantau kluster Kubernetes yang dihosting dan terus memperbarui gateway aplikasi sehingga layanan yang dipilih terekspos ke internet. AGIC berjalan dalam podnya sendiri pada instans AKS pelanggan. AGIC memantau subset sumber daya Kubernetes untuk perubahan. Status kluster AKS diterjemahkan ke konfigurasi khusus Application Gateway dan diterapkan ke Resource Manager. Arsitektur ini menjelaskan praktik yang terbukti untuk menyebarkan kluster AKS publik atau privat melalui gateway aplikasi dan add-on AGIC.

Satu instans AGIC dapat menyerap peristiwa dari dan mengamati beberapa namespace layanan. Jika administrator AKS menggunakan Application Gateway sebagai ingress, semua namespace menggunakan instans Application Gateway yang sama. Satu instalasi AGIC memantau namespace yang dapat diakses dan mengonfigurasi gateway aplikasi yang terkait dengannya.

Kemungkinan kasus penggunaan

Gunakan AGIC untuk mengekspos dan melindungi beban kerja yang menghadap internet yang berjalan pada kluster AKS di lingkungan multipenyewa.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Beberapa pertimbangan ini tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini. Pertimbangan ini mencakup panduan keamanan, performa, ketersediaan, keandalan, penyimpanan, penjadwal, jala layanan, dan pemantauan.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

Pertimbangan ketersediaan dan keandalan ini tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini. Pertimbangkan beberapa cara berikut untuk mengoptimalkan ketersediaan untuk kluster dan beban kerja AKS Anda.

Kontainer

• Gunakan probe kesehatan Kubernetes untuk memeriksa apakah kontainer Anda aktif dan sehat:

  • Probe liveness mengindikasikan apakah kontainer sedang berjalan. Jika pemeriksaan keaktifan gagal, kubelet mengakhiri kontainer, dan kontainer tunduk pada kebijakan hidupkan ulang.

  • Probe readiness mengindikasikan apakah kontainer siap untuk menanggapi permintaan. Jika pemeriksaan kesiapan gagal, pengontrol titik akhir akan menghapus alamat IP pod dari titik akhir semua layanan yang cocok dengan pod. Status default kesiapan sebelum penundaan awal adalah kegagalan.

  • StartupProbe menunjukkan apakah aplikasi dalam kontainer dimulai. Jika Anda memiliki pemeriksaan startup, semua pemeriksaan lainnya dinonaktifkan hingga pemeriksaan startup berhasil. Jika pemeriksaan startup gagal, kubelet menghentikan kontainer, dan kontainer tunduk pada kebijakan hidupkan ulang.

• Ketidaksesuaian sumber daya dapat memengaruhi ketersediaan layanan. Menetapkan batasan sumber daya kontainer sehingga tidak ada satu kontainer pun yang dapat membanjiri memori kluster dan sumber daya CPU. Anda dapat menggunakan diagnostik AKS untuk mengidentifikasi masalah apa pun dalam kluster.

• Gunakan batas sumber daya untuk membatasi total sumber daya yang dialokasikan ke kontainer sehingga satu kontainer tidak dapat menghilangkan yang lain.

Registri Kontainer

• Simpan gambar kontainer di Container Registry. Gunakan replikasi geografis Container Registry untuk mereplikasi registri secara geografis ke setiap wilayah AKS. Geo-replikasi adalah fitur Premium SKU Container Registry.

• Pindai citra kontainer Anda untuk kerentanan. Hanya sebarkan gambar yang lulus validasi. Perbarui gambar dasar dan durasi aplikasi secara teratur, lalu pindahkan kembali beban kerja di kluster AKS.

• Batasi registri gambar yang dapat digunakan oleh pod dan penyebaran. Batasi akses ke registri tepercaya tempat Anda dapat memvalidasi dan mengontrol gambar yang tersedia.

• Pindai gambar kontainer untuk kerentanan sebagai bagian dari alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) sebelum Anda menerbitkan gambar ke Container Registry. Saat Anda menggunakan gambar dasar untuk gambar aplikasi, gunakan otomatisasi untuk membangun gambar baru saat Anda memperbarui gambar dasar. Gambar dasar biasanya mencakup perbaikan keamanan, jadi Anda harus memperbarui gambar kontainer aplikasi hilir apa pun. Kami menyarankan agar Anda mengintegrasikan Pertahanan Microsoft untuk Kontainer ke dalam alur kerja CI/CD. Untuk informasi selengkapnya, lihat Mengotomatiskan build gambar kontainer.

• Gunakan tugas Container Registry untuk mengotomatiskan OS dan patching kerangka kerja untuk kontainer Docker Anda. Tugas Container Registry mendukung proses build otomatis saat Anda memperbarui gambar dasar kontainer. Misalnya, Anda dapat menambal OS atau kerangka kerja aplikasi di salah satu gambar dasar Anda.

Ketahanan intrawilayah

• Pertimbangkan untuk menyebarkan kumpulan simpul kluster AKS Anda di semua zona ketersediaan dalam suatu wilayah. Gunakan Azure Standard Load Balancer atau Application Gateway di depan kumpulan simpul Anda. Topologi ini memberikan ketahanan yang lebih baik jika terjadi pemadaman pusat data tunggal. Metode ini mendistribusikan node kluster di beberapa pusat data yang berada di tiga zona ketersediaan terpisah dalam suatu wilayah.

• Aktifkan redundansi zona di Container Registry untuk ketahanan intra-wilayah dan ketersediaan tinggi.

• Gunakan batasan penyebaran topologi pod untuk mengontrol cara Anda menyebarkan pod di seluruh kluster AKS di antara domain kegagalan, seperti wilayah, zona ketersediaan, dan simpul.

• Pertimbangkan untuk menggunakan perjanjian tingkat layanan waktu aktif (SLA) untuk kluster AKS yang menghosting beban kerja misi penting. SLA waktu aktif adalah fitur opsional untuk mengaktifkan SLA yang didukung secara finansial dan lebih tinggi untuk kluster. Waktu aktif SLA menjamin ketersediaan 99,95% dari titik akhir server API Kubernetes untuk kluster yang menggunakan zona ketersediaan. Ini menjamin ketersediaan 99,90% untuk kluster yang tidak menggunakan zona ketersediaan. AKS menggunakan replika simpul sarana kontrol di seluruh domain pembaruan dan kesalahan untuk membantu memenuhi persyaratan SLA.

Pemulihan bencana dan keberlangsungan bisnis

• Pertimbangkan untuk menerapkan solusi Anda ke setidaknya dua wilayah Azure berpasangan dalam sebuah geografi. Anda juga harus mengadopsi load balancer global, seperti Azure Traffic Manager atau Azure Front Door. Gabungkan load balancer dengan metode perutean aktif/aktif atau aktif/pasif untuk membantu menjamin kelangsungan bisnis dan pemulihan bencana.

• Skrip, dokumen, dan uji secara berkala setiap proses failover regional di lingkungan jaminan kualitas. Proses failover membantu menghindari masalah yang tidak dapat diprediksi jika pemadaman di wilayah utama memengaruhi layanan inti.

• Gunakan pengujian proses failover untuk memverifikasi apakah pendekatan pemulihan bencana memenuhi target tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO). Sertakan proses dan intervensi manual dalam verifikasi Anda.

• Uji prosedur fail-back untuk memastikan bahwa prosedur tersebut berfungsi seperti yang diharapkan.

• Simpan gambar kontainer Anda di Container Registry. Replikasi geografis registri ke setiap wilayah AKS. Untuk informasi selengkapnya, lihat Replikasi geografis di Container Registry.

• Hindari menyimpan status layanan di dalam kontainer, jika memungkinkan. Sebagai gantinya, gunakan Azure PaaS yang mendukung replikasi multiregion.

• Siapkan dan uji cara memigrasikan penyimpanan Anda dari wilayah utama ke wilayah cadangan jika Anda menggunakan Azure Storage.

• Pertimbangkan untuk menggunakan GitOps untuk menyebarkan konfigurasi kluster. GitOps memberikan keseragaman antara kluster pemulihan primer dan bencana dan juga menyediakan cara cepat untuk membangun kembali kluster baru jika Anda kehilangan kluster.

• Pertimbangkan pencadangan dan pemulihan konfigurasi kluster dengan menggunakan alat, seperti cadangan AKS atau Velero.

Lapisan infrastruktur manajemen komunikasi antar layanan (service mesh)

• Pertimbangkan untuk menggunakan jala layanan sumber terbuka, seperti Istio, Linkerd, atau Consul, di kluster AKS Anda. Jala layanan menggunakan TLS bersama untuk membantu meningkatkan pengamatan, keandalan, dan keamanan untuk layanan mikro Anda. Anda juga dapat menerapkan strategi pemisahan lalu lintas, penyebaran biru/hijau dan penyebaran kenari. Jala layanan adalah lapisan infrastruktur khusus yang membantu membuat komunikasi layanan-ke-layanan lebih aman, cepat, dan andal. Untuk informasi selengkapnya, lihat Add-on AKS mesh layanan Istio.

• Pertimbangkan untuk mengadopsi Dapr untuk membangun aplikasi berbasis layanan mikro yang tangguh, baik tanpa status maupun stateful. Anda dapat menggunakan bahasa pemrograman dan kerangka kerja pengembang apa saja.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.

Pertimbangan keamanan tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini.

Multitenant

• Desain kluster AKS untuk multi-tenant. Kubernetes menyediakan fitur yang dapat Anda gunakan untuk mengisolasi tim dan beban kerja secara logis di kluster yang sama. Berikan jumlah hak istimewa paling sedikit untuk sumber daya yang dibutuhkan setiap tim. Namespace di Kubernetes membuat batas isolasi logis.

• Gunakan isolasi logis untuk memisahkan tim dan proyek. Minimalkan jumlah kluster AKS fisik yang Anda sebarkan untuk mengisolasi tim atau aplikasi. Pemisahan kluster yang logis biasanya memberikan kepadatan pod yang lebih tinggi daripada kluster yang terisolasi secara fisik.

• Gunakan kumpulan node khusus, atau kluster AKS khusus setiap kali Anda perlu menerapkan isolasi fisik yang ketat. Misalnya, Anda dapat mendedikasikan kumpulan simpul pekerja atau seluruh kluster untuk tim atau penyewa di lingkungan multipenyewa.

  Gunakan kombinasi taint dan toleransi untuk mengontrol penyebaran pod ke kumpulan simpul tertentu. Anda hanya dapat memberi taint node di AKS pada saat pembuatan kumpulan simpul. Atau, Anda dapat menggunakan label dan pemilih nodePool untuk menyebarkan beban kerja ke kumpulan simpul tertentu saja.

Keamanan jaringan

• Buat titik akhir privat untuk layanan PaaS apa pun yang digunakan beban kerja AKS Anda, seperti Key Vault, Azure Bus Layanan, atau Azure SQL Database. Titik akhir privat membantu memastikan bahwa lalu lintas antara aplikasi dan layanan ini tidak terekspos ke internet publik. Untuk informasi selengkapnya, lihat Apa itu Private Link.

• Konfigurasikan sumber daya ingress Kubernetes Anda untuk mengekspos beban kerja melalui HTTPS. Gunakan subdomain terpisah dan sertifikat digital untuk setiap penyewa. AGIC secara otomatis mengonfigurasi listener Application Gateway untuk penghentian SSL.

• Konfigurasikan Application Gateway untuk menggunakan kebijakan WAF untuk membantu melindungi beban kerja yang menghadap publik yang berjalan pada AKS dari serangan berbahaya.

• Gunakan jaringan Azure CNI di AKS untuk berintegrasi dengan jaringan virtual atau jaringan lokal yang ada. Model jaringan ini memungkinkan pemisahan sumber daya dan kontrol yang lebih besar di lingkungan perusahaan.

• Gunakan kebijakan jaringan untuk memisahkan dan mengamankan komunikasi intralayanan dengan mengendalikan komponen mana yang dapat berkomunikasi satu sama lain. Secara default, semua pod dalam kluster Kubernetes dapat mengirim dan menerima traffic tanpa batasan. Untuk meningkatkan keamanan, Anda dapat menggunakan kebijakan jaringan Azure atau kebijakan jaringan Calico untuk menentukan aturan yang mengontrol arus lalu lintas antara berbagai layanan mikro. Untuk informasi selengkapnya, lihat Kebijakan jaringan.

• Jangan mengekspos konektivitas jarak jauh ke node AKS Anda. Buat host bastion, atau jumpbox, di jaringan virtual manajemen. Gunakan host bastion untuk merutekan lalu lintas ke klaster AKS Anda dengan aman ke tugas manajemen jarak jauh.

• Pertimbangkan untuk menggunakan rentang alamat IP resmi di AKS untuk membuat kluster AKS privat di lingkungan produksi Anda. Jika Anda tidak dapat menggunakan kluster AKS privat, setidaknya akses aman ke server API.

• Gabungkan Azure DDoS Protection dengan praktik terbaik desain aplikasi untuk menyediakan fitur mitigasi DDoS yang ditingkatkan dan pertahanan ekstra terhadap serangan DDoS. Aktifkan DDoS Protection pada jaringan virtual perimeter.

Autentikasi dan otorisasi

• Sebarkan kluster AKS dengan integrasi Microsoft Entra. Untuk informasi selengkapnya, lihat Integrasi Microsoft Entra yang dikelola AKS. MICROSOFT Entra ID mempusatkan komponen manajemen identitas.

• Gunakan Kubernetes RBAC untuk menentukan izin yang dimiliki pengguna atau grup ke sumber daya dalam kluster. Gunakan peran atau ClusterRoles dan pengikatan untuk mencakup pengguna atau grup ke jumlah izin paling sedikit yang diperlukan. Integrasikan RBAC Kubernetes dengan MICROSOFT Entra ID sehingga setiap perubahan status pengguna atau keanggotaan grup secara otomatis memperbarui akses ke sumber daya kluster. Untuk informasi selengkapnya, lihat RBAC Kubernetes.

• Gunakan RBAC Azure untuk menentukan izin minimum yang diperlukan yang dimiliki pengguna dan grup untuk sumber daya AKS dalam satu atau beberapa langganan. Untuk informasi selengkapnya, lihat Menggunakan Azure RBAC untuk Otorisasi Kubernetes.

• Gunakan ID Beban Kerja Microsoft Entra untuk menetapkan identitas terkelola ke layanan mikro individual untuk akses sumber daya Azure. Layanan mikro kemudian dapat mengakses sumber daya terkelola, seperti Key Vault, SQL Database, Bus Layanan, dan Azure Cosmos DB. Layanan mikro tidak perlu menyimpan dan mengambil string koneksi atau kredensial dari rahasia Kubernetes.

• Gunakan Driver Secrets Store CSI untuk Key Vault untuk mengakses rahasia, seperti kredensial dan string koneksi, dari Key Vault daripada dari rahasia Kubernetes.

• Gabungkan blok penyusun penyimpanan rahasia Dapr dengan penyimpanan Key Vault dan identitas terkelola di Kubernetes untuk mengambil rahasia, seperti kredensial dan string koneksi, dari Key Vault.

Beban kerja dan kluster

• Amankan akses ke server API Kubernetes untuk membantu mengamankan kluster Anda. Integrasikan RBAC Kubernetes dengan MICROSOFT Entra ID untuk mengontrol akses ke server API. Gunakan kontrol ini untuk membantu mengamankan AKS dengan cara yang sama seperti yang Anda lakukan untuk akses langganan Azure.

• Batasi akses ke tindakan yang dapat dilakukan kontainer. Gunakan fitur Penerimaan Keamanan Pod untuk mengaktifkan otorisasi terperinci dari pembuatan dan pembaruan pod. Berikan jumlah izin paling sedikit, dan hindari penggunaan root atau eskalasi istimewa. Untuk informasi selengkapnya, lihat Mengamankan akses pod ke sumber daya.

• Hindari menjalankan kontainer sebagai pengguna root jika memungkinkan.

• Gunakan modul keamanan kernel AppArmor Linux untuk membatasi tindakan yang dapat dilakukan oleh kontainer.

• Tingkatkan kluster AKS Anda ke versi Kubernetes terbaru secara teratur untuk memanfaatkan fitur baru dan perbaikan bug.

• Gunakan daemonset kured untuk mengawasi reboot, cordon, dan simpul pengurasan yang tertunda, dan terapkan pembaruan. Meskipun AKS dapat mengunduh dan menginstal perbaikan keamanan pada setiap node Linux secara otomatis, tetapi AKS tidak dapat me-reboot node secara otomatis ketika diperlukan. Untuk node Windows Server, lakukan operasi peningkatan AKS secara teratur untuk menutup dan menguras Pod dengan aman, serta menyebarkan node yang termutakhir.

• Pertimbangkan untuk menggunakan protokol transportasi aman HTTPS dan gRPC untuk semua komunikasi intra-pod. Dan gunakan mekanisme autentikasi yang lebih canggih yang tidak mengharuskan Anda mengirim kredensial biasa pada setiap permintaan, seperti Open Authorization (OAuth) atau JSON Web Tokens (JWT). Buat komunikasi intra-layanan yang lebih aman dengan menggunakan jala layanan, seperti Istio, Linkerd, atau Consul. Atau Anda dapat menggunakan Dapr.

Registri Kontainer

Pindai gambar kontainer Anda untuk kerentanan, dan hanya sebarkan gambar yang lulus validasi. Perbarui citra dasar dan runtime aplikasi secara teratur. Kemudian sebarkan ulang beban kerja di kluster AKS. Alur kerja penyebaran CI/CD Anda harus menyertakan proses untuk memindai gambar kontainer. Anda dapat menggunakan keamanan Pertahanan Microsoft untuk DevOps untuk memindai kode kerentanan dalam alur otomatis Anda selama fase build dan penyebaran. Atau, Anda dapat menggunakan alat seperti Prisma Cloud atau Aqua untuk memindai dan hanya mengizinkan gambar terverifikasi untuk disebarkan.

Pengoptimalan Biaya

Pengoptimalan Biaya adalah tentang melihat cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Pengoptimalan Biaya.

Biaya arsitektur ini tergantung pada aspek konfigurasi, seperti komponen berikut:

• Tingkat layanan
• Skalabilitas, atau jumlah instans yang dialokasikan layanan secara dinamis untuk mendukung permintaan tertentu
• Skrip Automation
• Tingkat pemulihan bencana Anda

Setelah Anda menilai aspek-aspek ini, gunakan kalkulator harga Azure untuk memperkirakan biaya Anda. Untuk informasi selengkapnya, lihat prinsip-prinsip Well-Architected Framework dari Pengoptimalan Biaya.

Keunggulan Operasional

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.

Penyimpanan

• Pertimbangkan untuk menyebarkan kluster AKS Anda dengan disk OS ephemeral yang memberikan latensi baca dan tulis yang lebih rendah, bersama dengan penskalaan simpul dan peningkatan kluster yang lebih cepat.

• Pahami kebutuhan aplikasi Anda untuk memilih penyimpanan yang tepat. Gunakan penyimpanan berkinerja tinggi yang didukung SSD untuk beban kerja produksi. Rencanakan sistem penyimpanan berbasis jaringan, seperti Azure Files, ketika beberapa pod perlu mengakses file yang sama secara bersamaan. Untuk informasi selengkapnya, lihat Opsi Microsoft Azure Storage untuk aplikasi di AKS.

• Rencanakan permintaan aplikasi Anda sehingga Anda menyebarkan ukuran simpul yang sesuai. Setiap ukuran simpul mendukung jumlah maksimum disk. Ukuran simpul yang berbeda juga menyediakan jumlah penyimpanan lokal dan bandwidth jaringan yang berbeda.

• Gunakan penyediaan dinamis. Untuk mengurangi overhead manajemen dan mengaktifkan penskalakan, jangan buat dan tetapkan volume persisten secara statis. Di kelas penyimpanan Anda, tentukan kebijakan klaim ulang yang sesuai untuk meminimalkan biaya penyimpanan yang tidak perlu setelah Anda menghapus pod.

DevOps

• Gunakan sistem DevOps, seperti GitHub Actions atau Azure DevOps, untuk menyebarkan beban kerja Anda ke AKS melalui bagan Helm di alur CI/CD. Untuk informasi selengkapnya, lihat Membangun dan menyebarkan ke AKS.

• Perkenalkan pengujian A/B dan penyebaran kenari dalam manajemen siklus hidup aplikasi Anda untuk menguji aplikasi dengan benar sebelum Anda memperkenalkannya kepada semua pengguna. Ada beberapa teknik yang dapat digunakan untuk membagi lalu lintas di berbagai versi layanan yang sama.

• Sebagai alternatif, Anda dapat menggunakan kemampuan manajemen lalu lintas yang disediakan oleh jala layanan. Untuk informasi selengkapnya, lihat Manajemen lalu lintas Istio.

• Gunakan Container Registry atau penyimpanan registri lain, seperti Docker Hub, untuk membuat katalog dan melayani gambar Docker privat yang Anda sebarkan ke kluster. AKS dapat menggunakan identitas Microsoft Entra-nya untuk mengautentikasi dengan Container Registry.

• Jika Anda perlu mengubah pengaturan pada Application Gateway, lakukan perubahan dengan menggunakan konfigurasi yang diekspos pada pengontrol ingress atau objek Kubernetes lainnya, seperti menggunakan anotasi yang didukung. Setelah Anda menautkan gateway aplikasi ke AGIC, pengontrol ingress menyinkronkan dan mengontrol hampir semua konfigurasi gateway tersebut. Jika Anda langsung mengonfigurasi Application Gateway secara imperatif atau melalui infrastruktur sebagai kode, pengontrol ingress akhirnya menimpa perubahan tersebut.

Pemantauan

• Pertimbangkan opsi pemantauan terintegrasi Azure untuk memantau status kesehatan kluster AKS dan beban kerja.

• Konfigurasikan semua layanan PaaS, seperti Container Registry dan Key Vault, untuk mengumpulkan log dan metrik diagnostik dan mengirimkannya ke Analitik Log.

Efisiensi Performa

Efisiensi Performa adalah kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan yang ditempatkan di atasnya oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Performa.

Pertimbangan performa tidak sepenuhnya berkaitan dengan multitenansi di AKS, tetapi merupakan persyaratan penting dari solusi ini:

• Untuk beban kerja latensi rendah, pertimbangkan untuk menyebarkan kumpulan simpul khusus dalam grup penempatan kedekatan. Saat Anda menyebarkan aplikasi di Azure, instans VM yang tersebar di seluruh wilayah atau zona ketersediaan membuat latensi jaringan, yang dapat memengaruhi performa keseluruhan aplikasi Anda. Grup penempatan kedekatan adalah pengelompokan logis yang dapat Anda gunakan untuk memastikan sumber daya komputasi Azure secara fisik terletak dekat satu sama lain. Beberapa kasus penggunaan, seperti game, simulasi rekayasa, dan perdagangan frekuensi tinggi, memerlukan latensi rendah dan tugas yang selesai dengan cepat. Untuk skenario komputasi berkinerja tinggi seperti ini, pertimbangkan untuk menggunakan grup penempatan kedekatan untuk kumpulan simpul kluster Anda.

• Selalu gunakan gambar kontainer yang lebih kecil karena Anda dapat membuat build yang lebih cepat. Gambar yang lebih kecil juga kurang rentan terhadap serangan vektor karena permukaan serangan yang berkurang.

• Gunakan penskalaan otomatis Kubernetes untuk menskalakan jumlah simpul pekerja secara dinamis dalam kluster AKS saat lalu lintas meningkat. Dengan Autoscaler Pod Horizontal dan autoscaler kluster, volume simpul dan pod disesuaikan secara dinamis secara real time agar sesuai dengan kondisi lalu lintas dan untuk menghindari waktu henti yang menyebabkan masalah kapasitas. Untuk informasi selengkapnya, lihat Menggunakan autoscaler kluster di AKS.

Penjadwal

• Tinjau dan terapkan praktik terbaik bagi operator kluster dan pengembang aplikasi untuk membangun dan menjalankan aplikasi dengan sukses di AKS.

• Rencanakan dan terapkan kuota sumber daya di tingkat namespace untuk semua namespace. Jika Pod tidak menentukan permintaan dan batasan sumber daya, maka tolak penyebaran. Pantau penggunaan sumber daya, lalu sesuaikan kuota sesuai kebutuhan. Ketika beberapa tim atau penyewa berbagi kluster AKS yang memiliki jumlah simpul tetap, Anda dapat menggunakan kuota sumber daya untuk menetapkan berbagi sumber daya yang adil untuk setiap tim atau penyewa.

• Mengadopsi rentang batas untuk membatasi alokasi sumber daya ke pod atau kontainer dalam namespace layanan, dalam hal CPU dan memori.

• Tentukan permintaan dan batas sumber daya secara eksplisit untuk penggunaan CPU dan memori untuk pod Anda dalam manifes YAML atau bagan Helm yang Anda gunakan untuk menyebarkan aplikasi. Saat Anda menentukan permintaan sumber daya untuk kontainer dalam pod, penjadwal Kubernetes menggunakan informasi ini untuk memutuskan di node mana pod harus diletakkan. Saat Anda menentukan batas sumber daya untuk kontainer, seperti CPU atau memori, kubelet memberlakukan batas tersebut sehingga kontainer yang sedang berjalan tidak dapat menggunakan lebih banyak sumber daya tersebut daripada batas yang Anda tetapkan.

• Pertahankan ketersediaan aplikasi dengan menentukan anggaran gangguan pod untuk memastikan bahwa jumlah minimum pod tersedia di kluster.

• Gunakan kelas prioritas untuk menunjukkan pentingnya pod. Jika penjadwal tidak dapat menjadwalkan pod, penjadwal mencoba untuk mendahului, atau mengeluarkan pod berprioritas lebih rendah sehingga dapat menjadwalkan pod yang tertunda.

• Gunakan taint dan toleransi Kubernetes untuk menempatkan aplikasi intensif sumber daya pada simpul tertentu dan untuk menghindari masalah tetangga yang bising . Jaga agar sumber daya node tetap tersedia untuk beban kerja yang memerlukannya. Jangan izinkan beban kerja lain dijadwalkan pada simpul.

• Gunakan pemilih simpul, afinitas simpul, atau afinitas antar pod untuk mengontrol penjadwalan pod pada simpul. Gunakan pengaturan afinitas antar-pod dan anti-afinitas untuk mengumpulkan pod yang memiliki komunikasi yang cerewet, untuk menempatkan pod pada node yang berbeda, dan untuk menghindari menjalankan beberapa instans dari jenis pod yang sama pada node yang sama.

Menyebarkan skenario ini

Kode sumber untuk sampel ini tersedia di GitHub. Diagram berikut menunjukkan aplikasi demo yang dapat Anda temukan di repositori AKS multitenant AGIC GitHub.

Unduh file Visio arsitektur ini.

Prasyarat

Untuk penyebaran online, Anda harus memiliki akun Azure terlebih dahulu. Jika Anda tidak memilikinya, buat akun Azure gratis sebelum Memulai.

Sebarkan ke Azure

1. Pastikan Anda memiliki informasi tentang berlangganan Azure.

2. Kloning repositori GitHub workbench:

   git clone https://github.com/Azure-Samples/aks-agic.git
   

3. Ikuti petunjuk yang diberikan di file GETSTARTED.md.

Kontributor

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

Penulis utama:

• Paolo Salvatori | Teknisi Layanan Utama

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

• Praktik terbaik kluster AKS
• Praktik terbaik untuk fitur penjadwal dasar di AKS
• Membuat kluster AKS privat
• Membuat kebijakan WAF untuk Application Gateway
• Perbedaan antara penyebaran Helm dan add-on AKS
• Cara kerja gateway aplikasi

Sumber daya terkait

• Arsitektur garis besar untuk kluster AKS