Belajar MetalLB - Production-Ready Architecture

#Pendahuluan

Setelah 20 episode teori, praktik, dan troubleshooting, tiba saatnya merangkai semuanya menjadi satu kesatuan: arsitektur MetalLB yang siap produksi. Episode 21 bukan tentang satu fitur baru, melainkan tentang keputusan desain — perencanaan pool, pilihan mode, integrasi router, high availability, strategi upgrade, pipeline GitOps, observability, sizing, dan runbook insiden.

Arsitektur produksi yang baik tidak muncul dari satu konfigurasi yang "benar". Dia muncul dari keputusan yang diambil dengan pemahaman terhadap trade-off — persis yang sudah kalian pelajari di sepanjang series ini. Episode ini adalah cetak biru lengkapnya.

#Perencanaan Pool IP

#Memilih Blok dan Struktur

Perencanaan pool adalah langkah pertama yang tidak boleh terburu-buru. Rekomendasi untuk produksi:

• Pilih blok IP yang terpisah dari subnet infrastruktur.
• Sediakan buffer minimal 20 persen di atas kebutuhan saat ini.
• Pisahkan pool per lingkungan dan fungsi (episode 9 dan 17).
• Dokumentasikan pemetaan subnet ke fungsi di konfigurasi.

Contoh konfigurasi produksi:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: prod-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.20.0/24
  avoidBuggyIPs: true

192.168.20.0/24 menyediakan lebih dari 200 IP yang bisa dipakai — cukup untuk sebagian besar kebutuhan awal, dengan avoidBuggyIPs: true menghindari alamat bermasalah.

#Memilih Mode: Layer 2 vs BGP

#Keputusan Berbasis Kebutuhan

Pemilihan mode adalah keputusan arsitektur terbesar. Panduannya:

• Pilih Layer 2 jika jaringan sederhana, tanpa router BGP, dan throughput per Service tidak terlalu besar.
• Pilih BGP jika cluster punya banyak node, butuh ECMP untuk menyebar traffic, dan tim jaringan siap mengelola peering.

kubectl get l2advertisement
kubectl get bgpadvertisement
kubectl get bgppeer

kubectl get l2advertisement, kubectl get bgpadvertisement, dan kubectl get bgppeer menunjukkan mode mana yang aktif. Cluster bisa menjalankan keduanya sekaligus — satu pool di-announce L2, pool lain lewat BGP.

#Integrasi Router dan High Availability

#Router sebagai Bagian dari Desain

Untuk mode BGP, integrasi router adalah proyek bersama dengan tim jaringan. Pastikan:

• Peering ganda ke minimal dua router (episode 13).
• routerID eksplisit untuk setiap node.
• Hold time yang wajar — tidak terlalu agresif.
• Prefix yang di-advertise sesuai kebijakan network team.

#High Availability Menyeluruh

High availability MetalLB hanya berarti jika lapisan di bawahnya juga HA:

• Minimal dua node yang siap meng-announce.
• Replica controller lebih dari satu untuk ketersediaan alokasi.
• externalTrafficPolicy: Local dengan replica pod tersebar (episode 9).
• Simulasi failover terjadwal (episode 15).

#Upgrade Strategy dan Pipeline GitOps

#Strategi Upgrade

Strategi upgrade yang aman untuk produksi:

• Semua konfigurasi dikelola lewat GitOps (episode 18).
• Upgrade dilakukan di staging lebih dulu, dipantau beberapa hari.
• Verifikasi status resource dan Service setelah upgrade.
• Siapkan rollback dengan version control.

#Pipeline GitOps

Argo CD atau Flux menerapkan konfigurasi secara otomatis dari repository. Praktik yang disarankan:

• Satu repository per lingkungan atau satu repository dengan overlay.
• CI menjalankan validasi YAML sebelum merge.
• Pemisahan peran: siapa yang boleh mengubah pool, peer, dan advertisement.

#Observability dan Sizing

#Stack Observability

Pantau MetalLB dengan stack yang sudah kalian bangun di episode 11:

• Prometheus untuk metric dan alert.
• Grafana dashboard untuk visualisasi.
• Alert penting: pemakaian pool di atas 80 persen, sesi BGP turun, speaker berkurang.

kubectl get pods -n metallb-system
kubectl top pods -n metallb-system

kubectl top pods -n metallb-system menampilkan pemakaian CPU dan memori. Data ini menjadi dasar sizing: pastikan resource request controller dan speaker sesuai beban, terutama di cluster dengan banyak Service dan node.

#Sizing yang Realistis

Sebagai titik awal: controller tidak butuh banyak resource — ia hanya memproses alokasi. Speaker berbagi beban per node. Jika metric menunjukkan throttling atau OOM, naikkan resource limit — tetapi ukur dulu, jangan menebak.

#Runbook Insiden

#Dokumen yang Membuat Operasional Tenang

Runbook insiden adalah dokumen yang menjelaskan langkah konkret saat masalah terjadi. Untuk MetalLB, isi runbook mencakup:

• Gejala umum dan langkah diagnosis pertama (episode 19).
• Kontak yang harus dihubungi — platform dan network engineer.
• Langkah mitigasi sementara dan permanen.
• Prosedur rollback konfigurasi.

kubectl get svc -A -o wide
kubectl get events --all-namespaces | grep -i metallb

kubectl get events --all-namespaces | grep -i metallb adalah langkah pembuka yang hampir selalu ditulis di runbook — cepat, dan sering langsung mengungkap akar masalah. Latih runbook ini dalam simulasi insiden agar tim terbiasa.

#Penutup

Episode 21 menuntaskan production-ready architecture: perencanaan pool, pemilihan mode, integrasi router, high availability, strategi upgrade, pipeline GitOps, observability, sizing, dan runbook insiden — semua dirangkai menjadi satu arsitektur yang utuh.

Inti yang harus dibawa pulang:

• Pool produksi dipisahkan per lingkungan dengan buffer kapasitas.
• Layer 2 untuk jaringan sederhana; BGP untuk skala dan ECMP.
• Peering ganda, routerID eksplisit, dan hold time wajar untuk HA BGP.
• Upgrade selalu lewat staging dan pipeline GitOps.
• Alert untuk pemakaian pool, sesi BGP, dan jumlah speaker.
• Runbook insiden menjabarkan gejala, diagnosis, mitigasi, dan rollback.

Di episode 22 selanjutnya — episode terakhir — kita akan membahas ekosistem alternatif & refleksi akhir: perbandingan menyeluruh MetalLB versus kube-vip, cloud LBs, dan NodePort, kapan memilih masing-masing, rekap perjalanan episode 0 sampai 21, checklist MetalLB production-grade, dan arah masa depan MetalLB di ekosistem Kubernetes.