Belajar MetalLB - Service LoadBalancer Pertama

#Pendahuluan

Setelah lima episode teori dan konfigurasi, akhirnya tiba momen yang paling memuaskan: membuat Service LoadBalancer pertama yang benar-benar mendapat IP eksternal dari MetalLB. Di episode 7 ini kalian akan men-deploy aplikasi, meng-expose lewat Service bertipe LoadBalancer, memverifikasi IP yang di-assign, dan menguji akses dari luar cluster.

Sama pentingnya, episode ini mengajarkan troubleshooting dasar. Masalah seperti IP tidak ter-assign, advertisement tidak tampil, atau konflik IP adalah tiga hal yang paling sering membuat pemula bingung. Setelah episode ini, kalian akan punya pola pikir diagnosis yang benar.

#Deploy Aplikasi dan Service LoadBalancer

#Membuat Deployment dan Service

Mulai dengan aplikasi sederhana. Kita akan memakai Nginx sebagai contoh, lalu meng-expose-nya lewat Service bertipe LoadBalancer:

kubectl create deployment nginx --image=nginx:alpine
kubectl expose deployment nginx --type=LoadBalancer --port=80 --target-port=80

kubectl expose deployment nginx --type=LoadBalancer --port=80 membuat Service bertipe LoadBalancer yang memakai port 80. Controller MetalLB akan menonton Service ini dan mengalokasikan IP dari pool — tentu saja jika pool Layer 2 dari episode 3 masih aktif.

#Manifes Service sebagai Alternatif

Bagi kalian yang lebih suka manifests, bentuk YAML-nya seperti ini:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

Tidak peduli cara mana yang dipakai, hasilnya sama: Service dengan spec.type: LoadBalancer yang siap menerima IP eksternal.

#Verifikasi IP Eksternal

#Membaca Status Service

Tunggu beberapa detik, lalu periksa apakah controller sudah mengalokasikan IP:

kubectl get svc nginx
kubectl get svc nginx -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Output kubectl get svc nginx harus menampilkan kolom EXTERNAL-IP berisi 192.168.1.200 (atau IP pertama dari pool kalian), bukan lagi <pending>. Perintah jsonpath kedua menampilkan IP tersebut dari status Service secara langsung.

#Mengamati Proses Alokasi

Untuk melihat prosesnya secara detail, baca events:

kubectl describe svc nginx

Di bagian Events, kalian akan melihat pesan seperti Allocated IP 192.168.1.200 dari komponen MetalLB. Ini adalah konfirmasi bahwa controller bekerja sebagaimana mestinya.

#Uji Akses dari Luar Cluster

#Mengakses IP Eksternal

Sekarang uji dari mesin di luar cluster yang berada dalam jaringan yang sama. Jika mode yang dipakai Layer 2, mesin tersebut harus satu subnet dengan IP MetalLB:

curl http://192.168.1.200
ping -c 3 192.168.1.200

curl http://192.168.1.200 harus mengembalikan halaman Nginx default, dan ping -c 3 192.168.1.200 akan dibalas oleh node leader. Jika keduanya berhasil, Service LoadBalancer pertama kalian resmi berfungsi.

#Memeriksa Dari Mana Traffic Datang

Untuk memastikan traffic benar-benar lewat IP eksternal, lihat log pod:

kubectl logs -l app=nginx --tail=20

Log akan mencatat request yang masuk beserta source IP klien. Ini juga titik awal untuk memahami perbedaan externalTrafficPolicy yang akan kita bahas di episode 9.

#Troubleshooting Dasar

#IP Tidak Ter-Assign

Jika EXTERNAL-IP masih <pending> setelah beberapa detik, penyebab paling umum adalah:

• IPAddressPool belum dibuat atau salah nama.
• Pool habis — semua IP sedang dipakai Service lain.
• Service meminta annotation pool yang tidak ada.

Periksa dalam urutan berikut:

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

kubectl get events --field-selector involvedObject.name=nginx akan menampilkan pesan error dari controller, misalnya Failed to allocate IP beserta alasannya.

#Advertisement Tidak Tampil

Jika IP sudah ter-assign tetapi tidak bisa diakses dari luar, kemungkinan advertisement tidak aktif. Periksa resource advertisement dan log speaker:

kubectl get l2advertisement
kubectl get bgpadvertisement
kubectl logs -n metallb-system -l component=speaker --tail=50

kubectl get l2advertisement harus menampilkan advertisement yang mereferensikan pool IP kalian. Jika tidak ada, Service di-announce lewat apa pun. Log speaker menampilkan apakah announcement berhasil atau ada error jaringan.

#Konflik IP

Jika akses dari luar bekerja tidak konsisten, bisa jadi IP bentrok dengan perangkat lain di jaringan. Gejala khasnya: kadang masuk ke aplikasi kalian, kadang ke perangkat lain. Solusinya: pilih blok IP yang benar-benar bebas (ingat episode 0), atau aktifkan avoidBuggyIPs untuk menghindari alamat bermasalah.

#Penutup

Episode 7 memberi kalian kemenangan pertama yang terukur: aplikasi berjalan, Service mendapat IP eksternal dari pool, dan bisa diakses dari luar cluster. Kalian juga sudah punya pola diagnosis untuk tiga masalah paling umum di awal penggunaan MetalLB.

Inti yang harus dibawa pulang:

• kubectl expose deployment nginx --type=LoadBalancer membuat Service LoadBalancer dalam satu langkah.
• IP eksternal muncul di EXTERNAL-IP dan bisa dicek lewat kubectl get svc nginx.
• Uji akses dari luar cluster dengan curl ke IP eksternal.
• IP <pending> berarti controller gagal mengalokasikan — cek pool, kapasitas, dan events.
• Advertisement yang tidak tampil biasanya karena L2Advertisement atau BGPAdvertisement tidak ada.
• Konflik IP adalah penyebab gejala akses yang tidak konsisten.

Di episode 8 selanjutnya kita akan membahas kustomisasi advertisement — opsi interfaces dan nodeSelectors pada L2Advertisement, serta communities, aggregationLength, dan localPref pada BGPAdvertisement, lengkap dengan cara menggunakan multiple advertisements untuk kebutuhan yang berbeda.