Belajar Calico - Multi-Cluster & Federation

#Pendahuluan

Satu klaster tidak selalu cukup. Organisasi besar menjalankan banyak klaster: satu per region, satu per tim, atau satu per environment. Episode 16 membahas bagaimana Calico menghubungkan dan mengamankan klaster-klaster itu.

Dua kemampuan utama yang akan kita pelajari: peering BGP antar klaster sehingga pod di klaster yang berbeda bisa saling bicara secara langsung, dan manajemen policy yang konsisten di semua klaster tanpa menulis ulang konfigurasi berulang kali.

#Peering BGP Antar Klaster

#Konsep Dasar

Dua klaster Calico bisa dihubungkan dengan peering BGP. Masing-masing klaster memakai AS number yang berbeda, lalu salah satu node di tiap klaster di-peering ke klaster lain. Hasilnya, rute pod dari klaster A di-advertise ke klaster B dan sebaliknya.

Cluster A (AS 64510)              Cluster B (AS 64511)
   node-a1  <--- BGPPeer --->  node-b1
   pod CIDR 192.168.0.0/16        pod CIDR 10.244.0.0/16

Setelah peering Established, pod di klaster A bisa menjangkau pod di klaster B memakai IP pod langsung — tanpa Service lintas klaster dan tanpa tunnel antar klaster.

#Konfigurasi BGPPeer Antar Klaster

Di klaster A, buat BGPPeer menuju node klaster B:

apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: peer-cluster-b
spec:
  nodeSelector: hostname == 'node-a1'
  peerIP: 198.51.100.7
  asNumber: 64511

peerIP adalah IP node yang akan di-peering di klaster B, dan asNumber adalah AS klaster B. Di klaster B, buat BGPPeer yang simetris menuju node klaster A.

#Verifikasi Peering

calicoctl node status | grep -A4 peer-cluster-b
calicoctl get bgppeer
kubectl exec -n calico-system ds/calico-node -- ip route | grep 10.244

calicoctl node status menunjukkan state peering antar klaster, dan route ke 10.244.0.0/16 (CIDR klaster B) di node klaster A membuktikan advertising bekerja.

#Model Keamanan Lintas Klaster

#Policy Tidak Melewati Batas Klaster

Penting untuk dipahami: NetworkPolicy Calico bekerja per klaster. Sebuah GlobalNetworkPolicy di klaster A tidak diterapkan di klaster B. Keamanan lintas klaster dibangun dengan policy di tiap klaster yang menyeleksi traffic yang datang dari klaster lain.

#Menandai Traffic dari Klaster Lain

Pola yang umum: tiap klaster menandai node yang menerima peering eksternal, lalu policy membatasi apa yang boleh masuk. Contoh di klaster A membatasi traffic masuk dari klaster B hanya ke pod tertentu:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: security-allow-intercluster
spec:
  tier: security
  order: 90
  selector: app == 'gateway'
  types:
    - Ingress
  ingress:
    - action: Allow
      protocol: TCP
      source:
        nets:
          - 10.244.0.0/16
      destination:
        ports:
          - 443

Source nets memakai CIDR pod klaster B, dan destinasi dibatasi ke workload gateway port 443. Semua traffic lintas klaster lain ditolak oleh default deny.

#Manajemen Policy Global yang Konsisten

#Template dan Repositori Bersama

Karena policy tidak otomatis menyebar antar klaster, konsistensi dijaga lewat sumber kebenaran bersama: repositori yang berisi template policy. Satu perubahan template di-apply ke semua klaster melalui pipeline CI. Ini adalah jembatan menuju GitOps yang kita dalami di episode 18.

Contoh template sederhana yang didistribusikan:

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: platform-default-deny
spec:
  tier: platform
  order: 100
  selector: all()
  types:
    - Ingress
    - Egress
  ingress: []
  egress: []

#Menjalankan Policy di Banyak Klaster

Dengan kubectl contexts, satu perintah bisa diulang ke banyak klaster:

for ctx in prod-asea prod-eu staging-asea; do
  kubectl --context "$ctx" apply -f baseline/
done
kubectl --context prod-asea get globalnetworkpolicy -o wide
kubectl --context prod-eu get globalnetworkpolicy -o wide

Loop for ctx in ... menjalankan apply ke tiap context, dan perintah kubectl --context memverifikasi hasilnya satu per satu.

#Menghindari Jebakan Multi-Cluster

#Overlap IPPool

Jebakan paling umum: dua klaster memakai CIDR pod yang sama. Saat BGP di-peering, rute bertabrakan dan routing rusak. Selalu pastikan setiap klaster memakai CIDR unik.

#Kube-proxy dan Lintas Klaster

Ingat: Service Kubernetes tidak otomatis tersebar lintas klaster. Akses lintas klaster terjadi di level pod (IP pod langsung) atau lewat Ingress/Service Mesh yang menghubungkan klaster. Jangan berharap nama Service klaster A bisa di-resolve dari klaster B.

#Verifikasi Lengkap

calicoctl get nodes -o wide
calicoctl get ippool -o wide
kubectl exec -n default client -- \
  wget -T 3 -q -O - http://10.244.0.15:8080

calicoctl get ippool -o wide memastikan CIDR antar klaster tidak tumpang tindih sebelum koneksi diuji.

#Penutup

Episode 16 membuka dunia multi-cluster: peering BGP antar klaster untuk routing langsung, model keamanan yang diatur per klaster, dan sumber kebenaran bersama untuk policy yang konsisten.

Inti yang harus dibawa pulang:

• Peering BGP antar klaster memungkinkan akses pod lintas klaster.
• Setiap klaster memakai AS number dan CIDR pod yang unik.
• NetworkPolicy bekerja per klaster; konsistensi dijaga lewat template bersama.
• Traffic lintas klaster dibatasi dengan policy yang menyeleksi CIDR asal.
• CI/CD pipeline menerapkan template yang sama ke semua klaster.
• Overlap IPPool adalah jebakan nomor satu yang harus dicegah.

Di episode 17 selanjutnya kita membahas eBPF dataplane advanced — prasyarat kernel, keunggulan seperti DSR dan socket-level policy, perbandingan eBPF versus iptables/nftables, dan kapan waktu yang tepat untuk mengaktifkannya.