Edit

Bagikan melalui

Pertimbangan Azure Kubernetes Service (AKS) untuk multitenansi

Azure
Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) menyederhanakan penyebaran kluster Kubernetes terkelola di Azure dengan membongkar overhead operasional ke platform cloud Azure. Karena AKS adalah layanan Kubernetes yang dihosting, Azure menangani tugas penting seperti pemantauan dan pemeliharaan kesehatan dan sarana kontrol.

Kluster AKS dapat dibagikan di beberapa penyewa dalam skenario dan cara yang berbeda. Dalam beberapa kasus, beragam aplikasi dapat berjalan di kluster yang sama. Dalam kasus lain, beberapa instans aplikasi yang sama dapat berjalan di kluster bersama yang sama, satu untuk setiap penyewa. Istilah multitenansi sering menjelaskan semua jenis berbagi ini. Kubernetes tidak memiliki konsep kelas satu dari pengguna akhir atau penyewa. Namun, ia menyediakan beberapa fitur untuk membantu Anda mengelola persyaratan penyewaan yang berbeda.

Artikel ini menjelaskan beberapa fitur AKS yang dapat Anda gunakan saat membuat sistem multipenyewa. Untuk panduan umum dan praktik terbaik untuk multitenansi Kubernetes, lihat Multi-penyewaan dalam dokumentasi Kubernetes.

Jenis multitenansi

Langkah pertama untuk menentukan cara berbagi kluster AKS di beberapa penyewa adalah mengevaluasi pola dan alat yang tersedia untuk digunakan. Secara umum, multitenansi dalam kluster Kubernetes termasuk dalam dua kategori utama, tetapi banyak variasi masih dimungkinkan. Dokumentasi Kubernetes menjelaskan dua kasus penggunaan umum untuk multitenansi: beberapa tim dan beberapa pelanggan.

Beberapa tim

Bentuk umum multitenansi adalah berbagi kluster antara beberapa tim dalam organisasi. Setiap tim dapat menyebarkan, memantau, dan mengoperasikan satu atau beberapa solusi. Beban kerja ini sering kali perlu berkomunikasi satu sama lain dan dengan aplikasi internal atau eksternal lainnya yang terletak di kluster yang sama atau platform hosting lainnya.

Selain itu, beban kerja ini perlu berkomunikasi dengan layanan, seperti database relasional, repositori NoSQL, atau sistem olahpesan, yang dihosting di kluster yang sama atau berjalan sebagai layanan platform as a service (PaaS) di Azure.

Dalam skenario ini, anggota tim sering memiliki akses langsung ke sumber daya Kubernetes melalui alat, seperti kubectl. Atau, anggota memiliki akses tidak langsung melalui pengontrol GitOps, seperti Flux dan Argo CD, atau melalui jenis alat otomatisasi rilis lainnya.

Untuk informasi selengkapnya tentang skenario ini, lihat Beberapa tim dalam dokumentasi Kubernetes.

Beberapa pelanggan

Bentuk umum lain dari multitenancy sering melibatkan vendor software as a service (SaaS). Atau, penyedia layanan menjalankan beberapa instans beban kerja, yang dianggap sebagai penyewa terpisah, untuk pelanggan mereka. Dalam skenario ini, pelanggan tidak memiliki akses langsung ke kluster AKS, tetapi mereka hanya memiliki akses ke aplikasi mereka. Selain itu, mereka bahkan tidak tahu bahwa aplikasi mereka berjalan di Kubernetes. Pengoptimalan biaya sering menjadi perhatian penting. Penyedia layanan menggunakan kebijakan Kubernetes, seperti kuota sumber daya dan kebijakan jaringan , untuk memastikan bahwa beban kerja sangat terisolasi satu sama lain.

Untuk informasi selengkapnya tentang skenario ini, lihat Beberapa pelanggan dalam dokumentasi Kubernetes.

Model isolasi

Menurut dokumentasi Kubernetes, kluster Kubernetes multipenyewa dibagikan oleh beberapa pengguna dan beban kerja yang umumnya disebut sebagai penyewa . Definisi ini mencakup kluster Kubernetes yang dibagikan oleh tim atau divisi yang berbeda dalam organisasi. Ini juga berisi kluster yang instans per pelanggan dari berbagi aplikasi SaaS.

Multitenansi kluster adalah alternatif untuk mengelola banyak kluster khusus penyewa tunggal. 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 dengan jumlah simpul tetap, satu tim mungkin menggunakan lebih dari berbagi sumber daya yang adil. Administrator dapat menggunakan kuota sumber daya untuk mengatasi masalah ini.

Berdasarkan tingkat keamanan yang disediakan isolasi, Anda dapat membedakan antara multitenansi lunak dan keras.

  • Multitenansi lunak cocok dalam satu perusahaan di mana penyewa adalah tim atau departemen yang berbeda yang saling mempercayai. Dalam skenario ini, isolasi bertujuan untuk menjamin integritas beban kerja, mengatur sumber daya kluster di berbagai grup pengguna internal, dan melindungi dari kemungkinan serangan keamanan.
  • Hard multitenancy menggambarkan skenario di mana penyewa heterogen tidak saling percaya, sering kali dari perspektif keamanan dan berbagi sumber daya.

Ketika Anda berencana untuk membangun kluster AKS multipenyewa, Anda harus mempertimbangkan lapisan isolasi sumber daya dan multitenansi yang Kubernetes sediakan, termasuk:

  • Kelompok
  • Namespace layanan
  • Kumpulan simpul atau simpul
  • Pod
  • Wadah

Selain itu, Anda harus mempertimbangkan implikasi keamanan berbagi sumber daya yang berbeda di antara beberapa penyewa. Misalnya, Anda dapat mengurangi jumlah komputer yang diperlukan dalam kluster dengan menjadwalkan pod dari penyewa yang berbeda pada simpul yang sama. Di sisi lain, Anda mungkin perlu mencegah beban kerja tertentu dikolokasi. 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.

Meskipun Kubernetes tidak dapat menjamin isolasi yang sangat aman antara penyewa, Kubernetes memang menawarkan fitur yang mungkin cukup untuk kasus penggunaan tertentu. Sebagai praktik terbaik, Anda harus memisahkan setiap penyewa dan sumber daya Kubernetes ke dalam namespace layanan mereka. Anda kemudian dapat menggunakan kontrol akses berbasis peran (RBAC) Kubernetes dan kebijakan jaringan untuk 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.

Diagram yang menunjukkan model penyedia SaaS yang menghosting beberapa instans aplikasi yang sama pada kluster yang sama.

Ada beberapa cara untuk merancang dan membangun solusi multipenyewa dengan AKS. Masing-masing metode ini dilengkapi dengan serangkaian tradeoff sendiri, dalam hal penyebaran infrastruktur, topologi jaringan, dan keamanan. Metode ini mempengaruhi tingkat isolasi, upaya implementasi, kompleksitas operasional, dan biaya. Anda dapat menerapkan isolasi penyewa di bidang kontrol dan data, berdasarkan kebutuhan Anda.

Isolasi sarana kontrol

Jika Anda memiliki isolasi di tingkat sarana kontrol, Anda menjamin bahwa penyewa yang berbeda tidak dapat mengakses atau memengaruhi sumber daya masing-masing, seperti pod dan layanan. Selain itu, mereka tidak dapat memengaruhi performa aplikasi penyewa lain. Untuk informasi selengkapnya, lihat isolasi sarana kontrol dalam dokumentasi Kubernetes. Cara terbaik untuk menerapkan isolasi di tingkat sarana kontrol adalah dengan memisahkan beban kerja setiap penyewa dan sumber daya Kubernetes-nya ke dalam namespace terpisah.

Menurut dokumentasi Kubernetes, namespace adalah abstraksi yang Anda gunakan untuk mendukung isolasi grup sumber daya dalam satu kluster. Anda dapat menggunakan namespace layanan untuk mengisolasi beban kerja penyewa yang berbagi kluster Kubernetes.

  • Namespace memungkinkan beban kerja penyewa yang berbeda berada di ruang kerja virtual mereka sendiri, tanpa risiko memengaruhi pekerjaan satu sama lain. Tim terpisah dalam organisasi dapat menggunakan namespace layanan untuk mengisolasi proyek mereka satu sama lain karena mereka dapat menggunakan nama sumber daya yang sama di namespace yang berbeda tanpa risiko nama tumpang tindih.
  • peran RBAC dan pengikatan peran adalah sumber daya cakupan namespace yang dapat digunakan tim untuk membatasi pengguna dan proses penyewa untuk mengakses sumber daya dan layanan hanya di namespace layanan mereka. Tim yang berbeda dapat menentukan peran untuk mengelompokkan daftar izin atau kemampuan dengan satu nama. Mereka kemudian menetapkan peran ini ke akun pengguna dan akun layanan untuk memastikan bahwa hanya identitas resmi yang memiliki akses ke sumber daya di namespace layanan tertentu.
  • Kuota sumber daya untuk CPU dan memori adalah objek namespace. Teams dapat menggunakannya untuk memastikan bahwa beban kerja yang berbagi kluster yang sama sangat terisolasi dari konsumsi sumber daya sistem. Metode ini dapat memastikan bahwa setiap aplikasi penyewa yang berjalan di namespace terpisah memiliki sumber daya yang perlu dijalankan dan menghindari masalah tetangga yang bising, yang dapat memengaruhi aplikasi penyewa lain yang berbagi kluster yang sama.
  • Kebijakan jaringan adalah objek namespace yang dapat diadopsi tim untuk menegakkan lalu lintas jaringan mana yang diizinkan untuk aplikasi penyewa tertentu. Anda dapat menggunakan kebijakan jaringan untuk memisahkan beban kerja berbeda yang berbagi kluster yang sama dari perspektif jaringan.
  • Aplikasi tim yang berjalan di namespace layanan yang berbeda dapat menggunakan akun layanan yang berbeda untuk mengakses sumber daya dalam kluster, aplikasi eksternal, atau layanan terkelola yang sama.
  • Gunakan namespace layanan untuk meningkatkan performa di tingkat sarana kontrol. Jika beban kerja dalam kluster bersama diatur ke dalam beberapa namespace, API Kubernetes memiliki lebih sedikit item untuk dicari saat menjalankan operasi. Organisasi ini dapat mengurangi latensi panggilan terhadap server API dan meningkatkan throughput sarana kontrol.

Untuk informasi selengkapnya tentang isolasi di tingkat namespace layanan, lihat sumber daya berikut dalam dokumentasi Kubernetes:

  • Namespace
  • kontrol Akses
  • Kuota

Isolasi sarana data

Isolasi sarana data menjamin bahwa pod dan beban kerja penyewa yang berbeda cukup terisolasi satu sama lain. Untuk informasi selengkapnya, lihat isolasi sarana data dalam dokumentasi Kubernetes.

Isolasi jaringan

Ketika menjalankan aplikasi modern berbasis layanan mikro di Kubernetes, Anda sering ingin mengontrol komponen mana yang dapat berkomunikasi satu sama lain. Secara default, semua pod dalam kluster AKS dapat mengirim dan menerima lalu lintas tanpa batasan, termasuk aplikasi lain yang berbagi kluster yang sama. Untuk meningkatkan keamanan, Anda dapat menentukan aturan jaringan untuk mengontrol arus lalu lintas. Kebijakan jaringan adalah spesifikasi Kubernetes yang menentukan kebijakan akses untuk komunikasi antar pod. Anda dapat menggunakan kebijakan jaringan untuk memisahkan komunikasi antara aplikasi penyewa yang berbagi kluster yang sama.

AKS menyediakan dua cara untuk menerapkan kebijakan jaringan:

  • Azure memiliki implementasinya untuk kebijakan jaringan, yang disebut kebijakan jaringan Azure.
  • kebijakan jaringan Calico adalah jaringan sumber terbuka dan solusi keamanan jaringan yang didirikan oleh Tigera.

Kedua implementasi menggunakan iptable Linux untuk memberlakukan kebijakan yang ditentukan. Kebijakan jaringan diterjemahkan ke dalam set pasangan IP yang diizinkan dan tidak diizinkan. Pasangan ini kemudian diprogram sebagai aturan filter iptables. Anda hanya dapat menggunakan kebijakan jaringan Azure dengan kluster AKS yang dikonfigurasi dengan plugin jaringan Azure CNI. Namun, kebijakan jaringan Calico mendukung azure CNI dan kubenet. Untuk informasi selengkapnya, lihat Mengamankan lalu lintas antar pod menggunakan kebijakan jaringan di Azure Kubernetes Service.

Untuk informasi selengkapnya, lihat isolasi Jaringan dalam dokumentasi Kubernetes.

Isolasi penyimpanan

Azure menyediakan sekumpulan repositori data PaaS terkelola yang kaya, seperti Azure SQL Database dan Azure Cosmos DB, dan layanan penyimpanan lainnya yang dapat Anda gunakan sebagai volume persisten untuk beban kerja Anda. Aplikasi penyewa yang berjalan pada kluster AKS bersama dapat berbagi database atau penyimpanan file, atau mereka dapat menggunakan repositori data khusus dan sumber daya penyimpanan. Untuk informasi selengkapnya tentang berbagai strategi dan pendekatan untuk mengelola data dalam skenario multipenyewa, lihat pendekatan arsitektur untuk penyimpanan dan data dalam solusi multipenyewa.

Beban kerja yang berjalan di AKS juga dapat menggunakan volume persisten untuk menyimpan data. Di Azure, Anda dapat membuat volume persisten sebagai sumber daya Kubernetes yang didukung Azure Storage. Anda dapat membuat volume data secara manual dan menetapkannya ke pod secara langsung, atau Anda dapat membuat AKS secara otomatis menggunakan klaim volume persisten . AKS menyediakan kelas penyimpanan bawaan untuk membuat volume persisten yang Azure Disks, Azure Files, dan dukungan Azure NetApp Files. Untuk informasi selengkapnya, lihat opsi Penyimpanan untuk aplikasi di AKS. Untuk alasan keamanan dan ketahanan, Anda harus menghindari penggunaan penyimpanan lokal pada simpul agen melalui emptyDir dan hostPath.

Saat AKS kelas penyimpanan bawaan tidak cocok untuk satu atau beberapa penyewa, Anda dapat membangun kelas penyimpanan kustom untuk memenuhi persyaratan penyewa yang berbeda. Persyaratan ini termasuk ukuran volume, SKU penyimpanan, perjanjian tingkat layanan (SLA), kebijakan cadangan, dan tingkat harga.

Misalnya, Anda dapat mengonfigurasi kelas penyimpanan kustom untuk setiap penyewa. Anda kemudian dapat menggunakannya untuk menerapkan tag ke volume persisten apa pun yang dibuat di namespace layanan mereka untuk membebankan kembali biayanya kepada mereka. Untuk informasi selengkapnya, lihat Menggunakan tag Azure di AKS.

Untuk informasi selengkapnya, lihat isolasi Penyimpanan dalam dokumentasi Kubernetes.

Isolasi node

Anda dapat mengonfigurasi beban kerja penyewa untuk berjalan pada simpul agen terpisah untuk menghindari masalah tetangga yang bising dan mengurangi risiko pengungkapan informasi. Di AKS, Anda dapat membuat kluster terpisah, atau hanya kumpulan simpul khusus, untuk penyewa yang memiliki persyaratan ketat untuk isolasi, keamanan, kepatuhan terhadap peraturan, dan performa.

Anda dapat menggunakan taint , toleransi , label simpul , pemilih simpul , dan afinitas simpul untuk membatasi pod penyewa untuk berjalan hanya pada set simpul atau kumpulan simpul tertentu.

Secara umum, AKS menyediakan isolasi beban kerja di berbagai tingkatan, termasuk:

  • Pada tingkat kernel, dengan menjalankan beban kerja penyewa di komputer virtual (VM) ringan pada simpul agen bersama dan dengan menggunakan Pod Sandboxing berdasarkan Kontainer Kata.
  • Pada tingkat fisik, dengan menghosting aplikasi penyewa pada kluster khusus atau kumpulan simpul.
  • Pada tingkat perangkat keras, dengan menjalankan beban kerja penyewa pada host khusus Azure yang menjamin bahwa VM simpul agen menjalankan komputer fisik khusus. Isolasi perangkat keras memastikan bahwa tidak ada VM lain yang ditempatkan pada host khusus, yang menyediakan lapisan isolasi tambahan untuk beban kerja penyewa.

Anda dapat menggabungkan teknik ini. Misalnya, Anda dapat menjalankan kluster per penyewa dan kumpulan simpul di grup Azure Dedicated Host untuk mencapai pemisahan beban kerja dan isolasi fisik di tingkat perangkat keras. Anda juga dapat membuat kumpulan simpul bersama atau per penyewa yang mendukung Federal Information Process Standard (FIPS), VM rahasia, atau enkripsi berbasis host.

Gunakan isolasi simpul untuk mengaitkan dan membebankan kembali biaya sekumpulan simpul atau kumpulan simpul dengan mudah ke satu penyewa. Ini sangat terkait dengan model penyewaan yang diadopsi oleh solusi Anda.

Untuk informasi selengkapnya, lihat isolasi Simpul dalam dokumentasi Kubernetes.

Model penyewaan

AKS menyediakan lebih banyak jenis model isolasi dan penyewaan simpul.

Penyebaran penyewa tunggal otomatis

Dalam model penyebaran penyewa tunggal otomatis, Anda menyebarkan sekumpulan sumber daya khusus untuk setiap penyewa, seperti yang diilustrasikan dalam contoh ini:

Diagram yang memperlihatkan tiga penyewa, masing-masing dengan penyebaran terpisah.

Setiap beban kerja penyewa berjalan di kluster AKS khusus dan mengakses sekumpulan sumber daya Azure yang berbeda. Biasanya, solusi multipenyewa yang Anda bangun dengan menggunakan model ini memanfaatkan infrastruktur secara ekstensif sebagai kode (IaC). Misalnya, Bicep, Azure Resource Manager, Terraform, atau REST API Azure Resource Manager membantu memulai dan mengoordinasikan penyebaran sumber daya khusus penyewa sesuai permintaan. Anda dapat menggunakan pendekatan ini ketika Anda perlu menyediakan infrastruktur yang sepenuhnya terpisah untuk setiap pelanggan Anda. Saat merencanakan penyebaran Anda, pertimbangkan untuk menggunakan pola stempel Penyebaran .

Keuntungan :

  • Manfaat utama dari pendekatan ini adalah bahwa API Server dari setiap kluster AKS penyewa terpisah. Pendekatan ini menjamin isolasi penuh di seluruh penyewa dari tingkat keamanan, jaringan, dan konsumsi sumber daya. Penyerang yang berhasil mendapatkan kontrol kontainer hanya memiliki akses ke kontainer dan volume yang dipasang milik satu penyewa. Model penyewaan isolasi penuh sangat penting bagi beberapa pelanggan dengan overhead kepatuhan peraturan yang tinggi.
  • Penyewa tidak mungkin memengaruhi performa sistem satu sama lain, sehingga Anda menghindari masalah tetangga yang berisik. Pertimbangan ini mencakup lalu lintas terhadap API Server. Server API adalah komponen penting bersama di kluster Kubernetes mana pun. Pengontrol kustom, yang menghasilkan lalu lintas volume tinggi yang tidak diatur terhadap server API, dapat menyebabkan ketidakstabilan kluster. Ketidakstabilan ini menyebabkan kegagalan permintaan, waktu habis, dan badai coba lagi API. Gunakan fitur SLA waktu aktif untuk memperluas skala sarana kontrol kluster AKS untuk memenuhi permintaan lalu lintas. Namun, menyediakan kluster khusus mungkin menjadi solusi yang lebih baik bagi pelanggan tersebut dengan persyaratan yang kuat dalam hal isolasi beban kerja.
  • Anda dapat meluncurkan pembaruan dan perubahan secara progresif di seluruh penyewa, yang mengurangi kemungkinan pemadaman di seluruh sistem. Biaya Azure dapat dengan mudah dibebankan kembali ke penyewa karena setiap sumber daya digunakan oleh satu penyewa.

Risiko :

  • Efisiensi biaya rendah karena setiap penyewa menggunakan sekumpulan sumber daya khusus.
  • Pemeliharaan yang sedang berlangsung kemungkinan akan memakan waktu karena Anda perlu mengulangi aktivitas pemeliharaan di beberapa kluster AKS, satu untuk setiap penyewa. Pertimbangkan untuk mengotomatiskan proses operasional Anda dan menerapkan perubahan secara progresif melalui lingkungan Anda. Operasi lintas penyebaran lainnya, seperti pelaporan dan analitik di seluruh properti Anda, mungkin juga berguna. Pastikan Anda merencanakan cara mengkueri dan memanipulasi data di beberapa penyebaran.

Penyebaran multipenyewa sepenuhnya

Dalam penyebaran yang sepenuhnya multipenyewa, satu aplikasi melayani permintaan semua penyewa, dan semua sumber daya Azure dibagikan, termasuk kluster AKS. Dalam konteks ini, Anda hanya memiliki satu infrastruktur untuk menyebarkan, memantau, dan memelihara. Semua penyewa menggunakan sumber daya, seperti yang diilustrasikan dalam diagram berikut:

Diagram yang menunjukkan tiga penyewa yang semuanya menggunakan satu penyebaran bersama.

Manfaat :

  • Model ini menarik karena biaya pengoperasian solusi yang lebih rendah dengan komponen bersama. Saat Anda menggunakan model penyewaan ini, Anda mungkin perlu menyebarkan kluster AKS yang lebih besar dan mengadopsi SKU yang lebih tinggi untuk repositori data bersama apa pun. Perubahan ini membantu mempertahankan lalu lintas yang dihasilkan oleh semua sumber daya penyewa, seperti repositori data.

Risiko:

  • Dalam konteks ini, satu aplikasi menangani semua permintaan penyewa. Anda harus merancang dan menerapkan langkah-langkah keamanan untuk mencegah penyewa membanjiri aplikasi dengan panggilan. Panggilan ini dapat memperlambat seluruh sistem dan memengaruhi semua penyewa.
  • Jika profil lalu lintas sangat bervariasi, Anda harus mengonfigurasi autoscaler kluster AKS untuk memvariasikan jumlah pod dan simpul agen. Dasarkan konfigurasi Anda pada penggunaan sumber daya sistem, seperti CPU dan memori. Atau, Anda dapat menskalakan dan menskalakan dalam jumlah pod dan node kluster berdasarkan metrik kustom. Misalnya, Anda dapat menggunakan jumlah permintaan yang tertunda atau metrik sistem olahpesan eksternal yang menggunakan Event Driven Autoscaler (KEDA) berbasis Kubernetes.
  • Pastikan Anda memisahkan data untuk setiap penyewa dan menerapkan perlindungan untuk menghindari kebocoran data antara penyewa yang berbeda.
  • Pastikan untuk melacak dan mengaitkan biaya Azure ke penyewa individual, berdasarkan penggunaan aktualnya. Solusi non-Microsoft, seperti kubecost, dapat membantu Anda menghitung dan memecah biaya di berbagai tim dan penyewa.
  • Pemeliharaan bisa lebih mudah dengan satu penyebaran karena Anda hanya perlu memperbarui satu set sumber daya Azure dan memelihara satu aplikasi. Namun, itu juga bisa lebih berisiko karena setiap perubahan pada infrastruktur atau komponen aplikasi dapat memengaruhi seluruh basis pelanggan.
  • Anda juga harus mempertimbangkan batasan skala. Anda lebih mungkin mencapai batas skala sumber daya Azure saat Anda memiliki sekumpulan sumber daya bersama. Untuk menghindari mencapai batas kuota sumber daya, Anda dapat mendistribusikan penyewa di beberapa langganan Azure.

Penyebaran yang dipartisi secara horizontal

Atau, Anda dapat mempertimbangkan untuk mempartisi aplikasi Kubernetes multipenyewa secara horizontal. Pendekatan ini berbagi beberapa komponen solusi di semua penyewa dan menyebarkan sumber daya khusus untuk penyewa individual. Misalnya, Anda dapat membuat satu aplikasi Kubernetes multipenyewa lalu membuat database individual, satu untuk setiap penyewa, seperti yang ditunjukkan dalam ilustrasi ini:

Diagram yang memperlihatkan tiga penyewa. Masing-masing menggunakan database khusus dan satu aplikasi Kubernetes bersama.

Keuntungan :

  • Penyebaran yang dipartisi secara horizontal dapat membantu Anda mengurangi masalah tetangga yang bising. Pertimbangkan pendekatan ini jika Anda mengidentifikasi bahwa sebagian besar beban lalu lintas pada aplikasi Kubernetes Anda adalah karena komponen tertentu, yang dapat Anda sebarkan secara terpisah, untuk setiap penyewa. Misalnya, database Anda mungkin menyerap sebagian besar beban sistem Anda karena beban kueri tinggi. Jika satu penyewa mengirim sejumlah besar permintaan ke solusi Anda, performa database mungkin terpengaruh secara negatif, tetapi database penyewa dan komponen bersama lainnya, seperti tingkat aplikasi, tetap tidak terpengaruh.

Risiko :

  • Dengan penyebaran yang dipartisi secara horizontal, Anda masih perlu mempertimbangkan penyebaran dan manajemen otomatis komponen Anda, terutama komponen yang digunakan penyewa tunggal.
  • Model ini mungkin tidak menyediakan tingkat isolasi yang diperlukan untuk pelanggan yang tidak dapat berbagi sumber daya dengan penyewa lain untuk alasan kebijakan internal atau kepatuhan.

Penyebaran yang dipartisi secara vertikal

Anda dapat memanfaatkan manfaat model penyewa tunggal dan sepenuhnya multipenyewa dengan menggunakan model hibrid yang secara vertikal mempartisi penyewa di beberapa kluster AKS atau kumpulan simpul. Pendekatan ini memberikan keuntungan berikut daripada dua model penyewaan sebelumnya:

  • Anda dapat menggunakan kombinasi penyewa tunggal dan penyebaran multipenyewa. Misalnya, Anda dapat memiliki sebagian besar pelanggan Anda berbagi kluster AKS dan database pada infrastruktur multipenyewa. Anda juga dapat menyebarkan infrastruktur penyewa tunggal untuk pelanggan yang memerlukan performa dan isolasi yang lebih tinggi.
  • Anda dapat menyebarkan penyewa ke beberapa kluster AKS regional, berpotensi dengan konfigurasi yang berbeda. Teknik ini paling efektif ketika Anda memiliki penyewa yang tersebar di berbagai geografi.

Anda dapat menerapkan variasi yang berbeda dari model penyewaan ini. Misalnya, Anda dapat memilih untuk menawarkan solusi multipenyewa Anda dengan tingkat fungsionalitas yang berbeda dengan biaya yang berbeda. Model harga Anda dapat menyediakan beberapa SKU yang masing-masing menyediakan tingkat performa dan isolasi bertahap dalam hal berbagi sumber daya, performa, jaringan, dan pemisahan data. Pertimbangkan tingkatan berikut:

  • Tingkat dasar: Permintaan penyewa dilayani oleh satu aplikasi Kubernetes multipenyewa yang dibagikan dengan penyewa lain. Data disimpan dalam satu atau beberapa database yang dibagikan semua penyewa tingkat Dasar.
  • Tingkat standar: Permintaan penyewa dilayani oleh aplikasi Kubernetes khusus yang berjalan di namespace terpisah, yang menyediakan batas isolasi dalam hal keamanan, jaringan, dan konsumsi sumber daya. Semua aplikasi penyewa, satu untuk setiap penyewa, berbagi kluster AKS dan kumpulan simpul yang sama dengan pelanggan tingkat standar lainnya.
  • Tingkat premium: Aplikasi penyewa berjalan di kumpulan simpul khusus atau kluster AKS untuk menjamin SLA yang lebih tinggi, performa yang lebih baik, dan tingkat isolasi yang lebih tinggi. Tingkat ini dapat menyediakan model biaya yang fleksibel berdasarkan jumlah dan SKU simpul agen yang menghosting aplikasi penyewa. Anda dapat menggunakan Pod Sandboxing sebagai solusi alternatif untuk kluster khusus atau kumpulan simpul untuk mengisolasi beban kerja penyewa yang berbeda.

Diagram berikut menunjukkan skenario di mana penyewa A dan B berjalan pada kluster AKS bersama, sedangkan penyewa C berjalan pada kluster AKS terpisah.

Diagram yang memperlihatkan tiga penyewa. Penyewa A dan B berbagi kluster AKS. Penyewa C memiliki kluster AKS khusus.

Diagram berikut menunjukkan skenario di mana penyewa A dan B berjalan pada kumpulan simpul yang sama, sedangkan penyewa C berjalan pada kumpulan simpul khusus.

Diagram yang memperlihatkan tiga penyewa. Penyewa A dan B berbagi kumpulan simpul. Penyewa C memiliki kumpulan simpul khusus.

Model ini juga dapat menawarkan SLA yang berbeda untuk tingkat yang berbeda. Misalnya, tingkat dasar dapat menawarkan waktu aktif 99,9%, tingkat standar dapat menawarkan waktu aktif 99,95%, dan tingkat premium dapat menawarkan waktu aktif 99,99%. Anda dapat menerapkan SLA yang lebih tinggi dengan menggunakan layanan dan fitur yang memungkinkan target ketersediaan yang lebih tinggi.

Keuntungan :

  • Karena Anda masih berbagi infrastruktur, Anda masih bisa mendapatkan beberapa manfaat biaya dari memiliki penyebaran multipenyewa bersama. Anda dapat menyebarkan kluster dan kumpulan simpul yang dibagikan di beberapa aplikasi penyewa tingkat dasar dan tingkat standar, yang menggunakan ukuran VM yang lebih murah untuk simpul agen. Pendekatan ini menjamin kepadatan dan penghematan biaya yang lebih baik. Untuk pelanggan tingkat premium, Anda dapat menyebarkan kluster AKS dan kumpulan simpul dengan ukuran VM yang lebih tinggi dan jumlah maksimum replika dan simpul pod dengan harga yang lebih tinggi.
  • Anda dapat menjalankan layanan sistem, seperti CoreDNS, Konnectivity, atau Pengontrol Ingress Azure Application Gateway , dalam kumpulan simpul mode sistem khusus. Anda dapat menggunakan taint , toleransi , label simpul , pemilih simpul , dan afinitas simpul untuk menjalankan aplikasi penyewa pada satu atau beberapa kumpulan simpul mode pengguna.
  • Anda dapat menggunakan taint , toleransi , label node , pemilih simpul , dan afinitas simpul untuk menjalankan sumber daya bersama. Misalnya, Anda dapat memiliki pengontrol ingress atau sistem olahpesan pada kumpulan simpul khusus yang memiliki ukuran VM tertentu, pengaturan autoscaler, dan dukungan zona ketersediaan.

Risiko :

  • Anda perlu merancang aplikasi Kubernetes untuk mendukung penyebaran multipenyewa dan penyewa tunggal.
  • Jika Anda berencana untuk mengizinkan migrasi antar infrastruktur, Anda perlu mempertimbangkan bagaimana Anda memigrasikan pelanggan dari penyebaran multipenyewa ke penyebaran penyewa tunggal mereka sendiri.
  • Anda memerlukan strategi yang konsisten dan satu panel kaca, atau satu titik pandang, untuk memantau dan mengelola lebih banyak kluster AKS.

Autoscaling

Untuk mengikuti permintaan lalu lintas yang dihasilkan aplikasi penyewa, Anda dapat mengaktifkan autoscaler kluster untuk menskalakan simpul agen AKS. Penskalaan otomatis membantu sistem tetap responsif dalam keadaan berikut:

  • Beban lalu lintas meningkat selama jam kerja atau periode tertentu dalam setahun.
  • Penyewa atau beban berat bersama disebarkan ke kluster.
  • Simpul agen menjadi tidak tersedia karena pemadaman zona ketersediaan.

Saat Anda mengaktifkan penskalaan otomatis untuk kumpulan simpul, Anda menentukan jumlah node minimum dan maksimum berdasarkan ukuran beban kerja yang diharapkan. Dengan mengonfigurasi jumlah maksimum simpul, Anda dapat memastikan ruang yang cukup untuk semua pod penyewa di kluster, terlepas dari namespace layanan tempat mereka berjalan.

Ketika lalu lintas meningkat, penskalaan otomatis kluster menambahkan simpul agen baru untuk mencegah pod masuk ke status tertunda karena kekurangan sumber daya seperti CPU dan memori.

Ketika beban berkurang, penskalaan otomatis kluster mengurangi jumlah simpul agen dalam kumpulan simpul berdasarkan batas yang ditentukan, yang membantu mengurangi biaya operasional Anda.

Anda dapat menggunakan autoscaling pod untuk menskalakan pod secara otomatis berdasarkan permintaan sumber daya. HorizontalPodAutoscaler secara otomatis menskalakan jumlah replika pod berdasarkan pemanfaatan CPU atau memori atau metrik kustom. Dengan menggunakan KEDA, Anda dapat mendorong penskalaan kontainer apa pun di Kubernetes berdasarkan jumlah peristiwa dari sistem eksternal, seperti Azure Event Hubs atau Azure Service Bus, yang digunakan aplikasi penyewa.

Vertical Pod Autoscaler (VPA) memungkinkan manajemen sumber daya yang efisien untuk pod. Dengan menyesuaikan CPU dan memori yang dialokasikan ke pod, VPA membantu Anda mengurangi jumlah simpul yang diperlukan untuk menjalankan aplikasi penyewa. Memiliki lebih sedikit simpul mengurangi total biaya kepemilikan dan membantu Anda menghindari masalah tetangga yang bising.

Tetapkan grup reservasi kapasitas ke kumpulan simpul untuk memberikan alokasi dan isolasi sumber daya yang lebih baik untuk penyewa yang berbeda.

Pemeliharaan

Untuk mengurangi risiko waktu henti yang dapat memengaruhi aplikasi penyewa selama peningkatan kluster atau kumpulan simpul, jadwalkan AKS pemeliharaan terencana selama jam sibuk. Jadwalkan jendela pemeliharaan mingguan untuk memperbarui sarana kontrol kluster AKS yang menjalankan aplikasi penyewa dan kumpulan simpul untuk meminimalkan dampak beban kerja. Anda dapat menjadwalkan satu atau beberapa jendela pemeliharaan mingguan pada kluster Anda dengan menentukan rentang hari atau waktu pada hari tertentu. Semua operasi pemeliharaan terjadi selama jendela terjadwal.

Keamanan

Bagian berikut menjelaskan praktik terbaik keamanan untuk solusi multipenyewa dengan AKS.

Akses kluster

Saat Anda berbagi kluster AKS antara beberapa tim dalam organisasi, Anda perlu menerapkan prinsip hak istimewa paling sedikit untuk mengisolasi penyewa yang berbeda satu sama lain. Secara khusus, Anda perlu memastikan bahwa pengguna hanya memiliki akses ke namespace layanan dan sumber daya Kubernetes mereka saat menggunakan alat seperti kubectl, Helm, Flux, atau Argo CD.

Untuk informasi selengkapnya tentang autentikasi dan otorisasi dengan AKS, lihat artikel berikut ini:

Identitas beban kerja

Jika Anda menghosting beberapa aplikasi penyewa pada satu kluster AKS, dan setiap aplikasi berada di namespace terpisah, maka setiap beban kerja harus menggunakan akun layanan Kubernetes yang berbeda dan kredensial untuk mengakses layanan Azure hilir. Akun layanan adalah salah satu jenis pengguna utama di Kubernetes. API Kubernetes menyimpan dan mengelola akun layanan. Kredensial akun layanan disimpan sebagai rahasia Kubernetes, sehingga pod yang berwenang dapat menggunakannya untuk berkomunikasi dengan API Server. Sebagian besar permintaan API menyediakan token autentikasi untuk akun layanan atau akun pengguna normal.

Beban kerja penyewa yang Anda sebarkan ke kluster AKS dapat menggunakan kredensial aplikasi Microsoft Entra untuk mengakses sumber daya yang dilindungi ID Microsoft Entra, seperti Azure Key Vault dan Microsoft Graph. ID Beban Kerja Microsoft Entra untuk Kubernetes terintegrasi dengan kemampuan asli Kubernetes untuk bergabung dengan penyedia identitas eksternal apa pun.

Pod Sandboxing

AKS mencakup mekanisme yang disebut Pod Sandboxing yang menyediakan batas isolasi antara aplikasi kontainer dan kernel bersama dan sumber daya komputasi host kontainer, seperti CPU, memori, dan jaringan. Pod Sandboxing melengkapi langkah-langkah keamanan atau kontrol perlindungan data lainnya untuk membantu beban kerja penyewa mengamankan informasi sensitif dan memenuhi persyaratan kepatuhan peraturan, industri, atau tata kelola, seperti Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS), International Organization for Standardization (ISO) 27001, dan Health Insurance Portability and Accountability Act (HIPAA).

Dengan menyebarkan aplikasi pada kluster atau kumpulan simpul terpisah, Anda dapat sangat mengisolasi beban kerja penyewa dari tim atau pelanggan yang berbeda. Menggunakan beberapa kluster dan kumpulan simpul mungkin cocok untuk persyaratan isolasi banyak organisasi dan solusi SaaS, tetapi ada skenario di mana satu kluster dengan kumpulan simpul VM bersama lebih efisien. Misalnya, Anda dapat menggunakan satu kluster saat menjalankan pod yang tidak tepercaya dan tepercaya pada simpul yang sama atau kolokasi DaemonSets dan kontainer istimewa pada simpul yang sama untuk komunikasi lokal dan pengelompokan fungsional yang lebih cepat. Pod Sandboxing dapat membantu Anda mengisolasi aplikasi penyewa dengan kuat pada node kluster yang sama tanpa perlu menjalankan beban kerja ini di kluster atau kumpulan simpul terpisah. Metode lain mengharuskan Anda mengkompilasi ulang kode atau menyebabkan masalah kompatibilitas lainnya, tetapi Pod Sandboxing di AKS dapat menjalankan kontainer apa pun yang tidak dimodifikasi di dalam batas VM keamanan yang ditingkatkan.

Pod Sandboxing pada AKS didasarkan pada Kata Containers yang berjalan pada host kontainer Azure Linux untuk tumpukan AKS untuk menyediakan isolasi yang diberlakukan perangkat keras. Kontainer Kata di AKS dibangun di atas hypervisor Azure yang diperkuat keamanan. Ini mencapai isolasi per pod melalui Kata VM berlapis dan ringan yang menggunakan sumber daya dari simpul VM induk. Dalam model ini, setiap Pod Kata mendapatkan kernelnya sendiri dalam VM tamu Kata berlapis. Gunakan model ini untuk menempatkan banyak kontainer Kata dalam satu VM tamu sambil terus menjalankan kontainer di VM induk. Model ini menyediakan batas isolasi yang kuat dalam kluster AKS bersama.

Untuk informasi selengkapnya, lihat:

Azure Dedicated Host

Azure Dedicated Host adalah layanan yang menyediakan server fisik yang didedikasikan untuk satu langganan Azure dan menyediakan isolasi perangkat keras di tingkat server fisik. Anda dapat menyediakan host khusus ini dalam wilayah, zona ketersediaan, dan domain kesalahan, dan Anda dapat menempatkan VM langsung ke host yang disediakan.

Ada beberapa manfaat menggunakan Azure Dedicated Host dengan AKS, termasuk:

  • Isolasi perangkat keras memastikan bahwa tidak ada VM lain yang ditempatkan pada host khusus, yang menyediakan lapisan isolasi tambahan untuk beban kerja penyewa. Host khusus disebarkan di pusat data yang sama dan berbagi jaringan yang sama dan infrastruktur penyimpanan yang mendasar sebagai host lain yang tidak terisolasi.

  • Azure Dedicated Host menyediakan kontrol atas peristiwa pemeliharaan yang dimulai platform Azure. Anda dapat memilih jendela pemeliharaan untuk mengurangi dampak pada layanan dan membantu memastikan ketersediaan dan privasi beban kerja penyewa.

Azure Dedicated Host dapat membantu penyedia SaaS memastikan aplikasi penyewa memenuhi persyaratan kepatuhan peraturan, industri, dan tata kelola untuk mengamankan informasi sensitif. Untuk informasi selengkapnya, lihat Menambahkan Azure Dedicated Host ke kluster AKS.

Karpenter

Karpenter adalah proyek manajemen siklus hidup simpul sumber terbuka yang dibangun untuk Kubernetes. Menambahkan Karpenter ke kluster Kubernetes dapat meningkatkan efisiensi dan biaya menjalankan beban kerja pada kluster tersebut. Karpenter mengawasi pod yang ditandai oleh penjadwal Kubernetes sebagai tidak dapat dischedulable. Ini juga secara dinamis menyediakan dan mengelola simpul yang dapat memenuhi persyaratan pod.

Karpenter memberikan kontrol terperindar atas provisi node dan penempatan beban kerja dalam kluster terkelola. Kontrol ini meningkatkan multitenansi dengan mengoptimalkan alokasi sumber daya, memastikan isolasi antara setiap aplikasi penyewa, dan mengurangi biaya operasional. Saat Anda membangun solusi multipenyewa di AKS, Karpenter menyediakan kemampuan yang berguna untuk membantu Anda mengelola berbagai persyaratan aplikasi untuk mendukung penyewa yang berbeda. Misalnya, Anda mungkin memerlukan beberapa aplikasi penyewa untuk berjalan pada kumpulan simpul yang dioptimalkan GPU dan yang lain untuk berjalan pada kumpulan simpul yang dioptimalkan memori. Jika aplikasi Anda memerlukan latensi rendah untuk penyimpanan, Anda dapat menggunakan Karpenter untuk menunjukkan bahwa pod memerlukan simpul yang berjalan di zona ketersediaan tertentu sehingga Anda dapat mengkolokasikan tingkat penyimpanan dan aplikasi Anda.

AKS memungkinkan provisi otomatis simpul pada kluster AKS melalui Karpenter. Sebagian besar pengguna harus menggunakan mode provisi otomatis simpul untuk mengaktifkan Karpenter sebagai addon terkelola. Untuk informasi selengkapnya, lihatprovisi otomatis Simpul . Jika Anda membutuhkan penyesuaian yang lebih canggih, Anda dapat memilih untuk menghost sendiri Karpenter. Untuk informasi selengkapnya, lihatpenyedia AKS Karpenter .

VM Rahasia

Anda dapat menggunakan VM rahasia untuk menambahkan satu atau beberapa kumpulan simpul ke kluster AKS Anda untuk mengatasi persyaratan isolasi, privasi, dan keamanan yang ketat penyewa. VM Rahasia menggunakan lingkungan eksekusi tepercaya berbasis perangkat keras. AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP) VM rahasia menolak akses kode hypervisor dan manajemen host lainnya ke memori dan status VM, yang menambahkan lapisan pertahanan dan perlindungan mendalam terhadap akses operator. Untuk informasi selengkapnya, lihat Menggunakan VM rahasia dalam kluster AKS.

Standar Proses Informasi Federal (FIPS)

FIPS 140-3 adalah standar pemerintah AS yang menentukan persyaratan keamanan minimum untuk modul kriptografi dalam produk dan sistem teknologi informasi. Dengan mengaktifkan kepatuhan FIPS untuk kumpulan simpul AKS, Anda dapat meningkatkan isolasi, privasi, dan keamanan beban kerja penyewa Anda. kepatuhan FIPS memastikan penggunaan modul kriptografi yang divalidasi untuk enkripsi, hashing, dan operasi terkait keamanan lainnya. Dengan kumpulan simpul AKS berkemampuan FIPS, Anda dapat memenuhi persyaratan kepatuhan peraturan dan industri dengan menggunakan algoritma dan mekanisme kriptografi yang kuat. Azure menyediakan dokumentasi tentang cara mengaktifkan FIPS untuk kumpulan simpul AKS, yang memungkinkan Anda memperkuat postur keamanan lingkungan AKS multipenyewa Anda. Untuk informasi selengkapnya, lihat Mengaktifkan FIPS untuk kumpulan simpul AKS.

Membawa kunci Anda sendiri (BYOK) dengan disk Azure

Azure Storage mengenkripsi semua data di akun penyimpanan saat tidak aktif, termasuk OS dan disk data kluster AKS. Secara default, data dienkripsi dengan kunci yang dikelola Microsoft. Untuk kontrol lebih besar atas kunci enkripsi, Anda dapat menyediakan kunci yang dikelola pelanggan untuk digunakan untuk enkripsi di sisa OS dan disk data kluster AKS Anda. Untuk informasi selengkapnya, lihat:

Enkripsi berbasis host

enkripsi berbasis Host pada AKS semakin memperkuat isolasi, privasi, dan keamanan beban kerja penyewa. Saat Anda mengaktifkan enkripsi berbasis host, AKS mengenkripsi data tidak aktif pada komputer host yang mendasar, yang membantu memastikan bahwa informasi penyewa sensitif dilindungi dari akses yang tidak sah. Disk sementara dan disk OS sementara dienkripsi saat tidak aktif dengan kunci yang dikelola platform saat Anda mengaktifkan enkripsi end-to-end.

Di AKS, OS dan disk data menggunakan enkripsi sisi server dengan kunci yang dikelola platform secara default. Cache untuk disk ini dienkripsi saat tidak aktif dengan kunci yang dikelola platform. Anda dapat menentukan kunci enkripsi kunci Anda sendiri untuk mengenkripsi kunci perlindungan data dengan menggunakan enkripsi amplop, juga dikenal sebagai membungkus. Cache untuk OS dan disk data juga dienkripsi melalui BYOK yang Anda tentukan.

Enkripsi berbasis host menambahkan lapisan keamanan untuk lingkungan multipenyewa. Setiap data penyewa di OS dan cache disk data dienkripsi saat tidak aktif dengan kunci yang dikelola pelanggan atau yang dikelola platform, tergantung pada jenis enkripsi disk yang dipilih. Untuk informasi selengkapnya, lihat:

Jaringan

Bagian berikut menjelaskan praktik terbaik jaringan untuk solusi multipenyewa dengan AKS.

Membatasi akses jaringan ke server API

Di Kubernetes, server API menerima permintaan untuk melakukan tindakan di kluster, seperti membuat sumber daya atau menskalakan jumlah simpul. Saat Anda berbagi kluster AKS di beberapa tim dalam organisasi, lindungi akses ke sarana kontrol dengan menggunakan salah satu solusi berikut.

Kluster AKS privat

Dengan menggunakan kluster AKS privat, Anda dapat memastikan lalu lintas jaringan antara server API dan kumpulan simpul Anda tetap berada dalam jaringan virtual Anda. Dalam kluster AKS privat, sarana kontrol atau server API memiliki alamat IP internal yang hanya dapat diakses melalui titik akhir privat Azure , yang terletak di jaringan virtual kluster AKS yang sama. Demikian juga, komputer virtual apa pun di jaringan virtual yang sama dapat berkomunikasi secara privat dengan sarana kontrol melalui titik akhir privat. Untuk informasi selengkapnya, lihat Membuat kluster AKS privat.

Rentang alamat IP resmi

Opsi kedua untuk meningkatkan keamanan kluster dan meminimalkan serangan adalah dengan menggunakan rentang alamat IP resmi . Pendekatan ini membatasi akses ke sarana kontrol kluster AKS publik ke daftar alamat IP yang terkenal dan rentang Classless Inter-Domain Routing (CIDR). Saat Anda menggunakan alamat IP resmi, alamat IP tersebut masih terekspos secara publik, tetapi akses terbatas pada serangkaian rentang. Untuk informasi selengkapnya, lihat Akses aman ke server API menggunakan rentang alamat IP resmi di AKS.

layanan Azure Private Link adalah komponen infrastruktur yang memungkinkan aplikasi untuk terhubung secara privat ke layanan melalui titik akhir privat Azure yang ditentukan dalam jaringan virtual dan terhubung ke konfigurasi IP front-end instans Azure Load Balancer. Dengan Private Link, penyedia layanan dapat dengan aman menyediakan layanan mereka ke penyewa mereka yang dapat terhubung dari dalam Azure atau lokal, tanpa risiko penyelundupan data.

Anda dapat menggunakan integrasi layanan Private Link untuk menyediakan konektivitas privat kepada penyewa ke beban kerja yang dihosting AKS mereka dengan cara yang aman, tanpa perlu mengekspos titik akhir publik apa pun di internet publik.

Untuk informasi selengkapnya tentang cara mengonfigurasi Private Link untuk solusi multipenyewa yang dihosting Azure, lihat Multitenancy dan Private Link.

Proksi terbalik

proksi terbalik adalah load balancer dan gateway API yang biasanya digunakan di depan aplikasi penyewa untuk mengamankan, memfilter, dan mengirimkan permintaan masuk. Proksi terbalik populer mendukung fitur seperti penyeimbangan beban, penghentian SSL, dan perutean lapisan 7. Proksi terbalik biasanya diterapkan untuk membantu meningkatkan keamanan, performa, dan keandalan. Proksi terbalik populer untuk Kubernetes mencakup implementasi berikut:

  • NGINX Ingress Controller adalah server proksi terbalik populer yang mendukung fitur canggih, seperti penyeimbangan beban, penghentian SSL, dan perutean lapisan 7.
  • penyedia Traefik Kubernetes Ingress adalah pengontrol Ingress Kubernetes yang dapat digunakan untuk mengelola akses ke layanan kluster dengan mendukung spesifikasi ingress.
  • Pengontrol Ingress Kubernetes HAProxy adalah proksi terbalik lainnya untuk Kubernetes, yang mendukung fitur standar seperti penghentian TLS, perutean berbasis jalur URL, dan banyak lagi.
  • Azure Application Gateway Ingress Controller (AGIC) adalah aplikasi Kubernetes, yang memungkinkan pelanggan AKS menggunakan penyeimbang beban Azure-native Application Gateway L7 untuk mengekspos aplikasi penyewa ke internet publik atau secara internal ke sistem lain yang berjalan di jaringan virtual.

Saat Anda menggunakan proksi terbalik yang dihosting AKS untuk membantu mengamankan dan menangani permintaan masuk ke beberapa aplikasi penyewa, pertimbangkan rekomendasi berikut:

  • Host proksi terbalik pada kumpulan simpul khusus yang dikonfigurasi untuk menggunakan ukuran VM dengan bandwidth jaringan tinggi dan jaringan yang dipercepat diaktifkan.
  • Konfigurasikan kumpulan simpul yang menghosting proksi terbalik Anda untuk penskalaan otomatis.
  • Untuk menghindari peningkatan latensi dan batas waktu untuk aplikasi penyewa, tentukan kebijakan penskalaan otomatis sehingga jumlah pod pengontrol ingress dapat langsung diperluas dan dikontrak agar sesuai dengan fluktuasi lalu lintas.
  • Pertimbangkan untuk memecah lalu lintas masuk ke aplikasi penyewa, di beberapa instans pengontrol ingress Anda, untuk meningkatkan skalabilitas dan tingkat pemisahan.

Saat Anda menggunakanAzure Application Gateway Ingress Controller (AGIC), pertimbangkan untuk menerapkan praktik terbaik berikut:

  • Konfigurasikan gateway aplikasi yang digunakan pengontrol ingress untuk penskalaan otomatis. Dengan autoscaling diaktifkan, gateway aplikasi dan web application firewall (WAF) v2 SKU peluasan skala atau masuk, berdasarkan persyaratan lalu lintas aplikasi. Mode ini memberikan elastisitas yang lebih baik untuk aplikasi Anda dan menghilangkan kebutuhan untuk menebak ukuran gateway aplikasi atau jumlah instans. Mode ini juga membantu Anda menghemat biaya dengan tidak memerlukan gateway untuk berjalan pada kapasitas yang disediakan puncak untuk beban lalu lintas maksimum yang diharapkan. Anda harus menentukan jumlah instans minimum (dan maksimum opsional).
  • Pertimbangkan untuk menyebarkan beberapa instansAGIC , masing-masing terkait dengan gateway aplikasi terpisah, ketika jumlah aplikasi penyewa melebihi jumlah maksimum situs. Dengan asumsi bahwa setiap aplikasi penyewa berjalan di namespace khusus, gunakan dukungan beberapa namespace layanan untuk menyebarkan aplikasi penyewa di lebih banyak instans AGIC.

Integrasi dengan Azure Front Door

Azure Front Door adalah load balancer lapisan-7 global dan jaringan pengiriman konten cloud (CDN) modern dari Microsoft yang menyediakan akses cepat, andal, dan aman antara pengguna dan aplikasi web di seluruh dunia. Azure Front Door mendukung fitur seperti akselerasi permintaan, penghentian SSL, penembolokan respons, WAF di tepi, perutean berbasis URL, penulisan ulang, dan pengalihan yang dapat Anda gunakan saat mengekspos aplikasi multipenyewa yang dihosting AKS ke internet publik.

Misalnya, Anda mungkin ingin menggunakan aplikasi multipenyewa yang dihosting AKS untuk melayani semua permintaan pelanggan. Dalam konteks ini, Anda dapat menggunakan Azure Front Door untuk mengelola beberapa domain kustom, satu untuk setiap penyewa. Anda dapat mengakhiri koneksi SSL di tepi dan merutekan semua lalu lintas ke aplikasi multipenyewa yang dihosting AKS yang dikonfigurasi dengan satu nama host.

Diagram yang menunjukkan bagaimana Azure Front Door dan AKS terhubung.

Anda dapat mengonfigurasi Azure Front Door untuk mengubah header host asal permintaan agar sesuai dengan nama domain aplikasi backend. Header Host asli yang dikirim oleh klien disebarluaskan melalui header X-Forwarded-Host, dan kode aplikasi multipenyewa dapat menggunakan informasi ini untuk memetakan permintaan masuk ke penyewa yang benar.

Azure Web Application Firewall, di Azure Front Door, memberikan perlindungan terpusat untuk aplikasi web. Azure Web Application Firewall dapat membantu Anda mempertahankan aplikasi penyewa yang dihosting AKS yang mengekspos titik akhir publik di internet dari serangan berbahaya.

Anda dapat mengonfigurasi Azure Front Door Premium untuk terhubung secara privat ke satu atau beberapa aplikasi penyewa yang berjalan pada kluster AKS, melalui asal load balancer internal, dengan menggunakan Private Link. Untuk informasi selengkapnya, lihat Menyambungkan Azure Front Door Premium ke asal load balancer internal dengan Private Link.

Koneksi keluar

Ketika aplikasi yang dihosting AKS terhubung ke sejumlah besar database atau layanan eksternal, kluster mungkin berisiko kelelahan port terjemahan alamat jaringan sumber (SNAT). port SNAT menghasilkan pengidentifikasi unik yang digunakan untuk mempertahankan alur berbeda yang dijalankan aplikasi pada set sumber daya komputasi yang sama yang dimulai. Dengan menjalankan beberapa aplikasi penyewa pada kluster AKS bersama, Anda mungkin melakukan sejumlah besar panggilan keluar, yang dapat menyebabkan kelelahan port SNAT. Kluster AKS dapat menangani koneksi keluar dengan tiga cara berbeda:

  • Azure Load Balancer: Secara default, AKS menyediakan Load Balancer SKU Standar untuk disiapkan dan digunakan untuk koneksi keluar. Namun, pengaturan default mungkin tidak memenuhi persyaratan semua skenario jika alamat IP publik tidak diizinkan atau jika hop tambahan diperlukan untuk keluar. Secara default, load balancer publik dibuat dengan alamat IP publik default yang aturan keluar yang gunakan. Aturan keluar memungkinkan Anda untuk secara eksplisit menentukan SNAT untuk load balancer standar publik. Konfigurasi ini memungkinkan Anda menggunakan alamat IP publik load balancer Anda untuk menyediakan konektivitas internet keluar untuk instans backend Anda. Jika perlu, untuk menghindari kelelahan port SNAT, Anda dapat mengonfigurasi aturan keluar load balancer publik untuk menggunakan lebih banyak alamat IP publik. Untuk informasi selengkapnya, lihat Menggunakan alamat IP front-end load balancer untuk keluar melalui aturan keluar.
  • Azure NAT Gateway: Anda dapat mengonfigurasi kluster AKS untuk menggunakan Azure NAT Gateway untuk merutekan lalu lintas keluar dari aplikasi penyewa. NAT Gateway memungkinkan hingga 64.512 arus lalu lintas UDP dan TCP keluar per alamat IP publik, dengan maksimum 16 alamat IP. Untuk menghindari risiko kelelahan port SNAT saat Anda menggunakan NAT Gateway untuk menangani koneksi keluar dari kluster AKS, Anda dapat mengaitkan lebih banyak alamat IP publik atau awalan alamat IP publik ke gateway. Untuk informasi selengkapnya, lihat pertimbangan Azure NAT Gateway untukmultitenansi .
  • rute yang ditentukan pengguna (UDR): Anda dapat menyesuaikan rute keluar kluster AKS untuk mendukung skenario jaringan kustom, seperti yang melarang alamat IP publik dan mengharuskan kluster untuk duduk di belakang appliance virtual jaringan (NVA). Saat Anda mengonfigurasi kluster untuk perutean yang ditentukan pengguna, AKS tidak secara otomatis mengonfigurasi jalur keluar. Anda harus menyelesaikan penyiapan keluar. Misalnya, Anda merutekan lalu lintas keluar melalui Azure Firewall. Anda harus menyebarkan kluster AKS ke jaringan virtual yang ada dengan subnet yang sebelumnya Anda konfigurasikan. Saat Anda tidak menggunakan arsitektur load balancer standar, Anda harus menetapkan egress eksplisit. Dengan demikian, arsitektur ini mengharuskan pengiriman lalu lintas keluar secara eksplisit ke appliance, seperti firewall, gateway, atau proksi. Atau, arsitektur memungkinkan terjemahan alamat jaringan (NAT) dilakukan oleh IP publik yang ditetapkan ke load balancer atau appliance standar.

Pemantauan

Anda dapat menggunakan Azure Monitor dan wawasan kontainer untuk memantau aplikasi penyewa yang berjalan pada kluster AKS bersama dan untuk menghitung perincian biaya pada namespace layanan individual. Gunakan Azure Monitor untuk memantau kesehatan dan performa AKS. Ini termasuk pengumpulan log dan metrik, analisis telemetri, dan visualisasi data yang dikumpulkan untuk mengidentifikasi tren dan untuk mengonfigurasi pemberitahuan yang secara proaktif memberi tahu Anda tentang masalah penting. Anda dapat mengaktifkan wawasan kontainer untuk memperluas pemantauan ini.

Anda juga dapat mengadopsi alat sumber terbuka, seperti Prometheus dan Grafana, yang banyak digunakan untuk pemantauan Kubernetes. Atau, Anda dapat mengadopsi alat non-Microsoft lainnya untuk pemantauan dan pengamatan.

Biaya

Tata kelola biaya adalah proses berkelanjutan dalam menerapkan kebijakan untuk mengontrol biaya. Dalam konteks Kubernetes, ada beberapa metode yang dapat digunakan organisasi untuk mengontrol dan mengoptimalkan biaya. Metode ini termasuk menggunakan alat Kubernetes asli untuk mengelola dan mengatur penggunaan dan konsumsi sumber daya dan untuk secara proaktif memantau dan mengoptimalkan infrastruktur yang mendasar. Saat menghitung biaya per penyewa, Anda harus mempertimbangkan biaya yang terkait dengan sumber daya apa pun yang digunakan aplikasi penyewa. Pendekatan yang Anda ikuti untuk membebankan biaya kembali ke penyewa tergantung pada model penyewaan yang diadopsi solusi Anda. Daftar berikut ini menjelaskan model penyewaan secara lebih rinci:

  • Sepenuhnya multipenyewa: Ketika satu aplikasi multipenyewa melayani semua permintaan penyewa, Anda bertanggung jawab untuk melacak konsumsi sumber daya dan jumlah permintaan yang dihasilkan setiap penyewa. Anda kemudian menagih pelanggan Anda sesuai.
  • Kluster khusus: Saat kluster didedikasikan untuk satu penyewa, mudah untuk membebankan biaya sumber daya Azure kembali kepada pelanggan. Total biaya kepemilikan tergantung pada banyak faktor, termasuk jumlah dan ukuran VM, biaya jaringan lalu lintas jaringan, alamat IP publik, penyeimbang muatan, dan layanan penyimpanan, seperti disk terkelola atau file Azure yang digunakan solusi penyewa. Anda dapat menandai kluster AKS dan sumber dayanya di grup sumber daya simpul untuk memfasilitasi operasi pengisian biaya. Untuk informasi selengkapnya, lihat Menambahkan tag ke kluster.
  • Kumpulan simpul khusus: Anda dapat menerapkan tag Azure ke kumpulan simpul baru atau yang sudah ada yang didedikasikan untuk satu penyewa. Tag diterapkan ke setiap simpul dalam kumpulan simpul dan dipertahankan melalui peningkatan. Tag juga diterapkan ke simpul baru yang ditambahkan ke kumpulan simpul selama operasi peluasan skala. Menambahkan tag dapat membantu tugas seperti pelacakan kebijakan atau pengisian biaya. Untuk informasi selengkapnya, lihat Menambahkan tag ke kumpulan simpul.
  • Sumber daya lain: Anda dapat menggunakan tag untuk mengaitkan biaya sumber daya khusus ke penyewa tertentu. Secara khusus, Anda dapat menandai alamat IP publik, file, dan disk dengan menggunakan manifes Kubernetes. Tag yang diatur dengan cara ini mempertahankan nilai Kubernetes, bahkan jika Anda memperbaruinya nanti dengan menggunakan metode lain. Ketika alamat IP publik, file, atau disk dihapus melalui Kubernetes, tag apa pun yang ditetapkan Kubernetes dihapus. Tag pada sumber daya yang tidak dilacak Kubernetes tetap tidak terpengaruh. Untuk informasi selengkapnya, lihat Menambahkan tag dengan menggunakan Kubernetes.

Anda dapat menggunakan alat sumber terbuka, seperti KubeCost, untuk memantau dan mengatur biaya kluster AKS. Anda dapat mencakup alokasi biaya ke penyebaran, layanan, label, pod, dan namespace, yang memberi Anda fleksibilitas dalam cara Anda menagih kembali atau menampilkan kembali pengguna kluster. Untuk informasi selengkapnya, lihat tata kelola biaya dengan Kubecost.

Untuk informasi selengkapnya tentang pengukuran, alokasi, dan pengoptimalan biaya untuk aplikasi multipenyewa, lihat pendekatan arsitektur untuk manajemen biaya dan alokasi dalam solusi multipenyewa. Untuk panduan umum tentang pengoptimalan biaya, lihat artikel Azure Well-Architected Framework, Gambaran Umum pilar Pengoptimalan Biaya.

Pemerintahan

Ketika beberapa penyewa berbagi infrastruktur yang sama, mengelola privasi data, kepatuhan, dan persyaratan peraturan dapat menjadi rumit. Anda perlu menerapkan langkah-langkah keamanan dan kebijakan tata kelola data yang kuat. Kluster AKS bersama menghadirkan risiko pelanggaran data yang lebih tinggi, akses tidak sah, dan ketidakpatuhan terhadap peraturan perlindungan data. Setiap penyewa mungkin memiliki persyaratan tata kelola data dan kebijakan kepatuhan yang unik, yang menyulitkan untuk memastikan keamanan dan privasi data.

Microsoft Defender for Containers adalah solusi keamanan kontainer cloud-native yang menyediakan kemampuan deteksi dan perlindungan ancaman untuk lingkungan Kubernetes. Dengan menggunakan Defender untuk Kontainer, Anda dapat meningkatkan tata kelola data dan postur kepatuhan saat menghosting beberapa penyewa di kluster Kubernetes. Gunakan Defender untuk Kontainer untuk membantu melindungi data sensitif, mendeteksi dan merespons ancaman dengan menganalisis perilaku kontainer dan lalu lintas jaringan, dan memenuhi persyaratan peraturan. Ini menyediakan kemampuan audit, manajemen log, dan pembuatan laporan untuk menunjukkan kepatuhan terhadap regulator dan auditor.

Kontributor

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

Penulis utama:

Kontributor lain: