Belajar Platform Engineer - Multi-Cluster & Multi-Tenancy

#Pendahuluan

Setelah di episode 14 platform bisa menyediakan data secara self-service, pertanyaan berikutnya muncul saat skala bertambah: apakah satu cluster cukup? Jawabannya seringkali tidak. Episode ini membahas multi-cluster & multi-tenancy — alasan membangun lebih dari satu cluster, cara mengelola fleet tanpa kacau, dan model tenancy yang tepat sebelum jumlah cluster meledak tak terkendali.

Mengapa ini penting? Platform yang baik di episode sebelumnya dibangun di atas satu cluster. Ketika organisasi tumbuh, satu cluster menjadi titik ledakan blast radius yang tunggal: satu misconfig bisa mengganggu semua tim, satu upgrade harus menunggu semua orang. Multi-cluster adalah alat pengendalian risiko dan skala — tapi tanpa strategi yang benar, sepuluh cluster bisa jadi sepuluh kali lipat kerumitan, bukan keamanan.

#Mengapa Multi-Cluster

Empat alasan paling umum:

Alasan	Contoh nyata
Blast radius	Satu upgrade control plane tidak boleh mematikan semua tim sekaligus
Isolasi environment	Dev, staging, dan prod di cluster terpisah
Region & latensi	Cluster per region untuk melayani pengguna dekat
Compliance	Data tertentu wajib tinggal di region/jurisdiksi tertentu

Pola praktis yang banyak dipakai: cluster bersama untuk dev, cluster per environment untuk staging/prod, dan cluster terpisah untuk workload khusus (misalnya GPU, data, atau tenant besar). Tujuannya bukan "sebanyak mungkin", melainkan "sekecil mungkin demi risiko yang terkendali".

#Pola Multi-Cluster: Satu Fleet, Banyak Cluster

Kunci multi-cluster adalah satu source of truth, banyak target. Semua yang kita bangun di episode 5 (GitOps) kini menjadi tulang punggung: repositori berisi definisi fleet, dan setiap cluster di-render dari overlay-nya sendiri.

100%

#ArgoCD App of Apps

Pola App of Apps adalah cara standar mengelola fleet: satu Application root yang mem-bootstrap Application per cluster atau per layer platform.

argocd/apps/fleet.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: fleet-dev-eu
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://github.com/org/platform
    path: fleets/dev-eu
    targetRevision: main
  destination:
    server: https://k8s-dev-eu.example.com
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Dengan pola ini, menambah cluster = menambah folder fleets/ + register destination di ArgoCD. Semua layer platform (namespace, RBAC, monitoring, mesh, NetworkPolicy) otomatis ter-deploy ke cluster baru lewat mekanisme yang sama.

#Model Tenancy

Pertanyaan kedua setelah jumlah cluster: siapa berbagi apa dengan siapa? Tiga model utama:

Model	Isolasi	Skala tenant	Cocok untuk
Cluster per tenant	Paling kuat (control plane terpisah)	Kecil (puluhan tenant)	Tenant enterprise besar, compliance ketat
Namespace per tenant	Sedang (control plane bersama)	Besar (ratusan+ tenant)	Tim internal, environment dev
Virtual cluster (vCluster)	Kuat, control plane virtual	Sedang	Isolasi lebih dalam tanpa cluster fisik

Namespace per tenant adalah default paling sehat untuk tim internal. Ia hemat biaya dan bisa diperkuat dengan ResourceQuota, LimitRange, NetworkPolicy, dan RBAC berbasis group (episode 4) — plus ArgoCD AppProject (episode 5) yang mengunci "tim A hanya bisa sync ke namespace A".

#Praktik: Onboard Cluster Baru

Onboarding cluster baru seharusnya menjadi PR, bukan proyek berhari-hari:

Buat folder fleets/{nama-cluster} dengan overlay kustomisasi (region, node pool, model tenancy).
Registrasi destination di ArgoCD + register context cluster (bootstrap kubeconfig).
Beri label di ArgoCD (environment=prod, region=eu) untuk memfilter rollout.
Policy fleet memverifikasi cluster baru memenuhi baseline — label wajib, NetworkPolicy default-deny aktif, monitoring agent terpasang.
Merge PR → ArgoCD menyebarkan seluruh platform layer otomatis.

#Common Pitfalls

Membuat cluster demi "isolation" tanpa biaya yang dihitung — tiap cluster punya overhead control plane; jangan jadikan 100 cluster tanpa model tenancy yang jelas.
Konfigurasi per cluster diubah manual — drift cepat terjadi; semua harus berasal dari satu repo fleet.
Tenancy namespace tanpa enforcement — namespace boleh banyak, tapi tanpa quota dan NetworkPolicy isolasinya hanya di atas kertas.
Mengabaikan workload identity lintas cluster — aplikasi di cluster A kesulitan memakai kredensial cloud yang sama; gunakan workload identity terpusat (episode 18).
Menambahkan cluster tanpa verifikasi baseline — cluster baru yang tidak memenuhi policy platform menjadi lubang keamanan.

Tip

Mulai dari model tenancy, bukan jumlah cluster. Tentukan dulu "siapa berbagi dengan siapa", baru putuskan berapa cluster yang benar-benar dibutuhkan. Aturan praktis: satu cluster dev bersama, satu cluster per environment kritis, dan cluster terpisah hanya untuk workload dengan kebutuhan isolasi nyata (GPU, data, tenant besar).

#Penutup

Inti yang harus dibawa pulang:

Multi-cluster adalah pengendalian risiko, bukan tren — blast radius, environment, region, dan compliance adalah alasannya.
Satu repo fleet + App of Apps = onboarding cluster baru menjadi PR, bukan proyek.
Pilih model tenancy berdasarkan kebutuhan nyata: cluster per tenant, namespace per tenant, atau vCluster.
Isolasi harus di-enforce oleh quota, NetworkPolicy, dan RBAC, bukan sekadar dijanjikan.
Setiap cluster baru wajib lolos baseline policy sebelum dipakai.

Di episode 16 selanjutnya kita menguatkan sisi keamanan dari semua yang sudah dibangun: platform security & compliance — policy-as-code tingkat lanjut, security gates di CI/CD, audit platform, dan cara membuat baseline keamanan yang bisa diverifikasi otomatis!