Belajar MetalLB - Multi-Pool & Traffic Policies

#Pendahuluan

Satu pool untuk semua Service memang sederhana, tetapi jarang memenuhi kebutuhan dunia nyata. Di cluster yang menangani banyak lingkungan sekaligus — dev, staging, produksi — atau banyak departemen, IP harus dikelola dengan pemisahan yang jelas. Episode 9 membahas multi-pool dan traffic policies: cara memisahkan pool per lingkungan, memilih pool per Service, dan memahami dampak externalTrafficPolicy terhadap source IP serta perilaku failover.

Traffic policy adalah salah satu konsep Kubernetes yang paling sering disalahpahami, dan kombinasinya dengan MetalLB membuat perbedaan yang sangat nyata — dari menjaga source IP klien hingga menentukan apakah traffic harus di-routing ulang antar node.

#Multi-Pool: Memisahkan IP per Lingkungan

#Dua Pool untuk Dua Lingkungan

Pemisahan yang paling umum adalah pool per lingkungan. Perhatikan dua pool berikut:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: dev-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.10.200-192.168.10.240
---
apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: prod-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.200-192.168.20.240

Sekarang ada dua blok IP terpisah: dev-pool untuk lingkungan development dan prod-pool untuk produksi. Kontainer traffic development tidak akan pernah masuk ke blok produksi — dan sebaliknya — selama pemilihan pool dikontrol dengan benar.

#Memilih Pool per Service: Annotation

Tanpa kontrol, controller bebas memilih pool mana pun. Untuk memastikan Service tertentu memakai pool tertentu, gunakan annotation pada Service:

apiVersion: v1
kind: Service
metadata:
  name: api-production
  annotations:
    metallb.universe.tf/address-pool: prod-pool
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - port: 8080

Annotation metallb.universe.tf/address-pool: prod-pool membuat controller mengalokasikan IP khusus dari prod-pool. Annotation ini bekerja dengan pool yang autoAssign: true, dan menjadi satu-satunya cara untuk menggunakan pool dengan autoAssign: false.

#Memeriksa Alokasi Multi-Pool

#Melihat Service dan Pool yang Terpakai

Untuk memastikan alokasi sesuai pool yang diinginkan:

kubectl get svc -A -o wide
kubectl get ipaddresspool

Dengan membandingkan EXTERNAL-IP pada kubectl get svc -A -o wide dan rentang di masing-masing pool, kalian bisa memastikan Service produksi benar-benar memakai IP dari blok produksi. Ini audit yang cepat dan sangat membantu di operasional harian.

#Traffic Policy: Local vs Cluster

#Dua Perilaku Kube-Proxy

externalTrafficPolicy pada Service menentukan bagaimana traffic eksternal diteruskan ke pod:

• Cluster (default): traffic masuk ke node mana pun, lalu kube-proxy meneruskan ke pod di node lain bila perlu.
• Local: traffic hanya diteruskan ke pod yang berada di node yang sama dengan tempat traffic masuk.

Perbedaan ini berdampak besar pada source IP dan perilaku failover.

apiVersion: v1
kind: Service
metadata:
  name: api-local
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: api
  ports:
    - port: 8080

externalTrafficPolicy: Local menjaga source IP klien tetap terlihat di pod, karena traffic tidak di-SNAT ulang saat diteruskan ke pod di node yang sama. Konsekuensinya: node yang tidak memiliki pod aplikasi tidak akan menangkap traffic untuk Service tersebut.

#Dampak pada Source IP

Dengan Cluster, source IP yang sampai di pod adalah IP node (karena ada SNAT di kube-proxy). Dengan Local, source IP asli klien dipertahankan. Jika aplikasi kalian butuh source IP asli untuk logging atau kebijakan akses, Local adalah jawabannya.

#Dampak pada Failover dan Distribusi

Trade-off utama Local adalah failover menjadi lebih halus: MetalLB hanya mengarahkan traffic ke node yang benar-benar memiliki pod. Ini menjaga kesehatan Service ketika sebuah node mati — traffic otomatis menghindari node tanpa pod. Namun jika replica pod hanya ada di sedikit node, sebagian node jadi menganggur sebagai pintu masuk.

Sebaliknya, Cluster mendistribusikan traffic ke semua node secara merata, tetapi memunculkan satu hop tambahan ketika pod ada di node lain, dan source IP klien hilang.

#Memilih Policy yang Tepat

#Panduan Keputusan

Pertimbangan praktis untuk memilih policy:

• Pakai Local jika source IP asli penting dan replica pod tersebar di semua node.
• Pakai Cluster jika mengutamakan penyebaran beban yang merata dan tidak peduli dengan source IP.
• Di mode Layer 2, Local membuat node leader hanya menerima traffic jika pod ada di sana — mencegah node leader menjadi titik mati.
• Di mode BGP, kombinasi Local dengan ECMP menghasilkan distribusi traffic yang jauh lebih merata ke node yang benar-benar punya pod.

kubectl get svc api-local -o yaml
kubectl describe svc api-local

kubectl describe svc api-local menampilkan kolom External Traffic Policy pada bagian LoadBalancer. Memeriksa kolom ini adalah langkah pertama yang baik saat mendiagnosis perilaku source IP di cluster.

#Penutup

Episode 9 menuntaskan pengelolaan multi-pool dan traffic policies: pool per lingkungan, annotation untuk memilih pool per Service, serta perbedaan nyata antara externalTrafficPolicy: Local dan Cluster terhadap source IP, distribusi, dan failover.

Inti yang harus dibawa pulang:

• Multi-pool memisahkan IP per lingkungan, departemen, atau kebutuhan.
• Annotation metallb.universe.tf/address-pool memilih pool untuk Service tertentu.
• externalTrafficPolicy: Local menjaga source IP asli dan menghindari SNAT.
• externalTrafficPolicy: Cluster menyebar beban merata dengan biaya source IP.
• Dengan Local, node tanpa pod tidak menangkap traffic Service.
• Pilihan policy harus mempertimbangkan distribusi replica pod kalian.

Di episode 10 selanjutnya kita akan membahas validating admission & CRD — bagaimana webhook metallb-controller memvalidasi konfigurasi sebelum diterapkan, cara membaca error konfigurasi, migrasi CRD dari v1beta1 ke v1beta2, serta best practice saat meng-upgrade MetalLB.