CNI Plugin #
Container Network Interface (CNI) adalah standar yang mendefinisikan bagaimana program eksternal — disebut plugin — mengonfigurasi jaringan untuk container. Kubernetes tidak mengimplementasikan jaringan sendiri; ia mendelegasikan seluruh pekerjaan itu ke CNI plugin yang kamu pilih saat setup cluster. Pilihan CNI plugin punya dampak nyata pada performa, fitur (terutama NetworkPolicy), dan kemudahan operasional.
Apa yang Dilakukan CNI Plugin #
Setiap kali sebuah Pod dibuat atau dihapus, kubelet memanggil CNI plugin untuk mengerjakan tugas jaringan:
Saat Pod dibuat:
kubelet → panggil CNI plugin
CNI plugin:
1. Buat network namespace untuk Pod
2. Buat virtual ethernet pair (veth)
3. Hubungkan satu ujung veth ke namespace Pod, ujung lain ke bridge node
4. Alokasikan IP dari Pod CIDR
5. Konfigurasi routing agar Pod bisa komunikasi lintas node
6. Terapkan NetworkPolicy jika didefinisikan
Saat Pod dihapus:
kubelet → panggil CNI plugin
CNI plugin:
1. Hapus interface jaringan
2. Bebaskan IP ke pool
3. Hapus aturan routing terkait
Perbandingan CNI Plugin Populer #
Flannel #
Plugin paling sederhana. Fokus pada satu hal: memastikan Pod bisa berkomunikasi lintas node. Tidak ada fitur canggih lain.
Flannel:
Cara kerja: VXLAN overlay (default) atau host-gw
NetworkPolicy: TIDAK mendukung (butuh Calico atau plugin lain untuk NetworkPolicy)
Performa: overhead VXLAN mengurangi throughput ~10-20%
Instalasi: sangat mudah
Gunakan jika:
✓ Cluster sederhana yang tidak butuh NetworkPolicy
✓ Ingin instalasi yang paling mudah
✓ Resource node terbatas
Jangan gunakan jika:
✗ Butuh NetworkPolicy
✗ Cluster produksi dengan kebutuhan keamanan
Calico #
Plugin yang paling banyak digunakan di produksi. Mendukung NetworkPolicy secara penuh dan punya mode performa tinggi dengan BGP routing.
Calico:
Cara kerja: BGP native routing (tanpa overlay) atau IP-in-IP/VXLAN
NetworkPolicy: MENDUKUNG penuh, bahkan punya CiliumNetworkPolicy yang lebih canggih
Performa: sangat baik dengan mode BGP (tidak ada overhead overlay)
Observability: cukup, tapi butuh tools tambahan untuk detail
Gunakan jika:
✓ Butuh NetworkPolicy yang kuat
✓ Cluster produksi skala menengah-besar
✓ Environment on-premise dengan kontrol jaringan penuh
✓ Performa tinggi dengan BGP mode
Trade-off:
→ BGP butuh integrasi dengan router fisik
→ Lebih kompleks dari Flannel
Cilium #
Plugin generasi terbaru yang menggunakan eBPF (extended Berkeley Packet Filter) — teknologi kernel Linux modern yang memungkinkan program berjalan langsung di kernel tanpa overhead syscall.
Cilium:
Cara kerja: eBPF (tidak ada iptables, tidak ada kube-proxy!)
NetworkPolicy: MENDUKUNG penuh + Layer 7 (HTTP, gRPC, Kafka)
Performa: terbaik di antara semua CNI, eBPF lebih efisien dari iptables
Observability: luar biasa — Hubble UI untuk real-time network flow visualization
Service mesh: built-in service mesh capabilities
Gunakan jika:
✓ Cluster modern yang butuh performa maksimal
✓ Butuh Layer 7 NetworkPolicy (filter by HTTP path, method)
✓ Butuh observability jaringan yang detail
✓ Ingin menggantikan kube-proxy (eBPF mode)
✓ Cluster besar (ratusan node)
Trade-off:
→ Butuh kernel Linux >= 4.9 (4.19+ direkomendasikan)
→ Lebih kompleks untuk di-setup dan di-troubleshoot
→ Resource lebih tinggi dari Flannel/Calico
Weave Net #
Weave Net:
Cara kerja: VXLAN overlay atau fast datapath
NetworkPolicy: MENDUKUNG
Performa: menengah
Fitur unik: enkripsi jaringan antar node built-in
Gunakan jika:
✓ Butuh enkripsi jaringan antar node secara mudah
✓ Cluster hybrid (on-premise + cloud)
Tabel Perbandingan #
Flannel Calico Cilium Weave
─────────────────────────────────────────────────────────
NetworkPolicy ✗ ✓ ✓✓ ✓
Layer 7 Policy ✗ ✗ ✓ ✗
Performa Cukup Baik Sangat Baik Cukup
eBPF ✗ Sebagian ✓ ✗
Observability Minim Menengah Luar Biasa Menengah
Enkripsi ✗ ✓ (WireGuard) ✓ (WireGuard) ✓ built-in
Setup Mudah Menengah Kompleks Mudah
On-premise BGP ✗ ✓ ✓ ✗
Instalasi CNI Plugin #
Sebagian besar CNI plugin di-install via manifest YAML atau Helm chart:
# Calico
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.0/manifests/calico.yaml
# Flannel
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
# Cilium (via Helm, direkomendasikan)
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
--namespace kube-system \
--set kubeProxyReplacement=strict # gantikan kube-proxy dengan eBPF
Mengganti CNI Plugin #
Mengganti CNI plugin di cluster yang sudah berjalan adalah operasi berisiko dan disruptif:
Langkah umum (dengan downtime):
1. Drain semua node (evict semua Pod)
2. Hapus CNI plugin lama:
- Hapus DaemonSet
- Hapus konfigurasi /etc/cni/net.d/ di setiap node
- Hapus binary di /opt/cni/bin/ di setiap node
3. Install CNI plugin baru
4. Uncordon semua node
5. Verifikasi Pod bisa komunikasi antar node
Tidak ada cara hot-swap CNI plugin tanpa downtime.
Rencanakan jendela maintenance yang cukup.
Ringkasan #
- CNI plugin = implementasi jaringan Pod — Kubernetes mendelegasikan semua jaringan ke plugin; buat network namespace, alokasikan IP, konfigurasi routing.
- Flannel untuk simplicity, Calico untuk produksi, Cilium untuk modern — pilih berdasarkan kebutuhan NetworkPolicy, performa, dan observability.
- Cilium eBPF memberikan performa terbaik — menggantikan iptables dan kube-proxy dengan eBPF yang lebih efisien; cocok untuk cluster besar yang butuh performa maksimal.
- NetworkPolicy butuh CNI yang mendukung — Flannel tidak mendukung NetworkPolicy; gunakan Calico, Cilium, atau Weave jika butuh isolasi jaringan antar Pod.
- Layer 7 policy hanya Cilium — jika perlu filter traffic berdasarkan HTTP path, method, atau gRPC service, Cilium adalah satu-satunya pilihan native.
- Ganti CNI plugin membutuhkan downtime — rencanakan dengan matang; tidak ada hot-swap; ini alasan mengapa pilihan CNI di awal setup cluster sangat penting.
← Sebelumnya: Load Balancing & kube-proxy Berikutnya: Service Mesh →