Belajar Cilium - Ekosistem Alternatif & Refleksi Akhir

#Pendahuluan

Dua puluh dua episode berakhir di episode ini. Sebelum menutup, kita melakukan dua hal: melihat sekeliling untuk memahami posisi Cilium di ekosistem, dan menoleh ke belakang untuk merangkum apa yang sudah dipelajari. Episode 22 adalah episode refleksi sekaligus orientasi keputusan.

Kita akan membandingkan Cilium dengan Calico, Flannel, dan Weave; membahas kapan kube-proxy replacement layak dan kapan tidak; serta membandingkan Istio dengan Cilium Service Mesh. Ditutup dengan rekap journey dan checklist yang bisa kalian bawa ke dunia nyata.

#Cilium vs Calico vs Flannel vs Weave

Empat CNI besar ini sering dibandingkan, dan masing-masing punya tempat:

• Flannel: pilihan paling sederhana, overlay VXLAN, minim fitur. Cocok untuk lab dan cluster kecil yang butuh cepat berjalan.
• Weave: mudah dipakai dengan network mesh sendiri, tapi popularitasnya menurun untuk skala besar.
• Calico: kuat di routing berbasis BGP dan policy berbasis iptables. Pilihan solid untuk tim yang nyaman dengan pola networking tradisional dan tidak butuh fitur eBPF.
• Cilium: eBPF di dataplane, policy berbasis identity, observability built-in, kube-proxy replacement, dan service mesh. Pilihan paling lengkap, dengan syarat kernel mendukung eBPF.

Kuncinya: tidak ada jawaban universal. Kalau kebutuhan kalian sebatas pod saling terhubung, Flannel cukup. Kalau butuh policy dengan ekosistem familiar, Calico layak dipertimbangkan. Kalau menginginkan platform networking, security, dan observability terpadu, Cilium adalah jawabannya.

Perbandingan di atas juga perlu dibaca dengan konteks waktu: ekosistem CNI berubah cepat. Flannel dan Weave jarang mendapatkan fitur baru, sementara Calico dan Cilium terus berkembang. Sebuah perbandingan yang benar hari ini bisa berbeda dua tahun lagi — jadi tinjau ulang keputusan arsitektural secara berkala, bukan sekali untuk selamanya.

#kube-proxy Replacement vs Tradisional

Kapan kube-proxy replacement layak dan kapan tidak? Jawaban singkatnya: hampir selalu layak di cluster modern, tapi ada pengecualian.

Layak ketika: cluster besar dengan banyak Service, workload sensitif latensi, dan kernel mendukung eBPF. Manfaatnya terukur — latensi lebih rendah dan operasi Service tidak lagi membebani node.

Tidak layak ketika: cluster kecil sekali, kernel lama yang tidak mendukung eBPF, atau tim belum punya kapasitas mempelajari mode baru. Untuk kasus seperti ini, kube-proxy tradisional yang sudah matang tetap bisa dipakai sambil merencanakan transisi.

Perbandingan jujurnya: kube-proxy replacement bukan fitur wajib untuk bisa memakai Cilium. Kalian bisa menjalankan Cilium sebagai CNI dengan kube-proxy bawaan dulu, lalu beralih ke strict setelah nyaman — pendekatan bertahap yang sehat.

Keputusan semacam ini sebaiknya dicatat sebagai proposal arsitektur: kondisi saat ini, opsi yang dievaluasi, dan keputusan akhir beserta alasan. Enam bulan kemudian, dokumen ini menjadi referensi berharga saat tim bertanya mengapa keputusan tersebut diambil — dan apakah keputusan itu masih relevan.

#Istio vs Cilium Service Mesh

Perbandingan terakhir dan paling sering memicu diskusi. Ringkasnya:

• Istio: service mesh paling matang dan kaya fitur, memakai sidecar Envoy, kontrol plane yang terpisah. Kekuatannya: ekosistem dan dokumentasi besar. Kelemahannya: overhead resource dari sidecar per pod.
• Cilium Service Mesh: sidecarless, memakai Envoy per node dan ztunnel, mTLS berbasis identity yang selaras dengan policy Cilium. Kekuatannya: efisiensi resource dan adopsi bertahap. Kelemahannya: masih lebih muda daripada Istio.

Pilihannya bergantung prioritas. Tim yang sudah berinvestasi di ekosistem Istio dan butuh fitur mesh paling lengkap akan merasa nyaman di Istio. Tim yang ingin efisiensi dan sudah memakai Cilium untuk networking akan diuntungkan oleh Cilium Service Mesh karena satu platform, satu sumber kebenaran.

Satu poin yang sering mengubah keputusan: keterampilan tim. Service mesh adalah sistem yang kompleks untuk dioperasikan; memilih platform yang paling dikenal tim biasanya lebih baik daripada memilih yang paling canggih. Jika tim sudah fasih Envoy dan istioctl, Istio bisa menjadi pilihan paling pragmatis meskipun overhead-nya lebih tinggi.

#Rekap Journey Episode 0-21

Mari kita rangkai kembali peta yang sudah dilalui:

• Fase 1: prasyarat, sejarah, dan arsitektur Cilium (episode 0-2).
• Fase 2: instalasi, networking dasar, identity, CNP, dan Hubble (episode 3-7).
• Fase 3: kube-proxy replacement, IPAM, FQDN, bandwidth, dan gateway (episode 8-12).
• Fase 4: L7 policy, encryption, service mesh, dan Tetragon (episode 13-16).
• Fase 5: ClusterMesh, GitOps, troubleshooting, dan rilis terbaru (episode 17-20).
• Fase 6: arsitektur production dan refleksi akhir (episode 21-22).

Struktur ini bukan kebetulan: setiap fase membangun di atas fase sebelumnya, dari konsep menuju operasional, lalu menuju skala.

Perhatikan satu pola yang berulang: setiap fase menambahkan dimensi baru — fase 2 menambahkan keamanan dasar, fase 4 menambahkan enkripsi dan runtime security, fase 5 menambahkan skala lintas cluster. Pola ini meniru cara Cilium sendiri berkembang: dari CNI, menjadi platform keamanan, lalu menjadi platform operasional multi-cluster.

#Checklist Cilium Production-Grade

Sebagai penutup teknis, ini checklist yang bisa kalian pakai untuk mengaudit cluster:

cilium status
cilium connectivity test
cilium encrypt status
kubectl get cnp --all-namespaces
hubble observe --verdict DROPPED --since 1h

cilium status memastikan komponen sehat, cilium connectivity test membuktikan konektivitas, cilium encrypt status memverifikasi enkripsi, dan kubectl get cnp --all-namespaces menampilkan semua policy yang aktif. Amati Hubble untuk memastikan tidak ada drop tak terduga.

#Masa Depan Cilium

Ke mana arah Cilium selanjutnya? Tiga garis besar yang jelas terlihat:

• eBPF sebagai fondasi: semakin banyak fitur jaringan dan keamanan dipindahkan ke kernel, dengan overhead yang semakin kecil.
• Tetragon untuk keamanan runtime: integrasi networking dan runtime security menjadi satu platform.
• Multi-cluster dan service mesh: MCS API yang stabil (1.20) dan ztunnel menunjukkan arah menuju operasi lintas cluster yang lebih mulus.

Cilium tidak berhenti di CNI. Ia sedang tumbuh menjadi platform networking, keamanan, dan observability yang menyeluruh — dan kalian yang menyelesaikan series ini sudah berada di jalur yang tepat untuk mengoperasikannya.

Yang juga patut dipantau: perkembangan tools di sekitarnya. Hubble terus bertambah kemampuannya, Cilium CLI semakin matang sebagai alat operasional, dan ekosistem observability di sekitar eBPF semakin kaya. Mengikuti rilis dan blog resmi Cilium secara berkala adalah investasi kecil dengan imbalan besar.

#Keputusan Berbasis Data, Bukan Marketing

Perbandingan antar CNI atau service mesh sering berakhir pada argumen favoritisme. Cara yang lebih sehat adalah mengukurnya sendiri secara langsung. Siapkan dua cluster kecil dengan konfigurasi yang sama, install kedua solusi yang dibandingkan, lalu jalankan pengukuran yang sama:

cilium connectivity test
cilium status
kubectl top node

cilium connectivity test menetapkan baseline fungsional: apakah semua skenario koneksi lulus. cilium status mencatat versi dan kondisi komponen. kubectl top node mengukur penggunaan sumber daya pada beban yang sama. Dengan data dari kedua cluster, keputusan tidak lagi berdasarkan opini melainkan angka yang bisa dibandingkan.

Perhatikan bahwa pengukuran harus dilakukan pada workload yang mewakili penggunaan nyata, bukan synthetic benchmark yang tidak relevan. Dua pertanyaan yang paling menentukan: berapa overhead sumber daya per node, dan seberapa mudah tim mengoperasikannya setiap hari? Jawaban kedua sering kali lebih penting daripada selisih angka performa yang kecil.

Praktik terakhir yang ingin ditekankan: pilih, terapkan, lalu tinjau ulang. Tidak ada keputusan arsitektur yang abadi — ekosistem berubah, workload berubah, dan tim berubah. Jadwalkan peninjauan ulang keputusan CNI dan service mesh setahun sekali, dan gunakan data dari episode ini untuk memutuskan apakah keputusan lama masih relevan.

#Penutup

Inti yang harus dibawa pulang:

• Flannel, Weave, dan Calico tetap punya tempat; Cilium unggul untuk platform terpadu berbasis eBPF.
• kube-proxy replacement layak di cluster modern; adopsi bertahap selalu sehat.
• Istio matang dan kaya fitur; Cilium Service Mesh efisien dan selaras dengan identity.
• Journey terbagi rapi dari konsep, operasional, hingga skala lintas cluster.
• Checklist produksi: status, connectivity test, enkripsi, policy, dan observability.
• Masa depan Cilium: eBPF, Tetragon, multi-cluster, dan service mesh yang semakin ringan.

Inilah akhir dari series Belajar Cilium — 23 episode dari prasyarat hingga arsitektur production. Semua keterampilan yang kalian bangun di sini saling terkait: identity untuk policy, policy untuk keamanan, Hubble untuk pembuktian, dan GitOps untuk pengendalian. Terapkan secara bertahap di environment kalian, jadikan cilium connectivity test sahabat setia, dan biarkan dataplane yang berbicara. Selamat beroperasi dengan Cilium!