L
Kubernetes & CI/CD • Literally Web ID

Zero-Downtime Deployment Menggunakan Kubernetes, ArgoCD, dan GitOps Pipeline

⏱️ 18 menit baca • 📅 15 Oct 2026 • 👁️ 1 views
Zero-Downtime Deployment Menggunakan Kubernetes, ArgoCD, dan GitOps Pipeline

1. Konteks Industri & Analisis Akar Masalah

Di era modern web engineering, tuntutan akan ketersediaan sistem (high availability) mencapai 99.999% bukan lagi sekadar ekspektasi enterprise, melainkan standar industri. Namun, realitas operasional sering kali bertolak belakang. Pendekatan deployment tradisional—seperti SSH langsung ke server web Nginx/Apache, eksekusi skrip Bash kustom, atau pengoperasian pipeline CI/CD imperatif seperti Jenkins yang melakukan kubectl apply secara langsung dari server eksternal—menyimpan kerapuhan sistemik yang masif.

Analisis Bottleneck & Risiko Keamanan

  1. Drift Konfigurasi (Configuration Drift): Keadaan aktual infrastruktur sering kali menyimpang dari state yang didefinisikan dalam repositori akibat hotfix manual di production. Hal ini menciptakan lingkungan yang tidak konsisten (Staging $\neq$ Production).
  2. Kelemahan Kredensial CI/CD: Penyimpanan secret atau file kubeconfig dengan akses cluster-admin di dalam runner CI/CD pihak ketiga (GitHub Actions, GitLab CI) membuka celah serangan lateral yang sangat berbahaya jika runner tersebut disusupi.
  3. Kurangnya Visibilitas Real-time: SRE sering kali kesulitan membedakan antara apa yang seharusnya berjalan di Kubernetes dengan apa yang sedang berjalan, berujung pada proses debugging yang memakan waktu saat insiden terjadi.
  4. Downtime Akibat Rollout Buruk: Pembaruan image backend (Go, Node.js, PHP-FPM) atau konfigurasi web server tanpa manajemen lifecycle pod yang tepat menyebabkan dropped connections, 502 Bad Gateway, dan latensi melonjak drastis.

Perbandingan: Sebelum vs. Sesudah GitOps

Parameter Pendekatan Imperatif Tradisional (CI/CD Push) Pendekatan GitOps Deklaratif (ArgoCD Pull)
Sumber Kebenaran (Source of Truth) Skrip CI, state lokal developer, server production Repositori Git (Git as Single Source of Truth)
Mekanisme Eksekusi Push eksternal dari sistem CI ke Kubernetes API Pull internal oleh ArgoCD agent di dalam cluster
Audit Trail Terfragmentasi di log sistem CI/CD Otomatis terekam dalam git commit history dan diff ArgoCD
Pemulihan Insiden (Rollback) Re-run job CI yang gagal atau manual hotfix git revert atau argo cd rollback dalam hitungan detik
Keamanan Cluster Kredensial kubeconfig beredar di luar cluster Cluster aman; agent hanya membaca repo Git publik/privat

2. Konsep Inti & Deep Dive Arsitektur

GitOps adalah seperangkat praktik yang menggunakan Git sebagai satu-satunya sumber kebenaran (single source of truth) untuk deklarasi infrastruktur dan konfigurasi aplikasi. Dalam ekosistem Kubernetes, ArgoCD mengimplementasikan pola ini menggunakan model Pull-based Control Loop.

Alur Kerja di Balik Layar (Under the Hood)

+------------------+       Git Commit       +----------------------+
| Developer / SRE  | ---------------------> | Git Repository (1)   |
+------------------+                        +----------------------+
                                                       |
                                                       | Poll / Webhook
                                                       v
+----------------------------------------------------------------------+
| Kubernetes Cluster (ArgoCD Control Loop)                             |
|                                                                      |
|  +--------------------+   Reconcile    +--------------------------+  |
|  | ArgoCD Application | -------------- | Live Cluster State (2)   |
|  +--------------------+                +--------------------------+  |
|           |                                          ^               |
|           +----------------- Sync State -------------+               |
+----------------------------------------------------------------------+
  1. Definisi Deklaratif: Seluruh manifes Kubernetes (Deployment, Service, Ingress, PersistentVolumeClaim) serta objek pendukung seperti konfigurasi Nginx/Caddy, secret manager, dan Helm Chart disimpan dalam repositori Git.
  2. Rekonsiliasi Otomatis (Reconciliation Loop): ArgoCD Controller secara berkala (atau dipicu oleh webhook Git) membandingkan keadaan nyata (live state) di dalam cluster Kubernetes dengan keadaan yang diinginkan (desired state) yang didefinisikan dalam Git.
  3. Deteksi Perbedaan (Diffing): Jika ada deviasi—misalnya seseorang mengubah replika deployment secara manual menggunakan kubectl scale—ArgoCD mendeteksi perbedaan tersebut (OutOfSync) dan secara otomatis atau manual mengembalikan cluster ke keadaan yang didefinisikan di Git (jika fitur Self-Heal diaktifkan).

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun pipeline deployment untuk infrastruktur web berbeban tinggi, pemilihan strategi update sangat menentukan kelangsungan operasional.

Strategi Deployment Kelebihan Kekurangan Konsumsi Sumber Daya (CPU/RAM/Latency) Skenario Terbaik
Rolling Update Sederhana, native Kubernetes, efisien sumber daya Potensi latensi sesaat jika liveness/readiness probe kurang optimal Minimal (hanya butuh 1-2 pod ekstra saat transisi) Aplikasi stateless standar, web backend sederhana (Node.js/Go)
Canary Deployment Risiko kegagalan terisolasi ke sedikit pengguna, validasi metrik real-time Kompleksitas arsitektur routing (Inference/Service Mesh/Ingress Controller) Sedang (menjalankan versi lama dan baru secara bersamaan) Sistem moneter, e-commerce skala besar, API kritikal
Blue/Green Deployment Rollback instan, pengujian lingkungan baru secara utuh sebelum dialihkan Membutuhkan duplikasi sumber daya infrastruktur 100% selama transisi Tinggi (double capacity selama proses switchover) Database migrasi kompleks, rilis mayor arsitektur web

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan ArgoCD dan Zero-Downtime Pipeline, pastikan lingkungan Anda memenuhi spesifikasi berikut:

  • Kubernetes Cluster: Versi 1.26+ (direkomendasikan menggunakan k3s untuk lightweight atau EKS/GKE untuk enterprise).
  • CLI Tools: kubectl, helm, argocd CLI terpasang pada mesin manajemen.
  • Domain & Ingress Controller: Nginx Ingress Controller atau Traefik dengan dukungan manajemen sertifikat cert-manager (Let's Encrypt).
  • Storage & Database: S3/MinIO untuk static asset, MySQL/MariaDB & Redis terkluster untuk backend web.

Verifikasi kesiapan cluster:

kubectl cluster-info
kubectl get nodes -o wide

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi ArgoCD di Kubernetes Cluster

Buat namespace khusus untuk ArgoCD dan instal manifes stabil menggunakan skrip 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

Dapatkan password awal untuk akun admin argocd-server:

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

Akses UI ArgoCD dengan melakukan port-forwarding:

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

Buka https://localhost:8080 di browser, gunakan username admin dan password yang dihasilkan di atas.

Langkah 2: Menyiapkan Repositori Git untuk Aplikasi Web

Struktur direktori repositori Git Anda (gitops-infra-repo) harus terorganisir dengan jelas:

gitops-infra-repo/
├── apps/
│   └── web-backend/
│       ├── namespace.yaml
│       ├── deployment.yaml
│       ├── service.yaml
│       └── ingress.yaml
└── argocd/
    └── application.yaml

Berikut adalah isi file apps/web-backend/namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: production-web

Berikut adalah file apps/web-backend/deployment.yaml yang menerapkan konfigurasi Rolling Update yang aman dan zero-downtime:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-backend
  namespace: production-web
  labels:
    app: web-backend
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: web-backend
  template:
    metadata:
      labels:
        app: web-backend
    spec:
      containers:
      - name: web-app
        image: registry.internal.net/company/web-backend:v1.2.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "200m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["sh", "-c", "sleep 10"]

Berikut adalah file apps/web-backend/service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: web-backend-svc
  namespace: production-web
ექ
spec:
  type: ClusterIP
  selector:
    app: web-backend
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Berikut adalah file apps/web-backend/ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-backend-ingress
  namespace: production-web
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: app.enterprise.com
    http:
    paths:
    - path: /
      pathType: Prefix
      backend:
        service:
          name: web-backend-svc
          port:
            number: 80

Langkah 3: Mendaftarkan Aplikasi ke ArgoCD

Buat file manifest ArgoCD Application di argocd/application.yaml:

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

Terapkan aplikasi ke dalam cluster ArgoCD:

kubectl apply -f argocd/application.yaml

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dalam file konfigurasi di atas untuk memahami bagaimana zero-downtime tercapai:

  • maxSurge: 1 & maxUnavailable: 0: Kombinasi ini memastikan bahwa saat proses rollout terjadi, Kubernetes akan membuat 1 pod tambahan terlebih dahulu (maxSurge: 1), menunggu pod tersebut siap (ready), dan tidak mengizinkan pod lama dimatikan (maxUnavailable: 0) sampai pod baru benar-benar melayani traffic. Hal ini mencegah terjadinya penurunan kapasitas (capacity drop).
  • preStop Hook (sleep 10): Ketika sebuah pod dijadwalkan untuk dihentikan (terminasi), Kubernetes secara paralel menghapus endpoint pod tersebut dari Service Load Balancer dan mengirimkan sinyal SIGTERM. Sering kali, pembaruan aturan iptables/kube-proxy memakan waktu beberapa milidetik, menyebabkan request yang masuk terbuang. Perintah sleep 10 memberi waktu bagi network layer untuk memperbarui perutean sebelum proses aplikasi benar-benar mati.
  • readinessProbe & livenessProbe: readinessProbe menentukan apakah pod siap menerima traffic (jika gagal, pod dikeluarkan dari endpoint service tanpa dimatikan), sedangkan livenessProbe menentukan apakah pod perlu direstart total jika aplikasi mengalami deadlock.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!IMPORTANT] Pada lingkungan produksi dengan skala high concurrency (menerima 10,000+ request per detik), pastikan konfigurasi autoscaling (HPA - Horizontal Pod Autoscaler) diselaraskan dengan batas resource request/limit agar pod baru tidak mengalami CPU throttling saat fase startup.

Studi Kasus: Penanganan Traffic Flash Sale E-Commerce

Sebuah platform e-commerce menggunakan arsitektur Node.js/Go di belakang Nginx Ingress Controller. Saat lonjakan traffic terjadi:

  1. Pipeline CI/CD hanya bertugas memperbarui tag image Docker di file deployment.yaml pada repositori Git.
  2. ArgoCD mendeteksi perubahan commit, lalu memulai sinkronisasi otomatis.
  3. Berkat konfigurasi Rolling Update dengan maxUnavailable: 0, pengguna yang sedang melakukan checkout tidak merasakan gangguan sama sekali karena pod versi lama tetap aktif melayani request hingga pod versi baru siap sepenuhnya.

8. Common Pitfalls, Anti-Patterns & Solusi

  1. Anti-Pattern: Menyimpan Plaintext Secret di Git
    • Masalah: Menyimpan file .env atau password database langsung di repositori Git publik maupun privat.
    • Solusi: Gunakan enkripsi berbasis SOPS (Secrets OPerationS) atau integrasikan ArgoCD dengan External Secrets Operator yang mengambil data langsung dari HashiCorp Vault atau AWS Secrets Manager.
  2. Pitfall: Lupa Menetapkan Resource Requests & Limits
    • Masalah: Pod baru memakan seluruh kapasitas node saat rollout, menyebabkan kernel OOM (Out Of Memory) Killer mematikan pod lain secara acak.
    • Solusi: Selalu tetapkan batas resource yang realistis berdasarkan hasil load testing.
  3. Pitfall: Menggunakan imageTag: latest
    • Masalah: ArgoCD tidak dapat mendeteksi perubahan kode karena tag latest tidak berubah meskipun isi image di container registry telah diperbarui.
    • Solusi: Gunakan semantic versioning atau commit SHA hash unik untuk setiap tag image build.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan pipeline zero-downtime Anda benar-benar tahan terhadap gangguan, lakukan pengujian beban menggunakan k6 atau wrk secara simultan saat proses deployment sedang berjalan.

Skrip pengujian k6 (load-test.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 }, // Ramp up ke 100 VU
    { duration: '5m', target: 100 }, // Pertahankan beban
    { duration: '2m', target: 0 },   // Ramp down
  ],
};

export default function () {
  const res = http.get('https://app.enterprise.com/healthz');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Jalankan perintah berikut di terminal saat ArgoCD sedang melakukan sinkronisasi pembaruan aplikasi:

k6 run load-test.js

Target Keberhasilan: Pastikan tingkat kegagalan (error rate) tetap berada di angka 0.00% selama proses rollout berlangsung.


10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis arsitektur GitOps ini ke lingkungan production yang sebenarnya, pastikan Anda telah memverifikasi checklist berikut:

  • Repositori Git terisolasi dan dilindungi dengan aturan Branch Protection (wajib Pull Request dan Code Review).
  • ArgoCD dikonfigurasi dengan autentikasi berbasis RBAC (Role-Based Access Control) yang ketat.
  • Fitur Self-Heal dan Prune aktif untuk mencegah penyimpangan konfigurasi manual.
  • Readiness dan Liveness Probe terpasang pada seluruh pod aplikasi web.
  • Strategi Rolling Update dikonfigurasi dengan maxUnavailable: 0.
  • Sistem monitoring (Prometheus & Grafana) terintegrasi untuk melacak metrik latensi dan error rate secara real-time.

Dengan menerapkan arsitektur GitOps menggunakan Kubernetes dan ArgoCD secara disiplin, organisasi Anda tidak hanya mencapai otomatisasi penuh, tetapi juga membangun infrastruktur web yang tangguh, transparan, dan benar-benar bebas downtime.

🏷️ Tags: #Devops #Kubernetes #Ci/Cd #Gitops #Argocd