Tutorial Setup Cilium Cluster Mesh: Koneksi Multi-Kubernetes Cluster Pakai eBPF

Pernah ngelola beberapa Kubernetes cluster sekaligus? Misalnya satu cluster buat production di Jakarta, satu lagi di Singapore buat redundancy, terus ada lagi buat staging. Bikin service di cluster A ngobrol sama service di cluster B itu ribet banget. Biasanya ujung-ujungnya pasang ingress controller eksternal, setup VPN antar-cluster, atau pakai service mesh kayak Istio yang lumayan berat.

Cilium Cluster Mesh nawarin solusi yang lebih simpel dan ringan pakai eBPF. Cluster di Jakarta bisa langsung konek ke cluster di Singapore tanpa komponen tambahan yang bikin pusing.

Kenapa Harus Cilium Cluster Mesh?

Cilium itu CNI untuk Kubernetes yang dibangun di atas eBPF—teknologi di kernel Linux yang bikin kita bisa jalankan program kustom langsung di kernel tanpa perlu ubah source code kernel atau load modul tambahan. Jadi network processing-nya super cepat.

Cluster Mesh adalah fitur Cilium yang bikin beberapa cluster bisa saling nyambung secara native di layer networking. Pod di cluster Jakarta bisa langsung ngomong ke pod di cluster Singapore. Gak pakai proxy tambahan, gak pakai konfigurasi rumit. Service discovery juga otomatis jalan—service yang ada di cluster A bisa langsung di-resolve dari cluster B.

Banding-bandingin sama Solusi Lain

Kalau dibanding Istio atau Linkerd multi-cluster, Cilium punya beberapa plus:

• Lebih ringan: Gak perlu sidecar proxy di tiap pod. eBPF kerja langsung di kernel jadi overhead-nya minimal banget.
• Performa lebih kenceng: Network processing langsung di kernel tanpa bolak-balik ke userspace.
• Setup lebih gampang: Gak butuh control plane terpisah atau komponen tambahan. Cilium agent sudah handle semua.
• Network policy native: Policy enforcement langsung di kernel pakai eBPF programs.

Kelemahannya apa? Cilium Cluster Mesh lebih cocok buat use case networking murni. Kalau lo butuh traffic management advanced kayak canary deployment dengan routing yang detail banget, Istio masih lebih jago di bagian itu.

Setup Praktis: Hubungkan 2 Cluster K3s

Kita bakal setup 2 cluster K3s sederhana, install Cilium sebagai CNI, terus hubungkan mereka pakai Cluster Mesh. Asumsi gue lo punya 2 VM atau 2 server yang bisa saling komunikasi lewat network.

Persiapan Cluster

Install K3s di kedua server tanpa CNI bawaan karena kita mau pakai Cilium:

# Di server cluster-1
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable-network-policy' sh -

# Di server cluster-2
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable-network-policy' sh -

Flag --flannel-backend=none matiin CNI bawaan K3s. Copy kubeconfig dari kedua cluster ke mesin lokal, terus rename context-nya biar jelas:

kubectl config rename-context default cluster-1
kubectl config rename-context default cluster-2

Install Cilium dengan Cluster Mesh Support

Install Cilium CLI dulu kalau belum punya:

curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin

Sekarang install Cilium di cluster pertama dengan flag cluster mesh:

cilium install --context cluster-1 \
  --set cluster.name=cluster-1 \
  --set cluster.id=1 \
  --set ipam.mode=kubernetes

Ulangi buat cluster kedua dengan ID berbeda:

cilium install --context cluster-2 \
  --set cluster.name=cluster-2 \
  --set cluster.id=2 \
  --set ipam.mode=kubernetes

Cluster ID harus unique per cluster. Pastikan CIDR pod gak overlap antar cluster—biasanya K3s default udah aman tapi cek dulu pakai kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'.

Enable dan Hubungkan Cluster Mesh

Enable Cluster Mesh di kedua cluster:

cilium clustermesh enable --context cluster-1 --service-type NodePort
cilium clustermesh enable --context cluster-2 --service-type NodePort

Kita pakai NodePort karena asumsi kedua cluster bisa saling akses lewat IP publik atau private. Kalau di production pakai LoadBalancer, ganti jadi --service-type LoadBalancer.

Sekarang hubungkan cluster-1 ke cluster-2:

cilium clustermesh connect --context cluster-1 --destination-context cluster-2

Perintah ini otomatis setup certificate, endpoint, sama routing table yang dibutuhkan. Tunggu beberapa menit terus cek status:

cilium clustermesh status --context cluster-1
cilium clustermesh status --context cluster-2

Kalau koneksi sukses, lo bakal lihat status "ready" dan list remote cluster yang connected.

Deploy dan Test Global Service

Sekarang deploy aplikasi sederhana di cluster-1 dan expose sebagai global service yang bisa diakses dari cluster-2:

# Deploy di cluster-1
kubectl --context cluster-1 create deployment nginx --image=nginx
kubectl --context cluster-1 expose deployment nginx --port=80

Tandain service sebagai global pakai annotation:

kubectl --context cluster-1 annotate service nginx \
  io.cilium/global-service="true"

Dari cluster-2, deploy pod test buat coba akses service nginx:

kubectl --context cluster-2 run test --image=curlimages/curl -it --rm -- sh

Di dalam pod, coba curl ke service nginx:

curl nginx.default.svc.cluster.local

Kalau setup bener, lo bakal dapet response dari nginx yang running di cluster-1. Magic-nya di sini adalah service discovery jalan otomatis—CoreDNS di cluster-2 resolve nama service yang sebenernya ada di cluster-1.

Test Failover Cross-Cluster

Deploy replica nginx di cluster-2 juga dengan service name yang sama:

kubectl --context cluster-2 create deployment nginx --image=nginx
kubectl --context cluster-2 expose deployment nginx --port=80
kubectl --context cluster-2 annotate service nginx io.cilium/global-service="true"

Sekarang traffic bakal di-load balance otomatis antar kedua cluster. Kalau lo matiin pod nginx di salah satu cluster, traffic otomatis pindah ke cluster lainnya. Ini berguna banget buat multi-region high availability.

Best Practice dan Production Readiness

Network Policy Cross-Cluster

Salah satu kekuatan Cilium adalah network policy yang powerful. Lo bisa bikin policy yang enforce security antar cluster:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-cross-cluster
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        io.cilium.k8s.policy.cluster: cluster-2
        app: frontend

Policy ini cuma ngizinin pod dengan label app=frontend dari cluster-2 buat akses pod app=backend di cluster local. Label io.cilium.k8s.policy.cluster otomatis ditambahin Cilium buat identifikasi cluster asal.

Monitoring pakai Hubble

Hubble adalah observability platform bawaan Cilium. Enable buat monitoring traffic cross-cluster:

cilium hubble enable --ui --context cluster-1
cilium hubble enable --ui --context cluster-2

Akses Hubble UI lewat port-forward buat lihat flow traffic real-time antar pod, termasuk yang cross-cluster. Sangat membantu waktu troubleshooting connectivity issues.

Security: mTLS Antar Cluster

Cluster Mesh secara default udah pakai certificate buat autentikasi antar cluster. Tapi buat production, enable transparent encryption buat traffic antar node:

cilium install --context cluster-1 \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

WireGuard lebih ringan dibanding IPsec dan performa overhead-nya minimal. Semua traffic antar cluster bakal terenkripsi secara transparan tanpa perlu ubah aplikasi.

Troubleshooting Tips

Kalau connectivity gak jalan, cek beberapa hal ini:

• Firewall: Pastiin port 4240 (clustermesh-apiserver) terbuka antar node cluster.
• CIDR overlap: PodCIDR dan ServiceCIDR gak boleh overlap antar cluster.
• Certificate: Cek pakai cilium clustermesh status apakah certificate valid dan belum expired.
• Cilium agent logs: kubectl logs -n kube-system ds/cilium buat lihat error detail.

Kapan Pakai Cluster Mesh vs Solusi Lain?

Cluster Mesh cocok buat scenario ini:

• Multi-region deployment dengan latency-aware load balancing
• Disaster recovery dengan active-active setup
• Gradual migration antar cluster tanpa downtime
• Resource sharing antar cluster (database cluster, cache layer)

Jangan pakai Cluster Mesh kalau:

• Cluster lo terlalu jauh secara geografis (latency di atas 100ms)
• Butuh traffic management advanced kayak weighted routing per percentage
• Network antar cluster gak reliable atau bandwidth terbatas

Dari sisi performa, benchmark internal Cilium nunjukin overhead latency cuma sekitar 0.1-0.3ms buat cross-cluster call dibanding in-cluster. Throughput juga gak beda signifikan karena eBPF processing sangat efisien.

Saatnya Dicoba

Cilium Cluster Mesh ngasih cara yang elegan buat hubungkan multiple Kubernetes cluster tanpa kompleksitas service mesh tradisional. Setup awal emang perlu perhatian detail terutama soal networking dan certificate, tapi setelah jalan, maintenance-nya sangat minimal.

Mulai dengan 2 cluster di environment non-production dulu. Deploy aplikasi sederhana, test failover scenario, dan familiar dulu sama Hubble buat observability. Setelah yakin, baru roll out ke production dengan encryption dan network policy yang proper. Dokumentasi Cilium sangat lengkap jadi jangan ragu explore fitur-fitur advanced lainnya kayak BGP integration atau external workload support.