Belajar Cilium - Sejarah, Latar Belakang & Mengapa Membutuhkan Cilium

#Pendahuluan

Selamat datang kembali di series Belajar Cilium! Di episode 0 kalian sudah menyiapkan cluster uji, Cilium CLI, hubble CLI, dan Helm. Sekarang kita mundur sejenak untuk memahami dari mana Cilium berasal dan masalah apa yang sebenarnya dia selesaikan. Tanpa konteks ini, semua perintah yang akan kita pelajari terasa seperti kotak hitam.

Episode 1 membahas tiga hal besar: evolusi Cilium dari proyek internal Isovalent pada 2017 menjadi proyek CNCF graduated, fondasi teknologi eBPF yang membuat semuanya mungkin, serta perbandingan awal dengan pendekatan lain seperti Flannel, Calico, dan kube-proxy. Mengapa penting? Karena keputusan memakai Cilium di production biasanya lahir dari pemahaman tentang keterbatasan pendekatan lama.

#Kelahiran Cilium: Dari Isovalent ke CNCF

#Proyek Internal Isovalent (2017)

Cilium lahir sekitar tahun 2017 sebagai proyek internal Isovalent, perusahaan yang didirikan antara lain oleh Thomas Graf — engineer kernel Linux yang sebelumnya berkontribusi di banyak proyek networking. Awalnya Cilium dirancang untuk menjawab satu pertanyaan sederhana: bagaimana menyediakan networking dan security yang skalabel untuk container dengan memanfaatkan eBPF, teknologi yang baru mulai tersedia luas di kernel Linux.

Pendekatan ini berbeda dari CNI lain yang lebih dulu ada. Alih-alih membangun semua aturan di user-space dengan iptables, Cilium memuat program kecil ke dalam kernel yang mengeksekusi logika jaringan langsung di jalur data. Hasilnya, keputusan routing, load balancing, dan policy diambil di dalam kernel tanpa bolak-balik ke user-space.

#CNCF dan Status Graduated

Cilium diserahkan ke CNCF pada tahun 2021 dan akhirnya mencapai status graduated. Status ini berarti proyek telah matang dari sisi governance, adoption, dan keamanan — bukan sekadar proyek eksperimental. Per pertengahan tahun 2026, Cilium berada di versi 1.20.x, dengan rilis stabil terbaru 1.20.0 pada Juli 2026, sementara versi 1.19.6 dan 1.18.12 masih berada di jalur maintenance.

Untuk selalu tahu versi terbaru, gunakan dua perintah sederhana ini:

curl -s https://api.github.com/repos/cilium/cilium/releases/latest | grep tag_name
cilium version

curl -s https://api.github.com/repos/cilium/cilium/releases/latest mengambil informasi rilis terbaru langsung dari GitHub API, sedangkan cilium version menampilkan versi CLI dan versi image yang akan dipakai di cluster kalian.

Penting juga memahami ekosistem di sekitar proyek: Cilium bukan proyek satu vendor. Meskipun dimulai di Isovalent, kini ia dikembangkan oleh komunitas luas lintas perusahaan, termasuk kontribusi dari penyedia cloud besar. Keberagaman kontributor ini menjadi salah satu alasan proyek dipercaya untuk production — tidak ada satu pihak yang bisa menghentikan pengembangan secara sepihak.

#eBPF: Fondasi Teknologi

eBPF (extended Berkeley Packet Filter) adalah mekanisme kernel Linux yang mengizinkan kalian menjalankan kode di dalam kernel secara aman dan terisolasi — tanpa menulis module kernel. Program eBPF diverifikasi, di-compile menjadi bytecode, lalu di-attach ke hook tertentu, misalnya saat paket tiba, saat syscall dipanggil, atau saat proses baru dimulai. Verifikasi memastikan program berhenti dalam waktu terbatas dan tidak mengakses memori secara sembarangan.

Keunggulan eBPF dibanding iptables sangat mendasar: iptables berjalan dengan memeriksa rule satu per satu secara sekuensial, sementara eBPF melakukan lookup tabel hash langsung di kernel dengan kompleksitas konstan. Bayangkan perbedaan membaca daftar ribuan aturan dari atas ke bawah versus menebak jawabannya dalam satu langkah.

Untuk mengecek apakah kernel kalian mendukung eBPF dengan fitur penuh, jalankan:

uname -r
ls /sys/kernel/btf

ls /sys/kernel/btf memverifikasi keberadaan file BTF (BPF Type Format) yang dibutuhkan Cilium untuk memuat program eBPF dengan CO-RE (compile once, run everywhere). Jika file tersebut tidak ada, fitur Cilium modern akan terbatas.

#Masalah yang Diselesaikan Cilium

#Keterbatasan kube-proxy

kube-proxy bekerja dengan menyusun aturan iptables di setiap node. Semakin banyak Service, semakin panjang chain iptables — sebuah paket harus melewati ribuan rule sebelum menemukan yang cocok. Akibatnya muncul dua masalah utama: latensi yang naik seiring skala, dan kompleksitas update ketika Service berubah. Cilium mengganti mekanisme ini dengan program eBPF yang melakukan lookup langsung di kernel, tanpa traversal rule panjang.

Masalah lain yang sering luput dari perhatian: keamanan. Karena iptables diisi banyak aturan dari berbagai sumber, sulit memastikan tidak ada aturan yang konflik atau menyimpang. Dengan eBPF, jalur data lebih mudah diaudit karena semua aturan terpusat di satu tempat yang dikelola Cilium — sebuah keuntungan yang tidak terlihat di benchmark tapi sangat terasa saat insiden keamanan.

#NetworkPolicy yang Tidak Memahami Identitas

NetworkPolicy bawaan Kubernetes berjalan di atas iptables dan hanya bekerja pada level IP dan port. Konsekuensinya berat: begitu pod restart, IP-nya berubah, dan semua aturan berbasis IP menjadi tidak akurat. Cilium memperkenalkan identity — angka numerik yang diturunkan dari label pod. Policy ditulis terhadap identity, bukan IP, sehingga policy tetap valid meskipun IP berubah. Detail lengkap akan dibahas di episode 5 dan 6.

#Satu Platform: Networking, Security, dan Observability

Sebelum Cilium, tim biasanya menggabungkan beberapa tool: satu CNI untuk networking, solusi terpisah untuk NetworkPolicy, dan tool observability lain untuk memantau traffic. Cilium mempersatukan ketiganya dalam satu dataplane eBPF. Hubble (episode 7) membaca flow log dari dataplane yang sama, sehingga kalian bisa melihat mengapa sebuah paket diterima atau di-drop tanpa memasang tool tambahan.

#Performa dan Skala

Perbedaan performa antara iptables dan eBPF bukan hanya teori. Benchmark komunitas menunjukkan bahwa untuk cluster dengan ratusan Service, kube-proxy berbasis iptables mulai menunjukkan peningkatan latensi yang terukur, sementara dataplane eBPF Cilium mempertahankan latensi yang hampir konstan. Alasan utamanya sederhana: iptables membaca aturan secara sekuensial, sedangkan eBPF melakukan pencarian dalam satu langkah.

Ada juga efek pada control plane yang jarang disadari. Setiap kali sebuah Service berubah, kube-proxy harus memperbarui seluruh chain yang terpengaruh — operasi yang bisa memakan detik di cluster besar. Di Cilium, perubahan Service hanya menambah atau mengubah satu entri di tabel hash kernel, sehingga operasinya hampir instan.

Perlu dicatat bahwa angka benchmark selalu bergantung pada workload dan perangkat keras. Jangan mengambil kesimpulan dari benchmark orang lain; jalankan cilium connectivity test dan ukur sendiri di cluster kalian untuk mendapatkan angka yang relevan dengan environment masing-masing.

#Praktik: Memeriksa Kesiapan Lingkungan

Sebelum kalian masuk ke episode 3 untuk instalasi, pastikan lingkungan belajar sudah siap. Cilium butuh kernel yang cukup modern dan dukungan BTF untuk memakai fitur eBPF secara penuh. Memeriksa ini sejak awal menghemat banyak waktu di kemudian hari.

uname -r
grep -c CONFIG_BPF /boot/config-$(uname -r) 2>/dev/null || echo "config tidak tersedia"
ls /sys/kernel/btf
kubectl get nodes -o wide

uname -r menampilkan versi kernel; pastikan setidaknya kernel 5.10 atau lebih baru untuk memakai fitur Cilium modern dengan nyaman. ls /sys/kernel/btf mengecek keberadaan file BTF yang kita bahas di bagian eBPF. kubectl get nodes -o wide menampilkan versi kernel setiap node sekaligus — cara cepat memastikan semua node konsisten, karena Cilium berjalan sebagai DaemonSet di setiap node.

Jika ada node dengan kernel yang jauh lebih tua, catat nomor node tersebut. Fitur yang kita gunakan di episode-episode awal mungkin tetap bekerja, tetapi fitur seperti bandwidth manager (episode 11) atau enkripsi WireGuard (episode 14) membutuhkan kernel yang lebih baru. Konsistensi kernel antar node adalah prasyarat operasional yang sering diabaikan.

cilium version

cilium version menampilkan versi CLI dan versi image yang akan dipakai. Perhatikan bahwa versi image yang tampil adalah versi yang akan di-install di cluster — jika berbeda dari yang kalian inginkan, tentukan versi secara eksplisit saat install seperti yang akan kita lakukan di episode 3.

#Cilium vs Pendekatan Lain

Sebagai gambaran awal, begini posisi Cilium di antara CNI lain yang umum dipakai:

• Flannel: sederhana, overlay VXLAN, tidak punya NetworkPolicy tingkat lanjut.
• Calico: routing berbasis IP dengan BGP, policy berbasis iptables, kuat untuk jaringan tradisional.
• Weave: mudah dipakai, fokus pada overlay, kurang populer untuk skala besar.
• Cilium: eBPF di dataplane, policy berbasis identity, observability built-in, dan kube-proxy replacement.

Penting untuk dicatat bahwa perbandingan ini bukan berarti Cilium selalu menang di segala situasi. Kalico dan Flannel tetap punya tempat di cluster yang sederhana atau di environment yang tidak mendukung eBPF. Perbandingan mendalam, termasuk Cilium vs Istio untuk service mesh, akan kita bahas di episode 22.

Perbandingan di atas diambil dari perspektif kemampuan fitur dan gaya operasional. Yang juga perlu dipertimbangkan adalah biaya migrasi: mengganti CNI berarti semua pod harus di-restart, jadi pilihan CNI sebaiknya dibuat dengan matang dan tidak diganti-ganti tanpa alasan kuat.

Yang paling penting dipahami: keputusan memilih CNI adalah keputusan arsitektural jangka panjang. Setelah workload berjalan, migrasi CNI memerlukan downtime dan perencanaan yang serius. Karena itu, memahami perbedaan antar CNI sejak awal — seperti yang sedang kita lakukan di series ini — adalah investasi yang sangat berharga.

#Penutup

Inti yang harus dibawa pulang:

• Cilium lahir dari Isovalent pada 2017 dan kini menjadi proyek CNCF graduated di versi 1.20.x.
• eBPF memungkinkan menjalankan kode di dalam kernel secara aman tanpa module.
• kube-proxy berbasis iptables tidak skalabel di cluster besar karena traversal rule panjang.
• NetworkPolicy klasik berbasis IP rapuh karena IP pod berubah; Cilium memakai identity.
• Cilium menyatukan networking, security, dan observability dalam satu dataplane.
• Posisi Cilium vs Flannel, Calico, Weave, dan Istio dibahas mendalam di episode 22.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Cilium — Cilium Agent di setiap node yang mengkompilasi dan memuat program eBPF, Cilium Operator yang mengelola state cluster-wide, dataplane eBPF untuk L3/L4/L7, serta komponen seperti CiliumNetworkPolicy, ClusterwideNetworkPolicy, Hubble, dan IPAM. Ini adalah fondasi arsitektur yang akan kita pakai di semua episode berikutnya.