Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Isolasi Penyewa
Ketika kita memikirkan multi-tenancy, kita sering ingin mengisolasi pengguna atau aplikasi dari pengguna atau aplikasi lain yang berjalan pada infrastruktur bersama.
Kubernetes adalah orkestrator penyewa tunggal, yaitu satu instance dari pesawat kontrol dibagi di antara semua penyewa dalam sebuah cluster. Namun, ada berbagai objek Kubernetes yang dapat Anda gunakan untuk membuat kemiripan multi-tenancy. Misalnya, Namespaces dan Role-based access control (RBAC) dapat diimplementasikan untuk secara logis mengisolasi penyewa satu sama lain. Demikian pula, Quotas dan Limit Ranges dapat digunakan untuk mengontrol jumlah sumber daya cluster yang dapat dikonsumsi setiap penyewa. Namun demikian, cluster adalah satu-satunya konstruksi yang menyediakan batas keamanan yang kuat. Ini karena penyerang yang berhasil mendapatkan akses ke host di dalam cluster dapat mengambil semua Rahasia,, dan VolumeConfigMaps, yang dipasang pada host itu. Mereka juga bisa meniru Kubelet yang memungkinkan mereka memanipulasi atribut node yang and/or bergerak secara lateral di dalam cluster.
Bagian berikut akan menjelaskan bagaimana menerapkan isolasi penyewa sambil mengurangi risiko menggunakan orkestrator penyewa tunggal seperti Kubernetes.
Multi-tenancy lembut
Dengan soft multi-tenancy, Anda menggunakan konstruksi Kubernetes asli, misalnya namespace, role dan role binding, dan kebijakan jaringan, untuk membuat pemisahan logis antar penyewa. RBAC, misalnya, dapat mencegah penyewa mengakses atau memanipulasi sumber daya masing-masing. Kuota dan rentang batas mengontrol jumlah sumber daya cluster yang dapat dikonsumsi setiap penyewa sementara kebijakan jaringan dapat membantu mencegah aplikasi yang digunakan ke ruang nama yang berbeda berkomunikasi satu sama lain.
Namun, tak satu pun dari kontrol ini mencegah pod dari penyewa yang berbeda berbagi node. Jika diperlukan isolasi yang lebih kuat, Anda dapat menggunakan pemilih node, aturan anti-afinitas, and/or taint, dan toleransi untuk memaksa pod dari penyewa yang berbeda dijadwalkan ke node terpisah; sering disebut sebagai node penyewa tunggal. Ini bisa menjadi agak rumit, dan biayanya mahal, di lingkungan dengan banyak penyewa.
penting
Soft multi-tenancy yang diimplementasikan dengan Namespaces tidak memungkinkan Anda untuk menyediakan penyewa dengan daftar Namespaces yang difilter karena Namespace adalah Tipe cakupan global. Jika penyewa memiliki kemampuan untuk melihat Namespace tertentu, ia dapat melihat semua Namespace dalam cluster.
Awas
Dengan soft-multi-tenancy, penyewa mempertahankan kemampuan untuk menanyakan CoreDNS untuk semua layanan yang berjalan di dalam cluster secara default. Seorang penyerang dapat mengeksploitasi ini dengan menjalankan dig SRV
..svc.cluster.local dari pod mana pun di cluster. Jika Anda perlu membatasi akses ke catatan DNS layanan yang berjalan dalam cluster Anda, pertimbangkan untuk menggunakan plugin Firewall atau Kebijakan untuk CoreDNS. Untuk informasi tambahan, lihat https://github.com/coredns/kebijakan # -policy kubernetes-metadata-multi-tenancy
Kiosk
-
Akun & Pengguna Akun untuk memisahkan penyewa di klaster Kubernetes bersama
-
Penyediaan Namespace Layanan Mandiri untuk pengguna akun
-
Batas Akun untuk memastikan kualitas layanan dan keadilan saat berbagi klaster
-
Template Namespace untuk isolasi penyewa yang aman dan inisialisasi namespace swalayan
Loft
-
Akses multi-cluster untuk memberikan akses ke ruang di cluster yang berbeda
-
Mode tidur menurunkan penyebaran di ruang selama periode tidak aktif
-
Sistem masuk tunggal dengan penyedia otentikasi OIDC seperti GitHub
Ada tiga kasus penggunaan utama yang dapat diatasi dengan soft multi-tenancy.
Pengaturan Perusahaan
Yang pertama adalah dalam pengaturan Perusahaan di mana “penyewa” semi-dipercaya karena mereka adalah karyawan, kontraktor, atau diberi wewenang oleh organisasi. Setiap penyewa biasanya akan menyelaraskan ke divisi administratif seperti departemen atau tim.
Dalam jenis pengaturan ini, administrator klaster biasanya akan bertanggung jawab untuk membuat ruang nama dan mengelola kebijakan. Mereka juga dapat menerapkan model administrasi yang didelegasikan di mana individu tertentu diberi pengawasan atas namespace, memungkinkan mereka untuk melakukan operasi CRUD untuk objek terkait non-kebijakan seperti penerapan, layanan, pod, pekerjaan, dll.
Isolasi yang disediakan oleh runtime kontainer mungkin dapat diterima dalam pengaturan ini atau mungkin perlu ditambah dengan kontrol tambahan untuk keamanan pod. Mungkin juga perlu untuk membatasi komunikasi antar layanan di ruang nama yang berbeda jika diperlukan isolasi yang lebih ketat.
Kubernetes sebagai Layanan
Sebaliknya, soft multi-tenancy dapat digunakan dalam pengaturan di mana Anda ingin menawarkan Kubernetes as a service (KaaS). Dengan KaaS, aplikasi Anda di-host di cluster bersama bersama dengan koleksi pengontrol dan CRDs yang menyediakan satu set layanan PaaS. Penyewa berinteraksi langsung dengan server API Kubernetes dan diizinkan untuk melakukan operasi CRUD pada objek non-kebijakan. Ada juga elemen layanan mandiri di mana penyewa dapat diizinkan untuk membuat dan mengelola ruang nama mereka sendiri. Dalam jenis lingkungan ini, penyewa diasumsikan menjalankan kode yang tidak tepercaya.
Untuk mengisolasi penyewa dalam jenis lingkungan ini, Anda mungkin perlu menerapkan kebijakan jaringan yang ketat serta pod sandboxing. Sandboxing adalah tempat Anda menjalankan kontainer pod di dalam VM mikro seperti Firecracker atau di kernel ruang pengguna. Hari ini, Anda dapat membuat polong kotak pasir dengan EKS Fargate.
Perangkat Lunak sebagai Layanan (SaaS)
Kasus penggunaan terakhir untuk soft multi-tenancy adalah dalam pengaturan ( Software-as-a-ServiceSaaS). Dalam lingkungan ini, setiap penyewa dikaitkan dengan instance tertentu dari aplikasi yang berjalan di dalam cluster. Setiap instance sering memiliki datanya sendiri dan menggunakan kontrol akses terpisah yang biasanya independen dari Kubernetes RBAC.
Berbeda dengan kasus penggunaan lainnya, penyewa dalam pengaturan SaaS tidak secara langsung berinteraksi dengan Kubernetes API. Sebaliknya, aplikasi SaaS bertanggung jawab untuk berinteraksi dengan Kubernetes API untuk membuat objek yang diperlukan untuk mendukung setiap penyewa.
Konstruksi Kubernetes
Dalam setiap contoh ini konstruksi berikut digunakan untuk mengisolasi penyewa dari satu sama lain:
Namespace
Ruang nama sangat penting untuk menerapkan soft multi-tenancy. Mereka memungkinkan Anda untuk membagi cluster menjadi partisi logis. Kuota, kebijakan jaringan, akun layanan, dan objek lain yang diperlukan untuk mengimplementasikan multi-tenancy dicakup ke namespace.
Kebijakan jaringan
Secara default, semua pod dalam klaster Kubernetes diizinkan untuk berkomunikasi satu sama lain. Perilaku ini dapat diubah menggunakan kebijakan jaringan.
Kebijakan jaringan membatasi komunikasi antar pod menggunakan label atau rentang alamat IP. Dalam lingkungan multi-tenant di mana isolasi jaringan yang ketat antara penyewa diperlukan, sebaiknya mulai dengan aturan default yang menolak komunikasi antar pod, dan aturan lain yang memungkinkan semua Pod melakukan query pada server DNS untuk resolusi nama. Dengan itu, Anda dapat mulai menambahkan aturan yang lebih permisif yang memungkinkan komunikasi dalam namespace. Ini dapat disempurnakan lebih lanjut sesuai kebutuhan.
catatan
Amazon VPC CNI sekarang mendukung Kebijakan Jaringan Kubernetes untuk membuat kebijakan
penting
Kebijakan jaringan diperlukan tetapi tidak cukup. Penegakan kebijakan jaringan membutuhkan mesin kebijakan seperti Calico atau Cilium.
Kontrol akses berbasis peran (RBAC)
Roles dan role binding adalah objek Kubernetes yang digunakan untuk menegakkan role-based access control (RBAC) di Kubernetes. Peran berisi daftar tindakan yang dapat dilakukan terhadap objek di klaster Anda. Ikatan peran menentukan individu atau kelompok kepada siapa peran tersebut berlaku. Dalam pengaturan perusahaan dan KaaS, RBAC dapat digunakan untuk mengizinkan administrasi objek oleh kelompok atau individu yang dipilih.
Kuota
Kuota digunakan untuk menentukan batasan beban kerja yang dihosting di klaster Anda. Dengan kuota, Anda dapat menentukan jumlah maksimum CPU dan memori yang dapat dikonsumsi pod, atau Anda dapat membatasi jumlah sumber daya yang dapat dialokasikan dalam klaster atau namespace. Rentang batas memungkinkan Anda untuk mendeklarasikan nilai minimum, maksimum, dan default untuk setiap batas.
Sumber daya yang berlebihan dalam cluster bersama seringkali bermanfaat karena memungkinkan Anda memaksimalkan sumber daya Anda. Namun, akses tak terbatas ke cluster dapat menyebabkan kelaparan sumber daya, yang dapat menyebabkan penurunan kinerja dan hilangnya ketersediaan aplikasi. Jika permintaan pod disetel terlalu rendah dan pemanfaatan sumber daya aktual melebihi kapasitas node, node akan mulai mengalami tekanan CPU atau memori. Ketika ini terjadi, pod dapat dimulai ulang and/or diusir dari node.
Untuk mencegah hal ini terjadi, Anda harus merencanakan untuk menerapkan kuota pada namespace di lingkungan multi-tenant untuk memaksa penyewa menentukan permintaan dan batasan saat menjadwalkan pod mereka di klaster. Ini juga akan mengurangi potensi penolakan layanan dengan membatasi jumlah sumber daya yang dapat dikonsumsi pod.
Anda juga dapat menggunakan kuota untuk membagi sumber daya cluster agar selaras dengan pengeluaran penyewa. Ini sangat berguna dalam skenario KaaS.
Prioritas dan preemption pod
Prioritas dan preemption Pod dapat berguna ketika Anda ingin lebih mementingkan Pod dibandingkan dengan Pod lainnya. Misalnya, dengan prioritas pod, Anda dapat mengonfigurasi pod dari pelanggan A agar berjalan pada prioritas yang lebih tinggi daripada pelanggan B. Ketika kapasitas yang tersedia tidak mencukupi, penjadwal akan mengusir pod dengan prioritas lebih rendah dari pelanggan B untuk mengakomodasi pod dengan prioritas lebih tinggi dari pelanggan A. Ini bisa sangat berguna di lingkungan SaaS di mana pelanggan yang bersedia membayar premi menerima prioritas yang lebih tinggi.
penting
Prioritas Pod dapat memiliki efek yang tidak diinginkan pada Pod lain dengan prioritas yang lebih rendah. Misalnya, meskipun pod korban dihentikan dengan baik tetapi tidak PodDisruptionBudget dijamin, yang dapat merusak aplikasi dengan prioritas lebih rendah yang bergantung pada kuorum Pod, lihat Batasan preemption.
Mengurangi kontrol
Perhatian utama Anda sebagai administrator lingkungan multi-penyewa adalah mencegah penyerang mendapatkan akses ke host yang mendasarinya. Kontrol berikut harus dipertimbangkan untuk mengurangi risiko ini:
Lingkungan eksekusi kotak pasir untuk kontainer
Sandboxing adalah teknik dimana setiap kontainer dijalankan di mesin virtual terisolasi sendiri. Teknologi yang melakukan pod sandboxing termasuk Firecracker
Agen Kebijakan Terbuka (OPA) & Penjaga Gerbang
Gatekeeper
Ada juga plugin OPA eksperimental untuk CoreDNS
Kyverno
Kyverno
Anda dapat menggunakan Kyverno untuk mengisolasi ruang nama, menerapkan keamanan pod dan praktik terbaik lainnya, dan menghasilkan konfigurasi default seperti kebijakan jaringan. Beberapa contoh disertakan dalam GitHub repositori untuk proyek
Mengisolasi beban kerja penyewa ke node tertentu
Membatasi beban kerja penyewa untuk berjalan pada node tertentu dapat digunakan untuk meningkatkan isolasi dalam model multi-tenancy lunak. Dengan pendekatan ini, beban kerja khusus penyewa hanya dijalankan pada node yang disediakan untuk penyewa masing-masing. Untuk mencapai isolasi ini, properti Kubernetes asli (afinitas node, dan taints dan toleransi) digunakan untuk menargetkan node tertentu untuk penjadwalan pod, dan mencegah Pod, dari penyewa lain, agar tidak dijadwalkan pada node khusus penyewa.
Bagian 1 - Afinitas simpul
Afinitas noderequiredDuringSchedulingIgnoredDuringExecution node diterapkan ke masing-masing pod. Hasilnya adalah pod akan menargetkan node yang diberi label dengan kunci/nilai berikut:. node-restriction.kubernetes.io/tenant: tenants-x
... spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: node-restriction.kubernetes.io/tenant operator: In values: - tenants-x ...
Dengan afinitas node ini, label diperlukan selama penjadwalan, tetapi tidak selama eksekusi; jika label node yang mendasarinya berubah, pod tidak akan diusir hanya karena perubahan label tersebut. Namun, penjadwalan masa depan dapat terpengaruh.
Awas
Awalan label node-restriction.kubernetes.io/ memiliki arti khusus di Kubernetes. NodeRestrictionkubelet mencegah adding/removing/updating label dengan awalan ini. Penyerang tidak dapat menggunakan apa yang kubelet’s credentials to update the node object or modify the system setup to pass these labels into `kubelet kubelet tidak diizinkan untuk memodifikasi label ini. Jika awalan ini digunakan untuk semua penjadwalan pod ke node, ini mencegah skenario di mana penyerang mungkin ingin menarik serangkaian beban kerja yang berbeda ke node dengan memodifikasi label node.
Alih-alih afinitas simpul, kita bisa menggunakan pemilih simpul
Bagian 2 - Noda dan toleransi
Menarik pod ke node hanyalah bagian pertama dari pendekatan tiga bagian ini. Agar pendekatan ini berhasil, kita harus mengusir pod dari penjadwalan ke node yang pod tidak diotorisasi. Untuk mengusir pod yang tidak diinginkan atau tidak sah, Kubernetes menggunakan node taints.tenant: tenants-x
... taints: - key: tenant value: tenants-x effect: NoSchedule ...
Mengingat node di atastaint, hanya pod yang mentolerir taint yang akan diizinkan untuk dijadwalkan pada node. Untuk memungkinkan pod yang diotorisasi dijadwalkan ke node, spesifikasi pod masing-masing harus menyertakan a toleration to the taint, seperti yang terlihat di bawah ini.
... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
Pod dengan hal di atas tidak toleration akan dihentikan dari penjadwalan pada node, setidaknya bukan karena taint khusus itu. Taints juga digunakan oleh Kubernetes untuk menghentikan sementara penjadwalan pod selama kondisi tertentu, seperti tekanan sumber daya node. Dengan afinitas node, dan taint dan toleransi, kita dapat secara efektif menarik pod yang diinginkan ke node tertentu dan mengusir pod yang tidak diinginkan.
penting
Pod Kubernetes tertentu diperlukan untuk berjalan di semua node. Contoh pod ini adalah yang dimulai oleh Container Network Interface (CNI)
Bagian 3 - Manajemen berbasis kebijakan untuk pemilihan simpul
Ada beberapa alat yang dapat digunakan untuk membantu mengelola afinitas node dan toleransi spesifikasi pod, termasuk penegakan aturan di pipeline CICD. Namun, penegakan isolasi juga harus dilakukan di tingkat cluster Kubernetes. Untuk tujuan ini, alat manajemen kebijakan dapat digunakan untuk mengubah permintaan server API Kubernetes masuk, berdasarkan payload permintaan, untuk menerapkan aturan afinitas node masing-masing dan toleransi yang disebutkan di atas.
Misalnya, pod yang ditujukan untuk namespace tenants-x dapat dicap dengan afinitas dan toleransi node yang benar untuk mengizinkan penjadwalan pada node tenants-x. Menggunakan alat manajemen kebijakan yang dikonfigurasi menggunakan Kubernetes Mutating Admission Webhook
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-nodeaffinity-pod annotations: aws-eks-best-practices/description: >- Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms" parameters: assign: value: - matchExpressions: - key: "tenant" operator: In values: - "tenants-x"
Kebijakan di atas diterapkan pada permintaan server API Kubernetes, untuk menerapkan pod ke namespace tenants-x. Kebijakan ini menambahkan aturan afinitas requiredDuringSchedulingIgnoredDuringExecution node, sehingga pod tertarik ke node dengan tenant: tenants-x label.
Kebijakan kedua, terlihat di bawah, menambahkan toleransi ke spesifikasi pod yang sama, menggunakan kriteria pencocokan yang sama dari namespace target dan grup, jenis, dan versi.
apiVersion: mutations.gatekeeper.sh/v1alpha1 kind: Assign metadata: name: mutator-add-toleration-pod annotations: aws-eks-best-practices/description: >- Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ spec: applyTo: - groups: [""] kinds: ["Pod"] versions: ["v1"] match: namespaces: ["tenants-x"] location: "spec.tolerations" parameters: assign: value: - key: "tenant" operator: "Equal" value: "tenants-x" effect: "NoSchedule"
Kebijakan di atas khusus untuk pod; ini disebabkan oleh jalur ke elemen yang bermutasi dalam elemen kebijakanlocation. Kebijakan tambahan dapat ditulis untuk menangani sumber daya yang membuat pod, seperti sumber daya Deployment dan Job. Kebijakan yang tercantum dan contoh lainnya dapat dilihat dalam GitHubproyek
Hasil dari dua mutasi ini adalah bahwa pod tertarik ke node yang diinginkan, sementara pada saat yang sama, tidak ditolak oleh noda node tertentu. Untuk memverifikasi ini, kita dapat melihat cuplikan output dari dua kubectl panggilan untuk mendapatkan node yang diberi labeltenant=tenants-x, dan mendapatkan pod di namespace. tenants-x
kubectl get nodes -l tenant=tenants-x NAME ip-10-0-11-255... ip-10-0-28-81... ip-10-0-43-107... kubectl -n tenants-x get pods -owide NAME READY STATUS RESTARTS AGE IP NODE tenant-test-deploy-58b895ff87-2q7xw 1/1 Running 0 13s 10.0.42.143 ip-10-0-43-107... tenant-test-deploy-58b895ff87-9b6hg 1/1 Running 0 13s 10.0.18.145 ip-10-0-28-81... tenant-test-deploy-58b895ff87-nxvw5 1/1 Running 0 13s 10.0.30.117 ip-10-0-28-81... tenant-test-deploy-58b895ff87-vw796 1/1 Running 0 13s 10.0.3.113 ip-10-0-11-255... tenant-test-pod 1/1 Running 0 13s 10.0.35.83 ip-10-0-43-107...
Seperti yang dapat kita lihat dari output di atas, semua pod dijadwalkan pada node yang diberi label. tenant=tenants-x Sederhananya, pod hanya akan berjalan pada node yang diinginkan, dan pod lainnya (tanpa afinitas dan toleransi yang diperlukan) tidak akan. Beban kerja penyewa secara efektif diisolasi.
Contoh spesifikasi pod bermutasi terlihat di bawah ini.
apiVersion: v1 kind: Pod metadata: name: tenant-test-pod namespace: tenants-x spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: tenant operator: In values: - tenants-x ... tolerations: - effect: NoSchedule key: tenant operator: Equal value: tenants-x ...
penting
Alat manajemen kebijakan yang terintegrasi dengan alur permintaan server API Kubernetes, menggunakan webhook masuk yang bermutasi dan memvalidasi, dirancang untuk menanggapi permintaan server API dalam jangka waktu tertentu. Ini biasanya 3 detik atau kurang. Jika panggilan webhook gagal mengembalikan respons dalam waktu yang dikonfigurasi, and/or validasi mutasi dari permintaan pemutusan API masuk mungkin atau mungkin tidak terjadi. Perilaku ini didasarkan pada apakah konfigurasi webhook penerimaan disetel ke Fail Buka atau Gagal
Dalam contoh di atas, kami menggunakan kebijakan yang ditulis untuk OPA/GateKeeper. Namun, ada alat manajemen kebijakan lain yang menangani kasus penggunaan pemilihan simpul kami juga. Misalnya, kebijakan Kyverno
catatan
Jika beroperasi dengan benar, kebijakan mutasi akan memengaruhi perubahan yang diinginkan pada muatan permintaan server API masuk. Namun, kebijakan validasi juga harus disertakan untuk memverifikasi bahwa perubahan yang diinginkan terjadi, sebelum perubahan diizinkan untuk bertahan. Ini sangat penting ketika menggunakan kebijakan ini untuk tenant-to-node isolasi. Ini juga merupakan ide yang baik untuk menyertakan kebijakan Audit untuk secara rutin memeriksa klaster Anda untuk konfigurasi yang tidak diinginkan.
Referensi
-
k-rail
Dirancang untuk membantu Anda mengamankan lingkungan multi-penyewa melalui penegakan kebijakan tertentu. -
Praktik Keamanan untuk Aplikasi MultiTenant SaaS menggunakan Amazon EKS
Multi-tenancy yang keras
Hard multi-tenancy dapat diimplementasikan dengan menyediakan cluster terpisah untuk setiap penyewa. Meskipun ini memberikan isolasi yang sangat kuat antara penyewa, ia memiliki beberapa kelemahan.
Pertama, ketika Anda memiliki banyak penyewa, pendekatan ini dapat dengan cepat menjadi mahal. Anda tidak hanya harus membayar biaya pesawat kontrol untuk setiap cluster, Anda tidak akan dapat berbagi sumber daya komputasi antar cluster. Ini pada akhirnya akan menyebabkan fragmentasi di mana sebagian dari cluster Anda kurang dimanfaatkan sementara yang lain digunakan secara berlebihan.
Kedua, Anda mungkin perlu membeli atau membangun perkakas khusus untuk mengelola semua cluster ini. Pada waktunya, mengelola ratusan atau ribuan cluster mungkin menjadi terlalu berat.
Akhirnya, membuat cluster per penyewa akan lambat relatif terhadap pembuatan namespace. Namun demikian, pendekatan penyewaan keras mungkin diperlukan di industri yang sangat diatur atau di lingkungan SaaS di mana isolasi yang kuat diperlukan.
Arah masa depan
Komunitas Kubernetes telah mengakui kekurangan soft multi-tenancy saat ini dan tantangan dengan multi-tenancy yang keras. Multi-Tenancy Special Interest Group (SIG)
Proposal HNC (KEP) menjelaskan cara untuk membuat hubungan orangtua-anak antara namespace dengan warisan objek [policy] bersama dengan kemampuan administrator penyewa untuk membuat sub-namespace.
Proposal Virtual Cluster menjelaskan mekanisme untuk membuat instance terpisah dari layanan bidang kontrol, termasuk server API, manajer pengontrol, dan penjadwal, untuk setiap penyewa di dalam klaster (juga dikenal sebagai “Kubernetes on Kubernetes”).
Proposal Multi-Tenancy Benchmarks
Alat dan sumber daya manajemen multi-cluster
