Belajar Cilium - Networking Dasar (Pod-to-Pod & Service)

#Pendahuluan

Setelah Cilium terinstall, mari kita lihat apa yang sebenarnya dia lakukan setiap hari: mengalirkan traffic antar pod dan ke service. Episode 4 membedah networking dasar Cilium — alokasi alamat, jalur pod-to-pod, masquerading, dan bagaimana Service ditangani sepenuhnya di eBPF.

Mengapa episode ini penting? Karena hampir semua topik berikutnya — policy, observability, hingga service mesh — berdiri di atas networking dasar ini. Jika kalian paham bagaimana paket menemukan jalannya dari pod A ke pod B, memahami policy dan Hubble akan jauh lebih mudah.

Sepanjang episode ini kita akan memakai perintah yang berjalan di dalam pod agent Cilium. Pastikan kalian terbiasa dengan pola kubectl exec -n kube-system -it ds/cilium -- <perintah> karena pola ini akan dipakai terus di episode-episode troubleshooting nanti. Alat-alat ini adalah jendela menuju apa yang sebenarnya terjadi di dataplane.

#Alokasi Alamat dan Endpoint

Ketika sebuah pod dibuat, runtime memanggil plugin CNI Cilium. Cilium mengalokasikan alamat IP dari pool IPAM (detail lengkap di episode 9), memasang veth, dan mendaftarkan pod tersebut sebagai sebuah endpoint. Setiap endpoint memiliki identitas, alamat IP, dan metadata dari pod yang bersangkutan.

Untuk melihat semua endpoint di sebuah node, jalankan di dalam pod agent:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg endpoint list

cilium-dbg endpoint list menampilkan tabel endpoint: alamat IP, label pod, identity, dan status health. Kolom Identity di sini adalah angka yang nanti menjadi kunci dari security model Cilium di episode 5.

#CIDR dan Subnet Pod

Setiap cluster punya ruang alamat pod (pod CIDR) yang ditentukan saat cluster dibuat. Cilium membagi ruang ini menjadi subnet per node, dan setiap node mengalokasikan alamat untuk pod lokal dari subnet miliknya. Ukuran subnet menentukan kapasitas pod maksimal per node — topik yang akan kita bedah lebih dalam di episode 9 tentang IPAM.

Alamat yang sudah dialokasikan tercatat di dataplane dan bisa dilihat lewat command yang sama dengan daftar endpoint. Jika kalian menemukan alamat yang tidak dikenal di daftar endpoint, kemungkinan besar itu pod dari node tetangga yang sedang dikomunikasikan atau sisa endpoint yang belum dibersihkan.

#Pod-to-Pod: Intra dan Antar Node

Ketika dua pod berada di node yang sama, paket berpindah lewat bridge dan veth. Program eBPF di hook egress dan ingress memastikan paket sampai ke endpoint tujuan dengan cepat, tanpa keluar ke jaringan fisik. Ini jalur paling cepat dalam sistem.

Ketika pod berada di node berbeda, jalurnya bergantung pada mode datapath:

• Tunnel mode: paket dibungkus VXLAN atau Geneve dan dikirim ke node tujuan.
• Direct routing: paket dikirim langsung ke IP node tujuan berdasarkan tabel routing.

Dalam kedua mode, Cilium tetap menerapkan identity dan policy pada kedua ujung jalur. Untuk menguji koneksi antar pod, jalankan sebuah client dan satu server sederhana:

kubectl run test-a --image=nginx --port=80
kubectl run test-b --image=curlimages/curl --command -- sh -c "sleep 3600"
kubectl exec test-b -- curl http://$(kubectl get pod test-a -o jsonpath='{.status.podIP}')

kubectl get pod test-a -o jsonpath='{.status.podIP}' mengambil alamat IP pod tujuan secara dinamis. Jika curl berhasil, jalur pod-to-pod sudah bekerja.

#Masquerading

Ketika traffic keluar dari cluster menuju internet, alamat IP pod harus diubah agar bisa di-routing oleh jaringan eksternal. Proses ini disebut masquerading — setara dengan NAT. Di Cilium, masquerading dilakukan oleh program eBPF, bukan iptables. Ini mengurangi beban node dan membuat prosesnya lebih cepat.

Perilaku masquerading bisa dilihat lewat Hubble nanti di episode 7: traffic yang keluar ke luar cluster akan menunjukkan proses source NAT. Untuk sekadar memastikan bahwa pod bisa mengakses internet, jalankan:

kubectl exec test-b -- curl -s -o /dev/null -w "%{http_code}" https://www.google.com

Jika perintah di atas mencetak kode 200, masquerading dan routing keluar sudah berfungsi dengan benar.

Satu detail yang perlu dipahami: masquerading hanya berlaku untuk traffic yang keluar dari cakupan routing cluster. Untuk komunikasi antar pod di dalam cluster, alamat asli pod dipertahankan sehingga policy berbasis identity bisa bekerja tanpa gangguan. Ini berarti kalian bisa membedakan dengan jelas antara traffic internal yang mempertahankan identitas aslinya dan traffic eksternal yang sudah di-NAT.

#Service Handling di eBPF

Service Kubernetes (ClusterIP, NodePort, LoadBalancer) di Cilium direplikasi sebagai tabel lookup di eBPF, bukan sebagai chain iptables. Setiap paket yang menuju IP service akan di-lookup di tabel ini dan langsung diarahkan ke salah satu backend pod berdasarkan algoritma load balancing.

Lihat bagaimana service tampak dari perspektif dataplane:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg service list

cilium-dbg service list menampilkan service ClusterIP dan NodePort beserta backend-nya. Bandingkan dengan kubectl get svc — keduanya harus sinkron. Karena handle-nya ada di kernel, penambahan service tidak membuat chain aturan panjang seperti di kube-proxy; yang berubah hanyalah satu entri di tabel hash.

Algoritma load balancing yang dipakai Cilium bisa dipilih: yang paling umum adalah random dan maglev. Maglev adalah algoritma hashing konsisten yang memastikan koneksi dari client yang sama selalu jatuh ke backend yang sama selama daftar backend tidak berubah — perilaku yang mirip session affinity (episode 8) tapi dihitung murni secara deterministik di kernel. Pilihan algoritma diatur lewat konfigurasi dataplane saat instalasi.

Untuk menguji akses service, buat service untuk pod test-a lalu panggil dari pod test-b memakai nama DNS:

kubectl expose pod test-a --port=80 --name=svc-test
kubectl exec test-b -- curl -s http://svc-test:80

kubectl expose pod test-a --port=80 --name=svc-test membuat Service ClusterIP yang direplikasi langsung ke eBPF. Panggilan http://svc-test:80 dari pod lain akan di-load balance ke pod test-a oleh dataplane, bukan oleh kube-proxy.

#Memeriksa Jalur Paket antar Node

Untuk memahami bagaimana paket berpindah antar node, dataplane menyimpan semua informasi yang dibutuhkan. Dari dalam pod agent, jalankan:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg node list
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg bpf tunnel list

cilium-dbg node list menampilkan daftar node yang dikenali dataplane lengkap dengan alamat yang dipakai untuk komunikasi antar node. cilium-dbg bpf tunnel list menampilkan tabel tunnel eBPF — jika tabel ini berisi entri, berarti dataplane berjalan dalam tunnel mode dan paket antar node dibungkus sesuai mode tersebut.

Perintah ini berguna saat kalian mencurigai masalah antar node: apakah node tujuan dikenali dataplane, dan melalui jalur apa paket dikirim. Bandingkan hasilnya di node yang sehat dan node yang bermasalah; perbedaan kecil seperti alamat yang salah atau entri tunnel yang hilang sering kali menjadi petunjuk utama.

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg bpf lb list

cilium-dbg bpf lb list melengkapi gambaran: jika tabel load balancer sudah berisi backend yang benar, masalah koneksi kemungkinan besar bukan di dataplane melainkan di policy atau aplikasi. Membaca dataplane dalam urutan node, tunnel, lalu load balancer adalah pola yang konsisten untuk semua episode berikutnya.

#Penutup

Inti yang harus dibawa pulang:

• Setiap pod menjadi endpoint dengan IP, identity, dan label yang terdaftar di agent.
• Pod-to-pod intra node lewat bridge; antar node lewat tunnel atau direct routing.
• Masquerading ditangani eBPF agar traffic keluar bisa di-routing eksternal.
• Service direplikasi sebagai tabel hash eBPF, bukan chain iptables.
• cilium-dbg service list dan cilium-dbg endpoint list adalah alat baca dataplane utama.

Di episode 5 selanjutnya kita akan membahas identity-based security model — bagaimana label Kubernetes dipetakan menjadi identity numerik, keamanan berbasis identitas alih-alih IP, perbedaan default allow versus deny, dan bagaimana policy dievaluasi langsung di dataplane. Ini adalah fondasi dari semua policy Cilium yang akan kita buat di episode 6 dan seterusnya.