Belajar Multigress - Gateway API & HTTPRoute

#Pendahuluan

Di episode 3 kalian sudah melihat Gateway dan HTTPRoute bekerja. Episode 4 memperdalam pemahaman tentang keluarga objek Gateway API: apa fungsi masing-masing, bagaimana kalian mengonfigurasi routing berdasarkan host dan path, serta bagaimana HTTPRoute berinteraksi dengan Service dan Ingress yang sudah ada di cluster.

Ini adalah episode inti dari seri ini. Hampir semua fitur di episode berikutnya — TLS, canary, rate limiting — dibangun di atas konsep route yang kalian kuasai di sini.

#Mengenal Objek Gateway API

#GatewayClass: Menyatakan Implementasi

GatewayClass adalah resource paling atas. Dia menyatakan implementasi mana yang menangani resource di bawahnya. Setiap cluster bisa punya beberapa class, misalnya multigress untuk production dan multigress-dev untuk development.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: multigress
spec:
  controllerName: multigress.io/multigress-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: multigress-dev
spec:
  controllerName: multigress.io/multigress-controller

Perhatikan bahwa keduanya memakai controller yang sama, hanya berbeda nama. Ini berguna untuk menerapkan policy yang berbeda antar lingkungan.

#Gateway: Mendeklarasikan Listener

Gateway menyatakan pintu masuk: port, protokol, dan host yang dilayani. Listener bisa dibatasi dengan hostname agar gateway hanya menerima domain tertentu.

#Route: Menentukan Kemana Traffic Mengalir

Family route di Gateway API mencakup HTTPRoute, TLSRoute, GRPCRoute, TCPRoute, dan UDPRoute. Masing-masing menangani protokol yang berbeda dan mengikuti struktur yang sama: parentRefs menunjuk ke Gateway, dan rules berisi aturan routing.

#ReferenceGrant: Izin Lintas Namespace

Secara default, route hanya boleh menunjuk backend di namespace yang sama. Untuk lintas namespace, kalian butuh ReferenceGrant:

apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-echo-route
  namespace: default
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: multigress-system
  to:
    - group: ""
      kind: Service

Resource ReferenceGrant di atas mengizinkan HTTPRoute dari namespace multigress-system menunjuk Service di namespace default. Tanpa ini, route lintas namespace akan ditolak.

#Mengonfigurasi Routing Host dan Path

#Hostname dan Path Matching

HTTPRoute mencocokkan request berdasarkan hostnames dan aturan path di dalam rules. Contoh berikut mengarahkan domain api.example.com dengan path /v1 ke Service api, dan semua path lain ke Service web:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: api
          port: 8080
    - backendRefs:
        - name: web
          port: 80

Rule tanpa matches berperan sebagai default: menangkap semua traffic yang tidak cocok dengan rule sebelumnya. Urutan rule sangat berpengaruh, jadi atur dari yang paling spesifik ke yang paling umum.

#Tipe Path Matching

Gateway API mengenal dua tipe match:

• PathPrefix: cocok dengan awalan path. /v1 akan cocok dengan /v1/users dan /v1/orders.
• Exact: hanya cocok dengan path yang persis sama.

curl -s http://localhost:8080/v1/health -H "Host: api.example.com"
curl -s http://localhost:8080/ -H "Host: api.example.com"

Request pertama diarahkan ke Service api, request kedua ke Service web. Perintah curl -s http://localhost:8080/v1/health -H "Host: api.example.com" memanfaatkan header Host untuk mensimulasikan domain tanpa perlu DNS.

#Mode Integrasi dengan Service dan Ingress

#Backend Selalu Service

Hal penting yang sering membingungkan: HTTPRoute menunjuk ke Service, bukan ke Deployment atau Pod. Ini menjaga konfigurasi tetap deklaratif — proxy hanya tahu nama Service dan port, dan Kubernetes yang mengurus pemilihan pod.

#HTTPRoute vs Ingress

Keduanya bisa hidup berdampingan. Ingress tetap berfungsi untuk controller lama, sedangkan HTTPRoute dipakai Multigress. Jika kalian ingin memigrasi, langkahnya:

1. Buat GatewayClass dan Gateway baru.
2. Buat HTTPRoute yang ekuivalen dengan tiap Ingress.
3. Verifikasi traffic, lalu hapus Ingress lama.

kubectl get ingress -A
kubectl get httproute -A

Migrasi bisa dilakukan bertahap per domain — tidak harus sekali habis. Selama proses ini, kedua jalur bisa berjalan paralel karena listener Gateway berbeda dengan ingress controller.

#Penutup

Episode 4 melengkapi pemahaman inti kalian tentang Gateway API: peran GatewayClass, Gateway, route, dan ReferenceGrant, cara mengonfigurasi routing host dan path dengan match yang tepat, serta cara HTTPRoute berbaur dengan Service dan Ingress yang sudah ada.

Inti yang harus dibawa pulang:

• GatewayClass menyatakan implementasi; Gateway menyatakan listener.
• HTTPRoute, TLSRoute, dan keluarga route menunjuk ke Service melalui parentRefs.
• ReferenceGrant wajib untuk route lintas namespace.
• PathPrefix cocok dengan awalan; Exact hanya path yang persis sama.
• Backend route selalu Service, bukan Deployment atau Pod.
• HTTPRoute dan Ingress bisa hidup berdampingan selama migrasi.

Di episode 5 selanjutnya kita akan mengamankan traffic dengan TLS & HTTPS termination — menyusun sertifikat TLS dalam Kubernetes secret, mengonfigurasi HTTPS termination pada Gateway, serta mempelajari TLS passthrough dan kontrol SNI. Pastikan Gateway dari episode 3 masih berjalan.