Belajar MetalLB - High Availability & Failover

#Pendahuluan

Cluster yang baik tidak hanya harus berfungsi — dia harus tetap berfungsi ketika satu komponen mati. Episode 15 membahas high availability & failover MetalLB: apa yang terjadi pada announcement ketika sebuah node mati, seberapa cepat Service pulih, dan bagaimana desain yang berbeda (Layer 2 versus BGP) menangani kegagalan.

Konteks yang perlu diingat: MetalLB tidak menangani traffic itu sendiri. Dia hanya mengarahkan jaringan ke node yang tepat. Karena itu "failover" di sini berarti memastikan announcement tetap akurat ketika topology berubah. Memahami mekanisme ini menentukan seberapa ketat SLA yang bisa kalian janjikan.

#Leader Election dan Failover Layer 2

#Bagaimana Leader Terpilih

Di Layer 2 mode, untuk setiap IP Service, para speaker memilih satu leader melalui proses election yang tersebar. Hasilnya bisa dilihat di log speaker. Leader inilah yang menjawab ARP/NDP untuk IP tersebut.

kubectl get pods -n metallb-system -o wide
kubectl logs -n metallb-system -l component=speaker --tail=50 | grep -i announcing

kubectl logs -n metallb-system -l component=speaker --tail=50 | grep -i announcing menampilkan baris seperti Announcing 192.168.1.200 from node worker-1 — inilah node yang menjadi leader untuk IP tersebut.

#Failover Saat Node Leader Mati

Ketika node leader mati, speaker lain mendeteksi bahwa node tersebut tidak lagi menanggapi election dan satu node baru terpilih sebagai leader. Node baru langsung mengirim gratuitous ARP untuk memperbarui cache perangkat di jaringan.

kubectl drain worker-2 --ignore-daemonsets --delete-emptydir-data
kubectl get pods -n metallb-system -o wide
kubectl logs -n metallb-system -l component=speaker --tail=20

kubectl drain worker-2 --ignore-daemonsets --delete-emptydir-data mengosongkan node untuk simulasi pemeliharaan. Setelah itu, log speaker menampilkan announcement yang berpindah ke node lain. Failover Layer 2 biasanya memakan waktu beberapa detik — deteksi kegagalan ditambah pengumuman ARP baru.

#Perilaku ARP Selama Failover

Perangkat klien menyimpan IP-to-MAC di cache ARP mereka. Saat leader berpindah, cache lama masih menunjuk ke MAC node yang mati. Gratuitous ARP dari leader baru memperbarui cache, tetapi klien dengan cache agresif bisa menahan alamat lama beberapa detik. Hasilnya, sebagian koneksi pendek bisa terputus selama window ini — pertimbangkan ini saat merancang aplikasi dengan sesi yang panjang.

#High Availability BGP: ECMP Multi-Node

#Semua Node Mengiklankan Prefix yang Sama

Berbeda dengan Layer 2, di mode BGP semua node mengiklankan prefix yang sama ke router. Ketika sebuah node mati, sesi BGP-nya terputus dan router membuang jalur tersebut dari tabel routing, lalu meneruskan traffic lewat node lain yang masih hidup — tanpa perlu proses election.

show ip bgp 192.168.1.200
show ip route 192.168.1.200

show ip bgp 192.168.1.200 di router menampilkan banyak jalur menuju prefix yang sama — bukti ECMP aktif. Ketika satu jalur mati, router otomatis menghitung ulang tanpa campur tangan manual.

#Keuntungan BGP untuk HA

• Failover lebih cepat dan lebih bersih — router berkomunikasi langsung lewat BGP.
• Tidak ada ketergantungan pada update ARP cache klien.
• Beban traffic tersebar ke banyak node selama semua jalur sehat.

#Path Monitoring dan Kegagalan Peer

#Bagaimana Router Menilai Kesehatan

BGP menjaga sesi lewat hold time: jika router tidak menerima keepalive dari peer dalam batas waktu, sesi dianggap mati dan jalur dibuang. Nilai holdTime di BGPPeer mengontrol agresivitas deteksi ini:

apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: core-a
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64512
  peerAddress: 192.168.1.1
  holdTime: 30s

holdTime: 30s membuat kegagalan peer terdeteksi lebih cepat dibanding default 90 detik. Trade-off-nya: hold time yang terlalu agresif bisa menyebabkan flapping jika jaringan tidak stabil. Mulai dari nilai default, lalu turunkan bertahap sambil memantau stabilitas.

#Menguji Kegagalan Peer

Untuk menguji bagaimana cluster merespons kegagalan peer, matikan salah satu router peer:

kubectl get bgppeer
kubectl logs -n metallb-system -l component=speaker --tail=30 | grep -i bgp

kubectl get bgppeer menampilkan status peer; kubectl logs -n metallb-system -l component=speaker --tail=30 | grep -i bgp menampilkan log sesi yang tertutup. Selama masih ada satu peer yang hidup, route tetap sampai ke jaringan — inilah nilai dari konfigurasi multi-peer di episode 13.

#Praktik: Menyiapkan HA yang Benar

#Checklist Ketersediaan Tinggi

Untuk mencapai high availability yang nyata, pastikan:

• Ada lebih dari satu node yang bisa meng-announce IP.
• Di mode L2, cluster memiliki minimal dua node dan speaker berjalan di semuanya.
• Di mode BGP, semua node di-peer-kan ke minimal dua router.
• externalTrafficPolicy: Local dan replica pod tersebar di banyak node (ingat episode 9).
• Alert terpasang untuk kegagalan sesi BGP dan pengurangan jumlah speaker.

#Simulasi Uji Rutin

Failover tidak bisa diuji sekali lalu dilupakan. Jadwalkan simulasi: drain satu node, amati perpindahan announcement, dan catat waktu pemulihan. Ini sekaligus melatih runbook yang akan kita bahas di episode 21.

#Penutup

Episode 15 menuntaskan high availability & failover: leader election dan failover Layer 2 dengan keterbatasan cache ARP, serta keunggulan BGP dengan ECMP multi-node dan path monitoring yang otomatis.

Inti yang harus dibawa pulang:

• Layer 2 memilih satu leader per IP; node baru di-announce lewat gratuitous ARP saat leader mati.
• Failover Layer 2 memakan waktu beberapa detik dan bergantung pada cache ARP klien.
• BGP mengiklankan prefix dari semua node; router menghitung ulang jalur saat node mati.
• holdTime mengontrol kecepatan deteksi kegagalan peer.
• Multi-peer (episode 13) adalah kunci redundancy jalur BGP.
• Simulasi failover rutin adalah cara terbaik menjaga kesiapan operasional.

Di episode 16 selanjutnya kita akan membahas advanced BGP — penggunaan communities untuk tagging route, local preference, agregasi prefix, peering multi-hop ke router luar, serta topologi route reflector untuk jaringan yang lebih besar.