Belajar Calico - Observability Dasar

#Pendahuluan

Sebuah CNI yang "sehat" tidak cukup dirasakan — harus bisa dibuktikan. Episode 7 membekali kalian cara membaca kondisi Calico: dari perintah debugging satu baris hingga metrik Prometheus yang bisa dipajang di dashboard.

Observability Calico bekerja di tiga lapis: status (apakah komponen hidup dan BGP up), policy state (apa yang diterapkan ke workload mana), dan dataplane (apakah rule benar-benar terpasang). Kalian akan bisa menjawab pertanyaan "kenapa pod tidak bisa saling akses?" dengan data, bukan tebakan.

#Debugging dengan calicoctl

#Status Node dan BGP

Perintah pertama yang harus dihafal adalah calicoctl node status:

calicoctl node status

Output yang diharapkan:

Calico process is running.
 
IPv4 BGP status
+--------------+-------------------+-------+----------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+--------------+-------------------+-------+----------+-------------+
| 172.18.0.2   | node-to-node mesh | up    | 10:20:05 | Established |
+--------------+-------------------+-------+----------+-------------+

Kolom STATE berisi up atau down, dan kolom INFO biasanya Established. Jika Established tidak muncul, BGP belum selesai — episode 8 dan 19 akan membahasnya.

#Memeriksa Resource Dataplane

Kumpulan perintah berikut adalah starter kit observasi Calico:

calicoctl get nodes
calicoctl get ippool -o wide
calicoctl get workloadendpoints -A
calicoctl get networkpolicy -A
calicoctl get felixconfiguration default -o yaml

calicoctl get workloadendpoints -A menampilkan endpoint pod beserta node, IP, dan interface-nya. Kalau sebuah pod tidak muncul di sini, berarti Calico belum melihat pod itu — biasanya karena masalah kubelet atau CNI.

#Flow Logs

#Apa Itu Flow Logs

Flow logs adalah catatan koneksi yang dihasilkan Calico — siapa bicara ke siapa, port apa, dan apakah diizinkan atau ditolak. Di Calico Open Source, flow logs tersedia lewat integrasi Fluentd, sementara edisi yang lebih lengkap memakai log pipeline terkelola. Pola yang digunakan sama: ambil log dataplane, kirim ke pipeline, lalu tampilkan.

Contoh mengikuti log Felix di tiap node untuk melihat aksi yang diambil:

kubectl logs -n calico-system ds/calico-node | grep -iE "action|deny|allow"

Grep "action|deny|allow" akan menampilkan baris yang mencatat keputusan policy di dataplane. Ini jalan pintas terbaik sebelum membangun pipeline log yang penuh.

#Metrik Prometheus

#Metrik Felix dan Typha

Felix dan Typha mengekspos metrik Prometheus di port 9091/metrics. Aktifkan dulu dengan menandai pod agar bisa di-scrape, lalu akses langsung dari dalam pod:

kubectl exec -n calico-system ds/calico-node -- sh -c \
  "curl -s localhost:9091/metrics | grep calico_felix"

Metrik penting yang dipantau:

• calico_felix_iptables_total_*: jumlah rule yang terpasang per chain.
• calico_felix_active_local_endpoints: endpoint aktif di node ini.
• calico_felix_num_...: angka global yang menunjukkan kesehatan Felix.
• Metrik Typha dengan prefix typha_: jumlah klien dan error koneksi.

#Service Monitoring

Untuk scraping otomatis, matikan pod label dari service monitor (pola umum dengan kube-prometheus-stack). Service yang mengekspos metrik biasanya diberi nama felix-metrics-svc dan typha-metrics-svc di namespace calico-system:

kubectl get svc -n calico-system | grep metrics
kubectl get svc -n calico-system felix-metrics-svc -o yaml

Dengan ServiceMonitor, metrik ini otomatis masuk ke Prometheus dan bisa dipajang di Grafana bersama metrik Kubernetes lain.

#Troubleshooting Dataplane

#Memeriksa Rule di Node

Kadang status API benar tapi traffic tetap macet. Saat itulah kalian turun ke dataplane dan memeriksa iptables/nftables di node:

kubectl exec -n calico-system ds/calico-node -- iptables -L -n | head -40
kubectl exec -n calico-system ds/calico-node -- iptables -S cali-PREROUTING

iptables -L -n menampilkan chain yang diprogram Felix. Jika chain cali-* tidak ada, Felix gagal memprogram dataplane — periksa log Felix dan status daemon.

#Menyelidiki Endpoint dan Policy

Untuk kasus "pod tidak bisa akses", lakukan urutan ini:

kubectl get pods -o wide
calicoctl get workloadendpoints -n <namespace> -o wide
calicoctl get networkpolicy -n <namespace>
kubectl exec <client> -- nc -zv <target> <port>

Langkah calicoctl get workloadendpoints memastikan Calico melihat kedua pod, lalu kubectl exec ... nc -zv menguji koneksi nyata. Jika koneksi gagal tapi policy tampak benar, lanjutkan cek di node asal dan tujuan.

#Penutup

Episode 7 melengkapi kalian dengan kebiasaan observability: membaca status dengan calicoctl node status, memeriksa resource dataplane, mengikuti flow log, menarik metrik Prometheus, dan menyelidiki rule di dalam node.

Inti yang harus dibawa pulang:

• calicoctl node status adalah pintu pertama: periksa state BGP dan proses.
• Workload endpoint yang hilang menandakan Calico belum melihat pod.
• Flow log bisa digrep langsung dari log Felix sebelum membangun pipeline.
• Felix dan Typha mengekspos metrik di port 9091/metrics.
• Rule dataplane bisa diverifikasi dengan iptables di dalam calico-node.
• Urutan penyelidikan: endpoint, policy, lalu uji koneksi nyata.

Di episode 8 selanjutnya kita membahas BGP peering dan routing — konfigurasi peer node-to-node, full-mesh, route reflector, BGPConfiguration, BGPPeer, hingga peering dengan router eksternal dan integrasi dengan MetalLB.