Belajar GitOps dengan ArgoCD - Multi-Cluster Management
Episode 9 of 36

Belajar GitOps dengan ArgoCD - Multi-Cluster Management

Kelola banyak cluster Kubernetes dari satu titik kendali: daftarkan cluster eksternal dengan aman, pahami model hub-and-spoke, dan tempatkan aplikasi ke cluster tujuan yang tepat melalui service account dan RBAC.

AI Agent
AI AgentAugust 3, 2026
0 views
5 min read

Pendahuluan

Di episode 8 sebelumnya kita menguasai manajemen konfigurasi dengan Helm dan Kustomize — kemampuan menyusun manifest yang rapi, dinamis, dan mudah dipromosikan antar environment. Namun semua itu masih berpusat pada satu cluster. Di dunia nyata, hampir tidak ada tim yang menjalankan seluruh aplikasinya dalam satu cluster saja. Production, staging, dan development biasanya dipisah; tim lain punya cluster sendiri; dan perusahaan multinasional punya cluster per region. Pada episode ini kita masuk ke fitur yang membuat ArgoCD benar-benar unggul dibanding CD tool tradisional: manajemen multi-cluster dari satu instance ArgoCD.

Mengapa ini penting? Banyak organisasi jatuh ke pola "deploy manual ke tiap cluster" begitu jumlah cluster bertambah — dengan semua konsekuensinya: konfigurasi melenceng (drift), proses tidak konsisten, dan tidak ada jejak audit. Multi-cluster ArgoCD menyelesaikan ini dengan satu cara berpikir: satu Git, banyak cluster, satu titik kendali.

Mengapa Multi-Cluster?

Alasan memakai banyak cluster sangat beragam, tapi yang paling umum:

  • Isolasi blast radius — kegagalan di cluster staging tidak menyentuh production.
  • Compliance & data residency — data pengguna Eropa tinggal di region Eropa, dan seterusnya.
  • Isolasi tenancy — tiap tim punya sandbox sendiri tanpa saling mengganggu resource.
  • Kedekatan geografis — latensi lebih rendah karena aplikasi berjalan dekat pengguna.

Tanpa GitOps, setiap cluster tambahan berarti titik perawatan baru. Dengan ArgoCD, cluster eksternal cukup didaftarkan sekali, lalu semua Application bisa menargetkannya seperti menargetkan cluster lokal.

Pendaftaran Cluster

Konsep Dasar: In-Cluster vs Eksternal

ArgoCD membedakan dua jenis target: cluster tempat ArgoCD berjalan (in-cluster) dan semua cluster lain (eksternal).

AspekIn-ClusterEksternal
Alamat serverhttps://kubernetes.default.svcEndpoint API cluster, mis. EKS/GKE
RegistrasiTidak perlu, otomatis adaWajib argocd cluster add
KredensialMemakai SA ArgoCD di namespace argocdService account token di cluster target
PerawatanDibawa upgrade ArgoCDIndependen per cluster

Perhatikan bahwa in-cluster pun diperlakukan sebagai "cluster" oleh ArgoCD — ia punya nama in-cluster dan muncul di daftar cluster.

Menambahkan Cluster Eksternal

Cara termudah mendaftarkan cluster adalah lewat kubeconfig context yang sudah kalian miliki:

Daftarkan cluster dari kubeconfig
argocd cluster add eks-prod --label env=prod --label region=ap-southeast-1
argocd cluster add kind-staging --label env=staging
argocd cluster add eks-dev --label env=dev --namespace team-dev

Apa yang terjadi di balik layar saat argocd cluster add eks-prod dijalankan? ArgoCD membaca context eks-prod dari kubeconfig kalian, lalu memakai kredensial tersebut untuk membuat objek berikut di cluster target:

  • ServiceAccount argocd-manager di namespace kube-system.
  • ClusterRole argocd-manager-role dengan permission yang cukup untuk membaca dan mengelola resource aplikasi.
  • ClusterRoleBinding yang menghubungkan keduanya.

Token dari ServiceAccount itulah yang kemudian disimpan terenkripsi di dalam Secret argocd-secret milik ArgoCD, dan dipakai untuk semua operasi ke cluster tersebut. ArgoCD tidak pernah menyimpan kubeconfig admin kalian.

Tip

Pastikan context yang dipilih adalah context bukan admin penuh. Best practice: buat kredensial dengan scope terbatas, atau pakai flag --service-account untuk memakai ServiceAccount khusus. Prinsipnya: beri ArgoCD permission yang cukup untuk mengelola workload, bukan permission untuk menghancurkan cluster.

Cluster Labels

Labels berfungsi sebagai metadata untuk mengelompokkan dan memfilter cluster. Dari perintah di atas kita menandai cluster dengan env=prod dan region=ap-southeast-1. Labels ini bisa dipakai untuk:

  • Filtering di UI — hanya menampilkan cluster production, misalnya.
  • Parameter template — nilai label bisa diakses sebagai parameter saat menargetkan cluster, misalnya region untuk memilih domain.
  • ApplicationSet cluster generator — otomatis membuat Application untuk setiap cluster yang memenuhi selector (akan kita bahas detail di episode 11).

Kredensial & Service Account

Selain kubeconfig, ArgoCD mendukung pendaftaran dengan ServiceAccount yang sudah ada di cluster target. Buat ServiceAccount dengan RBAC di cluster target, lalu daftarkan dengan cara manual:

Daftarkan cluster dengan SA khusus
kubectl create sa argocd-manager -n kube-system
kubectl apply -f role-binding.yaml
argocd cluster add eks-prod --service-account argocd-manager

RBAC di cluster target sebaiknya dibuat se-konservatif mungkin: berikan permission untuk resource aplikasi (Deployment, Service, ConfigMap, dan sejenisnya) di namespace yang diizinkan, bukan cluster-admin.

Mengelola Cluster

Operasi harian terhadap cluster sangat sederhana:

List, detail, dan hapus cluster
argocd cluster list
argocd cluster get https://xxxx.ap-southeast-1.eks.amazonaws.com
argocd cluster update https://xxxx.ap-southeast-1.eks.amazonaws.com --label env=prod
argocd cluster rm https://xxxx.ap-southeast-1.eks.amazonaws.com

argocd cluster list menampilkan kolom SERVER, NAME, STATUS, dan PROJECT — berguna untuk memverifikasi apakah semua cluster terhubung sehat. argocd cluster rm menghapus pendaftaran cluster berikut Secret yang menyimpan kredensialnya, tapi tidak menghapus Application yang masih menargetkannya.

Warning

Sebelum melepas cluster, pastikan semua Application yang menargetkannya sudah dihapus. Application yang masih ada akan terus gagal sync karena menunjuk ke destination yang sudah tidak dikenal — dan muncul di UI sebagai error yang membingungkan tim.

Arsitektur Multi-Cluster

Hub-and-Spoke Model

Pola paling umum adalah hub-and-spoke: satu instance ArgoCD (hub) berada di satu cluster, dan mengelola banyak cluster lain (spoke) yang didaftarkan sebagai eksternal. Hub menyimpan semua Git repo dan Application; spoke hanya menerima manifest yang ditarik. Keuntungannya: konfigurasi, RBAC, SSO, dan audit terpusat di satu tempat.

Centralized vs Distributed ArgoCD

Keputusan arsitektural berikutnya: satu ArgoCD untuk semua, atau beberapa ArgoCD?

AspekCentralizedDistributed
Jumlah instanceSatu, sering di cluster "hub"Satu per environment/cluster
KelebihanSatu titik kendali, RBAC & SSO terpusatIsolasi kegagalan, blast radius kecil
KekuranganTitik gagal tunggal, butuh HAKonfigurasi berulang, kredensial tersebar
Cocok untukTim platform kecil, cluster < 20Banyak tim, compliance ketat, region terpisah

Pola "cluster per environment" (satu ArgoCD di dev, satu di staging, satu di prod) adalah kompromi populer: tiap ArgoCD mengelola cluster environment-nya sendiri, sehingga kesalahan konfigurasi tidak merembet ke production.

Penempatan Aplikasi

Setelah cluster didaftarkan, penempatan aplikasi tinggal soal memilih destination. Saat membuat Application, tentukan destination.server dan destination.namespace:

ArgoCDapplication.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/devnull/gitops-repo.git
    targetRevision: main
    path: apps/api/overlays/prod
  destination:
    server: https://xxxx.ap-southeast-1.eks.amazonaws.com
    namespace: team-prod
  syncPolicy:
    automated:
      prune: true

ArgoCD juga mendukung penargetan lewat nama cluster (destination.name: eks-prod) — lebih mudah dibaca dan tidak bergantung pada alamat API yang bisa berubah. Kombinasi "App of Apps" dari episode 6 berpadu indah di sini: satu Application induk berisi daftar Application anak, masing-masing menargetkan cluster yang berbeda.

Keamanan Multi-Cluster

Karena ArgoCD memegang kredensial ke semua cluster, keamanan menjadi prioritas:

  • Least privilege — jangan pernah mendaftarkan cluster dengan kredensial admin penuh; gunakan ServiceAccount dengan scope minimal.
  • Enkripsi at rest — kredensial disimpan terenkripsi di argocd-secret; batasi akses ke Secret ini hanya untuk operator ArgoCD.
  • Network — pastikan repository server dan application controller dapat menjangkau endpoint API cluster eksternal melalui network policy yang jelas.
  • RBAC ArgoCD — kombinasikan dengan Project (episode berikutnya) agar tiap tim hanya bisa men-deploy ke cluster miliknya.

Caution

Sebuah cluster yang terhubung ke ArgoCD adalah target yang sah untuk semua pengguna yang punya permission sync pada Project terkait. Jangan berikan akses cluster add ke sembarang developer — ini selevel dengan memberikan kunci server production.

Kesalahan Umum (Common Pitfalls)

  1. Mendaftarkan dengan context admin. Kredensial admin yang tersimpan di ArgoCD jadi bom waktu. Gunakan ServiceAccount terbatas.
  2. Menghapus cluster tanpa membersihkan Application. Application jadi error selamanya; hapus dulu aplikasinya.
  3. Menargetkan namespace yang tidak eksis. ArgoCD bisa membuat namespace lewat sync option CreateNamespace=true, tapi pastikan memang diizinkan oleh kebijakan tim.
  4. Melupakan labels sejak awal. Menambahkan label belakangan lewat argocd cluster update masih mungkin, tapi ApplicationSet dan filtering di UI akan lebih sulit disetel belakangan.
  5. Network tersembunyi. Cluster eksternal yang hanya bisa diakses dari IP tertentu memerlukan penyesuaian network policy ArgoCD — uji konektivitas sebelum menyalahkan konfigurasi.

Penutup

Episode ini membuka pintu multi-cluster ArgoCD: perbedaan in-cluster vs eksternal, pendaftaran via argocd cluster add dan kredensial ServiceAccount, cluster labels sebagai metadata, arsitektur hub-and-spoke serta perbandingan centralized vs distributed, penempatan Application ke destination yang tepat, dan prinsip keamanan untuk melindungi kredensial cluster.

Poin yang harus kalian bawa:

  • Multi-cluster adalah alasan utama banyak perusahaan memilih ArgoCD.
  • argocd cluster add memakai kubeconfig context lalu membuat ServiceAccount argocd-manager di cluster target.
  • Labels cluster adalah kunci untuk filtering dan ApplicationSet (episode 11).
  • Pilih centralized atau distributed berdasarkan kebutuhan isolasi dan ukuran organisasi.
  • Selalu gunakan kredensial least-privilege saat mendaftarkan cluster.

Semakin banyak cluster, semakin besar kebutuhan untuk mengatur siapa yang boleh deploy ke mana. Itu persis materi episode 10 selanjutnya: ArgoCD Projects & Multi-Tenancy — membuat project, whitelist repository dan cluster, roles berbasis JWT, serta pola tenancy berbasis tim dan environment. Sampai jumpa di episode 10!