Belajar Calico - Sejarah, Latar Belakang & Mengapa Membutuhkan Calico

#Pendahuluan

Di episode 0 kalian sudah punya cluster uji dengan Calico berjalan. Sekarang saatnya memahami kenapa Calico ada dan masalah apa yang dia selesaikan. Sebuah teknologi baru akan terasa asing sampai kalian tahu sejarah yang membentuk desainnya.

Episode 1 membahas perjalanan Calico dari proyek kecil di Metaswitch Networks tahun 2014, keputusan desain besar berupa wire-rate routing alih-alih overlay, masalah networking yang dia pecahkan, dan bagaimana dia dibandingkan dengan CNI lain. Tanpa pemahaman ini, keputusan memakai IPIP, VXLAN, atau eBPF di episode-episode berikutnya akan terasa membingungkan.

#Evolusi Calico

#Dari Metaswitch ke Tigera

Calico lahir tahun 2014 di Metaswitch Networks, perusahaan telekomunikasi asal Inggris, sebagai solusi networking untuk container. Tahun 2015 proyek ini dirilis sebagai open source, dan tim yang mengembangkannya kemudian berdiri sebagai perusahaan Tigera yang hingga kini menjadi sponsor utama Project Calico.

Keputusan desain paling fundamental sejak awal: Calico tidak membangun overlay. Alih-alih meng-encapsulate packet ke dalam tunnel seperti VXLAN, Calico memanfaatkan routing Linux langsung dan BGP untuk menyebarkan rute pod antar node. Pendekatan ini disebut wire-rate routing karena packet diproses pada kecepatan wire tanpa overhead tunnel tambahan.

#Posisi di Ekosistem CNI 2026

Sepuluh tahun kemudian, Calico adalah salah satu CNI paling banyak diadopsi di Kubernetes. Per penulisan series ini, versi stabil adalah v3.32.x dengan rilis v3.32.1 di pertengahan 2026. Verifikasi versi kalian:

calicoctl version
kubectl get pods -n calico-system

calicoctl version menampilkan versi client dan datastore. Pastikan klaster kalian sudah berada di jalur v3.32.x agar sesuai dengan contoh di series ini.

#Masalah yang Diselesaikan Calico

#Networking Pod yang Scalable

Masalah pertama adalah skalabilitas networking pod. Pendekatan overlay tradisional butuh tunnel dan NAT di setiap hop, yang menambah overhead CPU dan kompleksitas. Dengan routing langsung, packet pod berpindah antar node seperti packet host biasa: lewat ip route. Rute pod disebarkan otomatis dengan BGP ke semua node, sehingga konektivitas pod-to-pod berjalan di kecepatan line rate.

#Network Policy Berfitur Lengkap

Masalah kedua adalah network policy. NetworkPolicy bawaan Kubernetes sudah bagus, tapi banyak kasus butuh lebih: policy cluster-scope, policy berbasis tier, kontrol untuk host itu sendiri, hingga policy berbasis FQDN dan L7. Calico menyediakan NetworkPolicy, GlobalNetworkPolicy, ClusterNetworkPolicy, dan HostEndpoint yang menutup semua celah itu. Contoh resource policy yang akan sering kalian pakai:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-nginx-ingress
  namespace: default
spec:
  selector: app == 'nginx'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 80

Perhatikan bahwa resource ini memakai apiVersion projectcalico.org/v3 — bukan networking.k8s.io/v1. API Calico yang diperkaya ini dibahas mulai episode 5.

#IPAM Fleksibel dan BGP Peering Eksternal

Masalah ketiga adalah kontrol IP dan koneksi ke dunia luar. Calico punya IPAM sendiri dengan IPPool yang bisa kalian atur ukuran bloknya, dan karena dia berbicara BGP, dia bisa peering langsung dengan router di data center, memungkinkan pod CIDR di-advertise ke jaringan luar tanpa NAT. Ini yang menjadi dasar integrasi dengan MetalLB dan pengaturan egress di episode 8 dan 10.

#Calico vs Pendekatan Lain

Untuk memposisikan Calico, bandingkan pendekatan desainnya dengan CNI lain:

• Flannel: murni overlay VXLAN, sangat sederhana, tanpa network policy. Cocok untuk lab, bukan untuk security.
• Weave: overlay dengan mesh antar node, mudah dimulai tapi overhead dan fitur policy-nya terbatas.
• Cilium: berbasis eBPF end-to-end dengan observability Hubble, kuat untuk L7, tapi footprint dan kompleksitas kernel-nya lebih tinggi.
• Calico: routing BGP + iptables/nftables, dengan opsi eBPF dan VXLAN. Memberikan keseimbangan fitur, kesederhanaan, dan performa.

Perbandingan mendalam termasuk rekomendasi kapan memilih masing-masing ada di episode 22. Untuk sekarang, yang perlu diingat: Calico unggul di routing langsung, kebebasan BGP, dan model policy yang lengkap tanpa wajib eBPF.

#Adopsi di Dunia Nyata

#Siapa yang Memakai Calico

Calico banyak dipakai oleh penyedia platform dan perusahaan besar karena alasan praktis: mudah diotomatisasi, berbasis CRD, dan tidak menuntut kernel tertentu di mode default. Beberapa distribusi Kubernetes mengadopsi Calico sebagai CNI bawaan, dan banyak tim memakainya sebagai jembatan sebelum bermigrasi ke dataplane eBPF penuh.

#Kapan Calico Paling Tepat Dipilih

Calico paling cocok saat kebutuhan kalian adalah routing yang dapat dikontrol penuh, integrasi BGP dengan jaringan luar, dan policy keamanan yang kuat tanpa membangun infrastruktur eBPF dari nol. Sebaliknya, jika kebutuhan utama kalian adalah observability L7 native dan kalian siap hidup di kernel eBPF saja, Cilium bisa menjadi pertimbangan — kita bahas di episode 22.

#Mengapa Memilih Calico

Alasan paling kuat memakai Calico untuk klaster produksi:

• Kinerja: routing tanpa tunnel mengurangi overhead dibanding overlay murni.
• Flexibilitas dataplane: pilih iptables, nftables, atau eBPF sesuai kebutuhan tanpa ganti CNI.
• Policy sekelas enterprise: tier, global policy, host endpoint, FQDN, dan L7.
• Jejak adopsi: dipakai jutaan node di perusahaan besar, dokumentasi dan komunitasnya matang.
• Bukan vendor lock-in: Calico Open Source tetap gratis, dan resource-nya berbasis CRD standar.

Cek cepat fitur yang sudah aktif di klaster kalian:

kubectl get felixconfiguration default -o yaml | grep -i dataplane
calicoctl get ipamconfig default -o yaml

#Penutup

Episode 1 menempatkan Calico dalam konteks: lahir dari kebutuhan routing container yang cepat, dikembangkan Tigera sejak 2014, dan kini menjadi standar de facto untuk networking plus policy di Kubernetes.

Inti yang harus dibawa pulang:

• Calico lahir tahun 2014 di Metaswitch Networks, kini dikelola Tigera.
• Filsafat utamanya adalah wire-rate routing dengan BGP, bukan overlay.
• Menyelesaikan tiga masalah besar: skalabilitas, policy lengkap, dan kendali IPAM/BGP.
• API projectcalico.org/v3 memberikan NetworkPolicy, GlobalNetworkPolicy, dan lainnya.
• Dataplane bisa memakai iptables, nftables, atau eBPF sesuai kebutuhan.
• Perbandingan mendalam dengan Cilium, Flannel, dan Weave menyusul di episode 22.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Calico — tugas calico/node, Felix sebagai dataplane program, BIRD sebagai daemon BGP, Typha yang menskalakan komunikasi Felix ke API server, kube-controllers, dan alur paket pod-to-pod di balik layar. Ini fondasi untuk semua episode teknis berikutnya.