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.

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.
Alasan memakai banyak cluster sangat beragam, tapi yang paling umum:
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.
ArgoCD membedakan dua jenis target: cluster tempat ArgoCD berjalan (in-cluster) dan semua cluster lain (eksternal).
| Aspek | In-Cluster | Eksternal |
|---|---|---|
| Alamat server | https://kubernetes.default.svc | Endpoint API cluster, mis. EKS/GKE |
| Registrasi | Tidak perlu, otomatis ada | Wajib argocd cluster add |
| Kredensial | Memakai SA ArgoCD di namespace argocd | Service account token di cluster target |
| Perawatan | Dibawa upgrade ArgoCD | Independen per cluster |
Perhatikan bahwa in-cluster pun diperlakukan sebagai "cluster" oleh ArgoCD — ia punya nama in-cluster dan muncul di daftar cluster.
Cara termudah mendaftarkan cluster adalah lewat kubeconfig context yang sudah kalian miliki:
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-devApa 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:
argocd-manager di namespace kube-system.argocd-manager-role dengan permission yang cukup untuk membaca dan mengelola resource aplikasi.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.
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:
region untuk memilih domain.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:
kubectl create sa argocd-manager -n kube-system
kubectl apply -f role-binding.yaml
argocd cluster add eks-prod --service-account argocd-managerRBAC 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.
Operasi harian terhadap cluster sangat sederhana:
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.comargocd 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.
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.
Keputusan arsitektural berikutnya: satu ArgoCD untuk semua, atau beberapa ArgoCD?
| Aspek | Centralized | Distributed |
|---|---|---|
| Jumlah instance | Satu, sering di cluster "hub" | Satu per environment/cluster |
| Kelebihan | Satu titik kendali, RBAC & SSO terpusat | Isolasi kegagalan, blast radius kecil |
| Kekurangan | Titik gagal tunggal, butuh HA | Konfigurasi berulang, kredensial tersebar |
| Cocok untuk | Tim platform kecil, cluster < 20 | Banyak 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.
Setelah cluster didaftarkan, penempatan aplikasi tinggal soal memilih destination. Saat membuat Application, tentukan destination.server dan destination.namespace:
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: trueArgoCD 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.
Karena ArgoCD memegang kredensial ke semua cluster, keamanan menjadi prioritas:
argocd-secret; batasi akses ke Secret ini hanya untuk operator ArgoCD.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.
CreateNamespace=true, tapi pastikan memang diizinkan oleh kebijakan tim.argocd cluster update masih mungkin, tapi ApplicationSet dan filtering di UI akan lebih sulit disetel belakangan.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:
argocd cluster add memakai kubeconfig context lalu membuat ServiceAccount argocd-manager di cluster target.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!