Belajar GitOps dengan ArgoCD - High Availability Setup

#Pendahuluan

Di episode 25 sebelumnya kita mengoptimalkan performa ArgoCD — membuatnya cepat di ribuan aplikasi. Namun kecepatan tidak menjamin ketersediaan: jika node yang menampung argocd-server mati, tidak peduli seberapa cepat ia, seluruh tim kehilangan akses ke UI dan CLI. Pada episode ini kita membahas high availability setup — mendesain ArgoCD sedemikian rupa sehingga kegagalan satu pod, satu node, atau satu zona tidak menghentikan delivery.

Mengapa ini penting? Ingat posisi ArgoCD: ia adalah satu-satunya jembatan antara Git dan cluster. Jika ArgoCD mati, aplikasi tidak serta-merta mati (Kubernetes terus menjalankan apa yang sudah ada), tetapi semua hal berikut berhenti: sync, drift detection, self-healing, dan akses operasional. Untuk lingkungan yang menjanjikan SLO, ArgoCD itu sendiri harus menjadi komponen yang paling sulit dimatikan. Episode ini memberikan resepnya — dan cara membuktikannya.

#Arsitektur HA

Prinsip dasar HA adalah tidak ada komponen tunggal yang menjadi titik kegagalan. Ini diwujudkan dengan tiga mekanisme:

• Multiple replicas — lebih dari satu pod untuk setiap komponen stateless.
• Leader election — untuk komponen stateful seperti controller: hanya satu yang "aktif", yang lain menunggu; ketika yang aktif mati, penggantinya naik dengan cepat.
• Load distribution — trafik tersebar ke semua replika lewat Service.

Ketika desain ini benar, satu pod mati adalah peristiwa biasa, bukan insiden. Kalian akan melihat log leader lease pada controller:

argocd-application-controller-0 ... starting leader election
argocd-application-controller-1 ... attempting to acquire leadership
argocd-application-controller-1 ... successfully acquired lease argocd/argocd-application-controller

#HA per Komponen

Mari bedah satu per satu.

#API Server — Multi Replica

argocd-server stateless; jalankan beberapa replika di belakang Service:

Server HA

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: argocd-server
          args:
            - /usr/local/bin/argocd-server
            - --staticassets=/shared/app

ArgoCD menangani ini dengan mudah; dengan topologySpreadConstraints (di bawah) replika tersebar antar node sehingga kegagalan satu node tidak mematikan semua replika.

#Repo Server — Multi Replica

argocd-repo-server juga stateless, tetapi menyimpan cache di Redis (bukan lokal). Karena itu skala horizontal aman. Gunakan HPA (episode 25) atau replika tetap, dan pastikan semua replika berbagi Redis yang sama agar cache tidak terpecah.

#Application Controller — Active-Passive

Controller stateful: ia menyimpan status aplikasi dan harus dieksekusi oleh satu leader pada satu waktu. ArgoCD menyelesaikannya dengan leader election berbasis coordination.k8s.io/Lease. Jalankan 2-3 replika; hanya leader yang bekerja, sisanya standby siap mengambil alih:

Controller active-passive

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: argocd-application-controller
spec:
  replicas: 2

Ketika leader mati, lease kedaluwarsa dan standby mengambil alih dalam hitungan detik. Inilah pola active-passive yang sama dengan konsep multi-cluster DR di episode 21, tetapi dalam satu cluster.

#Redis — Sentinel atau Cluster

Redis adalah otak cache ArgoCD. Jika mati, ArgoCD masih bekerja tetapi tanpa cache — dan performance kembali ke mode "kloning penuh". Untuk HA:

• Redis Sentinel — satu primary + beberapa replica dengan sentinel yang otomatis mempromosikan replica saat primary mati. Pilihan default chart HA.
• Redis Cluster — sharded, untuk skala sangat besar.

Keduanya membutuhkan PersistentVolumeClaim agar data tidak hilang saat pod restart, dan keduanya dikelola sebagai manifest di Git:

redis:
  enabled: true
  sentinel:
    enabled: true
    masterName: argocd
  metrics:
    enabled: true

#Pertimbangan Database

Cache Redis bukan database yang "harus selalu konsisten" — kehilangannya hanya menurunkan performa. Namun ada dua praktik yang tetap wajib:

• Persistent storage — beri PVC pada Redis agar data cache bertahan melewati restart pod. Data yang hilang bukan bencana, tetapi menyebabkannya berarti re-clone dan re-render ulang semua repo — beban yang bisa dihindari.
• Backup — cadangkan Redis (atau cukup terima pengisian ulang cache dari Git). Karena sumber kebenaran adalah Git, strategi paling murah adalah tidak membackup cache, melainkan memastikan pengisian ulang berjalan otomatis dan cepat. Catat ini sebagai keputusan desain di dokumentasi.

Untuk state controller, ingat: state sebenarnya ArgoCD sudah ada di Git. Inilah keuntungan struktural GitOps — ArgoCD tidak menyimpan kebenaran, ia menyimpan hasil. Kehilangan status internal hanya berarti re-reconcile, bukan kehilangan data.

#HA Jaringan

Lapisan terakhir adalah akses. UI/CLI harus tetap bisa diakses ketika komponen individual berganti:

• Load balancer — taruh Service di depan argocd-server (NodePort/LoadBalancer/Ingress). Health check memastikan trafik hanya menuju replika sehat.
• Ingress redundancy — jalankan lebih dari satu Ingress controller; jika satu node mati, controller di node lain melayani. Kombinasikan dengan network load balancer provider.
• DNS failover — untuk multi-cluster (episode 21), taruh record DNS di depan penyeimbang beban global yang bisa mengalihkan trafik ke cluster sekunder saat primary tidak sehat.

Topology spread adalah penyempurna penting: sebar replika ke node berbeda agar satu node down tidak menumbangkan semua replika:

Topology spread untuk server

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app.kubernetes.io/name: argocd-server

#Menguji HA: Chaos dan Failure Injection

Arsitektur HA yang tidak diuji sama dengan tidak ada. Gunakan chaos engineering untuk membuktikan klaim:

1. Failure injection — matikan satu pod secara acak: kubectl delete pod -n argocd argocd-server-xxx dan amati apakah Service menyembunyikan pergantiannya.
2. Matikan leader controller — pastikan standby mengambil alih tanpa menghentikan reconciliation.
3. Matikan Redis primary — pastikan Sentinel mempromosikan replica dalam waktu yang bisa diterima.
4. Matikan satu node (drain) — pastikan topologySpreadConstraints bekerja dan replika tersebar ulang.

Alat seperti kube-monkey atau Litmus mengeksekusi skenario ini terjadwal, tetapi bahkan manual monthly drill (pola yang sama dengan DR drill di episode 21) sudah bernilai besar:

kubectl delete pod -n argocd -l app.kubernetes.io/name=argocd-server --wait=false
kubectl get pods -n argocd -w
argocd app list

Recovery validation — ukur waktu dari injeksi kegagalan sampai semua komponen sehat kembali. Catat hasilnya: jika pemulihan memakan waktu lebih lama dari SLO kalian, perbaiki desain sebelum kegagalan nyata terjadi.

#Penutup

Episode ini menutup loop ketersediaan ArgoCD: arsitektur HA dengan replika ganda dan leader election, HA per komponen (server, repo server, controller active-passive, Redis Sentinel), pertimbangan storage dan backup Redis, HA jaringan dengan load balancer, ingress redundancy, dan topology spread, serta pengujian dengan chaos engineering dan failure injection.

Poin yang harus kalian bawa:

• Komponen stateless diskalakan horizontal; controller memakai leader election.
• Redis butuh Sentinel (atau cluster) dan PVC agar cache tidak jadi titik gagal.
• State asli ArgoCD ada di Git; kehilangan status internal hanya re-reconcile.
• Topology spread menyebar replika antar node untuk menghadapi kegagalan node.
• HA harus diuji: inject failure, ukur pemulihan, perbaiki bila meleset dari SLO.

Dengan episode ini, perjalanan dari dasar GitOps sampai produksi siap adalah garis yang utuh: instalasi, aplikasi, skala, keamanan, hingga ketahanan. Di episode 27 selanjutnya kita membahas troubleshooting & debugging — memecahkan sync failure, health check gagal, masalah autentikasi, akses repo, dan teknik debugging dengan CLI ArgoCD. Sampai jumpa di episode 27!