Belajar Cilium - Performance & Troubleshooting

#Pendahuluan

Pada titik ini kalian sudah tahu cara memasang dan mengkonfigurasi Cilium. Episode 19 membalik perspektif: apa yang terjadi ketika semuanya berjalan tidak sesuai harapan? Networking di level kernel sulit dilihat mata, jadi Cilium menyediakan perangkat diagnostik khusus untuk membedah masalah.

Kita akan memakai cilium-dbg untuk membaca endpoint, identity, dan policy; cilium-bugtool untuk mengumpulkan data diagnostik; cilium monitor untuk memantau traffic langsung di dataplane; serta mempelajari pola pemecahan masalah yang paling sering muncul di production.

Sebuah disiplin yang akan kita pakai sepanjang episode ini: diagnosa sebelum tindakan. Sebagian besar insiden networking bisa diselesaikan hanya dengan membaca data dengan benar — bukan dengan mengganti-ganti konfigurasi secara membabi buta. Semua alat yang kita pakai hari ini berfungsi untuk menghasilkan data itu.

#Alat Diagnostik: cilium-dbg

cilium-dbg (dulu bernama cilium-agent) adalah command yang berjalan di dalam pod agent. Setiap subcommand membaca keadaan dataplane pada node tersebut. Tiga perintah yang paling sering dipakai:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg endpoint list
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg identity list
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg policy get

cilium-dbg policy get menampilkan policy yang aktif beserta identitas yang diizinkan. Ketika sebuah pod tidak bisa berkomunikasi, urutan diagnosis dimulai dari sini: apakah endpoint ada, apakah identity terisi, dan apakah policy mengizinkan pasangan identity yang dituju.

Selain tiga perintah utama di atas, cilium-dbg punya banyak subcommand lain: cilium-dbg status untuk kesehatan node, cilium-dbg bpf policy get untuk melihat policy di level bpf map, dan cilium-dbg troubleshoot untuk memeriksa konektivitas dari perspektif kernel. Jelajahi subcommand yang ada; setiap perintah adalah jendela menuju lapisan dataplane yang berbeda.

#Alur Diagnosa yang Disarankan

#Urutan Langkah yang Disarankan

Ketika sebuah aplikasi tidak bisa terhubung, ikuti urutan ini agar tidak melewatkan penyebab:

1. Amati flow dengan hubble observe --verdict DROPPED untuk melihat apakah paket di-drop.
2. Jika di-drop, baca drop reason dan identitas yang terlibat.
3. Periksa policy dengan cilium-dbg policy get untuk membandingkan rule yang aktif.
4. Periksa endpoint dengan cilium-dbg endpoint list untuk memastikan identity terisi.
5. Jika endpoint bermasalah, cek log agent dan operator untuk petunjuk awal.

Urutan ini menangani kasus paling umum dari atas ke bawah: dari gejala (drop) ke akar (policy, identity, atau konfigurasi). Jangan mulai dari bawah — memeriksa konfigurasi tanpa melihat gejala biasanya menghabiskan waktu tanpa hasil.

#cilium-bugtool dan cilium monitor

Ketika masalah sulit ditebak, kumpulkan data sebanyak mungkin dengan cilium-bugtool — perintah ini menghasilkan tarball berisi status, log, dan snapshot dataplane:

kubectl exec -n kube-system -it ds/cilium -- cilium-bugtool

cilium-bugtool membuat arsip yang bisa dibagikan ke rekan tim atau dikirim ke maintainer Cilium. Bundle ini memuat log agent, state endpoint, policy, dan konfigurasi kernel yang relevan — jauh lebih lengkap daripada sekadar menyalin output satu perintah.

Untuk mengamati traffic secara langsung di jalur data, gunakan cilium monitor:

kubectl exec -n kube-system -it ds/cilium -- cilium monitor

cilium monitor menampilkan event dataplane secara real-time: paket yang diterima, di-forward, dan di-drop beserta alasan. Ini alat yang tepat ketika kalian mencurigai masalah ada di kernel, bukan di aplikasi.

Jika output cilium monitor terlalu banyak (karena memang memantau semua traffic node), kombinasikan dengan filter: cilium monitor --type drop hanya menampilkan event drop, dan cilium monitor --type policy-verdict menampilkan keputusan policy saja. Filter ini membuat aliran event yang bising menjadi bisa dibaca.

#hubble observe --verdict DROPPED

Kombinasi paling efektif untuk masalah policy: amati drop dari Hubble, lalu bandingkan dengan policy yang aktif. Pola ini sudah kita kenal dari episode 7:

hubble observe --verdict DROPPED --since 30m

hubble observe --verdict DROPPED --since 30m menampilkan setiap flow yang ditolak lengkap dengan alasan, biasanya Policy denied. Dari sini, kalian tahu persis pasangan identity mana yang diblokir, dan bisa memutuskan: perbaiki policy, atau ternyata aplikasi memang berusaha mengakses yang tidak seharusnya.

Penting juga memahami perbedaan sumber data: cilium monitor membaca event langsung dari dataplane node tempat perintah dijalankan, sedangkan hubble observe membaca dari relay yang menggabungkan semua node. Untuk masalah yang terbatas pada satu node, cilium monitor lebih langsung; untuk masalah yang tersebar, hubble observe memberi gambaran menyeluruh.

#Troubleshooting Umum

Beberapa masalah yang paling sering ditemui dan pola penyelesaiannya:

• Policy menolak traffic: periksa cilium-dbg policy get, cocokkan identity sumber dan tujuan, lalu pastikan rule selector memang mencakup label yang dipakai. Perluas selector atau tambah rule sesuai kebutuhan.
• Identity hilang atau berlabel salah: pod baru terkadang belum dapat identity. Periksa cilium-dbg endpoint list dan log operator; pastikan label pod benar karena identity diturunkan dari label.
• IPAM kehabisan pool: cilium-dbg ipam list menunjukkan alokasi yang penuh. Solusinya menambah pool, mengecilkan mask per node, atau menggunakan Multi-Pool (episode 9).
• Upgrade antar minor: ikuti Upgrade Guide resmi; biasanya aman melompat satu minor, dan setiap upgrade harus diuji dengan cilium connectivity test.
• Masalah kernel atau eBPF: cek versi kernel dan ls /sys/kernel/btf. Kernel yang terlalu tua membuat fitur eBPF gagal di-load — gejala paling umumnya pod Cilium crash-loop.

Satu lagi masalah yang sering muncul: gejala yang tampak seperti masalah Cilium ternyata bukan masalah Cilium sama sekali. Sebelum menyalahkan dataplane, pastikan alur dasar sudah benar — pod berjalan, service selector cocok, dan nama DNS yang dipakai memang valid. Banyak "insiden networking" berakhir sebagai salah penulisan nama service atau selector yang tidak cocok.

#Skenario Latihan: Pod Tidak Bisa Terhubung

Mari kita praktikkan alur di atas dalam satu skenario lengkap. Sebuah pod frontend tidak bisa mengakses pod backend. Jalankan diagnosis berurutan:

kubectl get pods -o wide
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg endpoint list
hubble observe --verdict DROPPED --since 10m

kubectl get pods -o wide memastikan kedua pod benar-benar berjalan dan mendapat IP. cilium-dbg endpoint list memeriksa apakah kedua pod terdaftar sebagai endpoint dengan identity yang terisi. hubble observe --verdict DROPPED --since 10m menunjukkan apakah paket di-drop dan oleh policy mana.

Jika flow yang di-drop menunjukkan pasangan identity yang seharusnya diizinkan, langkah berikutnya adalah memeriksa policy:

kubectl exec -n kube-system -it ds/cilium -- cilium-dbg policy get
kubectl get cnp -A
kubectl get ccnp

cilium-dbg policy get menampilkan policy yang aktif dari sisi dataplane. kubectl get cnp -A dan kubectl get ccnp menampilkan resource policy dari sisi control plane. Bandingkan keduanya: jika policy ada di control plane tapi tidak muncul di dataplane, ada masalah sinkronisasi — dan jika tidak ada di keduanya, masalahnya di tempat lain, misalnya namespace yang salah atau label selector yang tidak cocok.

Pola latihan seperti ini — dengan workload tiruan di namespace terpisah — adalah cara terbaik membangun refleks troubleshooting sebelum insiden nyata. Ulangi dengan variasi: pod sengaja diberi label salah, policy sengaja dibatasi port, dan identity sengaja dibuat kosong. Semakin banyak skenario yang pernah kalian lihat, semakin cepat kalian membaca gejala di production.

#Penutup

Inti yang harus dibawa pulang:

• cilium-dbg endpoint list, identity list, dan policy get adalah perintah diagnosis pertama.
• cilium-bugtool menghasilkan bundle diagnostik lengkap untuk dibagikan.
• cilium monitor mengamati event dataplane secara real-time.
• hubble observe --verdict DROPPED mengungkap alasan penolakan traffic.
• Policy, identity, dan IPAM adalah tiga area masalah paling umum.
• Selalu uji upgrade dengan cilium connectivity test.

Di episode 20 selanjutnya kita akan membahas fitur stabil terbaru Cilium 1.19 dan 1.20 — penyempurnaan Network Policy, Multi-Pool IPAM yang stabil, progres IPv6, ztunnel transparent encryption, MCS API yang stabil untuk ClusterMesh, serta pembaruan dataplane dan Hubble. Ini membawa kalian ke tepi perkembangan Cilium terkini.