# Membangun Zero-Downtime Deployment di Kubernetes dengan ArgoCD

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/membangun-zero-downtime-deployment-di-kubernetes-dengan-argocd

---

Pukul 2 pagi. PagerDuty berdering keras membangunkan saya dari mimpi buruk tentang disk yang kehabisan inode. Di layar terminal, pipeline CI/CD yang tadinya berjalan mulus tiba-tiba mandek karena *network timeout* saat melakukan `kubectl apply` langsung dari Jenkins server. Layanan web utama kami down selama 4 menit penuh, menyebabkan ribuan transaksi checkout gagal dan membuat tim *business development* mengamuk di Slack pagi harinya. Saat itulah kami sadar: mengandalkan skrip Bash manual atau pipeline CI yang mendorong *state* secara agresif ke cluster Kubernetes adalah resep bencana yang menunggu waktu meledak. Kita butuh perubahan radikal menuju GitOps murni menggunakan ArgoCD, membiarkan *cluster* melakukan sinkronisasi secara mandiri dari *repository* Git yang menjadi satu-satunya sumber kebenaran (*single source of truth*).

Mari kita bedah secara mendalam melalui *head-to-head architectural battle* antara pendekatan konvensional **Jenkins CI Push Deployment** melawan **ArgoCD GitOps Pull Deployment**, dua kubu yang saling bersaing ketat merebutkan kendali atas ekosistem Kubernetes modern.

| Metrik Evaluasi | Jenkins CI Push Deployment | ArgoCD GitOps Pull Deployment |
| :--- | :--- | :--- |
| Kecepatan Sync | 6/10 | 9/10 |
| Latency Pemulihan | 4/10 | 10/10 |
| Penggunaan RAM (Controller) | 7/10 | 8/10 |
| Kemudahan Setup Awal | 8/10 | 6/10 |
| Keamanan Akses Cluster | 3/10 | 9/10 |
| Skalabilitas Multi-Cluster | 5/10 | 10/10 |
| Audit Trail & Compliance | 6/10 | 10/10 |

## 1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Di satu sisi ring, kita punya **Jenkins CI Push Deployment**—veteran tua yang telah berjasa membangun dunia *software delivery* selama satu dekade terakhir. Filosofinya sederhana: *“Saya adalah mandor pabrik. Setiap ada kode baru, saya yang akan merakitnya, saya yang akan berjalan menuju server produksi, dan saya yang akan memaksa server tersebut menelan perubahan terbaru.”* Pendekatan ini membuat Jenkins harus memegang *kubeconfig* dengan hak akses penuh (`cluster-admin`) langsung di dalam *build agent*-nya. Bayangkan risikonya jika *agent* tersebut berhasil disusupi oleh penyerang; seluruh cluster Kubernetes Anda berada di ujung tanduk.

Di sudut sebaliknya, **ArgoCD GitOps Pull Deployment** datang membawa angin segar dari era Cloud-Native. Filosofinya berbalik 180 derajat: *“Tidak ada yang boleh menyentuh cluster secara langsung dari luar. Cluster akan secara proaktif mengawasi Git repository, dan jika ada perbedaan antara deklarasi di Git dan realitas di server, cluster itu sendiri yang akan menarik (pull) perubahan tersebut.”* ArgoCD bertindak sebagai penjaga gerbang yang disiplin. Tidak ada lagi admin yang iseng mengetik `kubectl edit deployment` secara diam-diam di *production*, karena ArgoCD akan langsung mendeteksinya sebagai *Drift* dan secara otomatis mengembalikannya ke kondisi semula atau memicu *alert*.

Tetapi, filosofi yang indah tidak akan berarti apa-apa jika implementasinya di lapangan justru membuat para *engineer* stres menghadapi konfigurasi YAML yang berlapis-lapis. Mari kita lihat bagaimana rasanya menulis dan mengelola konfigurasi harian dari kedua kubu ini.

## 2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Bekerja dengan Jenkins berarti Anda harus bergelut dengan `Jenkinsfile` yang panjang, penuh dengan skrip Groovy yang terkadang sulit di-debug ketika variabel lingkungan gagal diteruskan. Saat Anda ingin melakukan *rolling update* untuk aplikasi web berbasis Go atau Node.js yang melayani jutaan *request* dibalik Nginx/Cloudflare, Anda harus menulis baris perintah kubectl yang sangat panjang:

```groovy
stage('Deploy to Production') {
    steps {
        sh 'kubectl set image deployment/web-app web-app=registry.internal/app:${GIT_COMMIT} -n production'
        sh 'kubectl rollout status deployment/web-app -n production --timeout=300s'
    }
}
```

Jika terjadi kegagalan di tengah jalan, skrip Groovy tersebut sering kali meninggalkan *state* yang menggantung, memaksa engineer melakukan *manual rollback* menggunakan perintah `kubectl rollout undo` sambil berdoa agar koneksi database tidak mengalami *deadlock* akibat migrasi skema yang berjalan dua kali.

Sebaliknya, saat Anda mengonfigurasi ArgoCD, pengalaman hariannya terasa jauh lebih bersih karena dipisahkan secara tegas antara *pipeline build* dan *deployment state*. Anda hanya perlu mendaftarkan *Helm chart* atau sekumpulan manifest Kustomize ke dalam ArgoCD Application CRD (Custom Resource Definition):

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-app-production
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/company/k8s-gitops-configs.git'
    targetRevision: HEAD
    path: manifests/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
```

> [!TIP]
> Gunakan fitur `selfHeal: true` pada ArgoCD dengan hati-hati. Jika ada proses *hotfix* darurat yang dilakukan secara manual menggunakan `kubectl patch` di *production*, ArgoCD akan langsung menimpanya kembali dengan konfigurasi yang ada di Git dalam hitungan detik. Pastikan budaya *“Git is the only source of truth”* benar-benar dipahami oleh seluruh anggota tim Anda.

Namun, kemudahan deklaratif ini harus diuji di medan pertempuran yang sebenarnya: bagaimana performa keduanya saat menghadapi gempuran lonjakan trafik ekstrem yang mensimulasikan *flash sale* akhir tahun?

## 3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Kami melakukan pengujian stres menggunakan perangkat `k6` dan `wrk` untuk mensimulasikan 50.000 *concurrent users* yang mengakses layanan *e-commerce* berbasis PHP-FPM dan Redis cache, sementara proses *deployment* versi baru dijalankan secara bersamaan di latar belakang.

Pada kubu **Jenkins CI Push Deployment**, saat skrip `kubectl set image` dieksekusi di tengah beban puncak, server API Kubernetes mendadak mengalami lonjakan penggunaan CPU akibat antrean *requests* dari Jenkins agent yang mencoba melakukan *patch* pada ratusan pod secara simultan. Terjadi *dropped packets* pada Nginx Ingress Controller, dan latensi rata-rata melonjak dari 45ms menjadi 850ms. Beberapa pod baru gagal melakukan *readiness probe* karena koneksi ke Redis mengalami *timeout* akibat lonjakan koneksi mendadak, menyebabkan *downtime* parsial selama 45 detik.

Sementara itu, di arena **ArgoCD**, ketika repositori Git mendapati perubahan tag *image*, ArgoCD *controller* membaca pembaruan tersebut secara asinkron. ArgoCD tidak menembak Kubernetes API secara brutal; ia menggunakan mekanisme *rolling update* bawaan Kubernetes yang dikontrol dengan sangat presisi melalui strategi *Canary* menggunakan Argo Rollouts:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 10s }
        - setWeight: 50
        - pause: { duration: 10s }
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: registry.internal/app:v2.0.0
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 3
```

> [!IMPORTANT]
> Penggunaan Argo Rollouts dengan strategi *weighted canary* memastikan bahwa trafik pengguna dialihkan secara bertahap (20% -> 50% -> 100%). Jika terjadi anomali pada *error rate* yang dipantau oleh Prometheus, ArgoCD secara otomatis menghentikan peluncuran tanpa mengorbankan pengalaman pengguna akhir.

Pertandingan ini tidak hanya soal ketahanan di bawah beban, tetapi juga tentang seberapa besar sumber daya infrastruktur yang harus kita korbankan untuk menjalankan sistem *deployment* itu sendiri.

## 4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Mari berbicara jujur tentang angka di AWS Billing atau tagihan server fisik Anda. Menjalankan **Jenkins** di skala enterprise membutuhkan *provisioning* server khusus atau *build agent* berbasis ECS/Kubernetes Pods yang hidup dan mati setiap kali ada *build*. Dalam praktiknya, sebuah Jenkins Controller dengan plugin yang melimpah membutuhkan setidaknya 4GB hingga 8GB RAM agar tidak mengalami *OutOfMemoryError* saat melakukan *parallel builds*. Ditambah lagi dengan biaya penyimpanan *workspace* dan artefak sementara.

Di sisi lain, **ArgoCD** berjalan langsung di dalam klaster Kubernetes sebagai sekumpulan *microservices* (API Server, Application Controller, Repo Server, dan Redis untuk *cache* internal). Berdasarkan pemantauan dari Prometheus dan Grafana di lingkungan produksi kami yang mengelola lebih dari 40 *microservices*: 
- **ArgoCD Application Controller** memakan sekitar 1.5GB RAM dan konsumsi CPU yang sangat rendah (sekitar 0.2 vCPU) dalam kondisi stabil (*idle*), karena ia hanya melakukan *polling* atau mendengarkan *webhook* dari Git.
- **ArgoCD Repo Server** sedikit lebih boros saat melakukan *helm template rendering*, memakan hingga 2GB RAM pada saat bersamaan, namun dapat dioptimalkan dengan meningkatkan jumlah *replicas* dan menggunakan *persistent caching*.

Secara finansial dan operasional, ArgoCD jauh lebih efisien karena menghilangkan kebutuhan akan server CI eksternal yang kompleks hanya untuk melakukan tugas *deployment* ke Kubernetes. Namun, apakah ini berarti Anda harus langsung membuang Jenkins dan bermigrasi total ke ArgoCD? Tentu saja tidak. Mari kita tentukan batas garis penggunaannya secara objektif.

## 5. Kapan Wajib Menggunakan ArgoCD GitOps Pull Deployment

Anda wajib meninggalkan cara-cara lama dan segera mengadopsi ArgoCD jika organisasi Anda berada dalam kondisi berikut:
1. **Infrastruktur Multi-Cluster yang Kompleks:** Jika Anda mengelola klaster Kubernetes di AWS (EKS), Google Cloud (GKE), dan *on-premise* secara bersamaan, mengontrol semuanya dari satu *dashboard* ArgoCD pusat jauh lebih masuk akal daripada mengonfigurasi kredensial `kubeconfig` di puluhan *pipeline* CI yang berbeda.
2. **Kepatuhan Audit dan Keamanan Ketat (SOC2 / ISO 27001):** Ketika auditor menanyakan siapa yang mengubah konfigurasi produksi pada hari Selasa pukul 3 sore, Anda bisa menunjuk langsung ke *commit hash* di repositori Git yang memiliki tanda tangan GPG yang sah, lengkap dengan catatan siapa yang melakukan *merge PR* tersebut.
3. **Budaya Kolaborasi Berbasis Pull Request:** Tim Anda sudah terbiasa menggunakan *Pull Request workflow* untuk perubahan infrastruktur, di mana setiap perubahan konfigurasi harus melalui *code review* dan persetujuan dari rekan setim sebelum diterapkan ke lingkungan produksi.

## 6. Kapan Wajib Menggunakan Jenkins CI Push Deployment

Namun, mari bersikap realistis. Ada skenario di mana ArgoCD justru menjadi beban berlebih (*overkill*), dan Anda lebih baik tetap menggunakan Jenkins atau GitLab CI tradisional:
1. **Aplikasi Non-Kubernetes (Legacy Monolith):** Jika sebagian besar aplikasi Anda masih berupa skrip PHP tradisional yang berjalan di atas server VPS biasa dengan Nginx dan PHP-FPM tanpa kontainerisasi Docker, ArgoCD sama sekali tidak berguna bagi Anda.
2. **Pipeline CI/CD yang Sangat Dinamis dan Berbasis Artefak Kompleks:** Jika alur kerja Anda membutuhkan proses *compilation* berkas biner yang sangat rumit, *automated integration testing* dengan ribuan skenario *Selenium*, dan pengujian beban sebelum membuat artefak yang sangat spesifik per-branch, Jenkins tetap menjadi raja di ranah tersebut.
3. **Tim yang Belum Siap dengan Paradigma GitOps:** Jika kultur tim Anda masih menyukai *manual intervention* dan belum memiliki disiplin tinggi dalam mengelola repositori Git, memaksa migrasi ke ArgoCD hanya akan membuat mereka frustrasi ketika menghadapi masalah *sync drift* yang terkadang membingungkan pemula.

## 7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai arsitek yang telah melihat jatuh bangunnya infrastruktur skala besar, keputusan akhirnya sangat jelas: **Pisahkan urusan *Build* dan *Deploy*.**

Gunakan Jenkins, GitLab CI, atau GitHub Actions secara murni untuk apa yang mereka kuasai dengan sangat baik: menjalankan *unit test*, melakukan *linting* kode, mem-build *Docker image*, melakukan pemindaian keamanan (SCA/SAST), dan mendorong (*push*) *image* tersebut ke *container registry* privat (seperti Harbor atau AWS ECR). Setelah *image* terbaru dengan *tag* unik tersedia di *registry*, perbarui file manifes Kubernetes (atau file *values* Helm) di repositori Git terpisah secara otomatis melalui *pipeline* CI.

Biarkan **ArgoCD** mengambil alih tugas berikutnya: menarik (*pull*) perubahan manifes tersebut dari Git dan menerapkannya dengan aman ke dalam klaster Kubernetes produksi menggunakan strategi *Rolling Update* atau *Canary* yang elegan. Dengan kombinasi ini, Anda mendapatkan kecepatan pengembangan dari alat CI favorit Anda, digabungkan dengan ketenangan pikiran, keamanan tingkat tinggi, dan stabilitas mutlak dari arsitektur GitOps murni.