Belajar MetalLB - IPAddressPool & IPAM

#Pendahuluan

Di episode 3 kalian membuat IPAddressPool pertama tanpa membahas detailnya. Episode 4 mengorek bagian yang paling penting dalam operasi sehari-hari MetalLB: IPAddressPool dan IPAM (IP Address Management). Di sinilah kalian menentukan dari mana IP eksternal berasal, berapa banyak yang tersedia, dan bagaimana controller mengelolanya.

IPAM yang salah bisa menimbulkan masalah yang sulit dilacak: dua Service memakai IP sama, IP bentrok dengan perangkat lain di jaringan, atau pool yang kosong tanpa alasan yang jelas. Memahami cara kerja pool akan membuat semua masalah ini bisa dicegah sejak awal.

#Mengenal IPAddressPool

#Mendefinisikan Rentang IP

Sebuah IPAddressPool bisa berisi satu atau banyak rentang, baik berupa range eksplisit maupun CIDR. Contoh berikut menggabungkan keduanya:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: mixed-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.200-192.168.1.220
    - 192.168.2.0/28
    - fd00:1::10-fd00:1::1f

Rentang 192.168.1.200-192.168.1.220 dan CIDR 192.168.2.0/28 adalah cara yang sah untuk menyatakan blok IPv4, dan rentang IPv6 juga didukung. MetalLB akan menghitung semua IP yang tercakup dan memakainya sebagai satu kumpulan alamat.

#Menuliskan IP Tunggal

Jika hanya butuh satu IP, kalian bisa menuliskannya sebagai range satu alamat: 192.168.1.200-192.168.1.200. Ini berguna untuk memberi IP khusus pada Service tertentu — teknik yang akan kita pakai lagi di episode 9 untuk seleksi Service.

#Opsi Alokasi: autoAssign dan avoidBuggyIPs

#autoAssign

Secara default, controller bebas mengambil IP dari pool mana pun yang tersedia. Opsi autoAssign: false membatasi pool agar hanya melayani Service yang secara eksplisit memintanya lewat annotation:

apiVersion: metallb.io/v1beta2
kind: IPAddressPool
metadata:
  name: reserved-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.1.250
  autoAssign: false

Pool dengan autoAssign: false tidak akan dipakai otomatis oleh Service. Service yang menginginkan IP dari pool ini harus menyebutkannya lewat annotation metallb.universe.tf/address-pool: reserved-pool.

#avoidBuggyIPs

Perangkat jaringan tertentu memiliki bug dengan bit terakhir dari subnet — terutama alamat yang diakhiri dengan .255 atau .0. Opsi avoidBuggyIPs: true membuat controller menghindari IP yang berakhiran 0 dan 255 di setiap /24:

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

avoidBuggyIPs: true pada CIDR 192.168.1.0/24 membuat pool ini hanya menawarkan IP 192.168.1.1 sampai 192.168.1.254, minus alamat jaringan dan broadcast. Jika jaringan kalian dipenuhi switch lama yang bermasalah, opsi ini penyelamat.

#Bagaimana Controller Mengalokasikan IP

#Proses Pemilihan IP

Ketika Service LoadBalancer dibuat, controller menontonnya dan mulai mencari IP. Logika pemilihannya sederhana namun penting:

• IP yang sudah dipakai Service lain tidak akan dipakai lagi.
• Pool dengan autoAssign: false dilewati kecuali Service memintanya secara eksplisit.
• Jika banyak pool tersedia, controller memilih salah satu dan mengambil IP pertama yang bebas.

Proses ini bisa diamati langsung lewat events Service:

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

kubectl get events --field-selector involvedObject.name=nginx akan menampilkan pesan seperti Allocated IP 192.168.1.200 yang ditulis oleh controller. Inilah bukti visual dari proses IPAM.

#Konflik IP

MetalLB melacak alokasi secara internal, sehingga dua Service tidak akan pernah mendapat IP yang sama dari pool yang sama. Konflik bisa terjadi jika IP tersebut di luar kontrol MetalLB — misalnya dipakai DHCP atau perangkat statis lain di jaringan. Oleh karena itu penting memilih blok IP yang benar-benar bebas, seperti yang kita siapkan di episode 0.

#Pembebasan IP Saat Service Dihapus

#Siklus Hidup Alokasi

IP bersifat ephemeral: selama Service ada, IP dipinjamkan; begitu Service dihapus, IP dikembalikan ke pool dan bisa dipakai Service lain. Verifikasinya mudah:

kubectl delete svc nginx
kubectl get svc -A
kubectl get ipaddresspool

Setelah kubectl delete svc nginx, event mencatat Deallocating IP 192.168.1.200. IP kembali tersedia untuk alokasi berikutnya — tidak ada langkah manual yang diperlukan.

#Pengamatan dengan Status

Untuk mengetahui IP mana yang sedang dialokasikan oleh pool tertentu, periksa Service di namespace tersebut:

kubectl get svc -A -o wide

Kolom EXTERNAL-IP pada kubectl get svc -A -o wide menampilkan semua IP yang sedang dipinjam dari pool. Membandingkannya dengan daftar alamat di pool akan menunjukkan berapa kapasitas yang tersisa — pembahasan yang akan kalian dalami di episode 17.

#Penutup

Episode 4 menuntaskan pemahaman IPAM MetalLB: cara mendefinisikan pool dengan range dan CIDR, opsi autoAssign dan avoidBuggyIPs, logika alokasi controller, serta siklus hidup IP dari peminjaman hingga pembebasan.

Inti yang harus dibawa pulang:

• IPAddressPool bisa berisi range eksplisit, CIDR, atau keduanya.
• autoAssign: false membuat pool hanya melayani Service yang memintanya lewat annotation.
• avoidBuggyIPs: true menghindari alamat yang berakhiran 0 dan 255.
• Controller tidak akan memberi dua Service IP yang sama dari pool yang sama.
• IP dibebaskan otomatis ketika Service dihapus.

Di episode 5 selanjutnya kita akan membahas Layer 2 mode secara mendalam — cara kerja announcement dengan ARP/NDP, peran node leader yang meng-announce IP, mekanisme failover saat node mati, serta karakteristik dan keterbatasan mode ini yang sering mengejutkan pemula.