Belajar Calico - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kalian tahu kenapa Calico ada. Sekarang saatnya membuka kap mesin: siapa melakukan apa, dan bagaimana paket berpindah dari satu pod ke pod lain. Episode 2 adalah fondasi paling penting di series ini karena semua episode berikutnya akan menyebut komponen yang kita bahas di sini.

Arsitektur Calico pada dasarnya sederhana: satu agen per node (calico-node) yang menjalankan beberapa proses, satu pemberi skala (Typha), satu set controller, dan satu operator untuk instalasi. Setelah episode ini, kalian akan bisa membaca kubectl get pods -n calico-system dan menjelaskan fungsi setiap pod.

#Komponen Utama Calico

#calico-node dan Felix

calico-node adalah DaemonSet yang berjalan di setiap node. Di dalam pod ini hidup beberapa proses:

• Felix: dataplane program. Tugasnya menerjemahkan policy dan routing yang diinginkan menjadi iptables/nftables atau eBPF, serta mengelola route dan interface di node. Felix adalah satu-satunya komponen yang menyentuh kernel networking.
• BIRD: daemon BGP yang menyebarkan rute pod antar node dan ke peer eksternal.
• calico-node: proses yang mengelola IPAM, membership, dan koordinasi antar komponen.

Lihat proses yang berjalan di dalam pod calico-node:

kubectl get pods -n calico-system -l app.kubernetes.io/name=calico-node
kubectl exec -n calico-system ds/calico-node -- ps aux | grep -E "felix|bird|calico"

kubectl exec ... ps aux akan menampilkan felix, bird, dan proses calico-node dalam satu pod. Kalau kalian tidak melihat Felix berjalan, dataplane tidak akan bekerja sama sekali.

#Typha

Typha adalah pemberi skala arsitektur Calico. Masalah yang dia selesaikan: di klaster besar, Felix di setiap node menonton resource policy dan endpoint di API server. Kalau seribu node mengawasi langsung, API server kewalahan. Typha berdiri di tengah — satu koneksi ke API server, lalu menyiarkan perubahan ke ratusan Felix.

Dengan Typha, beban API server relatif konstan meskipun jumlah node naik. Deployment Typha default berjalan dua replika:

kubectl get deploy -n calico-system typha
kubectl logs -n calico-system deploy/typha --tail=10 | grep -i "connected"

#BIRD dan kube-controllers

BIRD bertanggung jawab penuh atas BGP: mem-build full-mesh antar node secara default, menerima konfigurasi peer dari BGPPeer, dan meng-advertise rute pod. kube-controllers menangani tugas reconciling — seperti membuat profile per namespace dan memperbarui endpoint status — sehingga policy dan networking selalu sinkron dengan objek Kubernetes.

#calico-apiserver dan calicoctl

calico-apiserver menyediakan API Kubernetes untuk resource Calico (NetworkPolicy, IPPool, dan lainnya), sehingga resource itu bisa diakses dengan kubectl biasa. calicoctl/calico adalah CLI yang membaca datastore yang sama. Model data ini penting: resource Calico adalah CRD, jadi semuanya bisa di-manage sebagai code — kita akan manfaatkan ini di episode 18.

#Tigera Operator

Tigera Operator mengelola siklus hidup seluruh komponen di atas. Dia mengawasi resource Installation dan APIServer, lalu men-deploy calico-node, typha, kube-controllers, dan konfigurasi terkait. Keuntungannya: upgrade Calico cukup dengan mengganti versi operator atau image, tanpa edit manifest manual.

kubectl get installation default -o yaml
kubectl get tigerastatus

kubectl get tigerastatus menampilkan status setiap komponen Calico (apiserver, calico-node, typha, dan lainnya) dalam satu tabel.

#Alur Paket Pod-to-Pod

#Perjalanan Paket dalam Satu Node

Saat pod A mengirim paket ke pod B di node yang sama, alurnya singkat: dari veth pod A masuk ke route, kernel menemukan bahwa destinasi ada di node ini, lalu meneruskan ke veth pod B. Felix hanya memasang rule iptables untuk allow traffic sesuai policy — jika tidak ada policy yang melarang, paket langsung diteruskan.

#Perjalanan Paket Antar Node

Untuk node berbeda, BIRD sudah meng-advertise rute pod B ke semua node. Maka di node A ada route 192.168.1.5/32 via <IP node B> dev eth0. Paket keluar dari veth pod A, di-routing langsung ke node B, lalu masuk ke veth pod B:

pod A -> veth A -> routing table -> NIC node A
      -> jaringan (paket asli, tanpa tunnel) -> NIC node B
      -> routing table -> veth B -> pod B

Inilah yang dimaksud wire-rate routing: tidak ada encapsulation di jalur ini. Mode IPIP atau VXLAN yang menambah tunnel akan kita bahas di episode 9.

#Verifikasi Route dengan calicoctl

Untuk melihat rute yang disebarkan BIRD:

calicoctl node status
kubectl exec -n calico-system ds/calico-node -- ip route | grep 192.168

#Model Data dan Profile

Setiap namespace Kubernetes otomatis mendapat profile Calico yang sama namanya. Profile inilah yang menyediakan policy default allow berbasis label dan menjadi tempat NetworkPolicy menempel. Jadi alur penyelarasan datanya adalah: kube-controllers menonton namespace → membuat profile → Felix memasang rule yang relevan di tiap node.

#Prinsip Desain yang Perlu Diingat

Ada tiga prinsip yang mengikat seluruh arsitektur ini dan akan sering kalian lihat lagi:

• Separation of concerns: BIRD hanya urus rute, Felix hanya urus dataplane dan policy, controller hanya urus penyelarasan. Ini membuat tiap komponen bisa diskalakan dan di-debug sendiri-sendiri.
• Desired state: konfigurasi ditulis sebagai resource (CRD), dan komponen terus-menerus menyamakan kondisi nyata dengan kondisi yang diinginkan. Kalian tidak pernah memaksa node; kalian mendeklarasikan.
• Everything is queryable: semua state bisa dibaca — route, endpoint, policy, dan status BGP — lewat kubectl atau calicoctl, yang menjadi modal utama troubleshooting di episode 19.

Selama kalian memegang tiga prinsip ini, episode 8 sampai episode 17 yang penuh komponen baru akan terasa seperti variasi dari arsitektur yang sama.

#Penutup

Episode 2 membuka arsitektur Calico dari komponen hingga alur paket: Felix memprogram dataplane, BIRD menyebarkan rute, Typha menskalakan, kube-controllers menyelaraskan, dan operator mengelola semuanya.

Inti yang harus dibawa pulang:

• calico-node menjalankan Felix (dataplane), BIRD (BGP), dan proses manajemen node.
• Typha menengahi Felix dan API server agar klaster besar tetap ringan.
• kube-controllers menyinkronkan objek Kubernetes ke model data Calico.
• Resource Calico adalah CRD, bisa diakses kubectl maupun calicoctl.
• Paket pod-to-pod antar node di-routing langsung, tanpa tunnel secara default.
• Profile per namespace menjadi tempat menempelnya policy.

Di episode 3 selanjutnya kita akan melakukan setup dan installasi yang lebih dalam: perbandingan cara install Tigera Operator, mode dataplane iptables versus eBPF berikut prasyarat kernel-nya, dan langkah verifikasi pasca-instalasi yang menyeluruh. Siapkan cluster kalian, karena mulai episode ini semua perintah akan kita jalankan bersama.