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 lain atau aplikasi yang berjalan pada infrastruktur bersama.

Kubernetes adalah orkestrator penyewa tunggal, yaitu satu instance dari bidang kontrol dibagi di antara semua penyewa dalam cluster. Namun, ada berbagai objek Kubernetes yang dapat Anda gunakan untuk membuat kemiripan multi-tenancy. Misalnya, ruang nama dan kontrol Role-based akses (RBAC) dapat diimplementasikan untuk secara logis mengisolasi penyewa satu sama lain. Demikian pula, Kuota dan Rentang Batas 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 dalam cluster dapat mengambil semua Rahasia,, dan VolumeConfigMaps, yang dipasang pada host itu. Mereka juga dapat menyamar sebagai Kubelet yang akan memungkinkan mereka untuk memanipulasi atribut and/or gerakan node secara lateral di dalam cluster.

Bagian berikut akan menjelaskan cara menerapkan isolasi penyewa sambil mengurangi risiko menggunakan orkestrator penyewa tunggal seperti Kubernetes.

Multi-penyewaan yang lembut

Dengan multi-tenancy lunak, Anda menggunakan konstruksi Kubernetes asli, misalnya ruang nama, peran dan ikatan peran, dan kebijakan jaringan, untuk membuat pemisahan logis antara penyewa. RBAC, misalnya, dapat mencegah penyewa mengakses atau memanipulasi sumber daya satu sama lain. 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, tidak 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, noda, and/or 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 biaya mahal, di lingkungan dengan banyak penyewa.

Kios adalah proyek open source yang dapat membantu dalam implementasi soft multi-tenancy. Ini diimplementasikan sebagai serangkaian CRD dan pengontrol yang menyediakan kemampuan berikut:

Loft adalah penawaran komersial dari pengelola Kios dan DevSpace menambahkan kemampuan berikut:

Ada tiga kasus penggunaan utama yang dapat diatasi dengan multi-tenancy lunak.

Pengaturan Perusahaan

Yang pertama adalah dalam pengaturan Perusahaan di mana “penyewa” setengah dipercaya karena mereka adalah karyawan, kontraktor, atau diberi wewenang oleh organisasi. Setiap penyewa biasanya akan menyelaraskan dengan divisi administrasi seperti departemen atau tim.

Dalam jenis pengaturan ini, administrator cluster 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 container mungkin dapat diterima dalam pengaturan ini atau mungkin perlu ditambah dengan kontrol tambahan untuk keamanan pod. Mungkin juga perlu 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 sebagai layanan (KaaS). Dengan KaaS, aplikasi Anda dihosting di cluster bersama dengan kumpulan pengontrol dan CRD yang menyediakan serangkaian 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 wadah pod di dalam VM mikro seperti Firecracker atau di kernel ruang pengguna. Hari ini, Anda dapat membuat pod kotak pasir dengan EKS Fargate.

Perangkat Lunak sebagai Layanan (SaaS)

Kasus penggunaan akhir untuk multi-tenancy lunak adalah dalam pengaturan Software-as-a-Service (SaaS). Dalam lingkungan ini, setiap penyewa dikaitkan dengan instance tertentu dari aplikasi yang berjalan di dalam cluster. Setiap instance sering memiliki data 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 API Kubernetes. Sebaliknya, aplikasi SaaS bertanggung jawab untuk berinteraksi dengan Kubernetes API untuk membuat objek yang diperlukan untuk mendukung setiap penyewa.

Konstruksi Kubernetes

Dalam masing-masing contoh ini konstruksi berikut digunakan untuk mengisolasi penyewa satu sama lain:

Namespace

Namespace 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 cluster 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. Di lingkungan multi-penyewa di mana isolasi jaringan yang ketat antar penyewa diperlukan, sebaiknya mulai dengan aturan default yang menolak komunikasi antar pod, dan aturan lain yang memungkinkan semua pod untuk menanyakan 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.

Role-based kontrol akses (RBAC)

Peran dan binding peran adalah objek Kubernetes yang digunakan untuk menerapkan kontrol akses berbasis peran (RBAC) di Kubernetes. Per an berisi daftar tindakan yang dapat dilakukan terhadap objek di cluster Anda. Pengikatan 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 batas pada beban kerja yang dihosting di cluster Anda. Dengan kuota, Anda dapat membatasi jumlah total CPU dan memori yang dapat dikonsumsi dalam namespace, atau membatasi jumlah objek yang dapat dibuat. Rentang batas memungkinkan Anda mendeklarasikan nilai CPU dan memori minimum, maksimum, dan default untuk masing-masing pod dan wadah dalam namespace.

Menginvestasikan 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 diatur terlalu rendah dan pemanfaatan sumber daya aktual melebihi kapasitas node, node akan mulai mengalami tekanan CPU atau memori. Ketika ini terjadi, pod dapat dihidupkan ulang di and/or usir dari node.

Untuk mencegah hal ini terjadi, Anda harus merencanakan untuk memberlakukan kuota pada ruang nama di lingkungan multi-tenant untuk memaksa penyewa menentukan permintaan dan batasan saat menjadwalkan pod mereka di cluster. 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 memberikan nilai yang lebih penting pada Pod dibandingkan 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 prioritas rendah dari pelanggan B untuk mengakomodasi pod 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.

Kontrol yang memitigasi

Perhatian utama Anda sebagai administrator lingkungan multi-tenant 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 di mana setiap wadah dijalankan di mesin virtual terisolasi sendiri. Teknologi yang melakukan pod sandboxing termasuk Fi recracker.

Untuk informasi tambahan tentang upaya menjadikan Firecracker runtime yang didukung untuk EKS, lihat https://threadreaderapp.com/thread/1238496944684597248.html.

Penjaga Gerbang Agen Kebijakan Terbuka (OPA&)

Gatekeeper adalah pengontrol penerimaan Kubernetes yang memberlakukan kebijakan yang dibuat dengan OPA. https://www.openpolicyagent.org/ Dengan OPA, Anda dapat membuat kebijakan yang menjalankan pod dari penyewa pada instans terpisah atau pada prioritas yang lebih tinggi daripada penyewa lainnya. Kumpulan kebijakan OPA umum dapat ditemukan di GitHub repositori untuk proyek ini.

Ada juga plugin OPA eksperimental untuk CoreDNS yang memungkinkan Anda menggunakan OPA ke filter/control catatan yang dikembalikan oleh CoreDNS.

Kyverno

Kyverno adalah mesin kebijakan asli Kubernetes yang dapat memvalidasi, mengubah, dan menghasilkan konfigurasi dengan kebijakan sebagai sumber daya Kubernetes. Kyverno menggunakan Kustomize-style overlay untuk validasi, mendukung Patch JSON dan patch gabungan strategis untuk mutasi, dan dapat mengkloning sumber daya di seluruh ruang nama berdasarkan pemicu fleksibel.

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 ini. Banyak lainnya termasuk dalam perpustakaan kebijakan di situs web Kyverno.

Mengisolasi beban kerja penyewa ke node tertentu

Membatasi beban kerja penyewa untuk dijalankan 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 simpul, dan noda dan toleransi) digunakan untuk menargetkan node tertentu untuk penjadwalan pod, dan mencegah pod, dari penyewa lain, dijadwalkan pada node khusus penyewa.

Bagian 1 - Afinitas simpul

Afinitas node Kubernetes digunakan untuk menargetkan node untuk penjadwalan, berdasarkan label node. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ Dengan aturan afinitas node, pod tertarik ke node tertentu yang cocok dengan istilah pemilih. Dalam spesifikasi pod di bawah ini, afinitas requiredDuringSchedulingIgnoredDuringExecution node diterapkan ke masing-masing pod. Hasilnya adalah pod akan menargetkan node yang diberi label sebagai berikut key/value: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 semata-mata karena perubahan label itu. Namun, penjadwalan di masa depan dapat terpengaruh.

Bagian 2 - Noda dan toleransi

Menarik pod ke node hanyalah bagian pertama dari pendekatan tiga bagian ini. Agar pendekatan ini berfungsi, kita harus mengusir pod dari penjadwalan ke node yang podnya tidak diizinkan. Untuk mengusir pod yang tidak diinginkan atau tidak sah, Kubernetes menggunakan noda node. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Taints digunakan untuk menempatkan kondisi pada node yang mencegah pod dijadwalkan. Taint di bawah ini menggunakan pasangan kunci-nilai. tenant: tenants-x

...
    taints:
      - key: tenant
        value: tenants-x
        effect: NoSchedule
...

Mengingat node di atastaint, hanya pod yang mentolerir noda yang diizinkan untuk dijadwalkan pada node. Untuk mengizinkan pod resmi 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 noda spesifik itu. Taints juga digunakan oleh Kubernetes untuk menghentikan sementara penjadwalan pod selama kondisi tertentu, seperti tekanan sumber daya node. Dengan afinitas simpul, dan noda serta toleransi, kita dapat secara efektif menarik pod yang diinginkan ke node tertentu dan mengusir pod yang tidak diinginkan.

Bagian 3 - Policy-based manajemen untuk pemilihan simpul

Ada beberapa alat yang dapat digunakan untuk membantu mengelola afinitas node dan toleransi spesifikasi pod, termasuk penegakan aturan dalam pipeline CICD. Namun, penegakan isolasi juga harus dilakukan di tingkat cluster Kubernetes. Untuk tujuan ini, alat manajemen kebijakan dapat digunakan untuk mengubah permintaan server Kubernetes API inbound, 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 memungkinkan penjadwalan pada node tenants-x. Memanfaatkan alat manajemen kebijakan yang dikonfigurasi menggunakan Kubernetes Mutating Admission Webhook, kebijakan dapat digunakan untuk mengubah spesifikasi pod masuk. Mutasi menambahkan elemen yang diperlukan untuk memungkinkan penjadwalan yang diinginkan. Contoh OPA/Gatekeeper kebijakan yang menambahkan afinitas simpul terlihat di bawah ini.

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 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 karena jalur ke elemen yang bermutasi dalam elemen kebijakan. location 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 di GitHub proyek pendamping untuk panduan ini.

Hasil dari kedua mutasi ini adalah bahwa polong tertarik ke simpul yang diinginkan, sementara pada saat yang sama, tidak ditolak oleh noda simpul tertentu. Untuk memverifikasi ini, kita dapat melihat cuplikan output dari dua kubectl panggilan untuk mendapatkan node berlabeltenant=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 berlabeltenant=tenants-x. Sederhananya, pod hanya akan berjalan pada node yang diinginkan, dan pod lainnya (tanpa afinitas dan toleransi yang diperlukan) tidak. Beban kerja penyewa diisolasi secara efektif.

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

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 ini dapat digunakan untuk menangani mutasi afinitas simpul.

Referensi

Multi-sewa 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 bidang kontrol untuk setiap cluster, Anda tidak akan dapat berbagi sumber daya komputasi antar cluster. Ini pada akhirnya akan menyebabkan fragmentasi di mana subset cluster Anda kurang dimanfaatkan sementara yang lain dimanfaatkan secara berlebihan.

Kedua, Anda mungkin perlu membeli atau membangun perkakas khusus untuk mengelola semua cluster ini. Seiring waktu, mengelola ratusan atau ribuan cluster mungkin menjadi terlalu sulit.

Akhirnya, membuat cluster per tenant akan lambat relatif terhadap pembuatan namespace. Namun demikian, pendekatan sewa keras mungkin diperlukan dalam industri yang sangat diatur atau di lingkungan SaaS di mana isolasi yang kuat diperlukan.

Arah masa depan

Komunitas Kubernetes telah mengakui kekurangan multi-tenancy lunak saat ini dan tantangan dengan multi-tenancy yang keras. Special Multi-Tenancy Interest Group (SIG) berusaha mengatasi kekurangan ini melalui beberapa proyek inkubasi, termasuk Hierarchical Namespace Controller (HNC) dan Virtual Cluster.

Proposal HNC (KEP) menjelaskan cara untuk membuat hubungan orangtua-anak antara ruang nama dengan warisan objek [kebijakan] bersama dengan kemampuan administrator penyewa untuk membuat sub-ruang nama.

Proposal Cluster Virtual menjelaskan mekanisme untuk membuat instance terpisah dari layanan bidang kontrol, termasuk server API, manajer pengontrol, dan penjadwal, untuk setiap penyewa dalam cluster (juga dikenal sebagai “Kubernetes on Kubernetes”).

Propos Multi-Tenancy al Benchmarks memberikan pedoman untuk berbagi cluster menggunakan ruang nama untuk isolasi dan segmentasi, dan alat baris perintah kubectl-mt b untuk memvalidasi kesesuaian dengan pedoman.

Multi-cluster alat manajemen dan sumber daya