Belajar GitOps dengan ArgoCD - Progressive Delivery dengan Argo Rollouts

#Pendahuluan

Di episode 18 sebelumnya kita membangun pipeline CI/CD yang utuh: CI menghasilkan image, manifest di Git diperbarui, dan ArgoCD menerapkannya. Namun ada satu pertanyaan yang belum kita jawab: bagaimana melepas versi baru tanpa memutus layanan? Rolling update bawaan Kubernetes memang tanpa downtime, tetapi ia buta — ia tidak tahu apakah versi barunya memperlambat respons atau memicu error 500. Di episode ini kita masuk ke progressive delivery dengan Argo Rollouts, jawaban Argo untuk deployment yang cerdas dan terkendali.

Konsepnya sederhana namun berdampak besar: alih-alih menukar semua pod sekaligus, kita menggelar sebagian kecil lalu mengamati metriknya; jika sehat, sisanya diikuti; jika rusak, kita mundur otomatis. Argo Rollouts adalah komponen resmi ekosistem Argo, dan menjadi pelengkap natural GitOps: rollback bukan lagi tebakan, melainkan keputusan berbasis bukti.

#Konsep Progressive Delivery

Progressive delivery adalah payung yang menaungi beberapa strategi pelepasan:

Argo Rollouts mengelola dua strategi utama — canary dan blue-green — secara langsung. A/B testing dilakukan dengan menggabungkan canary Rollouts dan traffic splitting berbasis header di service mesh (episode 20). Feature flags sendiri bukan pekerjaan Rollouts; ia pelengkap yang bisa dipicu oleh metrik yang sama.

#Argo Rollouts: CRD dan Controller

Argo Rollouts memperkenalkan resource kustom bernama Rollout, pengganti Deployment pada workload yang menginginkan progressive delivery. Perbedaannya: Rollout memahami langkah promosi, pengaturan traffic, dan analisis metrik. Instalasi cukup sederhana:

Instal Argo Rollouts

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

Controller yang berjalan membaca setiap Rollout dan mengelola Deployment, ReplicaSet, Service, serta Ingress atau konfigurasi service mesh di baliknya. Untuk pengalaman mirip kubectl, pasang plugin CLI kubectl argo rollouts yang menyediakan get, status, promote, dan abort.

#Strategi Canary

Canary adalah strategi paling populer karena hemat resource dan berbasis trafik nyata. Trafik pengguna dibagi: sebagian kecil ke versi baru, sisanya ke versi stabil.

#Konfigurasi Strategi Canary

rollout.yaml - canary bertahap

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-rollout
spec:
  replicas: 10
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/org/api:v2
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100

Urutan steps di atas bercerita: naikkan trafik versi baru ke 10 persen, tahan 5 menit (kesempatan memantau error), lalu 50 persen, tahan 10 menit, baru 100 persen. Setiap pause memberi manusia atau sistem waktu mengevaluasi. Tanpa analisis metrik, promosi tetap berjalan sesuai jadwal — itulah mengapa analysis di bawah menjadi penting.

#Traffic Splitting

Rollouts tidak membagi trafik sendiri; ia meminta alat di depannya melakukannya. Dua mode yang didukung:

• Mode Service — Rollouts membuat dua Service (api-stable dan api-canary) dan mengatur weight-nya. Cocok untuk NGINX Ingress yang memakai weight pada beberapa backend.
• Mode service mesh / gateway — Rollouts memodifikasi VirtualService (Istio), Service (Linkerd), atau HTTPRoute (Gateway API) agar split dilakukan di lapisan mesh.

Untuk mode Service sederhana, definisikan dua Service di manifest yang sama dan biarkan Rollout menambah weight:

service.yaml - stable dan canary

apiVersion: v1
kind: Service
metadata:
  name: api-stable
spec:
  selector:
    app: api
    # rollout menggunakan label rollouts-pod-template-hash
  ports:
    - port: 80
      targetPort: 8080

#Auto Promote dan Rollback Berbasis Metrik

Bagian paling berharga dari Rollouts adalah analysis: promosi berhenti dan menilai metrik sebelum melangkah ke step berikutnya. Ini diwujudkan lewat dua resource: AnalysisTemplate (definisi yang bisa dipakai ulang) dan rujukannya di spec.strategy.canary.analysis:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 60s
      count: 5
      successCondition: result[0] >= 0.95
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{app="api",status!~"5.."}[2m])) /
            sum(rate(http_requests_total{app="api"}[2m]))

successCondition: result[0] >= 0.95 berarti rollout hanya melanjutkan jika rasio sukses minimal 95 persen. Jika gagal melebihi failureLimit: 3, Rollout otomatis abort — trafik kembali 100 persen ke versi stabil. Ini adalah safety net otomatis yang tidak dimiliki Deployment biasa.

#Strategi Blue-Green

Blue-green dipilih saat rollback instan lebih penting daripada hemat resource. Dua ReplicaSet penuh berjalan berdampingan; trafik dialihkan lewat Service.

#Konfigurasi Blue-Green

rollout.yaml - blue-green

  strategy:
    blueGreen:
      activeService: api-active
      previewService: api-preview
      autoPromotionEnabled: false

• activeService: api-active — Service yang melayani trafik pengguna, selalu menunjuk versi yang sedang aktif.
• previewService: api-preview — Service untuk memverifikasi versi baru sebelum dialihkan (bisa diakses lewat Ingress sementara).
• autoPromotionEnabled: false — promosi butuh persetujuan manusia, baik lewat UI maupun CLI.

#Promosi Manual dan Rollback Instan

Dengan autoPromotionEnabled: false, tim menjalankan promosi secara eksplisit:

kubectl argo rollouts promote api-rollout
kubectl argo rollouts status api-rollout
kubectl argo rollouts abort api-rollout

Saat masalah muncul setelah promosi, abort memindahkan activeService kembali ke versi sebelumnya seketika — rollback "instan" yang menjadi alasan utama orang memilih blue-green.

#Traffic Management

Pilihan mekanisme traffic menentukan di mana Rollouts beroperasi:

Untuk NGINX Ingress, cukup definisikan backend dengan dua Service (api-stable dan api-canary) dan Rollout akan mengatur weight-nya saat canary berjalan. Untuk Istio, Rollout langsung menulis weight pada VirtualService — contohnya akan kita bedah di episode 20.

#Integrasi dengan ArgoCD

Karena Rollout, AnalysisTemplate, dan Service semuanya adalah manifest Kubernetes biasa, ArgoCD memperlakukannya seperti resource lain: disimpan di Git, disinkronkan, dan direkonsiliasi. Satu-satunya perhatian khusus: aplikasi yang memakai Rollouts harus SyncOptions menghormati resource custom. Jika kalian memakai Helm, tambahkan CRD ke chart; jika plain YAML, pastikan urutan apply tidak menghapus Rollout milik controller (jangan atur --force sembarangan).

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api
spec:
  source:
    repoURL: https://github.com/org/manifests.git
    path: apps/api
  destination:
    server: https://kubernetes.default.svc
    namespace: api

Ketika tim menaikkan versi image di Git, ArgoCD menyinkronkan Rollout baru, lalu Rollout controller yang mengambil alih: canary, analisis metrik, dan rollback berjalan di luar campur tangan ArgoCD.

#Penutup

Episode ini memperkenalkan progressive delivery sebagai pelengkap GitOps: konsep canary, blue-green, A/B testing, dan feature flags; instalasi Argo Rollouts dan resource Rollout; strategi canary dengan steps, pause, dan traffic splitting; analisis metrik lewat AnalysisTemplate dengan Prometheus; strategi blue-green dengan active dan preview service; serta ringkasan opsi traffic management dan cara ArgoCD mengelola semua resource tersebut dari Git.

Poin yang harus kalian bawa:

• Progressive delivery melepas versi baru bertahap dengan verifikasi di setiap langkah.
• Rollout menggantikan Deployment dan dipantau dengan kubectl argo rollouts.
• AnalysisTemplate memungkinkan auto promote dan auto rollback berbasis metrik.
• Blue-green memberi rollback instan dengan biaya resource dobel.
• ArgoCD mengelola resource Rollouts, Rollout controller yang menjalankan progresinya.

Mekanisme traffic splitting sudah menyebut service mesh beberapa kali. Di episode 20 selanjutnya kita membedah integrasi service mesh — Istio, Linkerd, VirtualService dan DestinationRule, mTLS, serta observabilitas terdistribusi — dengan arsitektur GitOps. Sampai jumpa di episode 20!