Multi-tenancy cluster

Halaman ini berisi penjelasan tentang multi-tenancy cluster di Google Kubernetes Engine (GKE). Hal ini mencakup cluster yang dibagikan kepada pengguna berbeda di satu organisasi, serta cluster yang dibagikan kepada instance per pelanggan dari aplikasi Software as a Service (SaaS). Multi-tenancy cluster adalah solusi alternatif untuk mengelola banyak cluster tenant tunggal.

Halaman ini juga berisi rangkuman berbagai fitur Kubernetes dan GKE yang dapat digunakan untuk mengelola cluster multi-tenant.

Apa yang dimaksud dengan multi-tenancy?

Cluster multi-tenant digunakan bersama oleh beberapa pengguna dan/atau workload yang disebut sebagai "tenant". Operator cluster multi-tenant harus memisahkan tenant satu sama lain untuk meminimalkan kerugian yang dapat terjadi pada cluster atau tenant lain akibat tenant yang berbahaya atau disusupi. Selain itu, resource cluster harus dialokasikan secara merata ke tiap-tiap tenant.

Saat merencanakan arsitektur multi-tenant, Anda harus mempertimbangkan lapisan isolasi resource di Kubernetes: cluster, namespace, node, Pod, dan container. Anda juga harus mempertimbangkan implikasi keamanan dari membagikan jenis resource yang berbeda kepada banyak tenant. Misalnya, menjadwalkan Pod dari tenant berbeda di node yang sama dapat mengurangi jumlah mesin yang diperlukan di cluster. Di samping itu, Anda mungkin perlu mencegah agar workload tertentu tidak ditempatkan bersama-sama. Misalnya, Anda mungkin tidak mengizinkan kode yang tidak tepercaya dari luar organisasi untuk berjalan di node yang sama dengan kontainer yang memproses informasi sensitif.

Kubernetes tidak dapat menjamin isolasi yang benar-benar aman di antara tenant, tetapi ada sejumlah fitur yang mungkin cukup untuk kasus penggunaan tertentu. Anda dapat memisahkan setiap tenant dan resource Kubernetes-nya ke dalam namespace-nya masing-masing. Kemudian, Anda dapat menggunakan kebijakan untuk menerapkan isolasi tenant. Kebijakan biasanya dicakup oleh namespace dan dapat digunakan untuk membatasi akses API, membatasi penggunaan resource, dan membatasi kontainer mana yang diizinkan.

Tenant dari cluster multi-tenant berbagi:

Terdapat beberapa keuntungan dari mengoperasikan cluster multi-tenant dibandingkan dengan mengoperasikan beberapa cluster tenant tunggal:

  • Mengurangi overhead pengelolaan
  • Mengurangi fragmentasi resource
  • Tidak perlu menunggu pembuatan cluster untuk tenant baru

Kasus penggunaan multi-tenancy

Bagian ini menjelaskan cara mengonfigurasi cluster untuk berbagai kasus penggunaan multi-tenancy.

Multi-tenancy perusahaan

Di lingkungan perusahaan, tenant cluster-nya adalah tim yang berbeda dalam organisasi. Biasanya, setiap tenant memiliki namespace masing-masing. Model alternatif multi-tenancy dengan satu tenant per cluster, atau satu tenant per project Google Cloud, lebih sulit dikelola. Traffic jaringan dalam namespace tidak dibatasi. Traffic jaringan antar-namespace harus diizinkan secara eksplisit. Kebijakan ini dapat diterapkan menggunakan kebijakan jaringan Kubernetes.

Pengguna cluster dikelompokkan ke dalam 3 peran berbeda, bergantung pada hak istimewa mereka:

Administrator cluster
Peran ini ditujukan untuk administrator dari seluruh cluster, yang mengelola semua tenant. Administrator cluster dapat membuat, membaca, mengupdate, dan menghapus objek kebijakan apa pun. Mereka dapat membuat namespace dan menetapkannya kepada administrator namespace.
Administrator namespace
Peran ini ditujukan untuk administrator tenant tunggal tertentu. Administrator namespace dapat mengelola pengguna di namespace mereka.
Developer
Anggota peran ini dapat membuat, membaca, mengupdate, dan menghapus objek non-kebijakan dalam namespace, seperti Pod, Tugas, dan Ingress. Developer hanya memiliki hak istimewa di namespace yang mereka miliki aksesnya.

Untuk mengetahui informasi tentang cara menyiapkan beberapa cluster multi-tenant untuk organisasi perusahaan, baca Praktik terbaik untuk multi- tenancy perusahaan.

Multi-tenancy penyedia SaaS

Tenant untuk cluster penyedia SaaS adalah instance per pelanggan aplikasi, dan bidang kontrol SaaS-nya. Untuk memanfaatkan kebijakan dalam cakupan namespace, instance aplikasi harus diatur ke dalam namespace-nya masing-masing, demikian pula dengan komponen bidang kontrol SaaS. Pengguna akhir tidak dapat berinteraksi dengan bidang kontrol Kubernetes secara langsung. Sebagai gantinya, mereka menggunakan antarmuka SaaS, yang kemudian berinteraksi dengan bidang kontrol Kubernetes.

Sebagai contoh, platform blogging dapat berjalan di cluster multi-tenant. Dalam kasus ini, tenant-nya adalah instance blog setiap pelanggan dan juga bidang kontrol platform itu sendiri. Bidang kontrol platform dan setiap blog yang dihosting akan berjalan di namespace terpisah. Pelanggan akan membuat dan menghapus blog, serta mengupdate versi software blogging mereka melalui antarmuka platform tanpa mengetahui cara cluster beroperasi:

Penerapan kebijakan multi-tenancy

GKE dan Kubernetes memberikan beberapa fitur yang dapat digunakan untuk mengelola cluster multi-tenant. Berikut ringkasan dari beberapa fitur tersebut:

Kontrol akses

GKE memiliki dua sistem kontrol akses, yaitu Identity and Access Management (IAM) dan role-based access control (RBAC). IAM merupakan sistem kontrol akses Google Cloud yang digunakan untuk mengelola autentikasi dan otorisasi resource Google Cloud. Anda dapat menggunakan IAM untuk memberi pengguna akses ke resource GKE dan Kubernetes. RBAC telah disertakan dalam Kubernetes dan memberikan izin terperinci untuk resource dan operasi tertentu dalam cluster Anda.

Lihat Ringkasan kontrol akses untuk mengetahui informasi selengkapnya tentang berbagai opsi ini dan kapan harus menggunakannya.

Baca Panduan cara kerja RBAC dan panduan cara kerja IAM untuk mempelajari cara menggunakan sistem kontrol akses ini.

Anda dapat menggunakan izin IAM dan RBAC beserta namespace untuk membatasi interaksi pengguna dengan resource cluster di Konsol Google Cloud. Untuk informasi selengkapnya, lihat Mengaktifkan akses dan melihat resource cluster berdasarkan namespace.

Kebijakan jaringan

Kebijakan jaringan cluster memberi Anda kontrol atas komunikasi di antara Pod cluster. Kebijakan menentukan namespace, label, dan rentang alamat IP mana saja yang dapat berkomunikasi dengan Pod.

Lihat panduan kebijakan jaringan untuk mengetahui petunjuk tentang cara mengaktifkan penerapan kebijakan jaringan di GKE.

Ikuti tutorial kebijakan jaringan untuk mempelajari cara menulis kebijakan jaringan.

Kuota resource

Kuota resource mengelola jumlah resource yang digunakan oleh objek dalam namespace. Anda dapat menetapkan kuota untuk penggunaan CPU dan memori, atau untuk jumlah objek. Kuota resource memungkinkan Anda untuk memastikan bahwa tidak ada tenant yang menggunakan resource cluster melebihi jumlah yang ditetapkan untuknya.

Lihat dokumentasi kuota resource untuk mengetahui informasi selengkapnya.

Kontrol penerimaan Pod berbasis kebijakan

Agar Pod yang melanggar batas keamanan tidak berjalan di cluster Anda, gunakan pengontrol penerimaan. Pengontrol penerimaan dapat memeriksa spesifikasi Pod berdasarkan kebijakan yang Anda tetapkan, dan dapat mencegah Pod yang melanggar kebijakan tersebut agar tidak berjalan di cluster.

GKE mendukung jenis kontrol akses berikut:

Anti-afinitas Pod

Anda dapat menggunakan anti-afinitas Pod untuk mencegah Pod dari tenant berbeda dijadwalkan pada node yang sama. Batasan anti-afinitas didasarkan pada label Pod. Sebagai contoh, spesifikasi Pod di bawah mendeskripsikan Pod dengan label "team": "billing", dan aturan anti-afinitas yang mencegah Pod agar tidak dijadwalkan bersama dengan Pod yang tidak memiliki label.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

Kekurangan dari teknik ini adalah pengguna yang berbahaya dapat mengakali aturan ini dengan menerapkan label team: billing ke Pod arbitrer. Anti-afinitas Pod saja tidak dapat menerapkan kebijakan dengan aman di cluster yang memiliki tenant tidak tepercaya.

Lihat dokumentasi anti-afinitas Pod untuk mengetahui informasi selengkapnya.

Node khusus dengan taint dan toleransi

Taint node adalah cara alternatif untuk mengontrol penjadwalan workload. Anda dapat menggunakan taint node untuk mencadangkan node khusus agar hanya digunakan oleh tenant tertentu. Sebagai contoh, Anda dapat menetapkan node yang dilengkapi GPU secara khusus kepada tenant tertentu yang workload-nya memerlukan GPU. Untuk cluster Autopilot, toleransi node hanya didukung untuk pemisahan workload. Taint node secara otomatis ditambahkan oleh penyediaan otomatis node sesuai kebutuhan.

Untuk menetapkan node pool secara khusus ke tenant tertentu, terapkan taint dengan effect: "NoSchedule" ke node pool. Kemudian, hanya Pod dengan toleransi yang sesuai yang dapat dijadwalkan ke node dalam node pool.

Kekurangan dari teknik ini adalah pengguna yang berbahaya dapat menambahkan toleransi ke Pod mereka untuk mendapatkan akses ke node pool khusus. Taint dan toleransi node saja tidak dapat menerapkan kebijakan dengan aman di cluster yang memiliki tenant tidak tepercaya.

Lihat halaman petunjuk taint node untuk mempelajari cara mengontrol penjadwalan dengan taint node.

Langkah selanjutnya