Belajar GitOps - FluxCD - Canary Deployments

#Pendahuluan

Di episode 15 kalian sudah berkenalan dengan Flagger: arsitekturnya, cara instalasinya, dan alur kerjanya secara umum. Sekarang saatnya membedah strategi paling populer — canary deployment — secara mendalam.

Di episode 16 ini kita akan membahas bagaimana Flagger menggeser traffic sedikit demi sedikit, bagaimana Canary CRD dikonfigurasi, bagaimana routing bekerja di berbagai provider, bagaimana metrics dianalisis, dan kondisi apa saja yang memicu rollback otomatis.

#Strategi Canary

Canary deployment mengirimkan sebagian kecil traffic ke versi baru sementara mayoritas tetap ke versi lama. Jika metrik pada traffic kecil itu sehat, porsi traffic dinaikkan secara bertahap sampai versi baru menerima seluruh traffic.

Keunggulan strategi ini:

• Incremental traffic shifting — perubahan berdampak minimal
• Step-by-step progression — setiap tahap diverifikasi sebelum lanjut
• Metrics validation — keputusan berdasarkan data, bukan asumsi
• Automatic rollback — kegagalan di tahap mana pun langsung dikembalikan

#Konfigurasi Canary CRD

Semua strategi dikendalikan dari satu objek: Canary. Berikut contoh konfigurasi lengkap untuk canary deployment:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
    portName: http
  analysis:
    interval: 1m
    iterations: 5
    threshold: 99
    stepWeight: 10
    maxWeight: 50
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m
      - name: request-duration
        threshold: 500
        interval: 30s
    webhooks:
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 20 http://podinfo-canary.test:9898/"

#Penjelasan Field Utama

#Traffic Routing

Flagger tidak menggeser traffic sendiri — dia mengonfigurasi resource routing provider. Tiga pendekatan yang umum:

Contoh VirtualService untuk Istio yang dikelola Flagger:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: podinfo
  namespace: test
spec:
  hosts:
    - podinfo.test
  http:
    - route:
        - destination:
            host: podinfo
          weight: 100
        - destination:
            host: podinfo-canary
          weight: 0

Saat analisis berjalan, Flagger memperbarui weight secara bertahap, misalnya dari 100 berbanding 0 menjadi 90 berbanding 10, lalu 80 berbanding 20, dan seterusnya.

Untuk NGINX, Flagger membuat Service canary dan mengelola annotation pada ingress seperti nginx.ingress.kubernetes.io/canary dan nginx.ingress.kubernetes.io/canary-weight secara dinamis.

#Metrics Analysis

Analisis metrik adalah jantung canary deployment. Flagger secara default memakai dua metrik bawaan: request-success-rate dan request-duration, yang diambil dari Prometheus.

#Prometheus Metrics

Flagger membaca metrik HTTP dari Prometheus dengan query yang menargetkan traffic canary dan primary. Untuk Pod yang tidak menghasilkan metrik HTTP, tambahkan Prometheus exporter di aplikasi.

#Request Success Rate

Metrik ini mengukur persentase request yang berhasil. Ambang default 99 berarti 99 persen request harus sukses selama analisis:

metrics:
  - name: request-success-rate
    threshold: 99
    interval: 1m

#Request Duration

Metrik ini mengukur latensi. Nilai threshold dalam milidetik:

metrics:
  - name: request-duration
    threshold: 500
    interval: 30s

#Custom Metrics dan MetricTemplate

Untuk metrik bisnis atau teknis yang lebih spesifik, gunakan MetricTemplate dan referensikan di dalam metrics:

analysis:
  metrics:
    - name: not-found-percentage
      templateRef:
        name: not-found-percentage
        namespace: test
      thresholdRange:
        max: 5
      interval: 1m

#Progressive Traffic Shifting

Kombinasi stepWeight, maxWeight, iterations, dan interval menentukan kurva pergeseran traffic. Dengan stepWeight: 10 dan maxWeight: 50, urutan traffic yang diuji adalah: 10 persen, 20 persen, sampai 50 persen. Jika maxWeight sudah tercapai dan semua metrik sehat, Flagger langsung mempromosikan versi baru ke 100 persen.

#Rollback Conditions

Rollback terjadi otomatis ketika salah satu kondisi berikut terpenuhi:

• Metric threshold breaches — success rate atau duration melewati ambang
• Failed checks threshold — jumlah iterasi gagal melewati threshold persen
• Webhook failure — load tester atau hook lain mengembalikan error
• Manual rollback — kubectl digunakan untuk menghentikan analisis

Saat rollback dipicu, Flagger mengembalikan seluruh traffic ke versi primary dan menandai canary gagal:

kubectl get canary podinfo -n test
kubectl describe canary podinfo -n test

Perintah di bawah ini bisa dipakai untuk rollback manual atau memulai ulang analisis:

kubectl -n test patch canary podinfo \
  --type merge \
  -p '{"status":{"phase":"Failed"}}'

#Penutup

Episode 16 ini membedah canary deployment sebagai strategi deploy bertahap yang berorientasi data.

Inti yang harus dibawa pulang:

• Canary CRD mengendalikan seluruh strategi: target, service, analysis, metrics, dan webhooks.
• Pergeseran traffic diatur lewat stepWeight, maxWeight, iterations, dan interval.
• Routing didelegasikan ke provider: Istio VirtualService, Linkerd TrafficSplit, NGINX annotations, atau Gateway API HTTPRoute.
• Metrik Prometheus seperti success rate dan duration menjadi dasar keputusan promote atau rollback.
• Rollback otomatis terjadi saat ambang metrik dilanggar, webhook gagal, atau diminta manual.

Di episode 17 berikutnya kita akan membahas Blue/Green dan A/B Testing — dua strategi progresif lainnya: blue-green dengan traffic mirroring dan switch instan, serta A/B testing berbasis header dan cookie untuk eksperimen pengguna. Sampai jumpa!