Progressive Delivery dengan Argo Rollouts: Canary & Blue-Green

Deployment Kubernetes biasa hanya memberi satu tuas keamanan: rolling update. Ia menukar pod beberapa sekaligus dan mengawasi readiness probe — tetapi readiness probe hanya memberi tahu bahwa proses hidup, bukan bahwa ia melayani respons yang benar dengan latensi wajar. Saya pernah merilis build yang lolos semua probe tetapi tetap menggandakan p95 pada jalur checkout. Pod-nya sehat; penggunanya tidak.

Progressive delivery menutup celah itu. Alih-alih memercayai sebuah probe, Anda mengekspos versi baru ke sepotong trafik nyata, mengukur apa yang benar-benar dilakukannya lewat metrik nyata, dan hanya memperluas dampak jika angkanya bertahan. Argo Rollouts adalah tool CNCF yang saya andalkan untuk ini di Kubernetes. Proyek Argo lulus (graduated) di CNCF pada Desember 2022, dan Rollouts kini di lini 1.8 — cukup matang untuk dijalankan di produksi tanpa kejutan.

Objek Rollout menggantikan Deployment Anda

Anda tidak menambahkan Argo Rollouts di samping Deployment — Anda mengonversi Deployment menjadi Rollout. Spec-nya hampir identik: template pod sama, selector sama, jumlah replika sama. Bedanya ada di blok strategy, tempat Anda mendeklarasikan canary atau blueGreen alih-alih rolling update bawaan. Semua hal lain yang sudah dipahami tim tentang spec pod tetap sama, dan itulah yang membuat migrasi murah.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-api
spec:
  replicas: 6
  selector:
    matchLabels:
      app: checkout-api
  template:
    metadata:
      labels:
        app: checkout-api
    spec:
      containers:
        - name: checkout-api
          image: registry.example.com/checkout-api:1.4.2
          ports:
            - containerPort: 8080
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 2m }
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 80
        - pause: { duration: 5m }

Canary: geser trafik dalam langkah berbobot

Canary adalah pilihan default saya untuk service HTTP stateless. Array steps dibaca dari atas ke bawah: kirim 20 persen trafik ke versi baru, tahan dua menit, lalu 50, lalu 80, lalu Rollouts mempromosikan canary ke 100 secara otomatis begitu langkah terakhir lolos. Pause tanpa duration berhenti tanpa batas sampai Anda promosikan manual — berguna untuk rilis produksi pertama saat Anda ingin manusia menatap dashboard sebelum memperluas.

Blue-green: alihkan semua trafik setelah preview

Blue-green cocok untuk rilis yang tidak boleh punya dua versi melayani sekaligus — perubahan skema yang tidak backward compatible, atau service yang respons campurannya bisa merusak alur kerja. Rollouts menyalakan seluruh stack green secara paralel, mengeksposnya di Service preview terpisah agar bisa Anda smoke-test, dan baru mengalihkan Service aktif saat Anda (atau sebuah analisis) menyetujui. Komprominya adalah biaya: Anda menjalankan pod dua kali lipat selama cutover, jadi lebih berat dari canary.

  strategy:
    blueGreen:
      activeService: checkout-api-active
      previewService: checkout-api-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
          - templateName: success-rate
      scaleDownDelaySeconds: 30

AnalysisTemplate: biarkan Prometheus yang memutuskan

Inti dari progressive delivery adalah menyingkirkan manusia dari jalur normal. AnalysisTemplate adalah objek yang dapat dipakai ulang, menanyakan provider metrik pada interval tertentu dan mengevaluasi sebuah kondisi. Rujuk ia dari langkah canary atau prePromotionAnalysis blue-green, dan Rollouts menjalankannya sebagai AnalysisRun yang terikat ke rollout tersebut. Field kuncinya adalah interval (seberapa sering sampel), count (berapa sampel), successCondition (ekspresi yang harus terpenuhi), dan failureLimit (berapa sampel gagal yang ditoleransi sebelum seluruh analisis dinyatakan gagal).

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: service-name
  metrics:
    - name: success-rate
      interval: 30s
      count: 6
      successCondition: result[0] >= 0.99
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring.svc:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}", code!~"5.."
            }[2m]))
            /
            sum(rate(http_requests_total{
              service="{{args.service-name}}"
            }[2m]))

Template itu menyampel rasio sukses non-5xx setiap 30 detik, enam kali. successCondition mensyaratkan minimal 99 persen sukses; failureLimit 2 berarti beberapa lonjakan noise dimaafkan, tetapi sampel gagal ketiga membuat analisis gagal. Saya biasanya menjalankannya sebagai background analysis agar dievaluasi terus-menerus di setiap langkah canary, bukan hanya di satu pause — regresi yang muncul di bobot 80 persen tetap harus tertangkap.

Rollback otomatis saat SLO terlanggar

Inilah hasilnya. Saat AnalysisRun melewati failureLimit-nya, Rollouts menandai rollout sebagai Degraded, membatalkan progresi, dan mengecilkan bobot canary ke nol — trafik langsung kembali ke versi stabil terakhir tanpa langkah pipeline dan tanpa pager. Karena Rollout melacak ReplicaSet stabil sebelumnya, revert-nya nyaris instan; Anda tidak membangun ulang image atau menjalankan ulang deploy, hanya menggeser bobot kembali ke pod yang sudah berjalan.

• Pantau rollout secara langsung dengan plugin kubectl — ia menampilkan tiap langkah, bobot saat ini, dan putusan AnalysisRun dalam satu tampilan.
• Pilih SLO yang mencerminkan derita pengguna, bukan noise infrastruktur: rasio sukses, latensi p95/p99, dan kode error bisnis lebih baik daripada CPU mentah.
• Beri tiap metrik interval yang cukup panjang untuk meredam jitter scrape; scrape Prometheus 30 detik butuh rate window minimal 1–2 menit.
• Jaga AnalysisTemplate tetap terparameter dengan args agar satu template melayani setiap service ketimbang menyalin-tempel query.

Canary versus blue-green: cara saya memilih

Dalam praktik saya menjalankan canary untuk mayoritas besar service dan menyimpan blue-green untuk segelintir yang dua versi bersamaannya benar-benar merusak sesuatu. Kedua strategi memakai mekanisme AnalysisTemplate yang sama persis, jadi investasi pada query Prometheus yang baik terbayar apa pun pilihan sebuah service. Mulai dengan satu service non-kritis, pasang satu analisis success-rate, dan buktikan abort otomatis bekerja dengan sengaja merilis sesuatu yang buruk di staging.