Belajar MetalLB - Integrasi Ingress & Nginx

#Pendahuluan

Mengekspos setiap aplikasi dengan Service LoadBalancer sendiri memang mungkin, tetapi boros IP dan sulit diatur. Di situlah Ingress berperan: satu titik masuk (entry point) yang membagi traffic ke banyak Service berdasarkan hostname atau path. Kombinasi MetalLB dan Ingress Controller adalah pola paling umum di cluster bare-metal — MetalLB menyediakan IP eksternal, Ingress yang membagi traffic.

Episode 12 memandu membangun pola ini dengan Nginx Ingress Controller: menginstall controller, meng-expose-nya lewat Service LoadBalancer, membandingkannya dengan pendekatan NodePort, dan merangkai alur end-to-end dari aplikasi menuju Ingress dan keluar lewat MetalLB.

#Mengapa Ingress + MetalLB

#Satu IP untuk Banyak Aplikasi

Tanpa Ingress, satu aplikasi butuh satu IP LoadBalancer. Dengan Ingress, satu IP LoadBalancer bisa melayani puluhan aplikasi — router-nya adalah Ingress Controller yang menilai request berdasarkan hostname dan path.

kubectl get svc -A

Pada kubectl get svc -A, kalian akan melihat banyak Service ClusterIP internal dan hanya satu Service LoadBalancer untuk Ingress. Inilah penghematan IP yang signifikan, apalagi untuk pool dengan kapasitas terbatas.

#Arsitektur Tiga Lapis

Alur traffic-nya menjadi:

1. Traffic eksternal masuk ke IP MetalLB yang dimiliki Service LoadBalancer Ingress.
2. Ingress Controller menerima request dan mencocokkan hostname atau path dengan rule Ingress.
3. Ingress meneruskan request ke Service backend, lalu ke pod aplikasi.

#Install Nginx Ingress Controller

#Instalasi via Helm

Cara tercepat menginstall Nginx Ingress Controller adalah lewat Helm:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace

helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx membuat controller di namespace ingress-nginx. Tunggu sampai pod controller berstatus Running:

kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

#Expose Ingress Controller via MetalLB

#Service LoadBalancer untuk Controller

Secara default, chart Nginx Ingress membuat Service bertipe LoadBalancer. MetalLB akan mengalokasikan IP eksternal untuk Service ini dari pool yang sudah dikonfigurasi:

kubectl get svc ingress-nginx-controller -n ingress-nginx
kubectl get svc ingress-nginx-controller -n ingress-nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Jika EXTERNAL-IP sudah terisi, misalnya 192.168.1.201, berarti MetalLB berhasil meng-expose Ingress Controller. kubectl get svc ingress-nginx-controller -n ingress-nginx adalah perintah untuk memeriksa status tersebut.

#Memastikan Advertisement

IP Ingress juga harus di-announce. Jika mode Layer 2, cek dari mesin lain bahwa IP tersebut menjawab ARP. Jika mode BGP, cek route di router. Kedua pemeriksaan ini memakai langkah yang sama seperti di episode 5 dan 6.

#LoadBalancer vs NodePort untuk Ingress

#Perbandingan Praktis

Kedua pendekatan bisa mengekspos Ingress, tetapi ada perbedaan penting:

• LoadBalancer: IP dedicated per Service, source IP lebih mudah dipertahankan dengan externalTrafficPolicy: Local, dan tidak perlu mengingat port acak.
• NodePort: tidak butuh IP ekstra, tetapi port yang dipakai acak di setiap node, dan akses memakai IP node plus port — misalnya http://192.168.1.10:31234.

Untuk produksi, LoadBalancer adalah pilihan yang jauh lebih rapi. NodePort tetap berguna sebagai cadangan cepat atau saat blok IP terbatas.

#Alur End-to-End: Aplikasi ke Ingress

#Deploy Aplikasi dan Rule Ingress

Sekarang rangkai semuanya. Deploy dua aplikasi dan buat rule Ingress berdasarkan hostname:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-apps
spec:
  ingressClassName: nginx
  rules:
    - host: app1.example.internal
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app1
                port:
                  number: 80
    - host: app2.example.internal
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app2
                port:
                  number: 80

#Menguji Akses Melalui Ingress

Dari mesin di luar cluster, arahkan hostname ke IP LoadBalancer Ingress:

curl --resolve app1.example.internal:80:192.168.1.201 http://app1.example.internal
curl -H "Host: app1.example.internal" http://192.168.1.201

curl -H "Host: app1.example.internal" http://192.168.1.201 memaksa Nginx memperlakukan request seolah-olah untuk hostname tersebut. Jika aplikasi app1 menjawab, alur end-to-end bekerja: aplikasi menuju Ingress, keluar lewat MetalLB.

#Penutup

Episode 12 menuntaskan pola Ingress + MetalLB: satu IP eksternal melayani banyak aplikasi, Ingress Controller diekspos lewat Service LoadBalancer, dan alur end-to-end dari aplikasi sampai keluar cluster terbukti bekerja.

Inti yang harus dibawa pulang:

• Satu IP LoadBalancer untuk Ingress menggantikan banyak IP per aplikasi.
• helm install ingress-nginx ingress-nginx/ingress-nginx adalah cara install tercepat.
• kubectl get svc ingress-nginx-controller -n ingress-nginx memeriksa IP yang dialokasikan MetalLB.
• LoadBalancer lebih rapi daripada NodePort untuk produksi.
• Rule Ingress membagi traffic berdasarkan hostname atau path.
• Uji dengan curl -H "Host: ..." untuk memverifikasi routing Ingress.

Di episode 13 selanjutnya kita akan membahas peering & network design — konfigurasi multi-peer BGP, penggunaan routerID, perencanaan subnet yang di-advertise, penempatan pool IP, dan komunikasi dengan firewall agar peering dan advertisement bekerja dengan aman.