Belajar GitOps - FluxCD - Multi-Cluster Management

#Pendahuluan

Di episode 22 kalian sudah mengamankan secret dengan Sealed Secrets — Git kini bisa menjadi rumah yang aman untuk konfigurasi rahasia. Tapi ada skala yang belum kita sentuh: organisasi nyata tidak berjalan di satu cluster. Ada staging, produksi, mungkin satu cluster per region atau per tim. Setiap cluster berarti lingkungan, konfigurasi, dan workflow yang harus dikelola.

Episode ini membahas multi-cluster management dengan FluxCD: strategi memilih topologi cluster, bootstrap banyak cluster dari Git, dependency lintas cluster seperti service discovery dan berbagi secret, serta integrasi dengan Cluster API, vcluster, dan service mesh multi-cluster.

#Strategi Multi-Cluster

Tidak ada satu model yang benar — pilihan tergantung pada isolasi, latensi, dan biaya. Empat pola umum:

Strategi	Kapan dipakai	Keuntungan
Cluster per environment	Pemisahan prod vs staging	Blast radius kecil, env independen
Geographic distribution	Pengguna tersebar lintas region	Latensi rendah, HA regional
Tenant per cluster	SaaS multi-tenant	Isolasi tenant ketat
Hub-and-spoke	Banyak workload, kontrol terpusat	Konfigurasi terpusat, spoke mandiri

Pola hub-and-spoke adalah yang paling populer untuk GitOps berskala: sebuah hub (atau repository pusat) menjadi sumber kebenaran, sementara tiap spoke cluster menarik konfigurasi yang relevan. Git bertindak sebagai bus komunikasi antar cluster.

#Bootstrap Multi-Cluster

#Bootstrapping Tiap Cluster

Flux dibootstrap per cluster, masing-masing menunjuk ke path yang berbeda di repository yang sama:

Bootstrap dua cluster

flux bootstrap github \
  --owner=devvnull --repository=gitops-production \
  --branch=main --path=clusters/production --personal
 
flux bootstrap github \
  --owner=devvnull --repository=gitops-production \
  --branch=main --path=clusters/staging --personal

Setiap bootstrap membuat koneksi Git-nya sendiri, kredensial sendiri, dan namespace flux-system sendiri. Struktur direktori menjadi pola utama organisasi:

Struktur repo multi-cluster

clusters/
├── production/
│   ├── flux-system/
│   └── apps/
├── staging/
│   ├── flux-system/
│   └── apps/
└── shared/
    ├── base/
    └── kustomization.yaml

#Shared vs Cluster-Specific Manifests

Manifest yang identik di semua cluster (misal monitoring, logging, policy) cukup ditulis sekali di shared/base lalu digunakan bersama. Manifest yang beda per cluster (misal ukuran resource, jumlah replica, endpoint) ditulis di path cluster masing-masing.

Flux menghubungkan keduanya lewat Kustomization tambahan yang menunjuk ke repository shared, atau lewat kustomize overlay yang me-reference base yang sama:

clusters/production/shared-kustomization.yaml

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: shared
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: shared
  path: ./shared/base
  prune: true

#Dependency Lintas Cluster

Cluster jarang berdiri sendiri. Tiga dependency paling umum:

#Service Discovery

Aplikasi di cluster A memanggil service di cluster B. Service mesh multi-cluster menyelesaikan ini secara transparan: Istio multi-primary memungkinkan VirtualService merujuk service di cluster lain, sementara Linkerd multicluster "mirroring" menyalin Service dari cluster remote ke cluster lokal:

Service mirroring Linkerd

linkerd multicluster link --cluster-name production | kubectl apply -f -
linkerd multicluster check

#Berbagi Secret

Secret bisa dibagi antar cluster dengan beberapa cara: Sealed Secrets dengan kunci yang sama di-restore ke tiap cluster (episode 22), atau ESO dengan satu backend pusat yang diakses semua cluster (episode 21). Pilihan antara Git-ciphertext dan backend eksternal berlaku sama di tingkat multi-cluster.

#Konfigurasi Propagasi

Perubahan konfigurasi disebarkan lewat Git: push ke repository, dan tiap cluster menarik perubahan pada interval masing-masing. Karena setiap cluster punya Kustomization sendiri, rollout bisa diatur — misal staging mengikuti otomatis, produksi menunggu approval via perubahan di path yang dijaga branch protection.

Tip

Propagasi bertahap memakai pola promotion: konfigurasi diuji di path clusters/staging lebih dulu, lalu di-copy ke clusters/production lewat pull request. Git menyediakan jejak audit lengkap untuk tiap perubahan antar environment.

#Integrasi Tools

#Cluster API

Cluster API (CAPI) menjadikan cluster itu sendiri sebagai resource yang dikelola secara deklaratif — dan karena CAPI adalah aplikasi Kubernetes, ia pun bisa dijalankan lewat Flux di sebuah management cluster:

clusters/mgmt/cluster.yaml

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: workload-production
  namespace: clusters
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 10.244.0.0/16
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: workload-production

#vcluster

vcluster membuat cluster virtual di dalam cluster fisik — setiap vcluster adalah namespace terisolasi dengan API server sendiri. Ini murah untuk tenant banyak dan sangat cocok digabung dengan Flux: setiap vcluster dibootstrap sebagai cluster terpisah dengan kredensial Flux sendiri, tanpa menambah hardware.

#Multi-Cluster Service Mesh

Service mesh multi-cluster menyatukan identitas dan policy keamanan lintas cluster: Istio multi-primary untuk failover dan split traffic lintas cluster, Linkerd multicluster untuk service mirroring sederhana, atau AWS App Mesh untuk mesh regional. mTLS dan kebijakan access menjadi konsisten di seluruh cluster. Verifikasi koneksi antar cluster dengan linkerd multicluster check.

#Penutup

Episode ini menutup fase multi-cluster: FluxCD tidak hanya menyinkronkan satu cluster, tapi menjadi fondasi untuk mengelola puluhan cluster dari satu atau beberapa repository. Strategi dipilih berdasarkan kebutuhan isolasi dan latensi, bootstrap berjalan per cluster dengan path terpisah, dependency lintas cluster ditangani lewat service mesh, berbagi secret, dan Git sebagai media propagasi.

Inti yang harus dibawa pulang:

Strategi menentukan arsitektur: cluster per environment, geografis, tenant, atau hub-and-spoke sesuai kebutuhan.
Bootstrap berulang per cluster: setiap cluster punya path, kredensial, dan flux-system sendiri.
Pisahkan shared dan specific: manifest bersama di base, perbedaan environment di overlay masing-masing.
Git adalah bus antar cluster: konfigurasi dipropagasi dan dipromosikan lewat pull request.
Tools memperbesar jangkauan: Cluster API mengelola lifecycle cluster, vcluster mengisolasi tenant, service mesh menyatukan network policy.

Dengan banyak cluster, muncul tantangan baru: konfigurasi yang sama tersebar dan harus konsisten, serta resource tiap cluster harus diawasi. Di episode 24 selanjutnya kita membahas Sharding and Performance: horizontal dan vertical sharding Flux, tuning reconciliation, dan pola repository skala besar. Sampai jumpa di episode 24!