Belajar MetalLB - IP Planning & Network Scale

#Pendahuluan

IP eksternal adalah sumber daya yang paling langka di cluster bare-metal. Setiap Service LoadBalancer meminjam satu IP dari pool, dan ketika pool kosong, Service baru tidak akan pernah mendapat IP — gejalanya: EXTERNAL-IP yang tak kunjung terisi. Episode 17 membahas IP planning & network scale: menghitung kebutuhan, memahami batas ARP dan BGP, merancang strategi pool besar, dan menghindari kehabisan IP serta fragmentasi alokasi.

Perencanaan IP yang baik dilakukan sekali dan menghemat bertahun-tahun operasional. Perencanaan yang buruk memaksa kalian membangun ulang pool di tengah produksi — pengalaman yang tidak menyenangkan. Mari lakukan dengan benar sejak awal.

#Kapasitas: Jumlah Service versus Jumlah IP

#Menghitung Kebutuhan

Setiap Service LoadBalancer memakai satu IP dari pool. Rumus kebutuhan dasarnya sederhana:

• Jumlah IP di pool = kapasitas maksimum Service LoadBalancer secara simultan.
• Tambahkan buffer untuk pertumbuhan dan pemeliharaan.

Contoh: pool 192.168.20.200-192.168.20.240 menyediakan 41 IP, cukup untuk sekitar 41 Service sekaligus. Jika kalian berencana 100 Service, butuh lebih dari 100 IP — karena pemeliharaan dan eksperimen juga memakai IP.

#Memantau Kapasitas Secara Terus-Menerus

Jangan menebak kapan pool hampir penuh — pantau dengan metric dari episode 11:

kubectl get svc -A -o wide | wc -l
kubectl get ipaddresspool

kubectl get svc -A -o wide | wc -l memberi gambaran jumlah Service; bandingkan dengan kapasitas total pool. Untuk angka yang presisi, pakai metric Prometheus metallb_allocator_addresses_in_use_total dibanding metallb_allocator_addresses_total per pool.

#Batas ARP dan BGP

#Keterbatasan Layer 2

Di Layer 2 mode, satu node leader menangani semua traffic untuk sebuah IP. Semakin banyak Service yang leader-nya jatuh di node yang sama, semakin besar beban node itu. Selain itu, setiap IP di-announce lewat ARP — semakin banyak IP, semakin banyak traffic broadcast ARP di jaringan. Pada skala tertentu, batas ini bukan di MetalLB melainkan di kemampuan node dan switch.

#Keterbatasan BGP

Di BGP mode, setiap IP yang tidak di-agregasi diiklankan sebagai route /32. Seribu Service berarti seribu route di tabel routing router. Ini tetap dianggap wajar untuk router modern, tetapi menimbulkan dua risiko:

• Tabel routing membengkak seiring pertumbuhan.
• Konvergensi (perhitungan ulang route) melambat saat jaringan berubah.

Solusinya adalah agregasi prefix (aggregationLength dari episode 8 dan 16): dengan agregasi, ratusan IP diiklankan sebagai satu prefix.

show ip bgp | wc -l

show ip bgp | wc -l di router menampilkan jumlah baris route yang diterima. Jika angka ini membengkak seiring Service bertambah, pertimbangkan agregasi lebih agresif atau pemisahan pool.

#Strategi Pool Besar

#Satu Pool Besar vs Banyak Pool Kecil

Dua pendekatan untuk skala besar:

• Satu pool besar: sederhana, tetapi semua Service berbagi satu kumpulan IP tanpa pemisahan lingkungan.
• Banyak pool kecil: memisahkan lingkungan, departemen, atau segmen jaringan — jauh lebih terkontrol dan mudah di-audit.

Untuk produksi, banyak pool kecil hampir selalu lebih baik. Pemilihan pool per Service memakai annotation yang sudah kita bahas di episode 9.

#Contoh Strategi Pool

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: apps-pool
  namespace: metallb-system
spec:
  addresses:
    - 10.0.20.0/24
---
apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: infra-pool
  namespace: metallb-system
spec:
  addresses:
    - 10.0.30.0/24

apps-pool dan infra-pool memisahkan IP aplikasi dari IP infrastruktur. Pemetaan fungsi-ke-subnet seperti ini membuat alokasi IP mudah diprediksi hanya dengan melihat alamatnya — sangat membantu saat troubleshooting.

#Menghindari IP Exhaustion dan Fragmentasi

#Fragmentasi Alokasi

IP yang dibebaskan (setelah Service dihapus) bisa meninggalkan lubang di pool. Jika controller selalu mengalokasikan IP pertama yang bebas, pool dengan banyak alokasi dan de-alokasi bisa menjadi terfragmentasi — sulit untuk mengenali pola atau menerapkan agregasi yang efisien.

Mitigasi: tetapkan blok IP per fungsi secara disiplin, hindari mencampur banyak fungsi dalam satu pool, dan secara berkala pantau pemakaian untuk mendeteksi pola aneh.

#Mencegah Kehabisan IP

Kehabisan IP bukan krisis yang mendadak — biasanya bisa diprediksi. Cara mencegahnya:

• Pantau metallb_allocator_addresses_in_use_total per pool dengan alert di ambang tertentu, misalnya 80 persen.
• Lakukan review kapasitas rutin terhadap rencana pertumbuhan Service.
• Siapkan pool cadangan di subnet yang belum dipakai sebelum pool utama penuh.
• Pertimbangkan externalTrafficPolicy dan Ingress (episode 12) untuk mengurangi pemakaian IP per aplikasi.

#Kapasitas yang Disarankan

Sebagai patokan awal: siapkan pool dengan buffer minimal 20 persen di atas kebutuhan saat ini, dan rencanakan subnet tambahan sebelum pool utama mencapai 80 persen pemakaian. Angka ini memberi waktu untuk perencanaan tanpa menunggu krisis.

#Penutup

Episode 17 menuntaskan IP planning & network scale: menghitung kapasitas, memahami batas ARP dan BGP, merancang strategi banyak pool, serta mencegah kehabisan IP dan fragmentasi alokasi.

Inti yang harus dibawa pulang:

• Satu Service LoadBalancer memakai satu IP — hitung kapasitas dari jumlah Service.
• Batas Layer 2 ada di beban node leader dan traffic ARP.
• Batas BGP ada di ukuran tabel routing; kurangi dengan agregasi prefix.
• Banyak pool kecil lebih mudah dikelola daripada satu pool besar.
• Alert di 80 persen pemakaian pool untuk mencegah kehabisan IP.
• Pantau metallb_allocator_addresses_in_use_total secara rutin.

Di episode 18 selanjutnya kita akan membahas GitOps & config as code — mengelola IPAddressPool, advertisement, dan BGPPeer sebagai code di repository, penerapan dengan Argo CD dan Flux, versioning konfigurasi, review flow, serta penerapan perubahan secara bertahap.