Belajar Multigress - Multi-tenant Routing & Namespace Isolation
Episode 10 of 23

Belajar Multigress - Multi-tenant Routing & Namespace Isolation

Episode ini membahas domain-based routing lintas namespace, gateway scoping dan pola isolasi namespace, serta pengelolaan shared gateway yang dipakai bersama banyak tim tenant.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Sebuah platform biasanya melayani banyak tim, masing-masing dengan domain dan aplikasinya sendiri. Episode 10 membahas multi-tenant routing dan namespace isolation: bagaimana satu gateway bisa melayani banyak namespace, bagaimana membatasi scope gateway, dan pola pengelolaan shared gateway supaya aman dan rapi.

Konsep kunci di episode ini adalah ReferenceGrant. Tanpa izin eksplisit ini, lintas namespace tidak akan berfungsi — ini bentuk kontrol akses bawaan Gateway API yang membatasi ruang gerak tiap tim.

Domain-Based Routing Across Namespaces

Satu Gateway, Banyak Namespace

Pola paling umum: gateway milik tim platform di namespace multigress-system, sedangkan aplikasi tiap tenant tinggal di namespace masing-masing. Routing tetap satu HTTPRoute per tenant:

Route tenant A
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: tenant-a-route
  namespace: team-a
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  hostnames:
    - "a.example.com"
  rules:
    - backendRefs:
        - name: app-a
          port: 8080

Route di namespace team-a menunjuk ke Gateway di namespace lain. Supaya diterima, tenant A harus menyediakan ReferenceGrant di namespace-nya sendiri:

ReferenceGrant tenant A
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-gateway
  namespace: team-a
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: team-a
  to:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: main-gateway

Perhatikan arah izin: ReferenceGrant dibuat di namespace yang menampung route, dan menyatakan route boleh menunjuk ke Gateway tertentu. Ini menjadikan akses lintas namespace sebagai pemberian izin eksplisit, bukan sekadar konvensi.

Menambahkan Tenant Baru

Menambahkan tenant berikutnya tinggal duplikasi pola di atas dengan namespace, domain, dan service yang berbeda:

Lihat route seluruh tenant
kubectl get httproute -A
kubectl get referencegrant -A

Perintah kubectl get httproute -A menampilkan semua route lintas namespace. Ini juga cara cepat mendeteksi route yang kehilangan ReferenceGrant — statusnya menjadi RefNotPermitted.

Gateway Scoping dan Pola Isolasi Namespace

AllowedRoutes pada Gateway

Platform ingin membatasi namespace mana yang boleh mengikat ke gateway-nya. Ini diatur di Gateway lewat allowedRoutes:

Batasi namespace tenant
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: multigress-system
spec:
  gatewayClassName: multigress
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              tenant: "true"

Dengan from: Selector, hanya namespace berlabel tenant: true yang boleh membuat route ke gateway ini. Ini adalah bentuk gateway scoping yang kuat untuk mencegah namespace liar menyedot traffic.

Pola Isolasi

Tiga pola umum isolasi yang bisa kalian pilih:

  • Shared gateway: satu gateway untuk semua tenant, diisolasi per domain. Hemat biaya, kontrol terpusat.
  • Gateway per team: tiap namespace punya gateway sendiri. Isolasi penuh, biaya lebih tinggi.
  • Gateway per environment: gateway staging dan prod terpisah, diisolasi per lingkungan.

Pilih pola berdasarkan ukuran organisasi dan kebutuhan compliance.

Mengelola Shared Gateways untuk Banyak Tim

Model Operasional yang Sehat

Shared gateway sukses ketika ada kesepakatan eksplisit. Praktik yang disarankan:

  • Ownership jelas: tim platform mengelola GatewayClass dan Gateway; tenant mengelola route mereka sendiri.
  • Domain terpisah: setiap tenant hanya memegang hostname yang dialokasikan, dicegah lewat hostname pada listener.
  • Rate limit per tenant: gunakan BackendTrafficPolicy untuk membatasi satu tenant agar tidak memakan semua resource.
  • Observability per label: tandai route dengan label tenant untuk memisahkan metric di Prometheus.
Rate limit per tenant
apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: tenant-a-policy
  namespace: team-a
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: tenant-a-route
  rateLimit:
    type: Global
    rps: 50

Policy di atas membatasi tenant A hingga 50 request per detik. Detail rate limiting dibahas mendalam di episode 14.

Menghindari Konflik Antar Tenant

Konflik yang paling umum adalah dua tenant mendaftarkan hostname yang sama. Deteksi dengan memeriksa apakah suatu hostname sudah dipakai:

Cari hostname yang sama
kubectl get httproute -A -o jsonpath="{range .items[*]}{.metadata.namespace}{'/'}{.metadata.name}{' => '}{.spec.hostnames}{'\n'}{end}"

Perintah kubectl get httproute -A -o jsonpath=... menampilkan daftar hostname per route. Jika dua route memakai hostname yang sama, traffic akan dibagi secara nondeterministik — tanda bahwa alokasi domain perlu diperketat.

Warning

Gateway API tidak mencegah duplikasi hostname antar route. Diperlukan proses review dan label untuk menjamin alokasi domain per tenant. Otomasi validasi ini akan dibahas di episode 19.

Penutup

Episode 10 membekali kalian struktur multi-tenant: routing lintas namespace dengan ReferenceGrant, pembatasan scope lewat allowedRoutes dan label, serta model operasional shared gateway yang jelas antar tim.

Inti yang harus dibawa pulang:

  • Route lintas namespace wajib memiliki ReferenceGrant di namespace route.
  • allowedRoutes di listener membatasi namespace yang boleh mengikat.
  • Pola isolasi: shared gateway, gateway per team, atau per environment.
  • Shared gateway butuh ownership, alokasi domain, dan rate limit per tenant.
  • Duplikasi hostname antar tenant tidak dicegah otomatis; butuh proses review.

Di episode 11 selanjutnya kita akan membahas configuration management & GitOps — menyimpan manifest Multigress di Git, memvalidasi perubahan konfigurasi, menerapkan pola rollout yang aman, dan mengelola overlay antar environment. Struktur multi-tenant kalian akan menjadi basis repo GitOps yang sesungguhnya.

Belajar Multigress - Multi-tenant Routing & Namespace Isolation | Belajar Multigress