Zero-Downtime Deployment Kubernetes & Strategi GitOps dengan ArgoCD

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan aplikasi modern, tuntutan untuk menghadirkan fitur baru dengan kecepatan tinggi sering kali berbenturan dengan kebutuhan fundamental stabilitas infrastruktur. Di era Continuous Delivery, proses deployment manual atau skrip shell tradisional yang mematikan layanan secara tiba-tiba (downtime) bukan lagi pilihan yang dapat diterima. Bagi bisnis berbasis web, detik-detik berhentinya layanan berarti kehilangan pendapatan, penurunan kepercayaan pengguna, dan potensi pelanggaran Service Level Agreement (SLA).

Secara historis, bottleneck utama dalam pembaruan aplikasi terletak pada bagaimana lalu lintas web (traffic) dialirkan ke instans aplikasi baru tanpa memutus koneksi yang sedang aktif. Masalah ini diperparah ketika kita mengelola arsitektur web berlapis yang melibatkan Reverse Proxy (seperti Nginx atau Caddy), Backend Services (Golang, Node.js, PHP-FPM), lapisan caching (Redis), hingga database relational (MySQL/MariaDB). Ketika satu komponen gagal memperbarui status kesehatannya (health check), efek domino dapat melumpuhkan seluruh ekosistem.

Sebelum penerapan model GitOps berbasis Kubernetes dan ArgoCD, kondisi operasional umumnya ditandai dengan:

• Konfigurasi Drift: Perbedaan antara konfigurasi yang dideklarasikan di repositori kode dengan kenyataan di klaster produksi akibat perubahan manual (hotfix langsung di server).
• Human Error: Eksekusi perintah kubectl apply atau skrip CI/CD mentah yang salah menargetkan namespace atau klaster.
• Recovery Lambat: Proses rollback yang memakan waktu lama karena harus mencari artefak versi sebelumnya secara manual dan menjalankan ulang skrip.

Sesudah penerapan Zero-Downtime Deployment dengan ArgoCD dan Kubernetes:

• Single Source of Truth: Seluruh status infrastruktur dideklarasikan secara eksplisit dalam Git. Apa yang ada di repositori adalah apa yang berjalan di produksi.
• Otomatisasi Penuh: Sinkronisasi berkelanjutan memastikan klaster secara otomatis menyamakan diri dengan repositori Git tanpa intervensi manual.
• In-Flight Request Protection: Rolling update cerdas memastikan koneksi HTTP/WebSocket yang sedang aktif diselesaikan secara anggun (graceful shutdown) sebelum pod lama dimusnahkan.

2. Konsep Inti & Deep Dive Arsitektur

GitOps adalah paradigma operasional di mana Git bertindak sebagai sumber kebenaran tunggal untuk deklarasi infrastruktur dan aplikasi. Dalam konteks ekosistem Kubernetes, ArgoCD bertugas sebagai Continuous Delivery tool deklaratif yang memantau repositori Git secara terus-menerus dan membandingkan keadaan aktual di klaster dengan keadaan yang diinginkan (desired state).

+-------------------------------------------------------------+ 
|                         GIT REPO                            |
|          (Manifests: Deployment, Service, Ingress)          |
+------------------------------+------------------------------+
                               |
                         (Webhook / Poll)
                               v
+------------------------------+------------------------------+
|                         ARGO CD                             |
|                  (Application Controller)                   |
+------------------------------+------------------------------+
                               |
                   (Reconcile & Sync Loop)
                               v
+-------------------------------------------------------------+ 
|                     KUBERNETES CLUSTER                      |
|                                                             |
|  +--------------------+           +---------------------+   | 
|  |   Old Pod (v1.0)   | <-------  |   New Pod (v1.1)    |   | 
|  | (Graceful Shutdown)|           | (Liveness/Readiness)|   | 
|  +--------------------+           +---------------------+   | 
|              ^                               ^              |
|              |                               |              |
|              +---------------+---------------+              | 
|                              |                              | 
|                    (Kubernetes Service)                     | 
+------------------------------+------------------------------+
                               |
                         (External Traffic)

Alur eksekusi di balik layar (under the hood) saat terjadi pembaruan kode:

1. Pengembang melakukan merge kode baru ke branch utama (misal: main) di Git.
2. Proses CI (seperti GitHub Actions atau GitLab CI) membangun container image baru (misal: app:v1.1.0), mendorongnya ke Container Registry, lalu memperbarui tag image pada repositori manifest Git.
3. ArgoCD mendeteksi perubahan tersebut melalui webhook atau mekanisme polling berkala.
4. ArgoCD memulai proses reconciliation. Jika konfigurasi di ArgoCD diatur ke Auto-Sync, ia langsung menerapkan manifest baru ke API Server Kubernetes.
5. Kubernetes menjalankan strategi RollingUpdate pada objek Deployment. Ia membuat pod baru (v1.1.0) dan menahan pod lama (v1.0.0).
6. Kubernetes menunggu hingga pod baru melewati Readiness Probe sebelum mengarahkannya ke Service dan mulai mengirimkan traffic web.
7. Pod lama dikirimkan sinyal SIGTERM, memulai masa tenggang (termination grace period), menyelesaikan permintaan HTTP yang sedang berjalan, dan akhirnya dimusnahkan (SIGKILL).

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis mendalam mengenai tiga strategi pembaruan aplikasi utama di Kubernetes beserta pertimbangan sumber daya (resources trade-off).

[!WARNING] Strategi Recreate tidak boleh digunakan pada lingkungan produksi untuk aplikasi web publik karena menyebabkan layanan mati total selama proses terminasi dan pembuatan pod baru.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan arsitektur ini, pastikan infrastruktur Anda memenuhi spesifikasi minimum berikut:

1. Klaster Kubernetes: Versi 1.25 atau lebih tinggi (mendukung fitur API manajemen siklus hidup pod modern).
2. ArgoCD: Terinstal pada klaster (biasanya pada namespace argocd).
3. CLI Tools: kubectl, argocd, dan helm (jika menggunakan Helm chart).
4. Domain & Ingress Controller: Nginx Ingress Controller atau Traefik yang dikonfigurasi dengan dukungan TLS (Let's Encrypt).

Verifikasi akses klaster dengan perintah berikut:

kubectl cluster-info
kubectl get nodes -o wide

Pastikan ArgoCD CLI terhubung dengan benar:

argocd login argocd.internal.domain --username admin --password <password-anda>

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah implementasi lengkap manifest Kubernetes untuk aplikasi web berbasis Go/Node/PHP dengan konfigurasi RollingUpdate, Liveness/Readiness Probes, dan integrasi ArgoCD.

A. Manifest Deployment dan Service (k8s/deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: enterprise-web-app
  namespace: production
  labels:
    app.kubernetes.io/name: enterprise-web-app
    app.kubernetes.io/part-of: core-infrastructure
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Maksimal jumlah pod tambahan di atas replicas yang ditentukan
      maxUnavailable: 0 # Menjamin tidak ada pod yang mati sebelum pod baru siap
  selector:
    matchLabels:
      app.kubernetes.io/name: enterprise-web-app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: enterprise-web-app
    spec:
      terminationGracePeriodSeconds: 60 # Waktu tunggu anggun untuk menyelesaikan request HTTP in-flight
      containers:
      - name: web-app
        image: registry.internal.domain/engineering/web-app:v1.0.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
          name: http
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "2000m"
            memory: "2048Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          timeoutSeconds: 3
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 2
          successThreshold: 1
          failureThreshold: 2
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh