Belajar Calico - IPAM & Networking Dasar

#Pendahuluan

Pernahkah kalian melihat IP pod seperti 192.168.1.4 padahal pod itu ada di node kedua? Itu hasil kerja IPAM (IP Address Management) Calico. Di episode 4 kita bedah bagaimana IP dialokasikan, bagaimana blok-blok IP dibagi antar node, dan bagaimana paket mengalir — termasuk peran kube-proxy untuk Service.

Memahami IPAM itu penting bukan hanya untuk rasa ingin tahu. Ketika blok IP habis, ketika IP pod harus tetap sama untuk egress, atau ketika kita mengatur IPPool untuk workload tertentu, semuanya bergantung pada pemahaman ini.

#IPPool dan Alokasi Blok

#Anatomi IPPool

IPPool adalah kumpulan IP yang bisa dialokasikan ke pod. Secara default Calico membuat default-ipv4-ippool dengan CIDR 192.168.0.0/16. Setiap IPPool punya beberapa atribut kunci:

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 192.168.0.0/16
  blockSize: 26
  ipipMode: Always
  vxlanMode: Never
  natOutgoing: true
  disabled: false

• cidr: rentang IP yang dipakai pod.
• blockSize: ukuran blok yang dialokasikan per node (26 berarti 64 alamat per node).
• ipipMode/vxlanMode: mode encapsulation (dibahas di episode 9).
• natOutgoing: apakah keluar ke non-pod di-NAT keluar IP node.

#Alokasi Per-Node Block

Saat node pertama kali butuh IP, Calico mengambil satu blok utuh dari IPPool untuk node tersebut. Blok inilah yang di-advertise via BGP. Ini menjelaskan kenapa semua pod di satu node biasanya berada di subnet yang berdekatan. Lihat alokasi aktualnya:

calicoctl ipam show --show-blocks
calicoctl get ippool

calicoctl ipam show --show-blocks menampilkan blok-blok yang sudah dialokasikan lengkap dengan node pemiliknya. Kalau satu node kehabisan alamat, Calico bisa mengambil blok tambahan selama IPPool masih punya ruang.

#Konektivitas Pod-to-Pod

#Dalam Satu Node

Saat pod A dan pod B berada di node yang sama, kernel memutuskan destinasi ada di lokal, lalu meneruskan paket dari veth ke veth tanpa meninggalkan node. Tidak ada tunneling dan tidak ada aturan policy yang menghalangi selama policy mengizinkan.

#Antar Node

Untuk node berbeda, BIRD sudah menyebarkan route blok pod. Di node asal ada route seperti 192.168.0.64/26 via <IP node tujuan>. Karena ipipMode: Always, paket lintas node dibungkus IP-in-IP (tunnel). Ini perlu diperhatikan: mode Always berarti tunnel selalu dipakai antar node, sedangkan mode Never atau direct routing memakai paket asli.

Cek route yang ada di salah satu node:

kubectl exec -n calico-system ds/calico-node -- ip route show proto bird
kubectl exec -n calico-system ds/calico-node -- ip -s link show tunl0

ip route show proto bird menampilkan rute yang di-install oleh BIRD, dan interface tunl0 adalah tunnel IPIP yang dipakai saat mode encapsulation aktif.

#Pod-to-Service dan kube-proxy

#Peran kube-proxy

Service di Kubernetes diimplementasikan oleh kube-proxy menggunakan iptables (atau IPVS). Saat pod mengakses Service, paket masuk ke chain KUBE-SERVICES, di-rewrite destinasi ke IP pod backend, lalu diteruskan ke pod tujuan — melewati network policy Calico seperti biasa.

#Alur lengkap paket

pod A -> kube-proxy (DNAT ke backend) -> policy Calico -> routing
      -> veth backend -> pod backend

Verifikasi interaksi ini dengan men-deploy satu Service dan melihatnya dari dalam pod:

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port 80
kubectl run client --image=busybox --command -- sleep 3600
kubectl exec client -- wget -q -O - http://nginx:80

Perintah wget -q -O - http://nginx:80 mengakses nama Service langsung dari dalam klaster. Kalau mengembalikan konten HTML, alur pod-to-service bekerja dengan baik.

#Praktik IPAM: Menambah IPPool

Saat IPPool utama mendekati penuh, kalian bisa menambah pool baru dan mengarahkan workload tertentu ke sana via selector label. Contoh IPPool khusus untuk workload yang memakai VXLAN sementara pool utama tetap IPIP:

apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: vxlan-ippool
spec:
  cidr: 10.48.0.0/16
  blockSize: 26
  vxlanMode: Always
  ipipMode: Never
  natOutgoing: true

Terapkan dengan calicoctl apply -f, lalu pod baru yang memakai selector pool akan mengambil IP dari 10.48.0.0/16:

calicoctl apply -f vxlan-ippool.yaml
calicoctl get ippool

Selector pool memungkinkan beberapa network coexist dalam satu klaster — pola yang umum dipakai untuk memisahkan tenant atau zona.

#Penutup

Episode 4 menutup pemahaman networking dasar: IPPool sebagai sumber IP, blok per node yang di-advertise BGP, mode encapsulation yang menentukan bentuk paket lintas node, dan peran kube-proxy untuk akses Service.

Inti yang harus dibawa pulang:

• IPPool menentukan rentang IP, ukuran blok, dan mode encapsulation.
• Blok IP dialokasikan per node lalu di-advertise via BGP.
• ipam show --show-blocks untuk melihat alokasi aktual.
• kube-proxy melakukan DNAT Service; policy Calico tetap dievaluasi.
• Mode Always vs Never menentukan apakah paket lintas node di-tunnel.
• IPPool tambahan bisa dipakai untuk memisahkan workload dengan network berbeda.

Di episode 5 selanjutnya kita membahas Network Policy dasar — NetworkPolicy namespaced bawaan, struktur ingress/egress, port dan protocol, hingga prinsip default deny dan urutan evaluasi policy. Ini adalah gerbang menuju sisi keamanan Calico yang sebenarnya.