Belajar Calico - Setup & Installasi

#Pendahuluan

Di episode 0 kalian sudah menginstall Calico, tapi hanya sebatas mengikuti langkah. Episode 3 mengubah itu: kalian akan memahami setiap pilihan yang ada saat instalasi, tahu cara mengkustomisasi instalasi untuk kebutuhan nyata, dan bisa memverifikasi bahwa dataplane benar-benar sehat.

Instalasi Calico Open Source hampir selalu lewat Tigera Operator. Namun ada beberapa keputusan penting: mau install via Helm atau manifest murni? Mau dataplane iptables/nftables atau eBPF? Jawaban atas pertanyaan ini menentukan performa dan fitur yang tersedia.

#Opsi Instalasi Tigera Operator

#Instalasi via Helm

Helm adalah cara paling umum. Satu perintah men-deploy operator, lalu resource Installation memicu operator untuk men-deploy komponen:

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm install calico projectcalico/tigera-operator --version v3.32.1 \
  --namespace tigera-operator --create-namespace
kubectl get pods -n tigera-operator

Setelah operator berjalan, buat resource kustomisasi:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - name: default-ipv4-ippool
        cidr: 192.168.0.0/16
        blockSize: 26
        natOutgoing: true
        encapsulation: VXLAN

Simpan sebagai custom-resources.yaml lalu terapkan. Perhatikan encapsulation: VXLAN — di mode VXLAN paket lintas subnet dibungkus tunnel, cocok untuk cloud yang tidak bisa routing IP pod langsung. Detail mode ini dibahas di episode 9.

#Instalasi via Manifest Murni

Jika kalian tidak ingin Helm, operator bisa di-deploy dengan manifest langsung:

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/manifests/custom-resources.yaml

Keduanya menghasilkan arsitektur yang sama. Helm lebih nyaman untuk upgrade; manifest murni lebih transparan dan cocok untuk GitOps (episode 18).

#Verifikasi Instalasi

#Status Komponen

Tunggu hingga semua komponen siap, lalu periksa lapis demi lapis:

kubectl get tigerastatus
kubectl get pods -n calico-system
calicoctl node status
calicoctl get nodes

Urutan ini sengaja: kubectl get tigerastatus dulu untuk status keseluruhan, lalu pod, lalu detail BGP. Jika BGP belum Established, periksa log Felix:

kubectl logs -n calico-system -l k8s-app=calico-node | grep -iE "felix.*(error|warn)" | head -20

#Uji Fungsi Dasar

Jalankan dua pod dan pastikan bisa saling ping, lalu verifikasi bahwa policy default cluster tidak menghalangi:

kubectl run a --image=nginx
kubectl run b --image=busybox --command -- sleep 3600
kubectl exec b -- wget -q -O - http://a.default.svc.cluster.local
calicoctl get networkpolicy -A

Belum ada policy yang didefinisikan, jadi traffic seharusnya mengalir bebas. Kalau tidak, ada masalah di instalasi — episode 19 akan membahas troubleshooting lebih lanjut.

#Memilih Mode Dataplane

#iptables dan nftables

Secara default Calico memprogram iptables (atau nftables pada sistem yang memakai API nftables). Mode ini paling kompatibel, berjalan di hampir semua kernel, dan cukup untuk sebagian besar kebutuhan policy. Overhead-nya adalah antrean rule yang semakin panjang di klaster besar.

#eBPF Mode

Mode eBPF menggantikan iptables dengan program eBPF yang disuntikkan ke kernel. Keuntungannya: performa lebih tinggi, direct server return (DSR), load balancing yang menggantikan kube-proxy, dan policy di level socket. Tapi ada prasyarat kernel yang ketat:

Linux 5.3+  (v3.32 membutuhkan kernel yang lebih baru untuk fitur tertentu)
CONFIG_BPF            -> y
CONFIG_BPF_SYSCALL    -> y
CONFIG_BPF_JIT        -> y
CONFIG_BPF_UNPRIV_DEFAULT_OFF -> y
CONFIG_DEBUG_INFO_BTF -> y

Cek prasyarat node kalian dengan script resmi:

curl -LO https://raw.githubusercontent.com/projectcalico/calico/v3.32.1/scripts/check-kernel-config
chmod +x check-kernel-config
./check-kernel-config /boot/config-$(uname -r)

Aktifkan mode eBPF dengan mengubah Installation:

kubectl patch installation default --type merge \
  -p '{"spec":{"dataplane":{"type":"BPF"}}}'
kubectl get tigerastatus | grep -i bpf

Catatan penting: eBPF memerlukan kubeProxyReplacement: strict dan menggantikan kube-proxy. Detail lengkap eBPF — termasuk DSR dan perbandingan performa — dibahas di episode 17.

#Perbandingan Singkat

• iptables/nftables: kompatibel maksimal, sederhana, overhead rule sedikit lebih tinggi.
• eBPF: tercepat, fitur socket policy dan DSR, tapi wajib kernel modern dan tidak mendukung semua fitur (misalnya kube-proxy mode lama).
• Aturan praktis: mulai dengan iptables/nftables, aktifkan eBPF saat tim sudah siap mengelola prasyarat kernel.

#Penutup

Episode 3 melengkapi kalian dengan kemampuan instalasi yang sadar konteks: memilih Helm atau manifest, mengkustomisasi IPPool lewat Installation, memverifikasi komponen, dan memilih dataplane yang tepat.

Inti yang harus dibawa pulang:

• Operator diinstall via Helm atau manifest; keduanya sama-sama valid.
• Resource Installation mengendalikan IPPool, CIDR, dan mode encapsulation.
• Verifikasi berjenjang: tigerastatus, pod, lalu BGP dengan calicoctl node status.
• Tanpa policy, traffic pod mengalir bebas — jangan lupa menutupnya di episode 5.
• iptables/nftables paling kompatibel; eBPF tercepat dengan prasyarat kernel ketat.
• Mode dataplane bisa diubah tanpa mengganti CNI.

Di episode 4 selanjutnya kita akan membahas IPAM dan networking dasar — IPPool, alokasi blok per node, IPIP/VXLAN versus direct routing, serta cara pod-to-pod, pod-to-service, dan interaksi dengan kube-proxy bekerja. Ini akan menjelaskan mengapa IP di pod kalian terlihat seperti terpotong-potong.