Belajar Cilium - Multi-Cluster & ClusterMesh

#Pendahuluan

Organisasi modern jarang berhenti di satu cluster. Ada cluster per region, per environment, atau per tim — dan tiba-tiba muncul kebutuhan: aplikasi di cluster A ingin memanggil service di cluster B. Episode 17 membahas ClusterMesh, fitur Cilium untuk menghubungkan cluster-cluster tersebut secara transparan.

Dengan ClusterMesh, pod di cluster yang berbeda bisa saling berkomunikasi seolah-olah berada di satu cluster besar: identity tetap berlaku, policy tetap berlaku, dan service bisa ditemukan lintas cluster. Dan dengan MCS API (Multi-Cluster Services) yang stabil di Cilium 1.20, cara mendefinisikan service lintas cluster menjadi standar dan rapi.

Satu aspek yang perlu disadari sejak awal: ClusterMesh bukan replicator state. Ia menghubungkan control plane dan dataplane antar cluster, bukan memindahkan data aplikasi. Pemahaman ini penting agar kalian tidak salah ekspektasi ketika service lintas cluster tidak membawa serta state lokal pod.

#Konsep ClusterMesh

ClusterMesh bekerja dengan menghubungkan kube-apiserver dan dataplane Cilium antar cluster. Beberapa cluster yang bergabung membentuk sebuah "mesh". Setiap cluster memakai rangkaian identity yang sama — artinya, identity dari sebuah pod di cluster A dikenali dan dipercaya di cluster B. Tanpa ini, policy antar cluster tidak mungkin konsisten.

Keamanan koneksi antar cluster dijamin dengan sertifikat TLS bersama. Setiap cluster memiliki sebuah key pair dan CA yang membentuk trust domain mesh. Konsekuensinya, ClusterMesh bukan sekadar VPN antar cluster — ini adalah ekstensi dari model identity yang sudah kita bangun sejak episode 5.

Karena identity dikenali lintas cluster, policy yang kita tulis di episode 6 dan 13 berlaku lintas cluster tanpa perubahan. Sebuah pod di cluster A yang berlabel app=backend memiliki identity yang sama di cluster B, sehingga aturan fromEndpoints yang menargetkan label tersebut bekerja di kedua arah. Konsistensi ini adalah alasan mengapa ClusterMesh terasa seperti satu cluster besar.

#Menghubungkan Cluster

Menghubungkan dua cluster dilakukan lewat Cilium CLI. Dari cluster pertama, aktifkan ClusterMesh:

cilium clustermesh enable --service-type LoadBalancer

cilium clustermesh enable --service-type LoadBalancer menginstall komponen ClusterMesh dan mengekspos service-nya agar bisa dijangkau cluster lain. Simpan nilai yang dihasilkan karena akan dipakai cluster kedua.

Dari cluster kedua, sambungkan ke mesh:

cilium clustermesh connect --context cluster-b

cilium clustermesh connect --context cluster-b menghubungkan cluster yang aktif ke cluster pertama memakai konfigurasi yang sudah disiapkan. Verifikasi koneksi:

cilium clustermesh status

cilium clustermesh status menampilkan status koneksi ke semua cluster dalam mesh. Semua koneksi harus menampilkan status OK sebelum service lintas cluster diuji.

Sebelum menghubungkan banyak cluster, perhatikan jarak geografis dan latensi antar cluster. ClusterMesh tidak mengoptimalkan route lintas cluster; setiap koneksi melewati jalur yang tersedia. Untuk cluster antar region dengan latensi tinggi, pertimbangkan apakah kebutuhan kalian memang membutuhkan service discovery lintas region atau cukup failover di level ingress.

#Service Discovery Lintas Cluster dan MCS API

Untuk mengekspos service ke cluster lain, Kubernetes menetapkan standar bernama MCS API: resource ServiceExport untuk menandai service yang boleh dilihat lintas cluster, dan ServiceImport untuk merepresentasikannya di cluster konsumen. Di Cilium 1.20, MCS API menjadi stabil — inilah salah satu rilis terpenting untuk multi-cluster.

Ekspor service dari cluster asal:

apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: svc-akunting
  namespace: akunting

ServiceExport dengan nama svc-akunting menandai bahwa service ini boleh ditemukan dari cluster lain. Di cluster konsumen, ServiceImport merepresentasikan service yang sama, dan pod bisa memanggilnya dengan nama yang sama persis.

Verifikasi bahwa service lintas cluster terlihat:

kubectl get serviceimports.multicluster.x-k8s.io

kubectl get serviceimports.multicluster.x-k8s.io menampilkan service yang sudah di-import dari cluster lain. Dari sini, DNS lintas cluster bekerja secara otomatis — aplikasi tidak perlu tahu cluster mana yang menyediakan service.

Perlu dipahami bahwa MCS API dan ClusterMesh saling melengkapi: ClusterMesh menyediakan jalur data antar cluster, sedangkan MCS API menyediakan cara standar untuk mengekspor dan mengimport service. Keduanya stabil di 1.20, dan kombinasi keduanya adalah fondasi arsitektur multi-cluster yang direkomendasikan saat ini.

#Failover Lintas Cluster

Kombinasi ClusterMesh dan ServiceImport membuka skenario failover: satu service di-export dari dua cluster yang berbeda. Ketika salah satu cluster terganggu, endpoint dari cluster lain tetap tersedia dan dataplane Cilium meneruskan traffic ke endpoint yang sehat.

Perlu dicatat bahwa failover ini bukan magic: aplikasi yang memakai state lokal per-cluster tetap butuh strategi replikasi data. ClusterMesh menangani konektivitas dan penemuan service, bukan sinkronisasi state aplikasi. Untuk service stateless, portability lintas cluster bekerja hampir sempurna — ini pola dasar untuk arsitektur multi-region.

Untuk menguji failover dengan aman, lakukan latihan rutin: matikan sementara service di satu cluster, amati apakah traffic berpindah ke cluster lain, lalu hidupkan kembali. Latihan ini sebaiknya dijadwalkan secara berkala, karena failover yang tidak pernah diuji cenderung gagal saat benar-benar dibutuhkan.

#Memeriksa Kesehatan Mesh

Koneksi antar cluster bisa diamati dari beberapa lapisan. Mulai dari status ClusterMesh, lalu detail koneksi, hingga bukti di dataplane:

cilium clustermesh status
kubectl exec -n kube-system -it ds/cilium -- cilium-dbg clustermesh status --verbose

cilium clustermesh status menampilkan ringkasan koneksi ke semua cluster. cilium-dbg clustermesh status --verbose memberikan detail per koneksi — termasuk status TLS dan jumlah endpoint yang disinkronkan. Ketika sebuah cluster dalam mesh menunjukkan status yang tidak sehat, detail di sini adalah sumber informasi pertama.

Periksa juga bahwa identity konsisten antar cluster:

kubectl get ciliumidentity -n default
kubectl get ciliumnodes -o wide

kubectl get ciliumidentity -n default menampilkan identity; kubectl get ciliumnodes -o wide menampilkan node dari semua cluster dalam mesh. Jika jumlah node sesuai dengan total node di semua cluster, sinkronisasi dataplane berjalan normal.

Catatan operasional penting: ClusterMesh menambah traffic control plane antar cluster. Setiap perubahan policy atau endpoint disinkronkan ke semua cluster, jadi perhatikan beban kube-apiserver di cluster yang sangat besar. Untuk arsitektur multi-cluster berskala besar, rencanakan kapasitas control plane ini sejak awal — topik yang akan kita sentuh lagi di episode 21 ketika membahas arsitektur production.

#Penutup

Inti yang harus dibawa pulang:

• ClusterMesh menghubungkan cluster-cluster Cilium dengan trust domain bersama.
• Identity konsisten antar cluster, sehingga policy dan mTLS tetap berlaku.
• cilium clustermesh enable dan cilium clustermesh connect menghubungkan cluster.
• MCS API, stabil di 1.20, memakai ServiceExport dan ServiceImport.
• Service lintas cluster diakses dengan nama yang sama dari cluster mana pun.
• Failover lintas cluster bekerja untuk service stateless dengan replikasi data.

Di episode 18 selanjutnya kita akan membahas Cilium dalam GitOps dan Policy as Code — mengelola CiliumConfig, helm values, dan policy CNP/CCNP sebagai code dengan Argo CD atau Flux, plus best practice versioning, review flow, dan penerapan bertahap. Ini mengubah cara tim mengoperasikan Cilium dari manual menjadi reproducible.