Zero-Downtime GitOps Deployment Menggunakan ArgoCD dan Kubernetes

1. Konteks Industri & Analisis Akar Masalah

Di era modern, siklus hidup pengembangan perangkat lunak (SDLC) menuntut kecepatan rilis yang tinggi tanpa mengorbankan stabilitas sistem. Pendekatan tradisional seperti Push-based CI/CD (menggunakan Jenkins, GitLab CI, atau GitHub Actions untuk melakukan kubectl apply langsung ke kluster Kubernetes dari pipeline eksternal) menyimpan celah keamanan dan kerentanan operasional yang serius. Kredensial kubeconfig dengan hak akses penuh (ClusterAdmin) harus disimpan di server CI/CD eksternal. Jika server tersebut disusupi, seluruh infrastruktur kluster Kubernetes akan jatuh ke tangan penyerang.

Selain itu, pendekatan push sering mengalami masalah drift konfigurasi—kondisi di mana keadaan aktual di dalam kluster berbeda dari apa yang didefinisikan dalam repositori kode akibat perubahan manual (hotfix darurat langsung di server). Hal ini menyebabkan auditabilitas yang buruk, sulitnya rollback saat terjadi kegagalan, dan ketidakpastian status aplikasi di lingkungan produksi.

GitOps membalik paradigma ini menjadi Pull-based Continuous Reconciliation. ArgoCD berjalan di dalam kluster Kubernetes, secara proaktif memantau repositori Git yang berisi Declarative Manifests (baik berupa manifes Kubernetes murni, Kustomize, maupun Helm chart), lalu mencocokkan kondisi aktual kluster dengan status yang diinginkan (desired state) di Git secara otomatis.

Perbandingan Kondisi: Sebelum vs Sesudah GitOps

2. Konsep Inti & Deep Dive Arsitektur

ArgoCD adalah implementasi declarative, GitOps continuous delivery tool untuk Kubernetes. Arsitekturnya dirancang dengan prinsip modular menggunakan beberapa komponen inti (controllers) yang bekerja secara asinkron di dalam namespace khusus (biasanya argocd).

Diagram Arsitektur ArgoCD Under the Hood

+-------------------------------------------------------------------------+
|                        KUBERNETES PRODUCTION CLUSTER                    |
|                                                                         |
|  +--------------------+       +-------------------------------------+   |
|  |                    |       |              ArgoCD API Server      |   |
|  |   Git Repository   |       |  (UI / CLI / Webhook Receiver)      |   |
|  | (Manifests/Charts) |       +------------------+------------------+   |
|  |                    |                          |                      |
|  +---------+----------+                          v                      |
|            |                  +------------------+------------------+   |
|            | (Webhook /       |          ArgoCD Repo Server         |   |
|            |  Polling)        | (Clones Git, Renders Helm/Kustomize)|   |
|            |                  +------------------+------------------+   |
|            |                                     |                      |
|            v                                     v                      |
|  +---------+----------+       +------------------+------------------+   |
|  |                    |       |         ArgoCD Application          |   |
|  |   Webhook Ingress  +-----> |             Controller              |   |
|  |                    |       | (Compares Live State vs Git State)  |   |
|  +--------------------+       +------------------+------------------+   |
|                                                  |                      |
|                                                  v                      |
|                               +------------------+------------------+   |
|                               |          Kubernetes API Server      |   |
|                               +-------------------------------------+   |
+-------------------------------------------------------------------------+

Penjelasan Komponen Inti:

1. API Server: Antarmuka berbasis gRPC/REST yang melayani Web UI, CLI, dan webhook penanganan notifikasi Git.
2. Repo Server: Komponen yang bertugas melakukan clone repositori Git secara lokal, menyimpan cache, serta merender manifests mentah dari template Helm, Kustomize, atau direktori YAML murni.
3. Application Controller: Mesin rekonsiliasi utama. Ia membandingkan status aktual sumber daya di kluster Kubernetes dengan status yang dihasilkan oleh Repo Server. Jika ditemukan perbedaan (OutOfSync), ia akan mengambil tindakan berdasarkan kebijakan sinkronisasi (Sync Policy) yang ditetapkan.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun sistem GitOps, terdapat dua pendekatan utama dalam pengorganisasian repositori:

[!TIP] Untuk lingkungan enterprise berskala besar, selalu gunakan Separate Infra/Manifest Repo guna memisahkan izin akses antara pengembang aplikasi (Developers) dan insinyur platform (Platform Engineers).

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi ArgoCD, pastikan infrastruktur pendukung telah memenuhi spesifikasi minimum berikut:

• Kluster Kubernetes: Versi 1.24 hingga 1.30+ dengan akses cluster-admin.
• Storage Class: Mendukung penyediaan Persistent Volume dinamis untuk database Redis ArgoCD.
• Network: Ingress Controller (seperti Nginx Ingress atau Traefik) dan Cert-Manager untuk manajemen SSL/TLS.
• Tooling CLI: kubectl, argocd CLI, dan helm v3.

Verifikasi koneksi kluster:

kubectl cluster-info
kubectl get nodes

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi ArgoCD di Kluster Kubernetes

Buat namespace khusus untuk ArgoCD dan terapkan manifes instalasi resmi:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Verifikasi bahwa seluruh pod ArgoCD berjalan dengan normal:

kubectl get pods -n argocd -w

Langkah 2: Mengakses ArgoCD Web UI

Secara default, layanan argocd-server tidak diekspos secara publik. Ubah tipenya menjadi LoadBalancer atau gunakan Port Forwarding untuk akses administratif awal:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Akses melalui browser di https://localhost:8080. Untuk mendapatkan kata sandi awal (admin password), jalankan perintah berikut:

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

Langkah 3: Membuat Manifes Aplikasi Deklaratif

Buat file bernama application-production.yaml untuk mendaftarkan aplikasi web enterprise berbasis Go/Node.js ke ArgoCD.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: enterprise-web-app
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/perusahaan-anda/k8s-manifests-repo.git'
    targetRevision: HEAD
    path: 'apps/production/web-service'
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Terapkan manifes aplikasi ke kluster:

kubectl apply -f application-production.yaml

Langkah 4: Konfigurasi Strategi Rolling Update dan Canary (Argo Rollouts)

Untuk mencapai zero-downtime sejati tanpa interupsi koneksi aktif (seperti WebSocket atau transaksi HTTP jangka panjang), gunakan Argo Rollouts dengan strategi Canary Deployment.

Instalasi Argo Rollouts Controller:

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

Buat file manifes rollout-canary.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-backend-rollout
  namespace: production
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 80
        - pause: { duration: 2m }
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: web-backend
  template:
    metadata:
      labels:
        app: web-backend
    spec:
      containers:
        - name: web-app
          image: registry.perusahaan.internal/web-backend:v1.2.0
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: "1"
              memory: 1Gi
            requests:
              cpu: "500m"
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Terapkan manifes rollout:

kubectl apply -f rollout-canary.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dalam file konfigurasi ArgoCD Application dan Argo Rollouts:

• prune: true pada syncPolicy.automated: Menginstruksikan ArgoCD untuk secara otomatis menghapus sumber daya Kubernetes di kluster jika manifesnya dihapus dari repositori Git. Tanpa opsi ini, sumber daya lama akan tetap tertinggal (orphaned) dan memicu konflik memori atau port.
• selfHeal: true: Memastikan bahwa setiap perubahan manual langsung pada kluster (misalnya seseorang menjalankan kubectl scale deployment web-backend --replicas=5) akan segera ditimpa kembali oleh ArgoCD agar konsisten dengan file konfigurasi di Git.
• steps pada strategy.canary: Mengatur tahapan peluncuran secara bertahap. Pada contoh di atas, 20% traffic dialihkan ke versi baru selama 10 menit. Jika metrik kesehatan stabil, traffic dinaikkan secara otomatis hingga 100% tanpa campur tangan manual.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!IMPORTANT] Pada lingkungan produksi dengan jutaan concurrent requests (misalnya sistem e-commerce flash sale), rolling update biasa dapat memicu lonjakan latensi jika Graceful Shutdown tidak diimplementasikan dengan benar pada aplikasi backend (Node.js/Go/PHP-FPM).

Studi Kasus: Penanganan Trafik Tinggi dengan Graceful Shutdown

Ketika ArgoCD memicu pembaruan pod, Kubernetes akan mengirim sinyal SIGTERM ke kontainer. Aplikasi backend harus merespons sinyal ini dengan cara:

1. Berhenti menerima koneksi HTTP baru (stop accepting new socket connections).
2. Menyelesaikan pemrosesan permintaan HTTP/WebSocket yang sedang berjalan (in-flight requests).
3. Menutup koneksi database dan Redis secara aman.
4. Keluar dengan kode exit 0.

Contoh implementasi Graceful Shutdown pada aplikasi Go:

package main

import (
    "context"
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func main() {
    server := &http.Server{Addr: ":8080\