Belajar Cilium - Bandwidth Management & QoS

#Pendahuluan

Di cluster yang padat, satu workload yang rakus bandwidth bisa menyiksa workload lain di node yang sama. Episode 11 membahas alat Cilium untuk menangani ini: bandwidth manager berbasis eBPF. Dengan bandwidth manager, kalian bisa menetapkan batas throughput per pod, memakai pacing BBR untuk efisiensi, dan mengamati hasilnya langsung dari dataplane.

Topik ini masuk kategori QoS (Quality of Service). Tidak seperti CPU dan memory yang diatur oleh scheduler Kubernetes, bandwidth selama ini sulit dikontrol di level CNI. Cilium mengubah situasi itu dengan memindahkan enforcement ke dalam kernel lewat eBPF.

Topik ini sering dianggap niche, padahal dampaknya terasa setiap hari. Di cluster yang dipakai banyak tim, satu workload yang membebani jaringan bisa merusak SLO seluruh tenant di node yang sama. Bandwidth manager memberi kalian alat untuk menetapkan batas — dan yang tidak kalah penting, cara mengukur apakah batas itu ditegakkan.

#Bandwidth Manager berbasis eBPF

Bandwidth manager adalah fitur Cilium yang mengaktifkan qdisc (queue discipline) eBPF di setiap pod. Alih-alih memakai mekanisme QoS klasik yang berat, Cilium meng-attach program eBPF yang membatasi kecepatan transmisi secara langsung. Hasilnya, batas bandwidth diberlakukan dengan overhead minimal dan akurasi tinggi.

Aktifkan bandwidth manager saat install:

cilium install --set bandwidthManager.enabled=true

cilium install --set bandwidthManager.enabled=true mengaktifkan fitur ini. Untuk kernel 5.18 ke atas, Cilium otomatis memakai FQ-BBR yang lebih modern; pada kernel yang lebih lama, ia memakai algoritma fallback yang tetap membatasi bandwidth dengan baik.

#Pacing dengan BBR

BBR (Bottleneck Bandwidth and Round-trip propagation time) adalah algoritma congestion control Google yang fokus pada throughput, bukan sekadar menghindari kehilangan paket. Dalam konteks bandwidth manager, BBR melakukan pacing: paket dilepaskan secara bertahap sesuai kecepatan yang ditentukan, alih-alih dikirim dalam burst.

Hasil pacing BBR: penggunaan bandwidth lebih halus, buffer kecil, dan throughput yang konsisten — terutama untuk traffic dengan latensi tinggi. Karena pacing dijalankan di kernel oleh eBPF, aplikasi tidak perlu diubah sama sekali. Kalian hanya perlu menetapkan batas, dan kernel yang menjalankannya.

Satu keuntungan praktis BBR yang patut dipahami: ia mengurangi kehilangan paket. Algoritma congestion control klasik (Reno atau CUBIC) bereaksi terhadap paket hilang, sehingga dalam jaringan dengan buffer kecil mereka bisa menyebabkan penurunan throughput yang tidak perlu. BBR mengukur bottleneck secara proaktif, sehingga mencapai throughput tinggi dengan lebih sedikit paket terbuang — hasil yang bagus untuk bandwidth yang dibatasi sekalipun.

#Annotation kubernetes.io/egress-bandwidth

Cara termudah menetapkan batas bandwidth per pod adalah dengan annotation di pod atau deployment. Annotation ini sudah dikenali Kubernetes dan ditangkap oleh Cilium bandwidth manager:

apiVersion: v1
kind: Pod
metadata:
  name: pod-limit
  annotations:
    kubernetes.io/egress-bandwidth: "10M"
spec:
  containers:
    - name: nginx
      image: nginx

kubernetes.io/egress-bandwidth: "10M" membatasi traffic keluar pod menjadi 10 megabit per detik. Nilai ditulis sebagai string dengan satuan yang jelas, misalnya 1M, 10M, atau 1G. Cilium membaca annotation ini saat pod dibuat dan menerapkan qdisc yang sesuai di veth pod.

Perhatikan format nilainya: nilai harus ditulis sebagai string karena dipakai oleh admission dari annotation Kubernetes, bukan angka numerik. Kesalahan umum adalah menulis 10 tanpa satuan atau 10MB dengan huruf besar — pastikan memakai format yang dikenali, yaitu angka diikuti satuan biner seperti M atau G.

#Memahami egress-bandwidth vs QoS Kubernetes

#Hubungan dengan QoS Kubernetes

Kubernetes punya konsep QoS untuk CPU dan memory (Guaranteed, Burstable, BestEffort), tapi tidak untuk jaringan. Annotation kubernetes.io/egress-bandwidth adalah jembatan: ia memakai format yang sama dengan annotation QoS lain, dan Cilium yang mengeksekusinya di dataplane.

Perlu diingat bahwa annotation ini hanya mengatur egress, bukan ingress. Untuk mengatur ingress bandwidth, kalian harus memakai mekanisme lain di luar pod — misalnya batas di load balancer atau shape traffic di gateway. Ini asimetri yang sering mengejutkan tim yang baru pertama kali memakai fitur ini.

#Verifikasi Rate Limit

Untuk membuktikan bahwa limit benar-benar berlaku, kita bisa mengamati dari dataplane dan mengukur throughput langsung. Cek tabel bandwidth di dalam pod agent:

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

cilium-dbg bpf bandwidth list menampilkan entri bandwidth manager: identity endpoint, alamat, dan batas yang diterapkan. Jika pod pod-limit muncul dengan nilai 10M, berarti qdisc sudah aktif.

Pengukuran yang lebih nyata: jalankan download dari dalam pod dan amati kecepatannya:

kubectl exec pod-limit -- sh -c "wget -qO /dev/null http://speedtest-berat:80/file.bin"

Perintah di atas akan men-download file besar dan throughput-nya dibatasi sekitar nilai annotation. Bandingkan dengan pod tanpa annotation yang sama — pod tersebut harus bisa mencapai kecepatan jauh lebih tinggi. Dampak terhadap latensi juga bisa diamati: batas yang terlalu rendah akan menambah antrian di qdisc, yang terlihat sebagai peningkatan RTT di ping.

Untuk pengukuran yang lebih teliti, kalian bisa memakai alat seperti iperf3 jika tersedia di image pod. Jalankan server iperf di satu pod dan client di pod yang dibatasi, lalu bandingkan hasilnya dengan pod tanpa annotation. Perbedaan angka inilah bukti bahwa bandwidth manager benar-benar menegakkan batas di jalur data.

#Prasyarat Kernel dan Qdisc

Bandwidth manager bergantung pada kemampuan kernel, jadi periksa dulu apakah node mendukung fitur yang dibutuhkan:

uname -r
cat /sys/module/sch_fq/parameters/nopacing 2>/dev/null || echo "modul belum dimuat"
tc qdisc show dev eth0

uname -r menampilkan versi kernel; untuk FQ-BBR, Cilium memerlukan kernel 5.18 ke atas. tc qdisc show dev eth0 menampilkan queue discipline pada interface — ketika bandwidth manager aktif, kalian akan melihat qdisc eBPF terpasang di interface veth pod.

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg status | grep -i bandwidth

cilium-dbg status | grep -i bandwidth menampilkan status bandwidth manager pada node tersebut. Jika baris ini tidak muncul atau menampilkan kondisi nonaktif, periksa versi kernel dan nilai bandwidthManager.enabled di Helm — dua penyebab paling umum sebelum fitur bekerja.

Satu praktik yang layak ditanamkan: dokumentasikan batas bandwidth yang kalian terapkan beserta alasannya, misalnya dalam komentar manifest atau halaman dokumentasi platform. Ketika nanti ada tanya jawab "mengapa pod ini dibatasi 10M?", jawabannya harus bisa ditemukan di repository, bukan di ingatan — prinsip yang sama dengan episode 18 tentang GitOps.

#Penutup

Inti yang harus dibawa pulang:

• Bandwidth manager menerapkan batas bandwidth per pod lewat qdisc eBPF.
• BBR melakukan pacing agar transmisi halus dan throughput konsisten.
• Annotation kubernetes.io/egress-bandwidth menetapkan batas egress per pod.
• cilium-dbg bpf bandwidth list menampilkan entri bandwidth yang aktif.
• Verifikasi limit dengan mengukur throughput dari dalam pod.
• Batas yang terlalu ketat menaikkan latensi karena antrian penuh.

Di episode 12 selanjutnya kita akan membahas egress dan ingress gateway — bagaimana CiliumEgressGatewayPolicy menyatukan traffic keluar lewat IP tertentu untuk NAT, serta bagaimana CiliumIngressGateway dan integrasi Gateway API membuka pintu masuk ke cluster. Ini menghubungkan networking internal kita dengan dunia luar.