Belajar Cilium - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah memahami sejarah dan motivasi di balik Cilium, sekarang waktunya membedah bagaimana Cilium bekerja di balik layar. Episode 2 ini adalah peta arsitektur: apa itu Cilium Agent, apa itu Cilium Operator, bagaimana dataplane eBPF bekerja, dan komponen apa saja yang membentuk ekosistem Cilium.

Mengapa penting memahami arsitektur sebelum praktik? Karena hampir semua troubleshooting di episode 19 nanti berakar pada pemahaman komponen ini. Ketika kalian melihat cilium status menunjukkan agent yang belum siap, kalian harus tahu komponen mana yang bermasalah dan mengapa. Mari kita bangun pemahaman itu sekarang.

#Arsitektur Dua Proses: Agent dan Operator

#Cilium Agent di Setiap Node

Cilium Agent adalah proses utama yang berjalan di setiap node sebagai DaemonSet. Tugasnya sangat berat: mengkompilasi program eBPF sesuai konfigurasi, memuatnya ke kernel, menjaga sinkronisasi dengan API Kubernetes, mengelola endpoint (pod), dan mengeksekusi semua keputusan jaringan. Ketika sebuah pod baru dibuat, agent-lah yang memasang veth, mengalokasikan IP, dan meng-attach program eBPF untuk pod tersebut.

Untuk melihat agent yang berjalan di cluster kalian:

kubectl get pods -n kube-system -l k8s-app=cilium

kubectl get pods -n kube-system -l k8s-app=cilium menampilkan satu pod agent per node. Karena berjalan sebagai DaemonSet, jumlah pod akan selalu sama dengan jumlah node yang sehat.

#Cilium Operator di Cluster

Berbeda dengan agent yang berjalan per node, Cilium Operator adalah proses yang berjalan per cluster (biasanya dua replika untuk redundancy). Operator tidak menangani jalur data; dia mengelola state cluster-wide: menjaga kuota alokasi IP (IPAM), mengelola daftar identity, menangani garbage collection, dan memastikan konfigurasi antar node konsisten.

Pemisahan ini penting secara arsitektural: semua yang butuh kecepatan dan local knowledge ditaruh di agent, sementara semua yang butuh gambaran menyeluruh ditaruh di operator. Kalau operator mati, traffic jaringan tetap berjalan, tetapi operasi seperti alokasi IP untuk pod baru akan terganggu.

#Dataplane eBPF

Dataplane adalah jalur data tempat paket melewati kernel. Di Cilium, dataplane dibangun hampir seluruhnya dari program eBPF yang di-attach di beberapa hook sekaligus: saat paket masuk dari NIC (tc ingress), saat paket keluar (tc egress), dan untuk socket-level load balancing. Tidak ada iptables yang terlibat di jalur utama.

Dengan eBPF, Cilium bisa menangani L3 (routing antar pod dan antar node), L4 (load balancing Service, policy berbasis port), dan L7 (inspeksi HTTP, gRPC, dan Kafka) dalam satu pipeline. Keputusan diambil di dalam kernel dengan kecepatan kernel, bukan di user-space. Ini yang membuat Cilium unggul dalam hal latency dan throughput.

Yang perlu ditekankan: istilah "tanpa iptables" bukan berarti iptables dihapus dari sistem. Kernel tetap memiliki iptables, tetapi jalur data utama pod-to-pod dan pod-to-service tidak lagi bergantung padanya. Beberapa fungsi tambahan, seperti masquerading untuk traffic tertentu, tetap memakai mekanisme kernel lain yang sesuai kebutuhan.

Untuk melihat status dataplane pada satu node, jalankan di pod agent:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg status

cilium-dbg status menampilkan ringkasan endpoint, controller, ipam, health, dan kernel. Output Kernel Version di sini berguna untuk memastikan kernel node memenuhi syarat eBPF.

#Komponen Utama Ekosistem Cilium

Berikut komponen yang akan sering kalian temui sepanjang series:

• Cilium Agent: proses per node, pengelola dataplane dan endpoint.
• Cilium Operator: proses per cluster, pengelola IPAM, identity, dan garbage collection.
• Cilium CLI: tool instalasi dan verifikasi dari luar cluster.
• Hubble: komponen observability dengan relay, CLI, dan UI.
• CiliumNetworkPolicy (CNP): policy networking scoped ke satu namespace.
• ClusterwideNetworkPolicy (CCNP): policy yang berlaku lintas namespace.
• IPAM: pengelolaan alokasi alamat IP pod.

Sebagian besar komponen ini sudah terinstall otomatis ketika Cilium dipasang. Hubble perlu diaktifkan secara eksplisit (episode 7), sedangkan CNP dan CCNP adalah CustomResource yang kita definisikan lewat YAML.

#Siapa Melakukan Apa: Pembagian Tanggung Jawab

Untuk memudahkan mengingat, inilah pembagian tanggung jawab utama di arsitektur Cilium:

• Cilium Agent: mengkompilasi eBPF, mengelola endpoint, mengeksekusi policy, dan melaporkan state node.
• Cilium Operator: mengalokasikan identity, mengelola IPAM, dan melakukan garbage collection.
• Hubble Relay: mengumpulkan flow dari semua agent dan menyediakan API observability.
• Hubble UI: menampilkan flow secara visual dari data relay.
• Cilium CLI: alat bantu dari luar cluster untuk install dan verifikasi.

Ketika salah satu komponen bermasalah, pertanyaan pertama yang selalu muncul: komponen mana yang bertanggung jawab atas fungsi yang gagal? Pola pikir ini akan sangat membantu di episode 19 ketika kita membahas troubleshooting. Simpan tabel ini dalam ingatan, karena akan terus dipakai sepanjang series.

#Alur Kerja Satu Paket

Mari kita ikuti satu paket sederhana dari pod A ke pod B di node yang sama:

1. Paket keluar dari container pod A melalui veth menuju bridge.
2. Program eBPF di hook egress membaca identitas pod A dari metadata socket.
3. Dataplane menentukan endpoint tujuan berdasarkan alamat IP pod B.
4. Policy egress dan ingress dievaluasi terhadap kedua identity.
5. Jika diizinkan, paket diteruskan ke veth pod B di jalur cepat.

Ketika pod A dan pod B berada di node yang berbeda, jalurnya diperpanjang dengan encapsulasi tunnel (VXLAN/Geneve) atau direct routing antar node — tergantung mode datapath yang dipilih saat instalasi. Kedua mode ini akan kita bandingkan di episode 3.

Perhatikan bahwa di kedua kasus, identitas dan policy ikut dipertimbangkan di setiap hop. Inilah yang membedakan Cilium dari CNI lain: jaringan bukan sekadar jalur, tapi juga keputusan keamanan yang dievaluasi terus-menerus. Kita akan melihat lebih dalam soal ini di episode 5.

#Melihat Arsitektur secara Langsung

Konsep arsitektur terasa abstrak sampai kita melihatnya dengan kubectl. Mari kita lihat komponen-komponen yang sudah terinstall dari episode 3:

kubectl get ds -n kube-system cilium
kubectl get deploy -n kube-system cilium-operator
kubectl get pods -n kube-system -l k8s-app=cilium -o wide

kubectl get ds -n kube-system cilium menampilkan DaemonSet agent. Kolom DESIRED dan READY harus sama — jika tidak, ada node yang agent-nya gagal berjalan. kubectl get deploy -n kube-system cilium-operator menampilkan deployment operator; perhatikan kolom AVAILABLE yang menunjukkan berapa replika siap.

Untuk melihat proses agent dan operator lebih dalam, periksa log-nya:

kubectl logs -n kube-system -l k8s-app=cilium --tail=20
kubectl logs -n kube-system deploy/cilium-operator --tail=20

kubectl logs -n kube-system -l k8s-app=cilium --tail=20 menampilkan 20 baris log terakhir dari semua agent. Saat troubleshooting (episode 19), pola inilah yang pertama kali kita pakai: apakah ada error di agent node yang bermasalah, lalu bandingkan dengan agent node yang sehat.

Pola pikir yang perlu diingat: agent adalah "karyawan di lantai pabrik" yang menangani paket setiap hari, sedangkan operator adalah "manajemen kantor pusat" yang mengurus administrasi. Ketika sebuah paket gagal, kemungkinan besar masalahnya di agent node terkait; ketika alokasi identity atau IP bermasalah, operator layak dicurigai lebih dulu.

#Penutup

Inti yang harus dibawa pulang:

• Cilium Agent berjalan per node dan mengelola dataplane eBPF serta endpoint.
• Cilium Operator berjalan per cluster dan mengelola IPAM, identity, dan state global.
• Dataplane eBPF menangani L3, L4, dan L7 tanpa iptables di jalur utama.
• Ekosistem Cilium mencakup CLI, Hubble, CNP, CCNP, dan IPAM.
• Satu paket diproses lewat endpoint, identity, policy, lalu diteruskan ke tujuan.
• Mode datapath tunnel vs direct routing ditentukan saat instalasi.

Di episode 3 selanjutnya kita akan menginstall Cilium — baik lewat cilium install maupun Helm chart, memverifikasi dengan cilium status dan cilium connectivity test, memilih antara tunnel dan direct routing, serta memahami integrasi dengan runtime containerd dan CRI-O. Ini adalah episode pertama di mana cluster kalian benar-benar berubah.