Pipeline CI/CD Berkecepatan Tinggi dengan Kubernetes dan GitOps

Pukul 2 pagi. Ruangan server dingin, suara kipas rack server berdengung konstan, dan Slack berdering tanpa henti. Tim engineering kami sedang terjebak dalam dilema klasik: deployment monolith tradisional memakan waktu 45 menit, test suite sering flaky di tengah jalan, dan insiden production outage akibat kesalahan konfigurasi manual kian sering terjadi. Di satu sisi, kami mendambakan kecepatan rilis fitur web modern; di sisi lain, kami dibebani tanggung jawab menjaga ketersediaan infrastruktur backend berbasis Go, PHP-FPM, Nginx, serta sinkronisasi DNS Cloudflare agar tetap stabil melayani jutaan request. Dari sinilah pertarungan arsitektural dimulai: membandingkan pendekatan pipeline CI/CD imperatif berbasis GitHub Actions tradisional melawan pendekatan deklaratif berbasis Kubernetes dan GitOps murni menggunakan ArgoCD.

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

Pendekatan pertama menganut filosofi Imperative Push. Di sini, pipeline CI/CD bertindak sebagai eksekutor aktif yang memegang kunci akses langsung ke cluster Kubernetes melalui skrip SSH atau perintah kubectl apply. Ketika developer melakukan push kode ke branch main, pipeline langsung membangun image, melakukan unit test, lalu menembakkan perintah update ke server web Nginx atau deployment Kubernetes secara brutal. Rasanya cepat pada awalnya, namun ketika terjadi kesalahan, melacak siapa yang mengubah konfigurasi terakhir terasa seperti mencari jarum di tumpukan jerami.

Sebaliknya, pendekatan kedua—GitOps murni dengan ArgoCD—mengubah paradigma menjadi Declarative Pull. Cluster Kubernetes tidak lagi mempercayai pipeline eksternal. Sebuah controller internal di dalam cluster secara konstan memantau repositori Git terpisah yang menyimpan manifes Kubernetes, Helm chart, dan External Secrets. Jika ada perbedaan antara keadaan di Git (Desired State) dan keadaan di cluster (Actual State), ArgoCD secara otomatis melakukan rekonsiliasi. Transisi dari model push ke pull ini bukan sekadar tren, melainkan pertahanan utama kami terhadap human error saat mengelola database MySQL, redis cluster, hingga konfigurasi SSL Let's Encrypt di edge.

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

Menulis pipeline CI/CD seringkali menguji kesabaran. Mari kita intip bagaimana kita merancang strategi Rolling Update dan Canary Deployment agar aplikasi web berbasis Node.js atau Go dapat diperbarui tanpa membuat user merasakan satu detik pun downtime.

Dalam ekosistem Kubernetes, kita mendefinisikan strategi deployment langsung di dalam manifes YAML. Berikut adalah konfigurasi valid untuk Rolling Update yang memastikan ketersediaan layanan web server tetap terjaga:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-backend-app
  namespace: production
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Maksimal 1 pod tambahan di atas replicas selama update
      maxUnavailable: 0 # Menjamin tidak ada pod yang mati sebelum pod baru siap
  selector:
    matchLabels:
      app: web-backend
  template:
    metadata:
      labels:
        app: web-backend
    spec:
      containers:
      - name: app
        image: registry.internal/web-backend:v1.4.2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

[!IMPORTANT] Pastikan maxUnavailable: 0 dikombinasikan dengan readinessProbe yang akurat. Jika tidak, Kubernetes akan menganggap pod baru sudah siap padahal koneksi ke database MySQL atau Redis cache belum sepenuhnya mapan, berakibat pada HTTP 500 error masif di sisi Nginx/Ingress controller.

Namun, bagaimana dengan ukuran image Docker yang sering membengkak hingga gigabyte? Di sinilah optimasi ukuran image Docker multi-stage menjadi penyelamat utama kecepatan pipeline.

# Stage 1: Build binary aplikasi Go
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /bin/web-service

# Stage 2: Runtime image yang sangat ringkas
FROM alpine:3.19
RUN apk --no-cache add ca-certificates tzdata
WORKDIR /root/
COPY --from=builder /bin/web-service .
EXPOSE 8080
CMD ["./web-service"]

Dengan teknik multi-stage build di atas, ukuran image final yang di-push ke registry terpangkas dari 950MB menjadi hanya 18MB saja. Pipeline CI/CD tidak lagi menghabiskan waktu berjam-jam hanya untuk mengunduh image raksasa ke node Kubernetes.

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

Ketika beban puncak (traffic spike) menerpa infrastruktur web kita—misalnya saat kampanye flash sale—stabilitas manajemen secrets menjadi titik krusial. Menyimpan kredensial database, API key pihak ketiga, atau sertifikat SSL di dalam Plaintext Kubernetes Secret adalah tindakan bunuh diri secara arsitektural.

Kami menguji ketahanan sistem menggunakan External Secrets Operator (ESO) yang disinkronkan langsung denganAWS Secrets Manager atau Vault, memastikan rahasia tidak pernah mendarat di repositori Git.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-secret
  namespace: production
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
  - secretKey: MYSQL_PASSWORD
    remoteRef:
      key: production/mysql
      property: password

[!TIP] Atur refreshInterval secara bijak. Terlalu cepat akan membebani API rate limit dari penyedia secret manager eksternal Anda, sementara terlalu lambat akan memperlambat rotasi kredensial keamanan web backend.

Saat kami melakukan pengujian beban menggunakan k6 dengan 10.000 virtual users, kombinasi ArgoCD, External Secrets, dan rolling update tanpa henti ini berhasil mempertahankan latensi rata-rata di bawah 45 milidetik tanpa ada satupun request yang terputus di tengah jalan.

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

Di atas kertas, pendekatan imperatif tradisional tampak hemat karena tidak membutuhkan controller tambahan yang berjalan terus-menerus di dalam cluster. GitHub Actions Runner atau GitLab Runner hanya menyala saat ada tugas build.

Sebaliknya, ArgoCD membutuhkan pod controller dan application controller yang siaga 24/7 memantau state. Pada cluster kecil dengan 3 node, ArgoCD memakan sekitar 350MB hingga 500MB RAM dan konsumsi CPU konstan sekitar 0.1 core. Namun, ketika skala perusahaan berkembang hingga mengelola ratusan mikroservis, efisiensi operasional yang diberikan ArgoCD jauh melampaui biaya sumber daya server yang dikonsumsinya. Tim tidak lagi menghabiskan waktu berjam-jam melakukan debugging skrip bash deployment yang rusak.

5. Kapan Wajib Menggunakan GitHub Actions + Imperative Deployment

Pilih pendekatan imperatif tradisional berbasis GitHub Actions/GitLab CI dengan kubectl apply atau SSH jika:

• Skala infrastruktur Anda masih berupa monolith sederhana atau sedikit mikroservis (kurang dari 5 layanan).
• Tim Anda terdiri dari sedikit engineer yang belum memiliki pengalaman mendalam mengenai Kubernetes Controller dan konsep GitOps.
• Proyek bersifat jangka pendek, proof of concept (PoC), atau aplikasi internal perusahaan yang tidak menuntut ketersediaan tinggi 24/7.

6. Kapan Wajib Menggunakan ArgoCD & Kubernetes GitOps

Wajib beralih ke ArgoCD dan ekosistem GitOps Kubernetes jika:

• Anda mengelola arsitektur web skala besar dengan puluhan hingga ratusan mikroservis yang didistribusikan ke berbagai cluster multi-region.
• Kepatuhan audit (audit compliance) dan keamanan adalah prioritas mutlak, di mana setiap perubahan state infrastruktur wajib tercatat rapi di dalam riwayat commit Git.
• Anda ingin menghilangkan sepenuhnya ketergantungan pada akses langsung cluster admin menggunakan token rahasia yang rawan bocor di pipeline CI/CD.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Pertarungan antara pipeline CI/CD tradisional dan GitOps berbasis ArgoCD bukan sekadar soal mana teknologi yang lebih baru, melainkan tentang kesiapan budaya kerja tim Anda. Jika Anda masih berjuang menstabilkan database MySQL, mengatur konfigurasi Nginx reverse proxy yang benar, dan mengamankan rekaman DNS, selesaikan fondasi dasar tersebut terlebih dahulu.

Namun, begitu Anda memasuki fase di mana kecepatan rilis fitur berbenturan langsung dengan stabilitas sistem produksi, memeluk GitOps dengan ArgoCD, optimasi Docker multi-stage, dan External Secrets Operator adalah tiket emas menuju ketenangan pikiran seorang Principal Engineer. Tulis kode dengan rapi, biarkan Git menjadi sumber kebenaran tunggal, dan biarkan sistem bekerja secara otomatis untuk Anda.