Belajar MetalLB - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami sejarah MetalLB, sekarang waktunya membuka kap mesin. Episode 2 menjelaskan konsep dasar dan arsitektur utama MetalLB: komponen apa saja yang berjalan di cluster, apa tugas masing-masing, dan bagaimana mereka bekerja sama mengubah Service LoadBalancer menjadi IP yang bisa diakses dari luar.

Arsitektur MetalLB sebenarnya sederhana — hanya ada dua binary utama: metallb-controller dan metallb-speaker. Namun memahami peran keduanya sangat penting, karena hampir semua troubleshooting di episode-episode berikutnya (terutama episode 7 dan 19) berakar dari pertanyaan "apakah controller sudah mengalokasikan IP?" atau "apakah speaker sudah meng-announce IP?"

#Controller dan Speaker: Dua Otak MetalLB

#metallb-controller

Controller berjalan sebagai satu Deployment (biasanya direplikasi menjadi dua untuk high availability) dan bertanggung jawab atas sisi manajemen:

• Menonton Service bertipe LoadBalancer dan mengalokasikan IP eksternal dari IPAddressPool.
• Menjalankan webhook validasi untuk memastikan konfigurasi MetalLB sah.
• Memelihara status semua Service dan pool.

Controller adalah brain yang membuat keputusan alokasi. Dia tidak menyentuh traffic jaringan sama sekali — dia hanya mencatat "IP ini milik Service ini".

#metallb-speaker

Speaker berjalan sebagai DaemonSet — satu pod di setiap node — dan bertanggung jawab atas sisi data plane:

• Dalam mode Layer 2, speaker di node terpilih meng-announce IP Service menggunakan ARP (IPv4) atau NDP (IPv6).
• Dalam mode BGP, speaker melakukan peering dengan router eksternal dan meng-advertise prefix IP.

Speaker adalah muscle yang berbicara dengan jaringan. Jika controller memutuskan IP, speaker lah yang memberitahukan jaringan bahwa IP tersebut ada di sini.

kubectl get pods -n metallb-system

Setelah instalasi (episode 3), output akan menampilkan satu atau dua pod metallb-controller dan satu pod metallb-speaker per node.

#Alur Kerja End-to-End

#Dari Service Hingga Traffic Eksternal

Berikut urutan yang terjadi ketika kalian membuat Service bertipe LoadBalancer:

1. Kalian membuat Service dengan spec.type: LoadBalancer dan menentukan port.
2. Controller menonton perubahan ini dan memilih IP dari IPAddressPool yang tersedia.
3. Controller menulis IP tersebut ke status.loadBalancer.ingress[0].ip milik Service.
4. Speaker di salah satu node (mode L2) atau di semua node (mode BGP) meng-announce IP tersebut.
5. Traffic eksternal masuk ke IP tersebut, diteruskan ke pod-pod di belakang Service.

kubectl get svc nginx
kubectl describe svc nginx

Pada kubectl describe svc nginx, kalian akan melihat LoadBalancer Ingress di bagian Status, dan Events yang mencatat alokasi IP oleh controller. Dua tempat ini adalah titik awal semua diagnosis.

#CRD: Konfigurasi MetalLB sebagai Code

Sejak v0.13, konfigurasi MetalLB tidak lagi berupa ConfigMap, melainkan Custom Resource Definitions (CRD). Ada empat CRD utama yang akan kalian temui terus-menerus:

#IPAddressPool

Mendefinisikan kumpulan IP yang boleh dipakai oleh controller, baik sebagai range maupun CIDR:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.200-192.168.1.250

#L2Advertisement dan BGPAdvertisement

Keduanya menentukan cara IP di-announce. L2Advertisement untuk mode Layer 2, dan BGPAdvertisement untuk mode BGP. Advertisement akan dijelaskan lengkap di episode 5, 6, dan 8.

#BGPPeer

Mendefinisikan router yang menjadi partner peering dalam mode BGP, lengkap dengan ASN, alamat peer, dan parameter seperti hold time.

#Melihat Arsitektur dalam Praktik

#Menelusuri Komponen yang Berjalan

Untuk membiasakan diri dengan arsitektur, biasakan tiga perintah berikut:

kubectl get deployment -n metallb-system
kubectl get daemonset -n metallb-system
kubectl get crd | grep metallb

kubectl get deployment -n metallb-system menampilkan controller, kubectl get daemonset -n metallb-system menampilkan speaker, dan perintah grep CRD menampilkan semua Custom Resource yang dimiliki MetalLB. Jumlah speaker selalu sama dengan jumlah node — karena itu speaker didesain sebagai DaemonSet.

#Kenapa Desainnya Dua Lapis

Pemisahan controller dan speaker bukan tanpa alasan. Controller yang tunggal memastikan alokasi IP tidak ganda: hanya satu otak yang memutuskan siapa mendapat IP apa. Sementara speaker yang menyebar di tiap node memastikan announcement selalu dekat dengan jaringan: setiap node siap meng-announce IP tanpa bergantung pada satu titik pusat.

#Penutup

Episode 2 membuka arsitektur MetalLB: controller mengalokasikan IP, speaker meng-announce IP, dan empat CRD menjadi bahasa konfigurasinya. Alur kerja end-to-end dari Service hingga traffic eksternal juga sudah kalian pahami.

Inti yang harus dibawa pulang:

• Controller berjalan sebagai Deployment dan mengalokasikan IP dari pool.
• Speaker berjalan sebagai DaemonSet dan meng-announce IP ke jaringan.
• Alokasi terjadi di status.loadBalancer.ingress dan bisa dilihat lewat kubectl describe svc.
• IPAddressPool mendefinisikan kumpulan IP yang boleh dipakai.
• L2Advertisement, BGPAdvertisement, dan BGPPeer mengontrol cara announcement dilakukan.

Di episode 3 selanjutnya kita akan melakukan setup dan instalasi MetalLB — membandingkan instalasi via manifest metallb.yaml dan via Helm chart, memverifikasi pod controller dan speaker, lalu membuat konfigurasi awal berupa IPAddressPool dan advertisement pertama. Saatnya tangan mulai mengetik!