Belajar Cilium - Kube-Proxy Replacement & Service Mesh Dasar

#Pendahuluan

Di episode 4 kita melihat sekilas bagaimana Cilium menangani Service. Episode 8 membahas topik itu secara utuh: kube-proxy replacement. Sejak awal series kita menyebut bahwa kube-proxy berbasis iptables tidak skalabel — sekarang saatnya membuktikan dan melihat penggantinya bekerja.

Kita akan membahas bagaimana Cilium mereplikasi semua tipe Service lewat eBPF, apa itu socket load balancing, session affinity, DSR (Direct Server Return), serta konfigurasi kube-proxy-replacement: strict dan interaksinya dengan cloud load balancer.

Catatan awal: kube-proxy replacement bersifat transparan terhadap workload. Pod dan Service tetap bekerja dengan cara yang sama; yang berubah adalah jalur di dalam kernel. Inilah salah satu fitur Cilium yang paling sering membuat orang ragu sebelum mencoba, padahal risiko kegagalannya bisa diukur dengan cilium connectivity test.

#Mengapa Mengganti kube-proxy

kube-proxy menerjemahkan Service menjadi aturan iptables atau ipvs di setiap node. Masalah utama iptables: setiap kali Service berubah, seluruh chain harus diperbarui — operasi yang mahal di cluster besar. Ditambah lagi, setiap paket harus melewati banyak rule sebelum menemukan yang cocok.

Cilium menggantinya dengan tabel hash di eBPF: satu entri service, satu lookup, langsung menuju backend terpilih. Tidak ada chain panjang dan tidak ada pembaruan masif. Ketika Service baru dibuat, Cilium hanya menambahkan satu baris ke tabel kernel — operasi yang hampir instan berapa pun ukuran cluster.

Ada alasan lain yang lebih halus: prediktabilitas. Di kube-proxy berbasis iptables, pembaruan aturan terjadi secara batch, dan dalam periode singkat itu sebagian paket bisa melihat state yang tidak konsisten — sebagian Service lama, sebagian baru. Di Cilium, setiap entri Service diperbarui secara atomik di tabel kernel, sehingga tidak ada periode transisi di mana perilaku tidak menentu.

Perlu juga dicatat bahwa kube-proxy replacement tidak hanya soal performa. Ia menyederhanakan stack jaringan: satu komponen yang lebih sedikit untuk dioperasikan, dipantau, dan di-debug. Mengurangi jumlah moving part adalah kemenangan operasional yang tidak selalu terlihat di benchmark.

#Socket Load Balancing

Salah satu keunggulan eBPF yang tidak bisa ditiru iptables: socket load balancing. Untuk koneksi di dalam node yang sama, Cilium bisa melakukan load balancing langsung di level socket, bahkan sebelum paket meninggalkan proses aplikasi. Artinya, komunikasi antar pod di node yang sama tidak perlu melewati jalur kernel jaringan yang penuh — hasilnya latensi yang sangat rendah.

Mekanisme ini otomatis aktif ketika kube-proxy replacement aktif. Kalian tidak perlu mengubah kode aplikasi apa pun; yang berubah hanyalah jalur yang ditempuh paket di dalam kernel. Detail implementasinya bisa dilihat lewat cilium-dbg bpf lb list di dalam pod agent:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg bpf lb list

cilium-dbg bpf lb list menampilkan entri load balancing di dataplane: IP service, port, backend, dan kesehatan backend. Bandingkan dengan kubectl get svc — keduanya harus sinkron.

Satu catatan penting: socket load balancing hanya aktif untuk koneksi yang bisa dioptimalkan di level socket — biasanya komunikasi antar pod di node yang sama. Untuk traffic yang melintasi node atau masuk dari luar, jalur tetap melalui program eBPF di hook jaringan. Jadi optimasi ini melengkapi, bukan menggantikan, load balancing di jalur umum.

#Session Affinity dan DSR

Session affinity memastikan koneksi dari satu client selalu diarahkan ke backend yang sama selama periode tertentu. Ini penting untuk aplikasi dengan state di memori. Aktifkan seperti biasa di Service Kubernetes, dan Cilium menerapkannya di tabel eBPF:

apiVersion: v1
kind: Service
metadata:
  name: svc-affinity
spec:
  selector:
    app: frontend
  ports:
    - port: 80
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 600

sessionAffinity: ClientIP memberitahu Cilium untuk mempertahankan backend yang sama bagi source IP yang sama. Implementasinya berjalan di kernel, jadi tidak menambah latensi yang berarti.

Satu hal yang sering ditanyakan: apakah session affinity bisa dikombinasikan dengan load balancing yang seimbang? Jawabannya ya, dengan trade-off. Session affinity membuat distribusi bergantung pada pola source IP; jika satu client mendominasi traffic, backend yang dipilihnya akan menerima beban lebih. Untuk beban yang merata, biarkan session affinity mati; aktifkan hanya ketika aplikasi memang membutuhkannya.

DSR (Direct Server Return) adalah teknik di mana respon dari backend kembali ke client secara langsung tanpa melewati node yang menerima request awal. Ini menghindari bottleneck di node ingress dan memotong satu hop per koneksi. Cilium mendukung DSR untuk traffic dari luar cluster ketika mode dsr diaktifkan.

#kube-proxy-replacement: strict

Mode strict adalah konfigurasi di mana Cilium sepenuhnya mengambil alih tugas kube-proxy. Tidak ada lagi iptables kube-proxy yang bekerja; semua Service ditangani oleh dataplane eBPF. Aktifkan saat install:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=strict

helm upgrade cilium cilium/cilium menerapkan perubahan konfigurasi tanpa menginstall ulang. Setelah upgrade, verifikasi statusnya:

cilium status | grep KubeProxyReplacement

cilium status | grep KubeProxyReplacement harus menampilkan mode Strict. Pada mode ini, daemonset kube-proxy bisa dihapus untuk menghemat sumber daya, meskipun membiarkannya juga aman selama tidak mengganggu.

Penting diketahui: dalam mode strict, Cilium tetap bekerja dengan cloud load balancer (AWS ELB, GCP LB, Azure LB). Load balancer cloud menunjuk ke port NodePort pada node, dan dataplane eBPF yang meneruskan traffic ke backend. Kalian tidak perlu mengubah cara kerja ingress eksternal sama sekali.

#Memverifikasi Penggantian kube-proxy

Setelah upgrade ke mode strict, jangan langsung percaya pada konfigurasi — verifikasi dari beberapa sudut pandang:

cilium status | grep KubeProxyReplacement
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg status --brief

cilium status | grep KubeProxyReplacement menampilkan mode yang aktif. cilium-dbg status --brief menampilkan ringkasan langsung dari dalam node, termasuk status KubeProxyReplacement dan BPF LoadBalancing — dua baris yang harus menunjukkan status aktif.

Langkah verifikasi yang paling meyakinkan adalah mematikan kube-proxy untuk sementara dan mengamati apakah Service tetap berfungsi:

kubectl scale ds kube-proxy -n kube-system --replicas=0
cilium connectivity test
kubectl scale ds kube-proxy -n kube-system --replicas=1

kubectl scale ds kube-proxy -n kube-system --replicas=0 menghentikan sementara daemon kube-proxy. Jika cilium connectivity test tetap lulus, dataplane eBPF benar-benar mengambil alih. Ingatlah untuk menaikkan kembali replika setelah uji selesai di environment lab.

Catatan penting untuk cluster yang memakai ipvs: kube-proxy berbasis iptables dan ipvs punya perilaku berbeda saat mati. Cilium mengelola transisi ini secara eksplisit, sehingga skenario di atas aman dilakukan di lab — tetapi di production, lakukan uji ini pada maintenance window dan siapkan rollback sebelum mematikan komponen lama.

#Penutup

Inti yang harus dibawa pulang:

• Kube-proxy replacement mengganti chain iptables dengan tabel hash eBPF.
• Socket load balancing memperpendek jalur paket antar pod di node yang sama.
• Session affinity diimplementasikan langsung di dataplane lewat sessionAffinity: ClientIP.
• DSR memotong satu hop untuk respon traffic dari luar cluster.
• Mode strict membuat Cilium sepenuhnya menggantikan kube-proxy.
• Cloud load balancer tetap bekerja normal di atas kube-proxy replacement.

Di episode 9 selanjutnya kita akan membahas IPAM (IP Address Management) — mode cluster-pool, Multi-Pool yang stabil di versi 1.19, mode cloud-native seperti ENI dan Azure, serta dukungan dual-stack IPv4 dan IPv6. Pemilihan mode IPAM menentukan kapasitas pod per node dan strategi pengalamatan seluruh cluster kalian.