Belajar Cilium - IPAM (IP Address Management)
Episode 9 of 23

Belajar Cilium - IPAM (IP Address Management)

Episode ini membahas IPAM di Cilium: mode cluster-pool untuk pengalamatan sederhana, Multi-Pool yang stabil di versi 1.19 untuk kontrol granular, serta mode cloud-native seperti ENI dan Azure. Kalian juga mempelajari dukungan dual-stack IPv4 dan IPv6.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Pendahuluan

Setiap pod yang lahir membutuhkan alamat IP, dan siapa yang mengalokasikannya serta dari pool mana adalah domain IPAM (IP Address Management). Di episode 4 kita menyebut IPAM sekilas; episode 9 membahasnya secara penuh karena keputusan IPAM memengaruhi kapasitas pod per node dan cara traffic di-routing.

Cilium mendukung beberapa mode IPAM dengan tingkat kompleksitas berbeda: cluster-pool untuk kesederhanaan, Multi-Pool untuk kontrol granular, dan mode cloud-native seperti ENI dan Azure untuk integrasi mendalam dengan cloud provider. Kita bahas satu per satu beserta kasus pemakaiannya.

Sepanjang episode ini, perhatikan satu dimensi penting: IPAM menentukan batas-batas kapasitas cluster. Berapa banyak pod per node? Berapa banyak pool yang tersedia? Jawaban atas pertanyaan-pertanyaan ini ada di konfigurasi IPAM, dan kesalahan perencanaan di sini biasanya baru terasa saat cluster mulai padat.

Mode cluster-pool

Mode paling umum dan direkomendasikan untuk kebanyakan cluster: cluster-pool. Cilium mengambil satu blok besar dari ruang alamat (biasanya dari pod CIDR cluster), membaginya menjadi per-node pools, dan setiap node mengalokasikan IP untuk pod lokal dari pool miliknya. Tidak ada server DHCP atau integrasi cloud — semuanya berjalan di dalam cluster.

Konfigurasi default bisa dilihat dan diubah lewat Helm:

Lihat konfigurasi IPAM
helm get values cilium -n kube-system | grep -A5 ipam

helm get values cilium -n kube-system menampilkan nilai yang sedang aktif. Default cluster-pool memakai mask IPv4 /24 per node, artinya sekitar 250 pod per node. Ukuran ini bisa disesuaikan dengan ipv4.nativeRoutingCIDR dan ipam.maskSize.

Keunggulan utama cluster-pool adalah tidak ada titik kegagalan eksternal: seluruh alokasi berjalan di dalam cluster oleh Cilium Operator. Tidak perlu bergantung pada DHCP server atau API cloud untuk mengalokasikan IP pod. Ini membuat cluster bisa terus menyediakan IP pod meskipun ada gangguan pada layanan cloud provider.

Multi-Pool IPAM

Multi-Pool IPAM, yang stabil sejak Cilium 1.19, memungkinkan alokasi dari beberapa pool berbeda secara bersamaan. Ini berguna ketika sebagian workload butuh range IP khusus, misalnya untuk compliance, atau ketika beberapa namespace harus dipisahkan secara alamat. Multi-Pool bekerja lewat CRD bernama CiliumPodIPPool:

Definisikan pool IP khusus
apiVersion: cilium.io/v2alpha1
kind: CiliumPodIPPool
metadata:
  name: pool-akunting
spec:
  ipv4:
    cidrs:
      - "10.100.0.0/24"

apiVersion: cilium.io/v2alpha1 menandai resource ini sebagai pool IP. Pool pool-akunting menyediakan range 10.100.0.0/24 yang hanya dipakai oleh namespace atau node yang diarahkan ke pool ini. Dengan Multi-Pool, kalian tidak perlu menebak kebutuhan semua workload sejak awal — cukup tambahkan pool baru saat kebutuhan muncul.

Skenario nyata lain yang cocok untuk Multi-Pool: mengintegrasikan pod dengan keamanan jaringan eksternal. Beberapa firewall atau security group perlu mengizinkan range IP tertentu untuk pod. Dengan Multi-Pool, kalian bisa mengisolasi pod yang butuh akses khusus ke satu pool, lalu meng-allowlist pool tersebut — tanpa membuka akses untuk seluruh range pod cluster.

IPAM Cloud-Native (ENI, Azure)

Untuk cluster di cloud publik, Cilium bisa berintegrasi langsung dengan layanan IP cloud provider:

  • AWS ENI: setiap pod mendapat IP dari Elastic Network Interface yang melekat di node. Pod traffic mengalir lewat ENI sehingga bisa memanfaatkan security groups AWS dan tidak membutuhkan overlay.
  • Azure IPAM: alokasi IP dari VNet Azure dengan integrasi ke Azure networking.

Mode ini diaktifkan saat install dengan menunjuk provider:

IPAM berbasis ENI di AWS
cilium install --set ipam.mode=eni

cilium install --set ipam.mode=eni memberitahu Cilium untuk memakai IPAM ENI AWS. Keunggulannya: pod memiliki IP yang bisa di-routing di dalam VPC dan tunduk pada security group. Namun kapasitas pod per node dibatasi jumlah ENI per instance — trade-off yang harus dihitung dengan matang.

Penting untuk dicatat bahwa mode ENI dan Azure tidak memakai overlay. Pod memiliki alamat yang bisa di-routing langsung di VPC, sehingga komunikasi pod-ke-pod lintas node tidak memerlukan encapsulasi. Ini mengurangi overhead per paket, tetapi menuntut perencanaan kapasitas yang lebih hati-hati karena jumlah IP dibatasi oleh sumber daya cloud per node.

Dual-Stack IPv4 dan IPv6

Dukungan IPv6 di Cilium berkembang pesat. Cilium mendukung dual-stack: pod mendapat alamat IPv4 dan IPv6 sekaligus, dan Service bisa diekspos di kedua stack. Aktifkan dengan memberikan CIDR untuk keduanya:

Aktifkan dual-stack
cilium install --set ipv4.enabled=true --set ipv6.enabled=true

cilium install --set ipv4.enabled=true --set ipv6.enabled=true membuat cluster berjalan dual-stack. Setiap pod menerima alamat dari kedua keluarga, memungkinkan transisi bertahap menuju IPv6-only tanpa menghentikan layanan IPv4 yang ada.

Mengaktifkan dual-stack sejak awal lebih murah daripada menambahkannya belakangan. Migrasi dari IPv4-only ke dual-stack memerlukan perubahan konfigurasi dan restart Cilium, yang berarti downtime terencana. Sebaliknya, memakai dual-stack sejak instalasi membuat kalian bebas bereksperimen dengan IPv6 kapan saja.

Untuk memverifikasi alokasi IP di node:

Cek status IPAM
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg ipam list

cilium-dbg ipam list menampilkan pool yang tersedia di node dan alamat yang sudah dialokasikan. Jika kapasitas habis, kalian akan melihat error di sini — salah satu masalah umum yang akan kita bahas saat troubleshooting di episode 19.

Mengukur Kapasitas dan Memilih Mask

Sebelum cluster ramai, lakukan perhitungan kapasitas sederhana agar tidak terkejut di kemudian hari. Untuk cluster-pool, kapasitas pod per node ditentukan oleh mask IPAM:

Lihat mask dan alokasi IPAM
helm get values cilium -n kube-system | grep -E "maskSize|ipam" 
kubectl get ciliumnode -o wide

helm get values cilium -n kube-system menampilkan nilai aktif; perhatikan ipam.maskSize. kubectl get ciliumnode -o wide menampilkan setiap node beserta pool IPv4 yang dialokasikan — kolom ini menunjukkan berapa banyak alamat yang tersedia untuk pod di node tersebut.

Rumus sederhananya: mask /24 memberi sekitar 250 alamat usable per node, /26 memberi sekitar 62, dan /28 hanya sekitar 14. Memilih mask yang terlalu besar membuang alamat, terlalu kecil membuat node cepat kehabisan. Perkirakan jumlah pod maksimal per node dari workload yang direncanakan, lalu tambahkan ruang untuk lonjakan.

Sesuaikan mask IPAM
cilium install --set ipam.mode=cluster-pool --set ipam.maskSize=25

cilium install --set ipam.maskSize=25 mengganti ukuran pool per node. Ingat bahwa perubahan mask hanya memengaruhi alokasi baru; pod yang sudah berjalan tidak otomatis dipindahkan. Perubahan ini sebaiknya dilakukan sebelum workload besar masuk — konsekuensinya kita bahas lebih dalam di episode 21 saat merencanakan arsitektur production.

Info

Pertanyaan pertama saat memilih mode IPAM: berapa pod maksimal per node yang kalian butuhkan? cluster-pool fleksibel dan sederhana, Multi-Pool memberi kontrol per workload, sedangkan ENI/Azure membawa IP ke lapisan VPC dengan batasan dari instance type.

Penutup

Inti yang harus dibawa pulang:

  • cluster-pool membagi satu blok IP menjadi per-node pools untuk alokasi sederhana.
  • Multi-Pool IPAM, stabil di 1.19, memakai CiliumPodIPPool untuk pool khusus.
  • Mode ENI dan Azure mengintegrasikan IP pod langsung ke VPC cloud.
  • Dual-stack memberi pod alamat IPv4 dan IPv6 sekaligus.
  • cilium-dbg ipam list adalah pintu untuk membaca status alokasi.
  • Kapasitas pod per node ditentukan oleh mode IPAM dan konfigurasi pool.

Di episode 10 selanjutnya kita akan membahas DNS-based policy (FQDN) — bagaimana DNS proxy bekerja, rule egress berbasis domain dengan toFQDNs, pengelolaan TTL dan cache, serta praktik mengizinkan akses keluar hanya ke domain tertentu seperti api.external.com. Ini melengkapi policy egress kita yang selama ini masih berbasis IP.