Belajar MetalLB - Performance & Troubleshooting

#Pendahuluan

Semua pengetahuan MetalLB kalian akhirnya bermuara pada satu pertanyaan praktis: apa yang dilakukan ketika Service tidak bisa diakses? Episode 19 menyusun metode diagnostik yang terstruktur — bukan kumpulan trik acak, melainkan alur yang berurutan dari yang paling cepat sampai yang paling dalam.

Metode yang benar menghemat berjam-jam. Diagnosis dimulai dari permukaan (status Service), naik ke tingkat jaringan (advertisement dan routing), dan berakhir di log serta metric. Episode ini juga membahas masalah umum yang berulang di komunitas, termasuk migrasi v0.15 ke v0.16 yang sering mengejutkan.

#Diagnostik Dasar: Status Service

#Langkah Pertama yang Selalu Diulang

Mulai dari tempat termudah: status Service. Alur ini hampir selalu menjadi pembuka diagnosis:

kubectl get svc nginx
kubectl get svc nginx -o wide

kubectl get svc nginx -o wide menampilkan TYPE, EXTERNAL-IP, dan port. Pertanyaan pertama yang harus kalian jawab: apakah EXTERNAL-IP sudah terisi? Jika ya, masalah ada di level advertisement; jika masih <pending>, masalah ada di level alokasi IP.

#Membaca Describe dan Events

Jika IP tidak terisi, kubectl describe svc memberi petunjuk paling jelas:

kubectl describe svc nginx
kubectl get events --field-selector involvedObject.name=nginx

kubectl get events --field-selector involvedObject.name=nginx menampilkan pesan seperti Allocated IP 192.168.1.200 atau Failed to allocate IP. Pesan ini menentukan arah diagnosis selanjutnya.

#Diagnostik Lanjutan: Log dan Routing

#Log Speaker dan Controller

Jika status Service baik tetapi akses gagal, pindah ke komponen MetalLB:

kubectl logs -n metallb-system -l component=speaker --tail=50
kubectl logs -n metallb-system -l component=controller --tail=50

kubectl logs -n metallb-system -l component=speaker --tail=50 menampilkan baris announcement atau error peering BGP. Log controller menampilkan keputusan alokasi. Dua log ini menjawab pertanyaan "apakah speaker sudah meng-announce?" dan "apakah controller sudah mengalokasikan?".

#Cek Route BGP di Router

Untuk mode BGP, sisi router adalah saksi terakhir:

show ip bgp
show ip bgp neighbors

show ip bgp menampilkan prefix yang diterima dari MetalLB. Jika prefix tidak ada, cek show ip bgp neighbors untuk memeriksa status sesi peering — dari situlah masalah peering yang gagal biasanya terlihat.

#Masalah Umum dan Solusinya

#IP Tidak Ter-Assign

Penyebab paling sering: pool tidak ada, pool penuh, atau Service meminta annotation pool yang salah. Periksa dalam urutan:

kubectl get ipaddresspool
kubectl get svc -A
kubectl describe svc nginx

Jika pool ada dan tidak penuh, periksa events Service untuk pesan error spesifik dari controller.

#Dua Service Ber-IP Sama

MetalLB tidak akan memberi dua Service IP yang sama dari pool yang sama. Jika dua Service tampak ber-IP sama, kemungkinan besar keduanya mengambil IP dari pool yang berbeda yang saling tumpang tindih. Periksa definisi semua pool:

kubectl get ipaddresspool -o yaml

kubectl get ipaddresspool -o yaml menampilkan seluruh definisi pool. Cari rentang yang tumpang tindih antar pool — inilah penyebab duplikasi yang paling umum.

#L2 Tidak Di-Announce

IP ter-assign tapi tidak bisa diakses lewat Layer 2. Periksa:

• Apakah L2Advertisement mereferensikan pool yang benar?
• Apakah node leader meng-announce lewat interface yang benar (episode 8)?
• Apakah IP berada dalam subnet yang sama dengan klien?

#BGP Tidak Establish

Jika show ip bgp neighbors menampilkan sesi yang tidak pernah Established, periksa:

• Konektivitas TCP ke port 179 (episode 13).
• Kecocokan ASN antara myASN dan peerASN.
• Firewall yang memblokir antara node dan router.
• Konfigurasi multiHop jika peer berada di luar subnet.

#Upgrade v0.15 ke v0.16

Masalah yang sering muncul saat upgrade antar versi mayor:

• Field CRD yang berubah — baca release notes terlebih dahulu.
• CRD lama yang tidak kompatibel dengan versi baru.
• Perilaku default yang berubah.

Cara amannya: upgrade di staging, periksa status semua resource dengan kubectl get, lalu barulah upgrade produksi. Selalu simpan manifests versi lama untuk rollback.

#Performance: Apa yang Perlu Dipantau

#Titik Pemantauan Utama

Beberapa indikator performa yang paling berguna:

• Pemakaian pool (metallb_allocator_addresses_in_use_total).
• Status sesi BGP (metallb_bgp_session_up).
• Jumlah prefix yang di-announce per speaker.
• Latensi akses dari luar cluster ke Service.

curl -s -o /dev/null -w "%{time_total}\n" http://192.168.1.200

curl -s -o /dev/null -w "%{time_total}\n" http://192.168.1.200 mengukur total waktu respons. Catat nilai ini sebagai baseline dan bandingkan saat performa mencurigakan.

#Penutup

Episode 19 menuntaskan performance & troubleshooting: alur diagnostik dari status Service, log komponen, hingga route di router, plus penanganan enam masalah umum yang paling sering dialami pengguna MetalLB.

Inti yang harus dibawa pulang:

• Mulai diagnosis dari kubectl get svc dan kubectl describe svc.
• kubectl get events menampilkan pesan alokasi atau kegagalan dari controller.
• Log speaker menjawab pertanyaan tentang announcement dan peering.
• show ip bgp dan show ip bgp neighbors adalah saksi dari sisi router.
• Duplikasi IP hampir selalu berasal dari pool yang tumpang tindih.
• Upgrade v0.15 ke v0.16 wajib diuji di staging terlebih dahulu.

Di episode 20 selanjutnya kita akan membahas fitur stabil terbaru v0.16.x — penyempurnaan CRD v1beta2, manajemen pool dan observability, perbaikan BGP dan Layer 2, serta pentingnya upgrade karena v0.15 sudah end of life sejak Mei 2026.