Belajar Multigress - Sejarah, Latar Belakang & Mengapa Menggunakan Multigress

#Pendahuluan

Traffic management di Kubernetes pernah berarti satu jalan sempit: objek Ingress yang dikontrol oleh satu controller dengan segudang annotation. Selama bertahun-tahun pola ini bertahan, tetapi mulai terasa sempit saat aplikasi tumbuh kompleks. Muncul kebutuhan akan API yang lebih ekspresif, vendor-neutral, dan mampu menangani ingress, egress, dan mesh sekaligus.

Episode 1 membahas mengapa Multigress hadir, bagaimana posisinya di ekosistem cloud native, perbandingannya dengan solusi lain seperti Ingress Controller, API Gateway, dan Istio Gateway, serta use case utama yang membuatnya menarik. Episode ini bersifat naratif — minim perintah — tetapi justru di sinilah kalian memahami kenapa series ini layak diikuti sampai tuntas.

Tidak perlu menginstall apa pun di episode ini. Silakan catat pertanyaan yang muncul selama membaca, dan pastikan semuanya terjawab saat kita masuk ke episode 2.

#Mengapa Multigress Hadir di Ekosistem Cloud Native

#Masalah pada Ingress Klasik

Objek Ingress lahir untuk memecahkan kebutuhan sederhana: route HTTP berdasarkan host dan path. Sayangnya, spesifikasinya terlalu minim. Fitur seperti rewrite, authentication, rate limiting, dan TLS passthrough tidak tersedia di API inti. Setiap controller akhirnya membuat annotation sendiri-sendiri sehingga konfigurasi menjadi tidak portable, sulit divalidasi, dan tidak bisa dipindah antar implementasi.

Masalah yang paling sering ditemui meliputi:

• Annotation khusus vendor membuat konfigurasi tidak portable.
• Fitur keamanan seperti authentication dan rate limit tidak standar.
• Tidak ada model status yang seragam untuk diagnosis.
• Duplikasi konfigurasi antar controller sulit dihindari.
• Upgrade controller bisa mengubah perilaku tanpa peringatan.

#Kelahiran Gateway API

Dari keterbatasan itu, komunitas Kubernetes menciptakan Gateway API — superset dari Ingress dengan konsep eksplisit GatewayClass, Gateway, dan HTTPRoute. API ini mendukung fitur yang selama ini hanya bisa lewat annotation, dan menyediakan status serta condition yang jelas untuk setiap resource.

Resource yang dulu membutuhkan puluhan annotation Ingress kini cukup dinyatakan sebagai objek dengan field eksplisit. Inilah yang membuat konfigurasi bisa divalidasi oleh tool seperti kubeconform, yang akan kita pakai di episode 19.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo-route
spec:
  parentRefs:
    - name: main-gateway
  hostnames:
    - "echo.example.com"
  rules:
    - backendRefs:
        - name: echo
          port: 80

Perhatikan: tidak ada annotation sama sekali. Perintah kubectl apply -f route.yaml cukup untuk menerapkan konfigurasi di atas ke implementasi Gateway API mana pun.

#Posisi Multigress di Tumpukan Cloud Native

Multigress lahir sebagai jawaban atas dua kebutuhan sekaligus: API yang standar dan runtime yang ringan. Secara arsitektur, Multigress terdiri dari dua lapisan:

• Control plane: sebuah controller yang mendengarkan resource Gateway API dan menerjemahkannya menjadi konfigurasi proxy.
• Data plane: proxy yang benar-benar memproses traffic, berbasis Envoy secara default dengan opsi HAProxy.

Aliran kerjanya sederhana: kalian menulis Gateway dan HTTPRoute, controller membacanya, lalu data plane di-update tanpa downtime. Detail arsitektur ini dibahas tuntas di episode 2.

#Multigress vs Solusi Lain

Kalian perlu memahami posisi Multigress agar tidak salah pilih:

• Ingress Controller: hanya menangani traffic masuk (north-south) dengan API yang minim dan bergantung pada annotation.
• API Gateway: fokus pada manajemen API, authentication, dan quota; umumnya berjalan di luar Kubernetes.
• Istio Gateway: bagian dari service mesh, kuat untuk east-west dan mTLS, tetapi berat jika hanya butuh ingress.
• Multigress: menyatukan ingress, egress, dan gatewaying dalam satu control plane berbasis Gateway API, dengan data plane Envoy atau HAProxy yang ringan dan scalable.

Multigress bukan pengganti service mesh. Dia adalah lapisan gateway yang berdiri sendiri dan bisa dipasang berdampingan dengan mesh bila diperlukan. Perbandingan ini akan kembali relevan di episode 13 dan 17.

Nilai utama Multigress ada pada konsistensinya: satu cara deklaratif untuk semua arah traffic, dengan validasi yang kuat lewat Gateway API.

kubectl api-resources | grep -i gateway

Jika belum ada implementasi yang terinstall, output-nya hanya menampilkan resource bawaan. Itu normal sebelum episode 3.

#Use Cases Utama

#Ingress dan Edge Routing

Use case paling dasar: menerima traffic HTTP atau HTTPS dari luar, men-terminasi TLS di gateway, lalu mengarahkan request ke Service yang tepat berdasarkan host dan path. Ini yang akan kalian bangun mulai episode 3.

#Egress

Multigress juga bisa menjadi pintu keluar traffic. Semua request dari pod menuju dunia luar dilewatkan lewat satu egress gateway sehingga policy, logging, dan kontrol akses bisa diterapkan terpusat. Detail lengkap ada di episode 13.

#Service Mesh Gatewaying

Ketika dipasang berdampingan dengan mesh seperti Istio, Multigress bisa bertindak sebagai gateway yang memahami identity workload. Traffic masuk diverifikasi dan diteruskan dengan mTLS hingga ke pod backend, membuka pola zero-trust di edge.

#Edge Routing Multi-Cluster

Use case terakhir yang sedang naik daun: edge routing lintas cluster. Satu entry point meneruskan request ke cluster yang tepat berdasarkan lokasi atau latensi — topik lengkap di episode 17.

Keempat use case di atas bukan daftar yang kaku. Semuanya bisa dikombinasikan, dan sebagian besar pola produksi yang akan kita bahas memakai lebih dari satu use case sekaligus.

#Penutup

Episode 1 menjelaskan alasan Multigress eksis: keterbatasan Ingress klasik melahirkan Gateway API, dan Multigress adalah salah satu implementasinya yang menyatukan ingress, egress, dan gatewaying dalam satu arsitektur control plane dan data plane.

Inti yang harus dibawa pulang:

• Ingress klasik terlalu minim dan annotation membuat konfigurasi tidak portable.
• Gateway API adalah superset Ingress dengan konsep GatewayClass, Gateway, dan route.
• Multigress adalah implementasi Gateway API dengan data plane Envoy atau HAProxy.
• Multigress berbeda dari Ingress Controller, API Gateway, dan Istio Gateway.
• Use case utama: ingress, egress, service mesh gatewaying, dan edge routing multi-cluster.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Multigress — peran control plane dan data plane, komponen multigress controller, Gateway API, dan backend Envoy atau HAProxy, alur dari GatewayClass sampai HTTPRoute, serta integrasi dengan CRD khusus Multigress. Pastikan pemahaman konsep di episode 1 sudah meresap sebelum lanjut.