Bayangkan sebuah cluster Kubernetes dengan puluhan node, ratusan Pod, dan lalu lintas data yang terus mengalir setiap detik. Bagaimana caranya Pod di node A bisa “berbicara” dengan Pod di node B, padahal keduanya berada di server fisik atau virtual yang berbeda? Jawabannya ada pada satu komponen yang sering luput dari perhatian pemula, tapi sangat krusial: Container Network Interface (CNI).
Bagi seorang Sysadmin, DevOps Engineer, atau siapa pun yang baru terjun ke dunia orkestrasi container, memahami CNI bukan sekadar pengetahuan tambahan — ini adalah fondasi. Salah pilih atau salah konfigurasi CNI, dan cluster Kubernetes Anda bisa mengalami masalah konektivitas, celah keamanan, hingga penurunan performa yang signifikan.
Pada artikel ini, kita akan membahas tuntas apa itu CNI, bagaimana dua CNI populer — Calico dan Flannel — bekerja, apa perbedaan mendasar dari sisi network policy, serta bagaimana cara memilih yang paling sesuai untuk kebutuhan infrastruktur IT Anda, mulai dari home lab sederhana hingga cluster production skala enterprise.
Pembahasan Utama
Apa Itu CNI (Container Network Interface)?
CNI adalah sebuah spesifikasi sekaligus plugin yang bertugas mengatur bagaimana jaringan dikonfigurasi untuk container. Setiap kali Kubelet membuat Pod baru, CNI-lah yang bertanggung jawab untuk:
- Memberikan alamat IP ke Pod tersebut
- Mengatur routing agar Pod bisa dijangkau dari node lain
- Menghubungkan interface jaringan Pod ke jaringan cluster
- Menegakkan (enforce) network policy jika didukung
Tanpa CNI, Pod-Pod dalam cluster Kubernetes hanya akan menjadi “pulau-pulau” yang terisolasi satu sama lain. Di sinilah CNI seperti Calico dan Flannel mengambil peran sebagai jembatan komunikasi.
Analoginya sederhana: jika Kubernetes adalah sebuah kota besar dengan banyak gedung (node) dan penghuni (Pod), maka CNI adalah sistem jalan raya, rambu lalu lintas, sekaligus petugas keamanan yang mengatur siapa boleh lewat ke mana dan siapa yang harus diblokir.
Mengenal Flannel: CNI yang Mengutamakan Simplisitas
Flannel adalah salah satu CNI paling populer di kalangan pemula karena filosofinya yang sederhana: lakukan satu hal dengan baik, yaitu menyediakan konektivitas jaringan overlay antar Pod di berbagai node.
Cara kerja Flannel secara garis besar:
- Sebuah daemon bernama
flanneldberjalan di setiap node untuk mengelola alokasi subnet - Flannel membungkus (encapsulate) paket data menggunakan backend VXLAN secara default, meskipun tersedia juga opsi
host-gwuntuk skenario tanpa overlay - Setiap node mendapatkan blok subnet unik, sehingga Pod di node berbeda tetap bisa saling menjangkau melalui tunnel virtual
Kelebihan utama Flannel adalah kemudahan instalasi dan operasional yang minim. Banyak distribusi Kubernetes ringan menjadikannya CNI default karena hampir tidak butuh konfigurasi tambahan agar Pod di node berbeda bisa saling berkomunikasi.
Namun, ada satu keterbatasan besar: Flannel secara native tidak mendukung Network Policy. Artinya, jika Anda hanya menggunakan Flannel, semua Pod dalam cluster pada dasarnya bisa saling mengakses tanpa pembatasan berbasis aturan keamanan. Untuk mengatasi ini, kombinasi populer yang sering dipakai adalah Canal, yaitu menjalankan Flannel untuk jaringan dasar sekaligus Calico khusus untuk fitur network policy-nya saja.
Mengenal Calico: CNI dengan Kekuatan Network Policy dan BGP
Berbeda dengan Flannel, Calico dirancang dengan pendekatan yang lebih menyeluruh. Calico tidak hanya menyediakan konektivitas dasar, tetapi juga menempatkan keamanan jaringan sebagai fitur inti, bukan tambahan.
Beberapa karakteristik utama Calico:
- Menggunakan BGP (Border Gateway Protocol) untuk mendistribusikan rute antar node, protokol yang sama yang menjadi tulang punggung routing di internet
- Mampu beroperasi pada mode Layer 3 murni tanpa overlay encapsulation ketika dikonfigurasi untuk direct routing, sehingga latensi lebih rendah dibanding pendekatan overlay
- Arsitekturnya memisahkan control plane (komponen bernama Felix) dari data plane, di mana Felix memantau perubahan Network Policy di Kubernetes API lalu menerapkannya ke node
- Mendukung Kubernetes NetworkPolicy standar, sekaligus GlobalNetworkPolicy buatan Calico sendiri yang lebih fleksibel dan granular
- Kini Calico juga menyediakan opsi dataplane berbasis eBPF, sebagai alternatif dari iptables tradisional, untuk meningkatkan performa terutama saat network policy diterapkan secara masif
Fitur network policy inilah yang menjadi “senjata utama” Calico. Dengan Calico, seorang admin bisa membuat aturan sangat detail, misalnya: Pod dengan label app=frontend hanya boleh berkomunikasi dengan Pod berlabel app=backend pada port tertentu saja, sementara akses dari namespace lain diblokir total.
Perbedaan Fitur Network Policy: Calico vs Flannel
Berikut perbandingan ringkas yang perlu dipahami:
| Aspek | Flannel | Calico |
|---|---|---|
| Model jaringan | Overlay (VXLAN) / host-gw | BGP routing, bisa non-overlay |
| Network Policy native | Tidak ada | Ada, lengkap dengan GlobalNetworkPolicy |
| Kompleksitas setup | Sangat sederhana | Menengah, lebih banyak opsi konfigurasi |
| Performa tanpa policy | Baik, ada sedikit overhead VXLAN | Sangat baik, terutama mode non-overlay |
| Cocok untuk | Cluster kecil, development, edukasi | Production, multi-tenant, kebutuhan keamanan tinggi |
Perbedaan ini bukan berarti salah satu “lebih baik” secara mutlak. Semua kembali pada kebutuhan. Jika Anda sedang belajar Kubernetes di home lab atau menjalankan cluster development yang tidak butuh isolasi jaringan ketat, Flannel sudah lebih dari cukup. Namun jika Anda mengelola cluster production dengan banyak tim atau workload sensitif, kemampuan network policy Calico menjadi nilai tambah yang sulit ditandingi.
Materi Praktis
Studi Kasus Sederhana
Bayangkan sebuah perusahaan rintisan yang menjalankan dua aplikasi dalam satu cluster Kubernetes: aplikasi billing yang menyimpan data sensitif dan aplikasi public-facing yang diakses banyak pengguna. Jika hanya menggunakan Flannel tanpa tambahan apa pun, Pod aplikasi public-facing yang “diretas” berpotensi langsung menjangkau Pod billing karena tidak ada isolasi jaringan.
Dengan Calico, tim infrastruktur dapat membuat NetworkPolicy yang secara eksplisit menolak semua trafik masuk ke namespace billing, kecuali dari Pod tertentu yang memang diizinkan. Prinsip ini dikenal sebagai zero trust networking — semua akses ditolak secara default, kecuali diizinkan secara eksplisit.
Contoh Implementasi Konsep NetworkPolicy
Secara konsep, sebuah NetworkPolicy di Calico atau Kubernetes native umumnya mendefinisikan:
- Pod selector — Pod mana yang menjadi target aturan
- Policy types — apakah mengatur trafik masuk (ingress), keluar (egress), atau keduanya
- Rules — dari/ke mana saja trafik diizinkan, termasuk berdasarkan label, namespace, atau range IP
- Ports — port dan protokol spesifik yang diizinkan
Dengan pendekatan berbasis label ini, aturan keamanan jaringan menjadi deklaratif dan mudah diaudit, alih-alih mengandalkan konfigurasi firewall manual di tiap node.
Tutorial Step-by-Step: Memahami Alur Kerja CNI Saat Pod Dibuat
- Kubelet menerima perintah membuat Pod dari API Server setelah proses scheduling selesai.
- Kubelet memanggil CNI plugin yang terpasang di node (Flannel atau Calico) melalui direktori binary CNI.
- CNI plugin mengalokasikan IP address untuk Pod dari rentang subnet yang sudah ditentukan.
- CNI plugin mengonfigurasi interface jaringan virtual (veth pair) yang menghubungkan Pod ke bridge jaringan node.
- CNI plugin mengatur routing agar Pod bisa dijangkau dari node lain — via tunnel VXLAN pada Flannel, atau via rute BGP pada Calico.
- Jika menggunakan Calico dengan Network Policy aktif, komponen Felix akan menerjemahkan aturan policy menjadi rule iptables atau program eBPF di node terkait.
- Pod siap berkomunikasi dengan Pod lain sesuai aturan konektivitas dan keamanan yang berlaku.
Proses ini terjadi otomatis dan berulang setiap kali Pod baru dibuat atau dihapus, sehingga admin cluster tidak perlu mengatur jaringan secara manual satu per satu.
Kesalahan yang Sering Terjadi
1. Menjalankan lebih dari satu CNI secara bersamaan tanpa perencanaan matang
- Penyebab: mencoba “upgrade” CNI tanpa proses migrasi yang benar
- Dampak: konflik alokasi IP, Pod gagal mendapatkan konektivitas, cluster menjadi tidak stabil
- Solusi: pastikan hanya satu CNI aktif dalam satu cluster; jika ingin beralih CNI, lakukan drain node secara bertahap dan ikuti panduan migrasi resmi
2. Mengasumsikan Flannel otomatis memberikan keamanan jaringan
- Penyebab: kurang memahami bahwa Flannel tidak memiliki fitur Network Policy native
- Dampak: semua Pod bisa saling mengakses tanpa batasan, meningkatkan risiko lateral movement saat terjadi insiden keamanan
- Solusi: kombinasikan dengan Calico (pola Canal) atau gunakan CNI lain yang mendukung Network Policy bila keamanan menjadi prioritas
3. Salah memilih backend Flannel untuk lingkungan cloud
- Penyebab: menggunakan backend
host-gwdi lingkungan cloud yang node-nya tidak berada dalam satu segmen Layer 2 - Dampak: Pod di node berbeda gagal saling terhubung
- Solusi: gunakan backend VXLAN untuk lingkungan cloud yang topologinya kompleks, dan
host-gwhanya jika seluruh node memang berada di L2 yang sama
4. Tidak memantau resource usage komponen CNI
- Penyebab: DaemonSet CNI (seperti
calico-nodeataukube-flannel) dianggap “ringan” sehingga jarang dipantau - Dampak: saat cluster membesar, komponen CNI bisa menjadi bottleneck CPU/memory di setiap node
- Solusi: pantau resource DaemonSet CNI secara berkala menggunakan
kubectl top pods -n kube-system
Tips dan Rekomendasi
- Gunakan Flannel untuk cluster development, edukasi, atau lingkungan yang tidak memerlukan isolasi jaringan ketat.
- Gunakan Calico ketika Anda membutuhkan Network Policy, integrasi BGP dengan infrastruktur jaringan yang sudah ada, atau dukungan node Windows.
- Pertimbangkan mode eBPF pada Calico jika performa menjadi prioritas utama sekaligus tetap membutuhkan Network Policy yang matang.
- Selalu uji perpindahan CNI di lingkungan staging terlebih dahulu sebelum diterapkan ke production, karena mengganti CNI pada cluster yang berjalan bersifat disruptif dan berisiko.
- Dokumentasikan setiap NetworkPolicy yang dibuat agar mudah diaudit oleh tim keamanan maupun tim operasional.
Kesimpulan
CNI seperti Calico dan Flannel memegang peran vital dalam memastikan komunikasi antar Pod berjalan lancar, baik dalam satu node maupun lintas node dalam cluster Kubernetes. Flannel unggul dari sisi kesederhanaan dan cocok untuk kebutuhan dasar, sementara Calico menawarkan kemampuan Network Policy yang jauh lebih matang serta fleksibilitas routing berbasis BGP — menjadikannya pilihan utama untuk lingkungan production yang mengutamakan keamanan.
Poin penting yang perlu diingat:
- CNI bertanggung jawab atas alokasi IP, routing, dan (opsional) enforcement Network Policy
- Flannel = sederhana, cepat setup, minim fitur keamanan native
- Calico = lebih kompleks, tapi kaya fitur keamanan dan routing tingkat lanjut
- Pemilihan CNI harus disesuaikan dengan kebutuhan skala, keamanan, dan kompleksitas infrastruktur
Frequently Asked Questions (FAQ)
Pertanyaan: Apa itu CNI dalam Kubernetes? Jawaban: CNI (Container Network Interface) adalah spesifikasi dan plugin yang mengatur konfigurasi jaringan Pod, termasuk alokasi IP, routing, dan penegakan network policy di dalam cluster Kubernetes.
Pertanyaan: Apa perbedaan utama Calico dan Flannel? Jawaban: Flannel berfokus pada kesederhanaan konektivitas overlay tanpa Network Policy native, sedangkan Calico menawarkan Network Policy lengkap, routing berbasis BGP, dan opsi dataplane eBPF untuk performa lebih tinggi.
Pertanyaan: Apakah Flannel bisa digunakan untuk keamanan jaringan production? Jawaban: Flannel sendiri tidak mendukung Network Policy, sehingga untuk kebutuhan keamanan production sebaiknya dikombinasikan dengan Calico (pola Canal) atau menggunakan CNI lain yang mendukung Network Policy.
Pertanyaan: Bisakah menjalankan dua CNI sekaligus dalam satu cluster? Jawaban: Tidak disarankan menjalankan dua CNI penuh secara bersamaan untuk mengelola jaringan Pod yang sama, karena berpotensi menyebabkan konflik IP dan routing; pengecualian hanya pada pola kombinasi khusus seperti Canal.
Pertanyaan: Kapan sebaiknya memilih Calico dibanding Flannel? Jawaban: Pilih Calico jika cluster Anda membutuhkan isolasi jaringan berbasis Network Policy, integrasi BGP dengan jaringan fisik, atau performa tinggi lewat eBPF; pilih Flannel jika prioritas utamanya adalah kesederhanaan setup.
Sudah lebih paham soal CNI Calico dan Flannel? Yuk, share pendapatmu di kolom komentar, tandai rekan timmu yang sedang belajar Kubernetes, dan bagikan artikel ini ke komunitas DevOps favoritmu.
Jangan lupa juga jelajahi artikel-artikel lain seputar Cloud Computing, Cybersecurity, dan Infrastruktur IT di website ini agar kamu selalu update dengan perkembangan teknologi terbaru!
