Belajar GitOps - FluxCD - Progressive Delivery dengan Flagger

#Pendahuluan

Di episode 14 kalian sudah belajar notifikasi: bagaimana setiap controller FluxCD menghasilkan event dan bagaimana Alert meneruskannya ke Slack, Discord, atau webhook. Sekarang kita masuk fase baru yang memanfaatkan observability tersebut: progressive delivery.

Di episode 15 ini kita akan berkenalan dengan Flagger, tool progressive delivery yang bagian dari ekosistem FluxCD. Kita pelajari konsepnya, arsitekturnya, cara instalasinya, dan alur kerjanya — sebelum nanti di episode 16 dan 17 kita membedah strategi canary, blue-green, dan A/B testing secara praktis.

#Apa Itu Progressive Delivery?

Progressive delivery adalah pendekatan mendeploy versi baru secara bertahap dengan mengukur dampaknya sebelum seluruh traffic dialihkan. Berbeda dengan rolling update yang hanya berfokus pada ketersediaan, progressive delivery berfokus pada verifikasi kualitas selama proses deploy berlangsung.

Flagger mendukung semua strategi di atas: canary, A/B testing, dan blue-green, dengan analisis metrics yang bisa dikonfigurasi.

#Mengenal Flagger

Flagger adalah tool open-source untuk progressive delivery yang dikembangkan oleh Weaveworks dan menjadi bagian dari ekosistem FluxCD. Flagger berjalan sebagai controller Kubernetes yang mengamati objek Deployment atau DaemonSet, lalu mengotomasi seluruh siklus analisis dan pergeseran traffic.

Beberapa hal penting tentang Flagger:

• Bekerja bersama FluxCD, bukan menggantikannya — FluxCD menyinkronkan manifest dari Git, Flagger mengelola strategi deployment
• Mengandalkan service mesh atau ingress controller untuk pergeseran traffic
• Menggunakan Prometheus sebagai sumber metrics utama
• Mendukung canary, A/B, dan blue-green dalam satu CRD Canary

#Arsitektur Flagger

Flagger terdiri dari satu controller dan beberapa CRD. Berikut komponen utamanya:

Canary CRD minimal:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
  analysis:
    interval: 1m
    iterations: 10
    stepWeight: 10
    maxWeight: 50
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m

MetricTemplate contoh untuk metrik kustom:

apiVersion: flagger.app/v1beta1
kind: MetricTemplate
metadata:
  name: not-found-percentage
  namespace: test
spec:
  provider:
    type: prometheus
    address: http://prometheus.observability:9090
  query: |
    sum(rate(http_request_duration_seconds_count{status="404"}[2m]))
    /
    sum(rate(http_request_duration_seconds_count[2m]))

AlertProvider contoh:

apiVersion: flagger.app/v1beta1
kind: AlertProvider
metadata:
  name: on-call
  namespace: flux-system
spec:
  type: slack
  channel: on-call
  secretRef:
    name: slack-url

#Instalasi Flagger

Flagger diinstall lewat Helm chart. Persyaratan dasar: cluster Kubernetes versi 1.16 atau lebih baru, kubectl, dan Prometheus yang berjalan di cluster.

helm repo add flagger https://flagger.app
helm upgrade -i flagger flagger/flagger \
  --namespace flux-system \
  --set crd.create=true \
  --set meshProvider=nginx \
  --set metricsServer=http://prometheus.observability:9090

Flagger biasanya diinstall di namespace flux-system, sedangkan resource aplikasi yang dikelolanya berada di namespace lain. Parameter meshProvider menentukan bagaimana Flagger menggeser traffic, dan metricsServer menunjuk ke Prometheus yang digunakan untuk analisis.

#Service Mesh dan Ingress yang Didukung

Flagger tidak menggeser traffic sendiri — dia mendelegasikan ke service mesh atau ingress controller yang terpasang:

#Cara Kerja Flagger

Saat sebuah Deployment baru diterapkan, Flagger menjalankan siklus berikut:

1. Deteksi perubahan — Deployment yang direferensikan Canary berubah spec-nya
2. Buat resource canary — Deployment canary dan service canary dibuat tanpa traffic
3. Automated canary analysis — Flagger menggeser traffic sedikit demi sedikit sesuai stepWeight dan iterations
4. Metrics analysis — Setiap tahap dicek terhadap metrik seperti request-success-rate dan request-duration
5. Promotion atau rollback — Jika semua metrik lolos, traffic dialihkan penuh; jika gagal, traffic kembali ke versi lama

Selama proses berlangsung, Flagger mengirim notifikasi melalui AlertProvider, misalnya saat canary dinaikkan, dipromosikan, atau di-rollback. Seluruh proses berjalan otomatis tanpa intervensi manusia.

kubectl get canaries.flagger.app -n test
kubectl describe canary podinfo -n test

#Penutup

Episode 15 ini memperkenalkan Flagger sebagai mesin progressive delivery dalam ekosistem FluxCD.

Inti yang harus dibawa pulang:

• Progressive delivery menggeser traffic bertahap sambil mengukur kualitas, bukan sekadar mengganti pod.
• Flagger bekerja bersama FluxCD: Flux menyinkronkan manifest, Flagger mengelola strategi deployment.
• Empat komponen arsitektur: controller, Canary CRD, MetricTemplate, dan AlertProvider.
• Traffic shifting didelegasikan ke service mesh, ingress controller, atau Gateway API yang terpasang.
• Keputusan promote atau rollback diambil otomatis berdasarkan analisis metrics.

Di episode 16 berikutnya kita akan membedah Canary Deployments secara mendalam: konfigurasi Canary CRD, strategi pergeseran traffic bertahap, analisis metrics, dan kondisi yang memicu rollback otomatis. Sampai jumpa!