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.

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:

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):

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:

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.