Belajar Calico - eBPF Dataplane Advanced

#Pendahuluan

Di episode 3 kita sempat menyinggung mode dataplane. Sekarang saatnya membedah eBPF secara menyeluruh: apa yang benar-benar berubah di kernel, keunggulan yang bisa kalian rasakan, biaya yang harus dibayar, dan kapan sebaiknya kalian mengaktifkannya.

eBPF adalah alasan utama sebagian orang memilih Cilium, tapi banyak yang tidak tahu bahwa Calico juga punya eBPF dataplane yang sangat matang. Dengan memahaminya, kalian bisa memilih dataplane berdasarkan kebutuhan, bukan gengsi.

#Prasyarat dan Aktivasi

#Prasyarat Kernel

eBPF menuntut kernel Linux modern dan konfigurasi yang sesuai:

Kernel 5.3+ untuk fitur dasar; 5.13+ untuk fitur terbaru
CONFIG_BPF                 -> y
CONFIG_BPF_SYSCALL         -> y
CONFIG_BPF_JIT             -> y
CONFIG_BPF_UNPRIV_DEFAULT_OFF -> y
CONFIG_DEBUG_INFO_BTF      -> y

BTF (BPF Type Format) wajib karena Calico memakai CO-RE. Cek prasyarat node dengan script resmi sebelum melanjutkan:

curl -LO https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/scripts/check-kernel-config
chmod +x check-kernel-config
./check-kernel-config /boot/config-$(uname -r)

#Mengaktifkan Mode eBPF

Aktivasi dilakukan lewat Installation, dan otomatis menonaktifkan kube-proxy:

kubectl patch installation default --type merge \
  -p '{"spec":{"dataplane":{"type":"BPF"}}}'
kubectl rollout restart ds/kube-proxy -n kube-system
kubectl get tigerastatus | grep -i bpf

dataplane.type: BPF menggantikan iptables dengan program eBPF. Karena eBPF menangani load balancing Service, kube-proxy di-scale ke nol atau dihapus.

#Keunggulan eBPF

#Direct Server Return (DSR)

Pada mode iptables, traffic yang kembali dari backend pod melewati node yang sama dengan node kube-proxy (client node), sehingga ada perjalanan ekstra. Dengan DSR, response dikirim langsung dari node backend ke client — jalur kembali lebih pendek, latensi turun, dan beban node front lebih ringan.

iptables:  client -> node A -> backend node B -> node A -> client
DSR:       client -> node A -> backend node B ------------> client

#Socket-Level Policy

eBPF memungkinkan policy dievaluasi pada saat socket dibuka, bukan saat paket lewat. Aplikasi bisa tahu hasil policy bahkan sebelum mengirim byte pertama, dan koneksi dari proses lokal bisa disaring lebih presisi.

#Load Balancing yang Lebih Kuat

Program eBPF melakukan load balancing Service di level kernel dengan dukungan untuk L4 dan beberapa L7, menggantikan chain iptables yang panjang.

#eBPF vs iptables/nftables

#Perbandingan Fungsional

Fitur                 iptables/nftables      eBPF
Kompatibilitas kernel sangat luas            butuh 5.3+ dan BTF
DSR                   tidak ada              ada
Socket policy         tidak ada              ada
Ganti kube-proxy      tidak                  ya
MTU                   normal                 sedikit lebih kecil
Migrasi               mudah                  perlu pelatihan

#Kompatibilitas Fitur

Tidak semua fitur Calico tersedia di eBPF pada awalnya; seiring versi, hampir semua sudah didukung. Yang perlu diperiksa: fitur yang berinteraksi dengan kube-proxy, host endpoints, dan beberapa mode encapsulation. Selalu baca release notes (episode 20) sebelum mengaktifkan.

#Verifikasi Dataplane Aktif

kubectl exec -n calico-system ds/calico-node -- calico-node --version
kubectl get ds -n kube-system kube-proxy
kubectl exec -n calico-system ds/calico-node -- sh -c "ls /sys/fs/bpf"

Mount /sys/fs/bpf yang ada dan kube-proxy yang nonaktif adalah tanda eBPF berjalan. Untuk konfirmasi dataplane aktif, jalankan kubectl get tigerastatus dan lihat status komponen calico-node.

#Kapan Mengaktifkan eBPF

#Skenario yang Cocok

• Klaster dengan traffic tinggi yang sensitif terhadap latensi dan membutuhkan DSR.
• Tim yang sudah terbiasa dengan kernel tuning dan punya prosedur upgrade node.
• Klaster yang ingin menghilangkan kube-proxy sebagai titik kegagalan.

#Skenario yang Belum Cocok

• Klaster berusia tua dengan kernel lama yang tidak mendukung BTF.
• Lingkungan yang tidak bisa mengganti kernel (managed nodes terkunci).
• Tim yang belum siap operasional — eBPF adalah perubahan besar, bukan sekadar toggle.

#Uji Bertahap

Pola penerapan yang aman: coba di klaster staging dengan beban sintetis, bandingkan metrik, lalu putuskan:

kubectl get pods -n calico-system -o wide
kubectl exec -n calico-system ds/calico-node -- sh -c \
  "curl -s localhost:9091/metrics | grep calico_felix_"

Metrik Felix (calico_felix_*) dari dua klaster yang identik bisa dibandingkan untuk mengukur overhead dataplane.

#Penutup

Episode 17 menutup topik eBPF: prasyarat kernel yang ketat, keunggulan DSR dan socket policy, perbandingan nyata dengan iptables/nftables, dan keputusan kapan mengaktifkannya berdasarkan kesiapan tim.

Inti yang harus dibawa pulang:

• eBPF butuh kernel 5.3+ dengan BTF dan konfigurasi BPF yang lengkap.
• DSR memperpendek jalur response dan menurunkan latensi.
• Socket-level policy menyaring koneksi sejak socket dibuka.
• eBPF menggantikan kube-proxy; pastikan klaster siap.
• iptables/nftables tetap valid untuk mayoritas klaster.
• Uji di staging dengan metrik sebelum berkomitmen di produksi.

Di episode 18 selanjutnya kita membahas GitOps dan policy as code — mengelola Installation, IPPool, BGPPeer, dan policy sebagai code dengan Argo CD atau Flux, lengkap dengan versioning, review flow, dan penerapan bertahap.