Belajar Multigress - Canary Deployments & Progressive Delivery

#Pendahuluan

Merilis versi baru tanpa mengganggu pengguna adalah salah satu tantangan terbesar dalam operasi. Episode 9 membahas canary deployments dan progressive delivery dengan Multigress: menggeser traffic perlahan memakai weights, memantau kesehatan rilis secara real-time, dan mengotomatisasi prosesnya dengan Argo Rollouts atau Flagger.

Canary adalah jembatan antara "langsung rilis" dan "rollback manual". Traffic dialirkan sedikit demi sedikit, dan keputusan lanjut atau mundur diambil berdasarkan data, bukan keberuntungan.

#Traffic Shifting dan Canary Release dengan HTTPRoute Weights

#Struktur Canary Dasar

Canary paling sederhana: dua Service menuju dua Deployment yang menunjuk ke image berbeda, lalu weights di HTTPRoute menentukan proporsinya:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
    - name: main-gateway
      namespace: multigress-system
  hostnames:
    - "api.example.com"
  rules:
    - backendRefs:
        - name: api-stable
          port: 8080
          weight: 95
        - name: api-canary
          port: 8080
          weight: 5

Lima persen traffic sudah menuju versi baru. Saat kalian yakin, ubah weight menjadi 50:50, lalu 0:100.

#Mengubah Weight secara Progresif

Alihkan traffic bertahap lewat patch:

kubectl patch httproute api-route --type=json \
  -p='[{"op":"replace","path":"/spec/rules/0/backendRefs/1/weight","value":25}]'

Perintah kubectl patch httproute api-route --type=json mengubah weight canary menjadi 25 tanpa menulis ulang seluruh file. Proses ini bisa diulang sesuai jadwal: 5, 25, 50, 100.

#Canary Berbasis Header

Untuk menguji ke tim internal saja, kombinasikan dengan rule header seperti episode 8. Weight lalu dipakai sebagai lapisan kedua untuk release ke publik.

#Observability Feedback Loops untuk Deployment Safety

#Metrik Penentu Lanjut atau Mundur

Canary yang aman membutuhkan pengamatan. Metrik yang harus dipantau selama canary berjalan:

• Error rate (5xx) per route.
• Latency p95 dan p99.
• Rate request yang mencapai backend canary.

Query Prometheus untuk membandingkan dua backend:

sum(rate(multigress_http_requests_total{backend="api-canary"}[5m])) by (code)
sum(rate(multigress_http_requests_total{backend="api-stable"}[5m])) by (code)

Bandingkan distribusi status code kedua backend. Jika api-canary memproduksi 5xx jauh lebih banyak dari api-stable, hentikan canary segera.

#Ambang Aman dalam Praktik

Tetapkan ambang sebelum rilis, misalnya:

• Error rate canary tidak boleh melebihi stable plus satu persen.
• Latensi p95 canary tidak boleh lebih dari 1.2 kali stable.

Tanpa ambang, observability hanya menjadi layar cantik tanpa keputusan. Feedback loop baru berguna ketika ada aturan eksplisit untuk bertindak.

#Integrasi dengan Argo Rollouts atau Flagger

#Argo Rollouts dengan Multigress

Argo Rollouts bisa mengotomatisasi penambahan weight dan analisis. Analisis dilakukan lewat AnalysisTemplate:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: canary-error-rate
spec:
  metrics:
    - name: error-rate
      interval: 30s
      successCondition: result < 1
      provider:
        prometheus:
          address: http://kube-prometheus-stack-prometheus.monitoring:9090
          query: |
            sum(rate(multigress_http_requests_total{backend="api-canary",code=~"5.."}[2m]))
            / sum(rate(multigress_http_requests_total{backend="api-canary"}[2m]))

Template di atas memicu pengukuran setiap 30 detik. Jika error rate canary di atas satu persen, analisis gagal dan Rollout otomatis kembali ke stable.

#Rollout yang Memakai Weight Multigress

Rollout kemudian memakai weights HTTPRoute Multigress sebagai langkah canary:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  strategy:
    canary:
      canaryService: api-canary
      stableService: api-stable
      trafficRouting:
        multigress:
          httpRoute: api-route
      steps:
        - setWeight: 10
        - pause: { duration: 10m }
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100

Alur di atas menahan traffic di 10 persen selama 10 menit, lalu 50 persen, lalu penuh. Perintah kubectl argo rollouts get rollout api menampilkan status analisis dan langkah canary secara real-time.

#Flagger sebagai Alternatif

Flagger bekerja dengan prinsip serupa tetapi memakai Kubernetes Deployment biasa dan menangani analisis sendiri. Pilihannya tergantung ekosistem tim: Argo Rollouts menyatu dengan Argo CD, sedangkan Flagger lebih ringan dan terintegrasi dengan Prometheus serta Grafana.

#Penutup

Episode 9 menutup lingkaran progressive delivery: kalian tahu cara menggeser traffic dengan weights, menentukan ambang keberhasilan dari observability, dan mengotomatisasi seluruh proses dengan Argo Rollouts atau Flagger.

Inti yang harus dibawa pulang:

• Weight pada HTTPRoute menggeser traffic secara bertahap dan reversibel.
• Ubah weight progresif dengan kubectl patch, bukan edit file utuh.
• Feedback loop butuh ambang eksplisit: error rate dan latensi maksimal.
• Argo Rollouts dan Flagger mengotomatisasi analisis dan penggeseran weight.
• Rollback canary semudah mengembalikan weight ke 100 persen stable.

Di episode 10 selanjutnya kita akan membahas multi-tenant routing & namespace isolation — routing berbasis domain lintas namespace, gateway scoping, pola isolasi namespace, dan pengelolaan shared gateway untuk banyak tim. Canary yang sudah kalian bangun akan hidup dalam struktur multi-tenant yang baru.