Praktik terbaik untuk multi-tenancy perusahaan

Multi-tenancy di Google Kubernetes Engine (GKE) mengacu pada satu atau beberapa cluster yang digunakan bersama di antara beberapa tenant. Di Kubernetes, tenant dapat ditentukan sebagai salah satu dari yang berikut:

  • Tim yang bertanggung jawab untuk mengembangkan dan mengoperasikan satu atau lebih workload.
  • Kumpulan workload terkait, baik yang dioperasikan oleh satu atau beberapa tim.
  • Workload tunggal, seperti Deployment.

Multi-tenancy cluster sering diterapkan untuk mengurangi biaya atau menerapkan kebijakan administrasi di seluruh tenant secara konsisten. Namun, salah mengonfigurasi cluster GKE atau resource GKE terkait dapat menyebabkan tidak tercapainya penghematan biaya, penerapan kebijakan yang salah, atau interaksi destruktif antara workload tenant yang berbeda.

Panduan ini memberikan praktik terbaik untuk menyiapkan beberapa cluster multi-tenant dengan aman dan efisien untuk organisasi perusahaan.

Asumsi dan persyaratan

Praktik terbaik dalam panduan ini didasarkan pada kasus penggunaan multi-tenant untuk lingkungan perusahaan, yang memiliki asumsi dan persyaratan berikut:

  • Organisasi ini adalah satu perusahaan yang memiliki banyak tenant (dua atau beberapa tim aplikasi/layanan) yang menggunakan Kubernetes dan ingin berbagi resource komputasi dan administratif.
  • Setiap tenant adalah satu tim yang mengembangkan satu workload.
  • Selain tim aplikasi/layanan, ada tim lain yang juga menggunakan dan mengelola cluster, termasuk anggota tim platform, administrator cluster, auditor, dll.
  • Tim platform memiliki cluster dan menentukan jumlah resource yang dapat digunakan setiap tim tenant; setiap tenant dapat meminta lebih banyak.
  • Setiap tim tenant harus dapat men-deploy aplikasi mereka melalui Kubernetes API tanpa harus berkomunikasi dengan tim platform.
  • Setiap tenant tidak boleh memengaruhi tenant lain di cluster bersama, kecuali melalui keputusan desain eksplisit seperti panggilan API, sumber data bersama, dll.

Penyiapan ini akan berfungsi sebagai model yang dapat kami gunakan untuk menunjukkan praktik terbaik multi-tenant. Meskipun mungkin tidak mendeskripsikan semua organisasi perusahaan dengan sempurna, penyiapan ini dapat dengan mudah diperluas untuk mencakup skenario serupa.

Menyiapkan folder, project, dan cluster

Praktik terbaik:

Membuat folder dan hierarki project.
Menetapkan peran menggunakan IAM.
Pusatkan kontrol jaringan dengan VPC Bersama.
Buat satu project admin cluster per cluster.
Jadikan cluster bersifat pribadi.
Pastikan bidang kontrol untuk cluster bersifat regional.
Pastikan node dalam cluster Anda mencakup setidaknya tiga zona.
Penskalaan otomatis node dan resource cluster.
Jadwalkan masa pemeliharaan di luar jam sibuk.
Menyiapkan Load Balancer Aplikasi eksternal dengan Ingress.

Untuk organisasi perusahaan yang men-deploy cluster multi-tenant di GKE, konfigurasi tambahan diperlukan di sistem Google Cloud lain untuk mengelola kompleksitas yang tidak ada dalam deployment Kubernetes satu tim dan aplikasi yang lebih sederhana. Ini mencakup konfigurasi project untuk mengisolasi masalah administratif serta memetakan struktur organisasi ke akun dan identitas cloud, serta mengelola resource Google Cloud tambahan, seperti database, logging dan pemantauan, penyimpanan, dan jejaring.

Membuat folder dan hierarki project

Untuk mengetahui cara organisasi Anda mengelola resource Google Cloud dan menerapkan pemisahan fokus, gunakan folder dan project. Dengan folder, tim yang berbeda dapat menetapkan kebijakan yang menurun di beberapa project, sedangkan project dapat digunakan untuk memisahkan lingkungan (misalnya, produksi vs. staging) dan tim satu dengan yang lainnya. Misalnya, sebagian besar organisasi memiliki tim untuk mengelola infrastruktur jaringan dan tim yang berbeda untuk mengelola cluster. Setiap teknologi dianggap sebagai bagian terpisah dari stack yang memerlukan tingkat keahlian, pemecahan masalah, dan aksesnya sendiri.

Folder induk dapat berisi hingga 300 folder, dan Anda dapat membuat folder bertingkat hingga 10 tingkat. Jika memiliki lebih dari 300 tenant, Anda dapat mengatur tenant ke dalam hierarki bertingkat agar tidak melebihi batas. Untuk informasi selengkapnya tentang folder, lihat Membuat dan Mengelola Folder.

Menetapkan peran menggunakan IAM

Anda dapat mengontrol akses ke resource Google Cloud melalui kebijakan IAM. Mulailah dengan mengidentifikasi grup yang diperlukan untuk organisasi Anda dan cakupan operasinya, lalu tetapkan peran IAM yang sesuai untuk grup tersebut.

Gunakan Google Grup untuk menetapkan dan mengelola IAM secara efisien bagi pengguna.

Kontrol jaringan terpusat

Untuk mempertahankan kontrol terpusat atas resource jaringan, seperti subnet, rute, dan firewall, gunakan Jaringan VPC bersama. Resource di VPC Bersama dapat berkomunikasi satu sama lain secara aman dan efisien di seluruh batas project menggunakan IP internal. Setiap Jaringan VPC Bersama ditentukan dan dimiliki oleh project host terpusat, dan dapat digunakan oleh satu atau beberapa project layanan.

Dengan VPC Bersama dan IAM, Anda dapat memisahkan administrasi jaringan dari administrasi project. Pemisahan ini membantu Anda menerapkan prinsip hak istimewa terendah. Misalnya, tim jaringan terpusat dapat mengelola jaringan tanpa memiliki izin apa pun ke dalam project yang berpartisipasi. Demikian pula, admin project dapat mengelola resource project mereka tanpa izin apa pun untuk memanipulasi jaringan bersama.

Saat menyiapkan VPC Bersama, Anda harus mengonfigurasi subnet dan rentang IP sekundernya di VPC. Untuk menentukan ukuran subnet, Anda perlu mengetahui perkiraan jumlah tenant, jumlah Pod dan Service yang diharapkan untuk dijalankan, serta ukuran Pod maksimum dan rata-rata. Dengan menghitung total kapasitas cluster yang diperlukan, Anda dapat memahami ukuran instance yang diinginkan, dan menampilkan jumlah total node. Dengan jumlah total node, total ruang IP yang terpakai dapat dihitung, dan ini dapat memberikan ukuran subnet yang diinginkan.

Berikut ini beberapa faktor yang juga harus Anda pertimbangkan saat menyiapkan jaringan:

  • Jumlah maksimum project layanan yang dapat dilampirkan ke project host adalah 1.000, dan jumlah maksimum project host VPC Bersama dalam satu organisasi adalah 100.
  • Rentang IP Node, Pod, dan Service harus unik. Anda tidak dapat membuat subnet yang rentang alamat IP primer dan sekundernya tumpang-tindih.
  • Jumlah maksimum Pod dan Service untuk cluster GKE tertentu dibatasi oleh ukuran rentang sekunder cluster.
  • Jumlah maksimum node dalam cluster dibatasi oleh ukuran rentang alamat IP utama subnet cluster dan rentang alamat Pod cluster.
  • Untuk fleksibilitas dan kontrol yang lebih besar atas pengelolaan alamat IP, Anda dapat mengonfigurasi jumlah maksimum Pod yang dapat berjalan pada sebuah node. Dengan mengurangi jumlah Pod per node, Anda juga mengurangi rentang CIDR yang dialokasikan per node, sehingga memerlukan lebih sedikit alamat IP.

Untuk mengetahui informasi tentang rentang jaringan dalam cluster VPC, lihat Membuat cluster VPC native.

Tenant yang memerlukan isolasi lebih lanjut untuk resource yang berjalan di luar cluster bersama (seperti VM Compute Engine khusus) dapat menggunakan VPC-nya sendiri, yang di-peering ke VPC Bersama yang dijalankan oleh tim networking. Hal ini memberikan keamanan tambahan dengan mengorbankan kerumitan dan berbagai batasan lainnya. Untuk mengetahui informasi selengkapnya tentang peering, lihat Menggunakan Peering Jaringan VPC. Pada contoh di bawah, semua tenant telah memilih untuk berbagi VPC tenant tunggal (per lingkungan).

Membuat cluster yang andal dan sangat tersedia

Rancang arsitektur cluster Anda untuk ketersediaan dan keandalan tinggi dengan menerapkan rekomendasi berikut:

  • Buat satu project admin cluster per cluster untuk mengurangi risiko konfigurasi level project (misalnya, binding IAM) yang berdampak buruk pada banyak cluster, dan untuk membantu menyediakan pemisahan kuota dan penagihan. Project admin cluster terpisah dari project tenant, yang digunakan masing-masing tenant untuk mengelola, misalnya, resource Google Cloud mereka.
  • Konfigurasi isolasi jaringan untuk menonaktifkan akses ke node dan mengelola akses ke bidang kontrol. Kami juga merekomendasikan untuk mengonfigurasi isolasi jaringan Anda untuk lingkungan pengembangan dan staging.
  • Pastikan bidang kontrol untuk cluster bersifat regional guna memberikan ketersediaan tinggi untuk multi-tenancy; setiap gangguan terhadap bidang kontrol akan berdampak pada tenant. Perhatikan bahwa ada implikasi biaya jika menjalankan cluster regional. Cluster Autopilot sudah dikonfigurasi terlebih dahulu sebagai cluster regional.
  • Pastikan node di cluster Anda mencakup setidaknya tiga zona untuk mencapai keandalan zona. Untuk mengetahui informasi tentang biaya traffic keluar antarzona di region yang sama, lihat dokumentasi harga jaringan.
Cluster regional pribadi dengan bidang kontrol regional yang berjalan di tiga zona
Gambar 3: Cluster regional pribadi dengan bidang kontrol regional yang berjalan di tiga zona.

Melakukan penskalaan otomatis node dan resource cluster

Untuk mengakomodasi permintaan tenant Anda, skalakan node secara otomatis dalam cluster dengan mengaktifkan penskalaan otomatis.

Penskalaan otomatis membantu sistem terlihat responsif dan sehat saat workload yang berat di-deploy oleh berbagai tenant di namespace mereka, atau untuk merespons pemadaman layanan di zona.

Dengan cluster Autopilot, node pool akan otomatis diskalakan untuk memenuhi persyaratan workload Anda.

Saat mengaktifkan penskalaan otomatis, Anda menentukan jumlah minimum dan maksimum node dalam cluster berdasarkan ukuran workload yang diharapkan. Dengan menentukan jumlah maksimum node, Anda dapat memastikan ada cukup ruang untuk semua Pod dalam cluster, terlepas dari namespace tempatnya dijalankan. Penskalaan otomatis cluster mengubah skala node pool berdasarkan batas min/maks, yang membantu mengurangi biaya operasional saat beban sistem berkurang, dan menghindari Pod menjadi status tertunda saat resource cluster yang tersedia tidak cukup. Untuk menentukan jumlah maksimum node, identifikasi jumlah maksimum CPU dan memori yang diperlukan setiap tenant, dan tambahkan jumlah tersebut untuk mendapatkan total kapasitas yang harus dapat ditangani cluster jika semua tenant telah mencapai batas. Dengan menggunakan jumlah maksimum node, Anda dapat memilih ukuran dan jumlah instance, dengan mempertimbangkan ruang subnet IP yang disediakan untuk cluster.

Menggunakan penskalaan otomatis Pod untuk menskalakan Pod secara otomatis berdasarkan permintaan resource. Horizontal Pod Autoscaler (HPA) menskalakan jumlah replika Pod berdasarkan pemakaian CPU/memori atau metrik kustom. Penskalaan Otomatis Pod Vertikal (VPA) dapat digunakan untuk menskalakan permintaan resource Pod secara otomatis. Tindakan ini tidak boleh digunakan dengan HPA kecuali jika metrik kustom tersedia karena dua autoscaler dapat bersaing satu sama lain. Oleh karena itu, mulailah dengan HPA dan hanya VPA berikutnya jika diperlukan.

Menentukan ukuran cluster

Saat menentukan ukuran cluster, berikut beberapa faktor penting yang perlu dipertimbangkan:

  • Ukuran cluster bergantung pada jenis workload yang ingin Anda jalankan. Jika workload Anda memiliki kepadatan yang lebih besar, efisiensi biaya akan lebih tinggi, tetapi juga ada peluang lebih besar untuk konflik resource.
  • Ukuran minimum cluster ditentukan oleh jumlah zona yang dicakupnya: satu node untuk cluster zona dan tiga node untuk cluster regional.
  • Per project, ada maksimum 50 cluster per zona, ditambah 50 cluster regional per region.

  • Per cluster, nilai maksimum berikut berlaku untuk node:

    • 1.000 node per node pool
    • 1.000 node per cluster (jika Anda menggunakan pengontrol GKE Ingress)
    • 5.000 node per cluster secara default. Anda dapat meningkatkan batas ini menjadi 15.000 atau 65.000 node. Untuk mempelajari lebih lanjut, lihat Cluster dengan lebih dari 5.000 node.
    • 256 Pod per node
    • 150.000 Pod per cluster, dan 300.000 penampung per cluster

    Lihat Halaman kuota dan batas untuk mengetahui informasi tambahan.

Menjadwalkan masa pemeliharaan

Untuk mengurangi periode nonaktif selama upgrade dan pemeliharaan cluster/node, jadwalkan masa pemeliharaan agar dilakukan di luar jam sibuk. Selama upgrade, mungkin akan ada gangguan sementara saat workload dipindahkan untuk membuat ulang node. Untuk memastikan dampak minimal dari gangguan tersebut, jadwalkan upgrade saat di luar jam sibuk dan desain deployment aplikasi Anda untuk menangani gangguan sebagian dengan lancar, jika memungkinkan.

Menyiapkan Load Balancer Aplikasi eksternal dengan Ingress

Untuk membantu pengelolaan Service yang dipublikasikan tenant Anda dan pengelolaan traffic masuk ke Service tersebut, buat load balancer HTTP untuk mengizinkan satu traffic masuk per cluster, dengan setiap Service tenant didaftarkan dengan resource Ingress cluster. Anda dapat membuat dan mengonfigurasi load balancer HTTP(S) dengan membuat resource Kubernetes Ingress, yang menentukan cara traffic menjangkau Service dan cara traffic dirutekan ke aplikasi tenant. Dengan mendaftarkan Service ke resource Ingress, konvensi penamaan Service akan menjadi konsisten, sehingga menampilkan satu ingress, seperti tenanta.example.com dan tenantb.example.com.

Mengamankan cluster untuk multi-tenancy

Praktik terbaik:

Mengontrol komunikasi Pod dengan kebijakan jaringan.
Menjalankan workload dengan GKE Sandbox.
Menyiapkan kontrol akses berbasis kebijakan.
Menggunakan Workload Identity Federation for GKE untuk memberikan akses ke layanan Google Cloud.
Membatasi akses jaringan ke bidang kontrol.

Mengontrol komunikasi Pod dengan kebijakan jaringan

Untuk mengontrol komunikasi jaringan antara Pod di setiap namespace cluster, buat kebijakan jaringan berdasarkan persyaratan tenant Anda. Sebagai rekomendasi awal, Anda harus memblokir traffic antara namespace yang menghosting aplikasi tenant yang berbeda. Administrator cluster Anda dapat menerapkan kebijakan jaringan deny-all untuk menolak semua traffic masuk guna menghindari Pod dari satu namespace secara tidak sengaja mengirim traffic ke Service atau database di namespace lain.

Sebagai contoh, berikut adalah kebijakan jaringan yang membatasi traffic masuk dari semua namespace lainnya ke namespace tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Menjalankan workload dengan GKE Sandbox

Cluster yang menjalankan workload yang tidak tepercaya lebih rentan terhadap kerentanan keamanan dibandingkan cluster lain. Dengan menggunakan GKE Sandbox, Anda dapat memperkuat batas isolasi antara workload untuk lingkungan multi-tenant. Untuk pengelolaan keamanan, sebaiknya mulai dengan GKE Sandbox lalu gunakan kontrol akses berbasis kebijakan untuk mengisi kekurangan yang ada.

GKE Sandbox didasarkan pada gVisor, sebuah project sandbox container open source, dan menyediakan isolasi tambahan untuk workload multi-tenant dengan menambahkan lapisan ekstra antara container Anda dan OS host. Runtime container sering dijalankan sebagai pengguna dengan hak istimewa pada node dan memiliki akses ke sebagian besar panggilan sistem ke kernel host. Dalam cluster multi-tenant, satu tenant berbahaya dapat memperoleh akses ke kernel host dan ke data tenant lainnya. GKE Sandbox mengurangi ancaman ini dengan mengurangi kebutuhan container untuk berinteraksi dengan host, dengan mengecilkan permukaan serangan host dan membatasi pergerakan pelaku kejahatan.

GKE Sandbox menyediakan dua batas isolasi antara container dan OS host:

  • Kernel ruang pengguna, yang ditulis dalam Go, yang menangani panggilan sistem dan membatasi interaksi dengan kernel host. Setiap Pod memiliki kernel ruang pengguna yang terisolasi.
  • Kernel ruang pengguna juga berjalan di dalam namespace dan panggilan sistem pemfilteran seccomp.

Menyiapkan kontrol akses 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:

  • Pengontrol Kebijakan: Mendeklarasikan kebijakan standar atau kustom dan menerapkan kebijakan tersebut di cluster dalam skala besar menggunakan fleet. Pengontrol Kebijakan adalah implementasi dari open policy agent Gatekeeper yang bersifat open source dan merupakan fitur dari GKE Enterprise.

Menggunakan Workload Identity Federation for GKE untuk memberikan akses ke layanan Google Cloud

Untuk memberikan akses workload ke layanan Google Cloud dengan aman, aktifkan Workload Identity Federation untuk GKE di cluster. Workload Identity Federation untuk GKE membantu administrator mengelola akun layanan Kubernetes yang digunakan workload Kubernetes untuk mengakses layanan Google Cloud. Saat Anda membuat cluster dengan Workload Identity Federation untuk GKE diaktifkan, namespace identitas akan ditetapkan untuk project tempat cluster tersebut berada. Dengan namespace identitas, cluster dapat mengautentikasi akun layanan secara otomatis untuk aplikasi GKE dengan memetakan nama akun layanan Kubernetes ke handle akun layanan Google virtual, yang digunakan untuk binding IAM tenant Kubernetes akun layanan.

Membatasi akses jaringan ke bidang kontrol

Untuk melindungi bidang kontrol, batasi akses ke jaringan yang diizinkan. Di GKE, saat mengaktifkan jaringan yang diizinkan, Anda dapat memberikan otorisasi hingga 50 rentang CIDR dan mengizinkan alamat IP hanya dalam rentang tersebut untuk mengakses bidang kontrol Anda. GKE sudah menggunakan Transport Layer Security (TLS) dan autentikasi untuk menyediakan akses yang aman ke endpoint bidang kontrol Anda dari internet publik. Dengan menggunakan jaringan yang diizinkan, Anda dapat membatasi akses lebih lanjut ke kumpulan alamat IP tertentu.

Penyediaan tenant

Praktik terbaik:

Membuat project tenant.
Gunakan RBAC untuk meningkatkan kualitas akses tenant.
Membuat namespace untuk isolasi antar-tenant.

Membuat project tenant

Untuk menghosting resource non-cluster tenant, buat project layanan untuk setiap tenant. Project layanan ini berisi resource logis khusus untuk aplikasi tenant (misalnya, log, pemantauan, bucket penyimpanan, akun layanan, dll.). Semua project layanan tenant terhubung ke VPC Bersama di project host tenant.

Gunakan RBAC untuk meningkatkan kualitas akses tenant

Tentukan akses yang lebih terperinci ke resource cluster untuk tenant Anda dengan menggunakan Kubernetes RBAC. Selain akses hanya baca yang awalnya diberikan dengan IAM ke grup tenant, tentukan peran dan binding RBAC Kubernetes seluruh namespace untuk setiap grup tenant.

Sebelumnya, kita telah mengidentifikasi dua grup tenant: admin tenant dan developer tenant. Untuk grup tersebut, kita menentukan peran dan akses RBAC berikut:

Grup Kubernetes
Peran RBAC		 Deskripsi
Admin Tenant admin namespace

Memberikan akses untuk melihat dan mencantumkan deployment dalam namespace.

Memberikan akses untuk menambahkan dan menghapus pengguna di grup tenant.
Developer Tenant editor namespace,
penampil namespace		 Memberikan akses untuk membuat/mengedit/menghapus Pod, deployment, Service, configmap di namespace-nya.

Selain membuat peran dan binding RBAC yang menetapkan berbagai izin ke grup Google Workspace atau Cloud Identity di dalam namespace mereka, admin Tenant sering kali memerlukan kemampuan untuk mengelola pengguna di setiap grup tersebut. Berdasarkan persyaratan organisasi Anda, hal ini dapat ditangani dengan mendelegasikan izin Google Workspace atau Cloud Identity kepada admin Tenant untuk mengelola keanggotaan grup mereka sendiri atau oleh admin Tenant yang bekerja sama dengan tim di organisasi yang memiliki izin Google Workspace atau Cloud Identity untuk menangani perubahan tersebut.

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

Menggunakan Google Grup untuk mengikat izin

Untuk mengelola izin tenant dalam cluster secara efisien, Anda dapat mengikat izin RBAC ke Google Grup Anda. Keanggotaan grup tersebut dikelola oleh administrator Google Workspace Anda, sehingga administrator cluster tidak memerlukan informasi mendetail tentang pengguna.

Sebagai contoh, kita memiliki Google Grup bernama tenant-admins@mydomain.com dan pengguna bernama admin1@mydomain.com adalah anggota grup tersebut, binding berikut memberi pengguna akses admin ke namespace tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Membuat namespace

Untuk memberikan isolasi logis antara tenant yang ada di cluster yang sama, terapkan namespace. Sebagai bagian dari proses RBAC Kubernetes, admin cluster akan membuat namespace untuk setiap grup tenant. Admin Tenant mengelola pengguna (developer tenant) dalam namespace tenant masing-masing. Kemudian, developer tenant dapat menggunakan resource khusus cluster dan tenant untuk men-deploy aplikasi mereka.

Menghindari mencapai batas namespace

Jumlah maksimum namespace dalam sebuah cluster secara teoritis adalah 10.000, meskipun pada praktiknya ada banyak faktor yang dapat mencegah Anda mencapai batas ini. Misalnya, Anda mungkin telah mencapai jumlah maksimum Pod (150.000) dan node (5.000) di seluruh cluster sebelum mencapai jumlah maksimum namespace; faktor lain (seperti jumlah Secret) dapat semakin mengurangi batas efektif. Oleh karena itu, aturan awal yang baik adalah hanya mencoba mendekati batas teoretis dari satu batasan pada satu waktu, dan menjauhi sekitar satu urutan besar dari batas lainnya, kecuali jika eksperimen menunjukkan bahwa kasus penggunaan berfungsi dengan baik. Jika Anda membutuhkan lebih banyak resource daripada yang dapat didukung oleh satu cluster, Anda harus membuat lebih banyak cluster. Untuk mengetahui informasi tentang skalabilitas Kubernetes, baca artikel Batas Skalabilitas Kubernetes.

Menstandarkan penamaan namespace

Untuk memudahkan deployment di beberapa lingkungan yang dihosting di cluster berbeda, standarkan konvensi penamaan namespace yang Anda gunakan. Misalnya, hindari mengikat nama lingkungan (pengembangan, staging, dan produksi) dengan nama namespace. Sebagai gantinya, gunakan nama yang sama di seluruh lingkungan. Dengan menggunakan nama yang sama, Anda tidak perlu mengubah file konfigurasi di seluruh lingkungan.

Membuat akun layanan untuk workload tenant

Buat akun layanan Google khusus tenant untuk setiap workload yang berbeda di namespace tenant. Hal ini memberikan bentuk keamanan yang memastikan tenant dapat mengelola akun layanan untuk workload yang mereka miliki/deploy di namespace masing-masing. Akun layanan Kubernetes untuk setiap namespace dipetakan ke satu akun layanan Google menggunakan Workload Identity Federation untuk GKE.

Menerapkan kuota resource

Untuk memastikan semua tenant yang membagikan cluster memiliki akses yang adil ke resource cluster, terapkan kuota resource. Buat kuota resource untuk setiap namespace berdasarkan jumlah Pod yang di-deploy oleh setiap tenant, serta jumlah memori dan CPU yang diperlukan oleh setiap Pod.

Contoh berikut menentukan kuota resource tempat Pod dalam namespace tenant-a dapat meminta hingga 16 CPU dan memori 64 GB, dengan CPU maksimum adalah 32 dan memori maksimum adalah 72 GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Pemantauan, logging, dan penggunaan

Praktik terbaik:

Melacak metrik penggunaan.
Memberikan log khusus tenant.

Melacak metrik penggunaan

Untuk mendapatkan perincian biaya pada setiap namespace dan label dalam cluster, Anda dapat mengaktifkan alokasi biaya GKE. Alokasi biaya GKE melacak informasi tentang permintaan resource dan penggunaan resource dari workload cluster, yang dapat Anda perinci lebih lanjut berdasarkan namespace dan label. Dengan alokasi biaya GKE, Anda dapat memperkirakan perincian biaya untuk departemen/tim yang berbagi cluster, memahami pola penggunaan setiap aplikasi (atau bahkan komponen dari satu aplikasi), membantu admin cluster menentukan prioritas lonjakan penggunaan, dan menyediakan perencanaan kapasitas dan penganggaran yang lebih baik.

Saat Anda mengaktifkan alokasi biaya GKE, nama cluster dan namespace workload GKE akan muncul di kolom label pada ekspor penagihan ke BigQuery.

Memberikan log khusus tenant

Untuk menyediakan data log khusus bagi tenant project mereka, gunakan Router Log Cloud Logging. Untuk membuat log khusus tenant, admin cluster membuat sink untuk mengekspor entri log ke bucket log yang dibuat di project Google Cloud tenant.

Untuk mengetahui detail tentang cara mengonfigurasi jenis log ini, lihat Logging multi-tenant di GKE.

Ringkasan checklist

Tabel berikut merangkum tugas-tugas yang direkomendasikan untuk membuat cluster multi-tenant dalam organisasi perusahaan:

Area Tugas
Penyiapan Organisasi
Pengelolaan akses dan identitas
Jaringan
Ketersediaan dan keandalan tinggi
Keamanan
Logging dan pemantauan

Langkah berikutnya