# Progressive Delivery dengan Argo Rollouts: Canary & Blue-Green

> Cara saya rilis ke Kubernetes dengan Argo Rollouts — strategi canary dan blue-green, analisis berbasis Prometheus, dan rollback otomatis saat SLO terlanggar.

URL: https://www.matthewswong.com/id/blog/argo-rollouts-progressive-delivery-canary/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-07-11
- Updated: 2026-07-11
- Category: DevOps

> **Key takeaway:** Argo Rollouts mengganti objek Deployment Kubernetes dengan CRD Rollout yang merilis versi baru secara bertahap. Canary menggeser trafik dalam langkah berbobot; blue-green mengalihkan seluruh trafik sekaligus setelah preview. AnalysisTemplate menanyakan Prometheus di tengah rollout, dan saat SLO seperti error rate atau latensi melewati ambang, rollout dibatalkan dan dikembalikan otomatis.

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.

## 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.

> Langkah berbobot hanya merutekan trafik akurat jika ada yang benar-benar bisa membaginya. Dengan objek Service biasa, pembagian didekati lewat jumlah pod, jadi 20 persen butuh minimal lima pod agar bermakna. Untuk bobot presisi, hubungkan Rollouts ke ingress controller atau service mesh (NGINX, Istio, atau Kubernetes Gateway API) yang melakukan pembobotan sungguhan di level request.

## 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.

## 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).

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.

> Abort tidak mengembalikan state Git Anda. Dalam setup GitOps dengan Argo CD, tag image yang diinginkan di repo masih yang buruk, sehingga sync berikutnya bisa memicu ulang rollout gagal yang sama dalam loop. Setelah abort otomatis, perbaiki atau revert tag di Git sebelum ada yang re-sync — cluster sudah rollback, sumber kebenaran Anda belum.

## Canary versus blue-green: cara saya memilih

| Aspek | Canary | Blue-green |
| --- | --- | --- |
| Perpindahan trafik | Bertahap, langkah berbobot | Sekaligus setelah preview |
| Biaya pod ekstra | Rendah — hanya potongan canary | Tinggi — stack kedua penuh |
| Dampak build buruk | Terbatas pada bobot saat ini | Nol pra-alih, penuh pasca-alih |
| Butuh pembagian trafik | Ya untuk bobot presisi | Tidak — satu tukar service |
| Paling cocok | API HTTP stateless | Rilis tak backward compatible |

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.

## Sources

- Argo Rollouts — Analysis & Progressive Delivery (official docs)
- Argo Rollouts — project overview
- The Argo Project Graduates at the CNCF

## Source links

- https://argo-rollouts.readthedocs.io/en/stable/features/analysis/
- https://argoproj.github.io/rollouts/
- https://www.redhat.com/en/blog/the-argo-project-graduates-at-the-cncf

## FAQ

### Apa perbedaan antara Deployment Kubernetes dan Rollout Argo Rollouts?

Deployment hanya menawarkan rolling update yang dijaga readiness probe, yang memastikan proses hidup tetapi bukan bahwa ia melayani respons benar. Rollout adalah pengganti CRD drop-in yang spec-nya nyaris identik tetapi menambahkan blok strategy untuk canary atau blue-green plus analisis berbasis metrik. Itu membuat Anda bisa menggerbang promosi pada SLO nyata, bukan sekadar liveness.

### Bagaimana Argo Rollouts memutuskan untuk rollback otomatis?

Anda melampirkan AnalysisTemplate yang menanyakan provider seperti Prometheus pada interval tertentu dan mengevaluasi successCondition. Tiap sampel gagal dihitung terhadap failureLimit; begitu batas itu terlewati, AnalysisRun gagal, Rollouts menandai rollout Degraded, membatalkan progresi, dan mengecilkan bobot canary ke nol. Trafik kembali ke ReplicaSet stabil terakhir nyaris seketika tanpa langkah pipeline.

### Kapan saya harus memakai canary alih-alih blue-green dengan Argo Rollouts?

Pakai canary untuk service HTTP stateless yang bisa mentoleransi dua versi melayani sekaligus dan menginginkan dampak kecil dengan biaya pod rendah. Pakai blue-green saat versi bersamaan akan merusak sesuatu — misalnya perubahan skema yang tidak backward compatible — dan Anda sanggup menjalankan stack kedua penuh selama cutover. Keduanya memakai mekanisme AnalysisTemplate yang sama.

### Apakah saya butuh service mesh untuk canary deployment Argo Rollouts?

Tidak secara ketat. Dengan objek Service biasa, Rollouts mendekati bobot trafik lewat jumlah pod, jadi langkah 20 persen butuh minimal lima pod agar bermakna. Untuk pembobotan presisi di level request, Anda sebaiknya mengintegrasikan ingress controller atau service mesh seperti NGINX, Istio, atau Kubernetes Gateway API.

### Apakah rollback otomatis juga mengembalikan repositori Git saya dalam setup GitOps?

Tidak. Abort me-rollback cluster dengan menggeser trafik ke ReplicaSet stabil sebelumnya, tetapi tag image yang di-commit di Git masih yang buruk. Dengan Argo CD, sync berikutnya bisa memicu ulang rollout gagal yang sama dalam loop, jadi Anda harus memperbaiki atau me-revert tag di Git setelah abort otomatis.

---

- HTML version: https://www.matthewswong.com/id/blog/argo-rollouts-progressive-delivery-canary/
- English: https://www.matthewswong.com/en/blog/argo-rollouts-progressive-delivery-canary/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json