Belajar Kata Containers - Multi-tenancy & Isolation Best Practice

#Pendahuluan

Enam belas episode pembelajaran berujung pada satu pertanyaan praktis: bagaimana mendesain cluster multi-tenant yang benar-benar aman? Kata Containers memberi alat — microVM per pod — tapi alat tanpa pola pakai adalah senjata yang disalahgunakan. Episode 16 membahas pola-pola itu: bagaimana menata tenancy, mengisolasi resource, dan memisahkan tingkat kepercayaan workload dalam satu cluster.

Ini episode yang menyatukan semuanya: apa yang kalian pelajari tentang arsitektur, resource, network, dan security kini dirangkai menjadi desain cluster yang bisa dipertanggungjawabkan.

#Satu Pod Satu MicroVM: Pola Dasar Multi-tenancy

#Tenancy di Level Pod

Pola inti multi-tenancy dengan Kata sederhana: satu tenant = satu pod = satu microVM. Tidak ada berbagi microVM antar tenant. Setiap tenant menjalankan pod-nya sendiri, dan setiap pod diisolasi oleh hardware.

Mengapa pola ini benar? Karena mencampur beberapa tenant dalam satu microVM berarti memindahkan masalah isolasi antar tenant kembali ke level container di dalam guest — menghancurkan tujuan utama memakai Kata. Guest kernel bersama dalam satu VM berarti tenant bisa saling menyerang lewat celah kernel guest.

#Konsekuensi Desain

• Setiap tenant punya microVM sendiri — jumlah microVM bisa banyak; pastikan node cukup.
• Namespace Kubernetes per tenant — satu namespace per tenant untuk kebijakan RBAC dan policy yang jelas.
• RuntimeClass tetap sama — kata untuk semua tenant; yang membedakan adalah namespace, quota, dan policy.

Pemisahan di level namespace membuat policy (episode 14-15) bisa ditargetkan per tenant dengan mudah.

#Resource Isolation via VM

#Mengapa VM Memberi Isolasi Resource Lebih Kuat

Di container biasa, resource dibatasi cgroup — satu tenant yang memakai CPU berlebihan memengaruhi tetangganya meskipun di-cgroup, terutama untuk memory dan I/O. Di Kata, setiap microVM punya alokasi resource sendiri (episode 5): memori dialokasikan ke VM, vCPU dialokasikan ke VM. Tenant tidak bisa "menggembungkan" resource tenant lain.

Dampak praktisnya: noisy neighbor hampir hilang di level resource utama. MicroVM tenant A yang memboroskan CPU tidak bisa menyentuh memori yang sudah dialokasikan ke microVM tenant B.

#Quota dan Limit per Tenant

Terapkan quota per namespace agar setiap tenant dibatasi dari atas:

kubectl create namespace tenant-a
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
EOF

ResourceQuota membatasi total resource namespace tenant-a. Karena setiap pod adalah microVM yang menahan resource, quota namespace berarti batas total kapasitas microVM tenant — kontrol yang tegas dan mudah dihitung.

#Pattern Sandbox untuk Workload Untrusted

#Sandbox sebagai Kategori Workload

Untuk workload yang benar-benar tidak dipercaya — kode yang dieksekusi dari pengguna, plugin pihak ketiga, AI agent yang menjalankan tool — gunakan pola sandbox eksplisit: namespace terpisah, RuntimeClass wajib Kata, egress dibatasi, dan masa hidup pendek.

Desain sandbox yang sehat:

• Namespace khusus dengan ResourceQuota sendiri.
• Admission policy yang mewajibkan runtimeClassName: kata (episode 15).
• NetworkPolicy dengan egress deny-by-default (episode 14).
• Image policy yang menolak image tanpa signature.
• TTL atau job yang membersihkan sandbox secara otomatis.

Ini pola yang dipakai deployment production untuk mengeksekusi kode tak dikenal — dan akan kita perluas ke AI agent sandboxes di episode 19.

#Sandbox Bukan Node Khusus

Penting dibedakan: pola sandbox di sini adalah kategori workload, bukan node khusus. MicroVM memberi isolasi di level hardware, sehingga sandbox bisa hidup di node yang sama dengan workload lain tanpa mengancamnya — selama node itu sendiri aman.

#Jangan Mencampur Trusted dan Untrusted di Node yang Sama

#Dua Tingkat Kepercayaan, Dua Taktik

Meskipun microVM sangat isolatif, ada satu pertimbangan yang membuat tim production membedakan node: tingkat kepercayaan node itu sendiri. Skenario contoh:

• Node dengan GPU passthrough (episode 10) memberi guest akses device fisik — host lebih rentan terhadap behavior guest.
• Node yang menjalankan workload high-trust (payment, kontrol plane) lebih baik dijaga dari segala kemungkinan.

Praktik terbaik: jangan campur workload untrusted dengan workload yang sangat sensitif di node yang sama. Gunakan node taint dan toleration untuk memisahkan:

kubectl taint nodes node-sandbox tier=sandbox:NoSchedule
kubectl label nodes node-sandbox workload=untrusted

kubectl taint nodes node-sandbox tier=sandbox:NoSchedule mencegah pod biasa masuk ke node sandbox. Pod untrusted menambahkan toleration agar bisa dijadwalkan ke sana — sementara workload trusted tidak pernah menyentuh node tersebut.

#Monitoring Per-VM

#Mengapa Per-VM Bukan Per-Node

Di cluster Kata, satu node bisa menampung puluhan microVM. Monitoring yang hanya melihat "node sehat" melewatkan masalah per-tenant: satu microVM yang memboroskan CPU atau kehabisan memori tidak terlihat dari rata-rata node. Monitoring harus per-microVM.

Metrik yang harus dipantau per microVM:

• Resource consumption: CPU, memori, dan I/O setiap VM.
• Boot latency: waktu dari pod dibuat sampai ready — perubahan menandakan masalah KVM atau kernel.
• Error rate: kegagalan shim, VMM, atau agent.
• Churn: terlalu banyak restart microVM menandakan masalah.

#Alat Monitoring

kubelet mengekspos metrik pod (termasuk CPU/memori cgroup), dan kubectl top adalah titik awal:

kubectl top pod -A
kubectl top node

kubectl top pod -A menampilkan konsumsi resource per pod — per microVM. Untuk metrik yang lebih dalam (per proses VMM, I/O virtio), ekspor metrik dari node dengan eksporter standar. Integrasikan dengan Prometheus + Grafana untuk melihat tren per namespace dan per tenant.

Untuk melihat footprint memori hypervisor per pod dari sisi host:

Proses VMM per pod

ps aux | grep -E "(qemu|cloud-hypervisor)" | awk '{print $11, $6/1024 "MB"}'

ps aux | grep -E "(qemu|cloud-hypervisor)" menampilkan setiap proses VMM dengan konsumsi memori-nya — cara cepat melihat berapa banyak memori yang ditahan microVM di host.

#Penutup

Inti yang harus dibawa pulang:

• Satu tenant = satu pod = satu microVM; jangan mencampur tenant dalam satu VM.
• Resource isolation via VM menghilangkan noisy neighbor di level utama.
• ResourceQuota per namespace membatasi kapasitas microVM per tenant.
• Pola sandbox: namespace terpisah, RuntimeClass wajib, egress deny-by-default.
• Taint + toleration memisahkan workload untrusted dari yang sensitif.
• Monitoring per-VM wajib: resource, boot latency, error, dan churn.

Di episode 17 selanjutnya kita akan membahas Kata 4.0 & runtime Rust (runtime-rs) — apa artinya Rust runtime menjadi default, optimasi Dragonball, fokus keamanan infrastruktur, serta transisi Go ke Rust di rilis 3.x dengan cadence bulanan. Inilah arah masa depan proyek yang kalian pelajari.