Belajar MetalLB - Validating Admission & CRD

#Pendahuluan

Salah satu penyebab frustrasi saat memakai MetalLB adalah konfigurasi yang kelihatannya benar tetapi diam-diam ditolak. Kabar baiknya, MetalLB memiliki lapisan pertahanan: validating admission controller yang dijalankan oleh metallb-controller. Setiap IPAddressPool, BGPPeer, dan advertisement yang kalian apply diperiksa keabsahannya sebelum benar-benar disimpan di cluster.

Episode 10 membedah mekanisme ini: bagaimana webhook bekerja, bagaimana membaca error yang ditolak, bagaimana CRD MetalLB berevolusi dari v1beta1 ke v1beta2, dan best practice saat meng-upgrade MetalLB agar tidak merusak konfigurasi yang sudah ada.

#Validating Admission Controller

#Bagaimana Webhook Bekerja

Ketika kalian menjalankan kubectl apply pada resource MetalLB, permintaan diteruskan ke Kubernetes API server. Sebelum disimpan, API server memanggil validating webhook yang dijalankan oleh controller. Webhook ini mengecek apakah konfigurasi valid — misalnya apakah rentang IP berbentuk benar, apakah ASN dalam jangkauan yang sah, dan apakah referensi antar resource konsisten.

Jika valid, resource disimpan. Jika tidak, request ditolak dan kalian menerima error. Webhook ini bisa dilihat di cluster:

kubectl get validatingwebhookconfiguration
kubectl get validatingwebhookconfiguration metallb-webhook-configuration -o yaml

kubectl get validatingwebhookconfiguration metallb-webhook-configuration menampilkan webhook bawaan MetalLB, lengkap dengan resource yang divalidasi dan aturan mutasi yang berlaku.

#Coba Kirim Konfigurasi Salah

Untuk merasakan bagaimana error handling bekerja, kirim konfigurasi yang sengaja salah — misalnya pool dengan format rentang yang tidak valid:

kubectl apply -f - <<EOF
apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: broken-pool
  namespace: metallb-system
spec:
  addresses:
    - not-an-ip
EOF

API server akan menolak dengan pesan seperti The IPAddressPool "broken-pool" is invalid beserta detail alasan penolakan dari webhook. Error semacam ini menyelamatkan kalian dari konfigurasi rusak yang bisa memicu perilaku aneh di jaringan.

#Error Handling Konfigurasi

#Membaca Pesan Penolakan

Pesan penolakan dari webhook biasanya menjelaskan field mana yang bermasalah dan mengapa. Contoh pola error yang umum:

• Rentang IP dalam format salah: addresses: not-an-ip ditolak karena bukan IP valid.
• Duplikasi IP antar pool: webhook mendeteksi dua pool mengklaim IP yang sama.
• ASN di luar jangkauan: myASN atau peerASN harus dalam rentang valid BGP (1-4294967295).

kubectl get ipaddresspool -A
kubectl describe ipaddresspool broken-pool

kubectl describe ipaddresspool broken-pool pada resource yang sempat tersimpan menampilkan status dan kondisi yang menjelaskan mengapa resource tidak berfungsi normal.

#Validasi Referensi Antar Resource

Selain format, webhook memvalidasi konsistensi referensi. Misalnya L2Advertisement yang mereferensikan pool dengan nama yang salah akan menghasilkan status yang menunjukkan bahwa pool tersebut tidak ditemukan. Perhatikan bahwa MetalLB sengaja mengizinkan referensi ke resource yang belum dibuat, sehingga urutan apply tidak kaku — tetapi status akan menandainya jika resource tak kunjung muncul.

#CRD Versioning: v1beta1 ke v1beta2

#Evolusi Versi API

Konfigurasi MetalLB pernah berupa ConfigMap, lalu berpindah ke CRD v1beta1 (mulai v0.13), dan sekarang memakai v1beta2 sebagai versi default dan stabil (mulai v0.14, disempurnakan di v0.16). Perhatikan bahwa IPAddressPool memakai metallb.io/v1beta2 sedangkan advertisement dan peer masih bisa ditulis dalam v1beta1:

kubectl get crd | grep metallb.io

kubectl get crd | grep metallb.io menampilkan semua Custom Resource MetalLB. Kolom versi pada output menunjukkan v1beta1 dan v1beta2 sebagai served versions — keduanya masih aktif sehingga manifests lama tetap bisa di-apply.

#Migrasi Antar Versi

Ketika MetalLB menambah versi CRD baru, versi lama umumnya tetap dilayani untuk beberapa waktu agar konfigurasi tidak rusak. Best practice saat migrasi:

• Baca release notes untuk memahami field yang berubah atau dihapus.
• Uji kubectl apply di cluster staging terlebih dahulu.
• Perbarui manifests satu per satu, mulai dari resource yang tidak saling bergantung.
• Verifikasi status dengan kubectl get sebelum menghapus versi API lama.

#Best Practice Upgrade MetalLB

#Persiapan Sebelum Upgrade

Upgrade MetalLB jarang berjalan mulus tanpa persiapan. Langkah-langkah berikut mengurangi risiko:

helm list -n metallb-system
kubectl get pods -n metallb-system
helm search repo metallb/metallb

helm search repo metallb/metallb menampilkan versi chart terbaru yang tersedia. Sebelum menaikkan versi, selalu bandingkan perubahan antara versi lama dan baru — terutama perubahan CRD, karena upgrade yang memaksa konversi versi API adalah sumber error paling umum.

#Jalur Upgrade yang Disarankan

• Upgrade dengan Helm (chart yang sama) agar RBAC dan webhook diperbarui bersama.
• Lakukan di cluster staging, verifikasi, lalu produksi.
• Jika memakai manifest, jangan gabungkan dua versi file secara acak — gunakan file resmi versi target.
• Pantau pod controller dan speaker setelah upgrade, lalu periksa CRD dan status pool.

helm upgrade metallb metallb/metallb --namespace metallb-system --version 0.16.1
kubectl get pods -n metallb-system

helm upgrade metallb metallb/metallb --version 0.16.1 akan menarik semua perubahan resource sekaligus. Setelah selesai, kubectl get pods -n metallb-system memastikan semua komponen kembali sehat.

#Penutup

Episode 10 menuntaskan mekanisme validasi dan versioning: webhook controller memvalidasi setiap konfigurasi sebelum disimpan, error ditolak dengan pesan yang bisa dibaca, CRD berevolusi dari v1beta1 ke v1beta2, dan upgrade dilakukan dengan langkah yang hati-hati.

Inti yang harus dibawa pulang:

• metallb-controller menjalankan validating webhook untuk semua resource MetalLB.
• Konfigurasi yang salah ditolak API server dengan pesan yang menjelaskan alasannya.
• Cek kubectl get validatingwebhookconfiguration untuk memastikan webhook aktif.
• CRD tersedia dalam v1beta1 dan v1beta2 sebagai served versions.
• Upgrade wajib diawali dengan membaca release notes dan menguji di staging.

Di episode 11 selanjutnya kita akan membahas observability & monitoring — metric Prometheus dari speaker dan controller, analisis events dan log untuk diagnosis, serta pemakaian Grafana dashboard untuk memantau alokasi IP dan status peering BGP secara visual.