Belajar Multigress - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami kenapa Multigress hadir, saatnya membedah bagaimana dia bekerja di dalam. Episode 2 menjelaskan arsitektur utama Multigress: pemisahan control plane dan data plane, komponen-komponen yang terlibat, alur request dari klien sampai pod backend, serta cara Multigress berintegrasi dengan Kubernetes Gateway API.

Arsitektur ini adalah fondasi dari semua episode praktik berikutnya. Kalau kalian paham siapa yang membaca konfigurasi dan siapa yang memproses traffic, troubleshooting di episode 7 dan 20 akan terasa jauh lebih mudah.

#Arsitektur Multigress: Control Plane dan Data Plane

#Control Plane: Multigress Controller

Control plane adalah otak Multigress. Komponen utamanya adalah multigress-controller, sebuah pod yang menonton resource Kubernetes seperti GatewayClass, Gateway, dan HTTPRoute. Ketika ada perubahan, controller membandingkan kondisi aktual dengan yang diinginkan, lalu mengirim konfigurasi baru ke data plane.

Controller juga mengelola status: kalian bisa melihat kondisi Accepted atau Ready pada setiap resource, dan jika ada error, controller menuliskannya dalam field status.conditions.

#Data Plane: Proxy Envoy atau HAProxy

Data plane adalah tangan yang memproses setiap request. Secara default Multigress memakai Envoy sebagai proxy — dipilih karena ekosistem filter yang kaya, dukungan HTTP/2 dan HTTP/3, serta observability bawaan. Opsi kedua adalah HAProxy untuk tim yang lebih nyaman dengan konfigurasi tradisional.

kubectl apply -f route.yaml  →  multigress-controller  →  Envoy/HAProxy  →  backend pod

Alur di atas terjadi dalam hitungan detik setelah kalian menerapkan sebuah route.

#Komponen Utama dan Alur Traffic

#Dari GatewayClass sampai HTTPRoute

Ketika kalian menerapkan konfigurasi, ada empat objek yang saling terhubung:

• GatewayClass: deklarasi implementasi, misalnya multigress. Satu cluster bisa punya beberapa class.
• Gateway: instance gateway dengan listener (port dan protokol). Ini yang merepresentasikan proxy yang benar-benar berjalan.
• HTTPRoute: aturan routing host dan path menuju backend.
• ReferenceGrant: izin eksplisit bagi route di namespace lain untuk memakai resource lintas namespace.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: multigress
spec:
  controllerName: multigress.io/multigress-controller
---
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

Manifest di atas adalah pasangan minimal yang dipakai di seluruh series. Setelah diterapkan, cek statusnya:

kubectl get gateway main-gateway -n multigress-system
kubectl describe gateway main-gateway -n multigress-system

Perintah kubectl describe gateway main-gateway -n multigress-system menampilkan kondisi listener. Perhatikan bagian Status — di sanalah kesalahan konfigurasi biasanya terlihat jelas.

#Bagaimana Request Diproses

Saat sebuah request HTTP masuk:

1. Envoy menerima koneksi pada port listener Gateway.
2. Host dan path request dicocokkan dengan rule pada HTTPRoute.
3. Policy seperti timeout atau retry diterapkan (episode 6).
4. Request diteruskan ke Service backend sesuai backendRefs.
5. Respon dikembalikan ke klien, lalu dihitung dalam metrics.

Lima langkah ini adalah model mental yang akan kalian pakai terus sepanjang series.

#Integrasi dengan Kubernetes Gateway API dan CRD Multigress

#Gateway API Standar

Multigress memakai resource Gateway API versi stabil dari channel standard: GatewayClass, Gateway, HTTPRoute, TLSRoute, GRPCRoute, dan ReferenceGrant. Karena ini standar, konfigurasi kalian bisa dipindah ke implementasi lain bila diperlukan — inilah nilai utama vendor-neutral.

#CRD Khusus Multigress

Selain standar, Multigress menyediakan CRD tambahan untuk fitur yang belum ada di Gateway API inti. Beberapa yang akan kita pakai:

• BackendTrafficPolicy: timeouts, retries, circuit breaker, dan rate limiting per route atau per gateway.
• SecurityPolicy: JWT authentication dan policy keamanan lain (episode 12).
• ClientTrafficPolicy: pengaturan perilaku di sisi klien seperti gzip dan buffering.

kubectl get crd | grep multigress

Setelah instalasi di episode 3, perintah di atas akan menampilkan CRD standar Gateway API serta CRD khusus di atas.

#Penutup

Episode 2 memetakan arsitektur Multigress: control plane yang menerjemahkan keinginan menjadi konfigurasi, data plane Envoy atau HAProxy yang memproses traffic, dan lapisan resource Gateway API yang menjadi bahasa bersama antara keduanya.

Inti yang harus dibawa pulang:

• Multigress controller adalah control plane; Envoy atau HAProxy adalah data plane.
• GatewayClass mendeklarasikan implementasi; Gateway mendeklarasikan listener.
• HTTPRoute menentukan host dan path menuju Service backend.
• Status dan condition pada resource adalah sumber kebenaran saat troubleshooting.
• CRD khusus Multigress seperti BackendTrafficPolicy dipakai hanya jika fitur standar kurang.

Di episode 3 selanjutnya kita akan menginstall Multigress di cluster menggunakan Helm, menerapkan Gateway pertama, membuat HTTPRoute sederhana, serta memverifikasi instalasi, service, dan logs. Siapkan cluster kalian — praktik sesungguhnya dimulai sekarang.