Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Saat menjawab pertanyaan, "Bagaimana cara mengonfigurasi Kubernetes untuk multitenansi?", arsitek harus terlebih dahulu memahami batas konseptual dan model isolasi yang tersedia. Multitenansi di AKS adalah praktik menjalankan beberapa beban kerja terisolasi yang dimiliki oleh tim, aplikasi, atau pelanggan yang berbeda dalam satu kluster Kubernetes bersama. Artikel ini menjelaskan konsep dasar dan model arsitektur untuk multitenansi di Azure Kubernetes Service (AKS).
Tip
Apa saja tiga model multitenansi di AKS? Multitenansi AKS menggunakan spektrum isolasi dengan tiga model umum: isolasi namespace, isolasi pool node, dan satu kluster untuk setiap penyewa. Isolasi namespace paling sesuai untuk tim internal tepercaya dan efisiensi biaya maksimum, isolasi pool node memberikan pemisahan beban kerja yang lebih kuat dengan overhead moderat, dan satu kluster per penyewa memberikan isolasi terkuat untuk skenario yang tidak tepercaya atau dengan regulasi ketat.
Untuk petunjuk implementasi langkah demi langkah dan manifes YAML, lihat panduan terkait: Praktik terbaik untuk multitenansi di AKS.
Mengapa multitenansi di AKS?
Multi-tenancy memungkinkan beberapa tim, aplikasi, atau pelanggan berbagi satu cluster Kubernetes. Alasan utama untuk multitenansi di AKS adalah efisiensi biaya dan skala operasional.
Menjalankan klaster khusus untuk setiap aplikasi atau tim mengakibatkan fragmentasi sumber daya yang signifikan, kapasitas komputasi yang menganggur, dan overhead bidang kontrol yang berlipat ganda. Dengan mengonsolidasikan beban kerja ke dalam kluster multi-penyewa, organisasi memaksimalkan penggunaan sumber daya dan mengurangi biaya cloud. Secara operasional, multitenansi mengurangi jumlah armada, yang berarti tim platform memiliki lebih sedikit kluster untuk ditambal, dimutakhirkan, dipantau, dan diamankan, sehingga menyederhanakan pengelolaan siklus hidup.
Apa perbedaan antara multi-tenancy lunak dan multi-tenancy keras?
Kubernetes pada dasarnya bukan sistem multitenan. Untuk mewujudkan arsitektur multi-tenant, Anda harus merancang dengan model isolasi "soft" atau "hard" berdasarkan tingkat kepercayaan di antara tenant.
Perbedaan antara soft dan hard multitenansi di Kubernetes terutama terletak pada model kepercayaan dan kebutuhan isolasi yang timbul karenanya. Multi-tenancy lunak mengasumsikan tenant internal yang tepercaya dan berfokus pada pencegahan interferensi yang tidak disengaja melalui kontrol logis seperti namespace, RBAC, dan kuota. Hard multi-tenancy mengasumsikan tingkat kepercayaan yang rendah atau tidak ada sama sekali antara tenant dan memerlukan kontrol isolasi yang lebih kuat untuk mengurangi risiko akses berbahaya, pergerakan lateral, dan paparan data.
| Model | Tingkat kepercayaan | Maksud | Skenario penggunaan | Contoh skenario |
|---|---|---|---|---|
| Multitenansi lunak | Kepercayaan tinggi antara penyewa internal | Mencegah interferensi yang tidak disengaja, kekurangan sumber daya, dan konflik konfigurasi | Lingkungan platform internal tempat tim berbagi infrastruktur | Beberapa tim produk dalam satu organisasi berbagi kluster AKS untuk layanan dev/test dan internal |
| Multi-penyewa ketat | Kepercayaan rendah atau nol antar penyewa | Mencegah serangan berbahaya, gerakan lateral, dan penyelundupan data | Hosting pelanggan eksternal dan beban kerja yang diatur | Penyedia SaaS menghosting beban kerja khusus pelanggan di mana isolasi penyewa adalah persyaratan keamanan dan kepatuhan |
Spektrum tingkat isolasi
Multitenancy pada AKS bukanlah pilihan biner; melainkan berada pada suatu spektrum. Saat Anda bergerak melintasi spektrum, isolasi meningkat, tetapi begitu juga kompleksitas dan biaya operasional. Spektrum ini membentuk kerangka utama untuk desain kluster multi-penyewa:
- Isolasi namespace (Logis): Tenant berbagi pool node dan control plane yang sama, tetapi dipisahkan secara logis oleh namespace Kubernetes. Ini adalah dasar dari soft multi-tenant.
- Isolasi kumpulan simpul (Komputasi fisik): Penyewa berbagi sarana kontrol tetapi diberi simpul pekerja khusus. Ini meningkatkan pemisahan beban kerja dan mitigasi gangguan dari tenant lain, tetapi ini belum merupakan isolasi tenant yang sepenuhnya karena control plane dan komponen pada level kluster masih digunakan bersama.
- Satu kluster per penyewa (Sepenuhnya fisik): Setiap penyewa sepenuhnya terisolasi dan masing-masing memiliki bidang kontrol AKS serta bidang data AKS sendiri. Ini adalah bentuk paling ekstrem dari hard multi-tenancy, yang secara efektif mengabaikan model berbagi pada tingkat Kubernetes dan beralih ke isolasi pada tingkat Azure.
Komponen dasar AKS untuk multitenansi
AKS menyediakan serangkaian primitif bawaan dan yang terintegrasi dengan Azure untuk menerapkan spektrum isolasi.
- Microsoft Entra ID: Menyediakan manajemen identitas dan akses terpusat untuk mengautentikasi pengguna dan sistem otomatis ke API Kubernetes.
- Azure RBAC: Memetakan identitas Microsoft Entra ID ke izin Kubernetes, memastikan penyewa hanya dapat mengakses sumber daya yang diotorisasi.
- Namespace terkelola: Menyediakan batas logis dalam kluster untuk mengelompokkan sumber daya penyewa, menerapkan kuota, dan akses cakupan.
- Azure Policy / Gatekeeper: Memberlakukan aturan kepatuhan dan tata kelola terpusat di seluruh kluster untuk mencegah penyewa menyebarkan konfigurasi yang tidak aman atau tidak sah.
- Azure CNI: Menyediakan integrasi jaringan virtual asli untuk jaringan AKS dan mendukung segmentasi lalu lintas penyewa dengan kontrol kebijakan jaringan. Perilaku IP Pod tergantung pada mode CNI yang dipilih (misalnya, Overlay atau Pod Subnet).
- Azure Container Networking Services (ACNS) Cilium L7: Memberikan kebijakan jaringan berbasis eBPF berkinerja tinggi dan pemfilteran lalu lintas Lapisan 7 untuk mengisolasi lalu lintas jaringan penyewa secara ketat.
- Identitas beban kerja: Memungkinkan pod individual mengautentikasi dengan aman ke layanan Azure eksternal menggunakan identitas federasi, menghilangkan rahasia bersama antar penyewa.
Memetakan lapisan isolasi di seluruh bidang
Untuk membangun arsitektur multitenant yang aman, Anda harus menerapkan komponen dasar AKS di tiga lapisan berbeda dalam lingkungan kluster.
| Pesawat | Description | Komponen inti AKS yang diterapkan |
|---|---|---|
| Pesawat kontrol | Mengamankan akses ke server API Kubernetes dan batas logis. | Microsoft Entra ID, Azure RBAC, Namespace terkelola |
| data plane | Mengamankan lalu lintas jaringan, eksekusi komputasi, dan batas tingkat simpul. | Azure CNI, ACNS Cilium L7, Kumpulan simpul |
| Bidang sumber daya | Mengatur konsumsi komputasi, akses eksternal, dan kepatuhan konfigurasi. | Azure Policy, Identitas beban kerja |
Model isolasi mana yang harus Anda pilih?
Gunakan matriks berikut untuk menentukan titik mana pada spektrum isolasi yang paling sesuai dengan persyaratan organisasi Anda.
| Model isolasi | Tingkat keamanan | Efisiensi biaya | Kompleksitas operasional | Paling cocok untuk |
|---|---|---|---|---|
| Namespace-per-tenant | Rendah ke Sedang (Logis) | Tinggi (Berbagi maksimal) | Rendah (hanya satu kluster untuk dikelola) | Tim internal, lingkungan dev/test, multi-penyewaan lunak. |
| Node-pool-per-tenant | Tinggi (Komputasi terisolasi) | Sedang (Sarana kontrol bersama) | Sedang (Mengelola taint/toleransi) | Beban kerja internal dan eksternal yang membutuhkan pemisahan komputasi yang lebih kuat saat berbagi sarana kontrol; tidak ideal untuk penyewaan zero-trust yang bermusuhan. |
| Kluster per penyewa | Tertinggi (Fisik) | Rendah (beban tambahan tinggi) | Tinggi (memerlukan pengelolaan armada) | Multi-penyewaan yang bermusuhan, pelanggan perusahaan eksternal, tanpa kepercayaan. |
Kapan menggunakan setiap model
- Gunakan namespace per tenant ketika penyewa merupakan pihak internal atau tepercaya, efisiensi biaya menjadi prioritas, dan kontrol isolasi logis sudah memadai.
- Gunakan node-pool-per-tenant saat Anda memerlukan pemisahan komputasi yang lebih kuat dan mengurangi dampak gangguan dari tenant lain, dengan tetap berbagi satu bidang kontrol AKS.
- Gunakan kluster per penyewa saat penyewa tidak tepercaya, batas peraturan ketat, atau model risiko Anda memerlukan infrastruktur bersama minimal.
Langkah berikutnya
Sekarang setelah Anda memahami model konseptual dan primitif untuk multitenansi, lanjutkan ke panduan implementasi untuk menerapkan konsep ini ke kluster Anda.
Intinya
- Arsitektur multi-tenant di Azure Kubernetes Service (AKS) adalah praktik menjalankan beberapa beban kerja tenant yang terisolasi di atas infrastruktur Kubernetes bersama untuk mengurangi biaya dan menyederhanakan operasional.
- Namespace per penyewa adalah model yang paling hemat biaya untuk beban kerja internal tepercaya karena memaksimalkan berbagi infrastruktur sambil menerapkan batas logis.
- Node-pool-per-tenant meningkatkan pemisahan komputasi dan kontrol tetangga yang bising, tetapi masih berbagi sarana kontrol AKS dan komponen tingkat kluster lainnya.
- Kluster per penyewa menyediakan isolasi penyewa terkuat untuk skenario zero-trust dan sangat teregulasi, tetapi membutuhkan biaya yang lebih tinggi dan overhead operasional yang lebih tinggi.