Belajar MetalLB - Sejarah, Latar Belakang & Mengapa Membutuhkan MetalLB

#Pendahuluan

Sebelum kalian menginstall MetalLB, ada baiknya memahami dari mana proyek ini berasal dan masalah apa yang benar-benar dia selesaikan. Episode 1 ini membedah sejarah, latar belakang, dan alasan mengapa MetalLB dibutuhkan — sekaligus membandingkannya dengan pendekatan lain yang sering dipakai sebelumnya.

Kata "MetalLB" sendiri adalah singkatan dari Metal Load Balancer. Namanya sudah menjelaskan misinya: menjadi load balancer untuk cluster Kubernetes yang berjalan di atas metal — server fisik atau VM yang tidak menikmati fasilitas load balancer otomatis dari cloud provider.

Pemahaman sejarah ini bukan sekadar trivia. Saat kalian harus memilih antara MetalLB, kube-vip, atau sekadar NodePort, alasan di balik keputusan itu justru berasal dari pemahaman masalah yang kita bahas di episode ini.

#Awal Mula: Lahir dari Kebutuhan Cluster Bare-Metal

#2017: Proyek di Google Cloud

MetalLB pertama kali dibuat di Google Cloud pada tahun 2017 oleh David Anderson, seorang software engineer yang melihat celah besar di ekosistem Kubernetes. Saat itu, Kubernetes sudah semakin populer, tetapi dukungannya terhadap jaringan luar (load balancer) hanya matang di cloud provider besar seperti AWS, GCP, dan Azure.

Cluster yang berjalan di on-premise, lab, atau data center sendiri harus mengelola load balancer secara manual. David Anderson menulis MetalLB sebagai solusi open-source, lalu pada tahun 2018 proyek ini disumbangkan ke CNCF (Cloud Native Computing Foundation) dan berkembang menjadi project yang di-adopt di ribuan cluster.

#Perjalanan Versi Hingga 2026

Evolusi MetalLB bisa dilihat dari deretan release utamanya:

2019: release publik pertama yang stabil untuk produksi.
2020-2023: seri v0.12 dan v0.13 memperkenalkan penggunaan FRR untuk implementasi BGP dan menetapkan CRD sebagai cara konfigurasi utama.
2024: v0.14 memperkenalkan CRD v1beta2 sebagai default.
2025: v0.15 menyempurnakan fitur dan observability.
2026: v0.16.x menjadi stable release terbaru — v0.16.0 dan v0.16.1 dirilis Mei 2026, dan v0.15 resmi memasuki masa end of life di bulan yang sama.

#Masalah Tanpa Load Balancer

Untuk merasakan masalahnya secara langsung, buat Service bertipe LoadBalancer di cluster tanpa MetalLB:

Service LoadBalancer tanpa MetalLB

kubectl get svc nginx

Kolom EXTERNAL-IP akan menampilkan <pending> selamanya. kubectl get svc nginx tidak akan pernah selesai men-assign IP karena tidak ada cloud provider yang hadir untuk mengisi posisi itu.

#Dari Google ke CNCF

Setelah menjadi proyek open-source, MetalLB disumbangkan ke CNCF pada tahun 2018. Konsekuensinya signifikan: proyek ini tidak lagi dikendalikan satu vendor, melainkan dikelola komunitas dengan proses governance yang terbuka. Vendor netral ini menjadi salah satu alasan mengapa MetalLB banyak dipakai — tim tidak khawatir terikat pada satu perusahaan.

Adopsi juga tumbuh lewat standarisasi: hampir semua distribusi Kubernetes on-premise yang serius menyertakan opsi pemasangan MetalLB, dan dokumentasinya menjadi referensi utama untuk menyediakan LoadBalancer di lingkungan tanpa cloud.

#Masalah yang Diselesaikan MetalLB

#Dua Tugas Utama

MetalLB menyelesaikan dua masalah yang secara umum menjadi tanggung jawab load balancer cloud-native:

IP Assignment: memberi setiap Service LoadBalancer sebuah IP eksternal dari pool yang kalian definisikan, menggantikan posisi cloud provider.
Announcement: meng-announce IP tersebut ke jaringan di luar cluster sehingga traffic eksternal bisa mencapai Service.

Untuk tugas kedua, MetalLB menyediakan dua mode yang sudah kita singgung di episode 0: Layer 2 yang menggunakan ARP/NDP, dan BGP yang melakukan peering dengan router.

#Analogi Sederhana

Bayangkan Service bertipe LoadBalancer seperti nomor telepon yang harus dipublikasikan di direktori. Cloud provider menyediakan nomor dan memasang iklan otomatis. Di bare-metal, tidak ada yang melakukan keduanya — kalian harus memasang "direktori" sendiri. MetalLB adalah direktori itu: dia memegang daftar nomor (IP pool) dan mengumumkannya ke jaringan (L2/BGP advertisement).

#MetalLB vs Pendekatan Lain

#Cloud Load Balancer

Di AWS, GCP, dan Azure, type: LoadBalancer langsung memicu pembuatan ELB/ALB atau load balancer regional. Masalahnya: mekanisme ini tidak tersedia untuk cluster di luar cloud tersebut. MetalLB tidak menggantikan cloud load balancer — dia mengisi kekosongan di lingkungan yang tidak memilikinya.

#NodePort

NodePort bisa meng-expose Service di port tertentu di setiap node. Namun dia memiliki keterbatasan: port harus berupa angka spesifik, satu Service sulit dibedakan dari yang lain, dan tidak ada IP dedicated per Service. externalTrafficPolicy: Local bisa membantu, tapi tetap bukan pengganti LoadBalancer yang sesungguhnya.

#kube-vip

kube-vip adalah pendekatan alternatif yang memakai protokol VRRP untuk memberikan VIP (virtual IP) pada node. Konsepnya berbeda: kube-vip umumnya menyediakan satu VIP per komponen (misalnya untuk control plane), sedangkan MetalLB mengelola pool IP yang luas untuk banyak Service LoadBalancer. Perbandingan mendalam akan kita bahas di episode 22.

Kondisi Service sebelum dan sesudah MetalLB

kubectl get svc nginx
kubectl apply -f ipaddresspool.yaml
kubectl get svc nginx

Baris pertama menampilkan EXTERNAL-IP <pending>, dan setelah konfigurasi MetalLB, baris terakhir menampilkan IP eksternal yang sebenarnya. Transformasi inilah yang akan kalian buktikan sendiri mulai episode 3.

#Evolusi dan Status Hari Ini

#Proyek CNCF yang Masih Aktif

Hingga penulisan series ini, MetalLB berada dalam status Incubating di CNCF, dengan komunitas yang aktif dan rilis reguler. Dokumentasi resmi di metallb.io, repository GitHub metallb/metallb, dan release notes menjadi sumber kebenaran yang akan kita rujuk sepanjang series ini.

#Mengapa Masih Relevan di 2026

Di tengah menjamurnya solusi jaringan seperti Cilium, Calico, atau layanan managed Kubernetes on-premise, pertanyaan "apakah MetalLB masih dibutuhkan?" sering muncul. Jawabannya: ya, karena MetalLB menyelesaikan satu masalah yang sangat spesifik — menyediakan IP eksternal untuk Service LoadBalancer — dengan cara yang sederhana, teruji, dan bisa berjalan di hampir semua cluster, apa pun CNI-nya.

Perlu juga dicatat bahwa banyak solusi CNI canggih memang menawarkan fitur load balancer sendiri. Namun pilihan tersebut biasanya mengikat kalian pada satu vendor CNI. MetalLB justru menjadi lapisan yang independen: bisa dipasang di atas Cilium, Calico, Flannel, atau CNI lainnya tanpa mengubah cara kerja jaringan yang sudah ada. Fleksibilitas inilah yang membuat MetalLB tetap relevan di lanskap yang terus berubah.

#Penutup

Episode 1 memberi kalian konteks: MetalLB lahir dari kebutuhan cluster bare-metal yang tidak memiliki load balancer cloud-native, tumbuh dari proyek di Google Cloud menjadi project CNCF, dan hari ini berada di versi stabil v0.16.x.

Inti yang harus dibawa pulang:

MetalLB dibuat oleh David Anderson di Google Cloud pada 2017, lalu menjadi project CNCF.
Tugas utamanya ada dua: men-assign IP eksternal dan meng-announce IP ke jaringan.
Tanpa MetalLB, Service LoadBalancer akan selamanya menunjukkan EXTERNAL-IP <pending>.
Cloud LB, NodePort, dan kube-vip adalah pendekatan yang berbeda dengan trade-off masing-masing.
v0.16.x adalah release stabil saat ini; v0.15 sudah end of life sejak Mei 2026.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur utama MetalLB — bagaimana controller mengalokasikan IP, bagaimana speaker meng-announce IP di tiap node, dan peran empat CRD utama yang akan menemani kalian sepanjang series ini. Pemahaman arsitektur ini akan membuat seluruh konfigurasi berikutnya jauh lebih masuk akal.