Belajar GitOps dengan ArgoCD - Multi-Tenancy at Scale

#Pendahuluan

Di episode 27 sebelumnya kita belajar memecahkan masalah — dan sebagian besar masalah itu tumbuh dari satu akar: terlalu banyak hal berbagi satu ruang tanpa batas. Ketika lima tim memakai satu ArgoCD, satu cluster, dan satu set namespace tanpa pemisahan yang jelas, bukan soal apakah konflik akan muncul, melainkan kapan. Pada episode ini kita membahas multi-tenancy at scale — bagaimana menjalankan satu ArgoCD (atau beberapa) untuk banyak tenant dengan batas yang tegas.

Mengapa ini penting? Multi-tenancy adalah titik di mana GitOps berubah dari "cara tim kita deploy" menjadi "platform perusahaan". Di sinilah tim platform bertugas membuat self-service yang aman: tenant mendapatkan kecepatan tanpa platform kehilangan kontrol. Episode ini menjelaskan model tenancy, strategi isolasi, pola self-service, dan cara mengelola resource serta biaya secara adil.

#Model Tenancy

Ada tiga model utama, dan pilihan di antara mereka menentukan seluruh desain berikutnya:

Dalam model namespace-based, satu ArgoCD mengelola semua tenant. Isolasi dilakukan lewat kombinasi Project (episode 10), ResourceQuota, dan NetworkPolicy per namespace. Ini model yang paling hemat biaya — tetapi menuntut disiplin tinggi. Dalam model cluster-based, setiap tenant mendapat cluster sendiri (mungkin di-cluster oleh ArgoCD hub); mahal tetapi isolasinya tak terbantahkan. Hybrid adalah jawaban pragmatis: tenant kecil berbagi cluster development, sementara production setiap tenant (atau environment) mendapat cluster sendiri.

#Strategi Isolasi

Isolasi bukan satu lapisan, melainkan empat lapisan yang saling melengkapi.

#Network Policies

Kontrol lalu lintas antar namespace secara default-deny:

Default deny antar tenant

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: tenant-billing
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Setiap tenant harus mengizinkan lalu lintas keluar masuk secara eksplisit. NetworkPolicy memastikan aplikasi tenant A tidak bisa menjadi jalan masuk ke tenant B bahkan ketika cluster ter-compromise.

#Resource Quotas

Quota dan LimitRange mencegah satu tenant menghabiskan seluruh cluster:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-billing-quota
  namespace: tenant-billing
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    count/deployments.apps: "20"

Tanpa quota, satu aplikasi yang salah konfigurasi bisa membuat seluruh tenant lain kelaparan resource. Quota juga menjadi dasar hitungan biaya (lihat Manajemen Resource di bawah).

#RBAC Boundaries

Dua lapis RBAC bekerja bersama: RBAC Kubernetes (siapa boleh menyentuh apa di cluster) dan RBAC ArgoCD (siapa boleh sync/melihat aplikasi apa). Di ArgoCD, ini dikendalikan lewat Project:

Project dengan batas sumber dan tujuan

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: tenant-billing
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/org/tenant-billing/*
  destinations:
    - namespace: tenant-billing
      server: https://kubernetes.default.svc
  roles:
    - name: developer
      policies:
        - p, proj:tenant-billing:developer, applications, get, tenant-billing/*, allow
        - p, proj:tenant-billing:developer, applications, sync, tenant-billing/*, allow

#Project Separation

Project adalah unit logis multi-tenancy di ArgoCD. Satu project satu tenant — bukan satu project banyak aplikasi multi-tenant. Project menentukan repo sumber yang boleh, cluster tujuan yang boleh, dan resource Kubernetes yang boleh dibuat.

#Pola Self-Service

Tenancy yang baik tidak menuntut platform team mengerjakan semuanya secara manual. Self-service adalah kunci skala.

#Onboarding Terotomasi

Saat tenant baru bergabung, tim platform menjalankan satu langkah: menyetor satu file ke repo onboarding. Sebuah ApplicationSet dengan generator Git mendeteksi direktori baru dan memprovisi semua kebutuhan tenant — namespace, quota, network policy, role, dan Application:

ApplicationSet untuk provisioning tenant

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: tenant-onboarding
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: https://github.com/org/tenant-registry
        revision: main
        directories:
          - path: tenants/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: '{{path.basename}}'
      source:
        repoURL: https://github.com/org/tenant-registry
        path: '{{path}}/manifests'
      destination:
        namespace: '{{path.basename}}'
        server: https://kubernetes.default.svc

#Template Repositories

Setiap tenant bukan titik awal kosong, melainkan turunan dari template. Template repo berisi standar platform: label, security context, liveness probe, resource request minimum. Perbedaan antar tenant hanya pada nilai yang di-override lewat Kustomize overlay atau Helm values — bukan duplikasi penuh yang menyimpang.

#Governance Policies

Self-service tanpa governance adalah anarki. Policy engine seperti Kyverno (episode 30) memvalidasi setiap manifest yang masuk: menolak image latest, memaksa securityContext non-root, memastikan resource requests selalu ada. Karena ArgoCD menerapkan dari Git, policy ini juga diterapkan ke setiap sync — satu gerbang otomatis untuk semua tenant.

#Manajemen Resource

Di lingkungan multi-tenant, resource adalah uang — dan platform team yang tidak bisa menjawab "siapa menghabiskan berapa" akan kesulitan di budget review.

#Alokasi yang Adil

Quota per tenant (di atas) menetapkan kesepakatan alokasi. Untuk alokasi yang adil, kombinasikan: quota tetap per tenant untuk baseline, plus pool bersama yang bisa diambil sementara untuk lonjakan (dengan approval).

#Cost Allocation, Chargeback, Showback

• Cost allocation — beri label pada resource (episode 33): team=billing, environment=prod, tenant=.... Cloud provider menggunakan label ini untuk memetakan biaya per tenant.
• Chargeback — tenant benar-benar ditagih sesuai pemakaian; berlaku di organisasi yang tenant-nya unit bisnis.
• Showback — tenant tidak ditagih tetapi melihat laporan pemakaiannya; lebih mudah diterima dan sudah cukup mengubah perilaku.

#Usage Monitoring

Pantau pemakaian per namespace dengan metrik:

kubectl get resourcequota -A
kubectl describe resourcequota tenant-billing-quota -n tenant-billing
kubectl top pods -n tenant-billing

kubectl top menunjukkan pemakaian aktual vs request — data penting untuk menemukan tenant yang over-request (meminta 8 vCPU tapi memakai 0.5) dan tenant yang under-provisioned.

#Penutup

Episode ini memetakan multi-tenancy di ArgoCD secara utuh: model namespace-based, cluster-based, dan hybrid, empat lapis isolasi (network policy, quota, RBAC, project separation), pola self-service dengan onboarding otomatis, ApplicationSet provisioning, template repo, dan governance policy, serta manajemen resource dengan alokasi adil, cost allocation, chargeback/showback, dan monitoring pemakaian.

Poin yang harus kalian bawa:

• Model tenancy menentukan seluruh desain; mulai dari namespace-based.
• Isolasi efektif adalah empat lapis, bukan satu.
• Project ArgoCD adalah batas utama: sumber, tujuan, dan resource yang diizinkan.
• ApplicationSet mengubah onboarding tenant menjadi satu commit.
• Label yang disiplin sejak awal membuat cost allocation mungkin dilakukan.

Tenancy yang baik mengelola aplikasi; langkah berikutnya adalah mengelola hal di bawah aplikasi. Di episode 29 selanjutnya kita membahas infrastructure GitOps — Terraform dengan GitOps, Crossplane untuk IaC native Kubernetes, Cluster API untuk lifecycle cluster, dan pola full stack GitOps. Sampai jumpa di episode 29!