Belajar Flannel - Sejarah, Latar Belakang & Mengapa Membutuhkan Flannel

#Pendahuluan

Setiap teknologi punya cerita, dan Flannel lahir dari masalah yang sangat konkret: bagaimana cara menghubungkan Pod yang tersebar di banyak node tanpa harus mengkonfigurasi jaringan secara manual satu per satu. Episode 1 ini membuka cerita itu.

Kita akan menelusuri evolusi Flannel sejak 2014, memahami filosofi kesederhanaan yang dijaga sampai hari ini, lalu memetakan masalah yang dia selesaikan dan posisinya terhadap pendekatan CNI lain. Di akhir episode kalian akan mengerti kapan Flannel adalah pilihan yang tepat dan kapan tidak.

#Lahirnya Flannel dari CoreOS

#Sejarah Singkat: 2014 sampai v0.28.x

Flannel dikembangkan oleh CoreOS dan dirilis sekitar 2014, di era awal Kubernetes. Saat itu tujuan utamanya sederhana: memberikan setiap node sebuah subnet unik untuk Pod, lalu menciptakan overlay network agar Pod di node berbeda bisa saling berkomunikasi. Nama Flannel sendiri berasal dari ide "menutupi" jaringan — seperti selimut — di atas jaringan host yang sudah ada.

Seiring waktu Flannel menjadi salah satu CNI paling awal dan paling banyak diadopsi. Kini Flannel dirawat di bawah flannel-io dan berjalan hingga versi v0.28.x. Meski usianya sudah lebih dari satu dekade, dia tetap dipakai karena satu alasan: kesederhanaan.

#Filosofi Sederhana: Satu Daemon per Host

Filosofi Flannel bisa diringkas dalam satu kalimat: satu binary flanneld per host yang mengalokasikan subnet lease. Tidak ada control plane terpusat tambahan, tidak ada database terpisah, tidak ada bahasa konfigurasi yang rumit. Flannel memanfaatkan apa yang sudah dimiliki Kubernetes, yaitu API server, dan apa yang sudah dimiliki Linux, yaitu routing, bridge, dan VXLAN.

Kesederhanaan ini yang membedakan Flannel dari CNI lain. Kalian bisa men-debug seluruh jaringan Flannel hanya dengan beberapa perintah ip dan kubectl.

#Masalah yang Diselesaikan Flannel

#Konektivitas Pod Lintas Node

Masalah inti yang diselesaikan Flannel adalah konektivitas Pod lintas node secara ringan. Tanpa CNI, IP Pod yang di-alokasikan di satu node tidak dikenal oleh node lain, sehingga dua Pod di node berbeda tidak bisa saling bertukar paket. Flannel memecahkan ini dengan dua mekanisme utama: overlay VXLAN atau routing langsung host-gw.

kubectl -n kube-flannel get ds kube-flannel-ds -o jsonpath='{.spec.template.spec.containers[0].image}'

Output akan menunjukkan image seperti docker.io/flannel/flannel:v0.28.8. Perintah kubectl -n kube-flannel get ds di atas juga berguna sebagai verifikasi cepat bahwa Flannel sudah terpasang.

#Alternatif Manual yang Menyakitkan

Sebelum Flannel populer, tim harus membuat bridge dan route secara manual di setiap node, memikirkan alokasi subnet agar tidak bentrok, dan menulis script sendiri. Pendekatan ini rapuh: satu kesalahan ketik di route membuat seluruh cluster tidak konsisten. Flannel menghilangkan pekerjaan manual ini dengan mengotomatiskan alokasi subnet dan pembuatan route melalui satu daemon.

#Flannel vs Pendekatan Lain

#VXLAN vs Routing Murni

Flannel memberikan pilihan filosofi di level backend. Untuk jaringan yang butuh fleksibilitas di jaringan host mana pun, Flannel memakai VXLAN yang membungkus paket dalam UDP. Untuk jaringan yang butuh performa tinggi dan semua node saling reachable, Flannel bisa memakai host-gw yang meneruskan paket langsung tanpa encapsulation.

ls -la /opt/cni/bin/

Output dari ls /opt/cni/bin/ menunjukkan plugin bridge, portmap, bandwidth, dan flannel yang bekerja sama membentuk jaringan Pod.

#Perbandingan Awal dengan Calico dan Cilium

Flannel adalah pilihan paling sederhana di antara tiga CNI yang umum. Calico menawarkan NetworkPolicy dan routing BGP yang kaya. Cilium menambahkan eBPF, observability mendalam, dan kebijakan berbasis identitas. Flannel tidak menawarkan semua itu, dan memang tidak mau. Ketika kalian hanya butuh Pod yang saling terhubung tanpa fitur tambahan, Flannel adalah jawaban paling hemat sumber daya.

#Mengapa Flannel Masih Relevan

#Ekosistem dan Adopsi

Relevansi Flannel tidak hanya dari kesederhanaan, tapi juga dari ekosistemnya. Manifest resmi dan Helm chart tersedia resmi, komunitasnya besar, dan integrasinya dengan kubeadm menjadi contoh pertama di dokumentasi resmi. Kombinasi ini membuat Flannel menjadi gerbang masuk yang ideal sebelum tim memutuskan apakah mereka butuh fitur CNI yang lebih canggih.

kubectl get pods -n kube-flannel -o wide

Semua Pod yang berstatus Running menandakan setiap node sudah memiliki daemon flanneld dan siap mengalokasikan subnet.

#Kapan Flannel Bukan Pilihan Terbaik

Jujur terhadap batas juga bagian dari belajar. Jika kalian butuh NetworkPolicy per namespace, policy berbasis identitas, atau observability traffic per service, Flannel perlu ditemani policy engine seperti Calico policy-only atau Cilium — yang akan kita bahas di episode 14 dan 22. Flannel memilih fokus: connectivity yang andal, bukan fitur yang banyak.

#Menelusuri Buah Kesederhanaan

#Arsitektur yang Mudah Dijelaskan

Bukti kesederhanaan Flannel ada di cara menjelaskannya. Dengan satu paragraf, kalian sudah bisa menggambarkan seluruh jaringan: setiap node menjalankan flanneld, mengambil satu subnet dari pool, membangun route atau tunnel, dan berhenti di situ. Tidak ada lagi yang perlu dijelaskan.

kubectl get lease -n kube-system -o wide

Perintah kubectl get lease -n kube-system menampilkan satu subnet per node. Semakin banyak node, semakin banyak lease, tetapi polanya tidak pernah berubah.

#Beban yang Dipikul Tim Operasi

Kesederhanaan juga berarti beban operasional yang kecil. Upgrade cukup mengganti image DaemonSet, konfigurasi cukup satu file JSON, dan debugging cukup beberapa perintah ip. Bagi tim kecil yang tidak punya ahli jaringan khusus, ini perbedaan yang sangat terasa.

#Memilih Titik Awal yang Tepat

Bagi banyak organisasi, Flannel adalah titik awal yang sehat sebelum keputusan CNI yang lebih besar. Dengan biaya migrasi yang kecil, tim bisa merasakan dulu bagaimana rasanya mengoperasikan CNI di produksi, lalu memutuskan apakah mereka membutuhkan fitur NetworkPolicy atau eBPF.

#Satu Pelajaran dari Sejarah

Keputusan arsitektur yang bertahan satu dekade biasanya lahir dari jawaban atas masalah nyata, bukan tren sesaat. Flannel lahir karena konektivitas Pod lintas node menyakitkan, dan sampai hari ini masalah itu tetap relevan. Ini pelajaran berharga: bangun keputusan di atas masalah, bukan di atas gimmick.

#Penutup

Episode 1 menutup babak sejarah Flannel: dari proyek CoreOS pada 2014, masalah konektivitas Pod lintas node yang memicunya, filosofi satu daemon per host, sampai posisinya di antara Calico dan Cilium.

Inti yang harus dibawa pulang:

• Flannel lahir di CoreOS sekitar 2014 dan kini dirawat flannel-io.
• Filosofinya: satu binary flanneld per host yang mengalokasikan subnet lease.
• Masalah utama yang diselesaikan: konektivitas Pod lintas node secara ringan.
• Dua mekanisme utama: overlay VXLAN dan routing langsung host-gw.
• Flannel fokus pada connectivity, bukan NetworkPolicy atau observability mendalam.
• Flannel adalah pilihan tepat ketika kesederhanaan dan hemat sumber daya adalah prioritas.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama — bagaimana flanneld mengambil subnet lease dari datastore, membangun interface VXLAN, dan berkoordinasi lewat CNI plugin. Inilah fondasi teknis yang akan kita pakai di seluruh episode berikutnya, jadi pastikan konsepnya melekat.