Belajar Helm Chart - Upgrade, Rollback & Riwayat Release

#Pendahuluan

Setelah di episode 4 sebelumnya kita membahas instalasi chart (helm install), dry-run untuk inspeksi hasil render, melihat status release dengan helm list dan helm status, hingga helm uninstall — pada episode kali ini kita masuk ke momen yang paling sering memicu insiden di production: upgrade dan rollback release.

Mengapa topik ini penting? Instalasi biasanya terjadi sekali jalan saat pertama kali aplikasi dideploy. Tetapi aplikasi itu hidup: kalian akan merilis versi baru, mengganti image tag, menaikkan jumlah replica, atau mengubah konfigurasi terus-menerus selama aplikasi eksis. Dan setiap upgrade adalah peluang untuk merusak aplikasi yang sedang berjalan — image gagal di-pull, readiness probe gagal, chart baru punya breaking change, atau nilai values yang keliru. Di sinilah perbedaan antara engineer pemula dan profesional terlihat: yang pemula mengetik helm upgrade frontend bitnami/nginx tanpa persiapan lalu panik saat production down; yang profesional memahami mekanisme revision, memilih flag yang membuat upgrade aman, dan menyiapkan rencana rollback sebelum tombol ditekan.

Di episode ini kita akan membedah anatomi perintah helm upgrade, opsi-opsi penting yang menentukan keamanan upgrade, cara mengelola values saat upgrade, mekanisme revision dan rollback, serta praktik terbaik yang berlaku di tim production.

#Pembahasan Utama

#Anatomi Perintah `helm upgrade`

Bentuk paling dasar perintah ini hampir identik dengan helm install, hanya kata kerjanya saja yang berbeda:

Upgrade release dengan chart yang sama

helm upgrade frontend bitnami/nginx --namespace web

Karena release frontend sudah ada di namespace web, Helm tidak membuat resource baru dari nol — ia menghitung perbedaan antara tiga kondisi: (1) manifest dari revision release sebelumnya, (2) manifest baru yang dirender dari chart dan values terkini, dan (3) kondisi aktual resource di cluster. Inilah yang disebut three-way strategic merge patch, dan inilah yang membedakan helm upgrade dari sekadar menimpa YAML dengan kubectl apply.

Apa konsekuensi praktis dari mekanisme ini? Bayangkan kalian sedang merenovasi rumah: Helm punya denah lama (manifest revision lama), denah baru (chart baru), dan kondisi ruangan terkini (live state). Ia hanya menyentuh yang berubah. Resource yang sudah tidak didefinisikan chart tidak otomatis dihapus, perubahan manual yang kalian lakukan lewat kubectl edit akan "di-reconcile" kembali mengikuti keinginan chart, dan field yang tidak disentuh sama sekali akan tetap apa adanya. Ini membuat upgrade idempoten dan deterministik — selama kondisi awal dan values sama, hasil akhirnya sama.

Saat mengubah values, kalian tinggal menambahkan opsi --values atau --set:

Upgrade dengan perubahan values

helm upgrade frontend bitnami/nginx \
  --namespace web \
  --version 19.0.1 \
  --set image.tag=1.27.0 \
  --set replicaCount=3

Perhatikan --version 19.0.1 — ini penting. Tanpa pin chart version, Helm memakai chart terbaru yang sudah di-cache dari repository. Di production, upgrade aplikasi (image tag) dan upgrade chart (struktur manifest) sebaiknya dipisahkan dan dikontrol, karena keduanya punya risiko yang berbeda. Menentukan --version membuat hasil upgrade bisa direproduksi — prinsip yang sama dengan mengunci versi dependency di package-lock.json.

Note

helm upgrade tidak pernah melakukan uninstall lalu install ulang dari nol. Ia selalu melakukan patch terhadap resource yang ada. Ini bagus untuk ketersediaan (rolling update tetap berjalan), tapi berarti kalian harus sadar bahwa "memperbaiki" kondisi yang sudah terlanjur rusak biasanya butuh --force atau --recreate-pods — bukan sekadar menjalankan upgrade biasa.

#Flag yang Sering Diabaikan: `--install`, `--force`, `--recreate-pods`

Tiga flag ini masing-masing menjawab satu kasus yang berbeda.

--install menjadikan helm upgrade berperilaku "upsert": jika release belum ada, Helm melakukan install; jika sudah ada, Helm melakukan upgrade. Ini sangat berguna di pipeline CI/CD, di mana kalian tidak ingin menulis cabang logika "release baru vs release lama":

Upsert dari pipeline CI/CD

helm upgrade --install frontend bitnami/nginx \
  --namespace web \
  --create-namespace \
  --values values.yaml \
  --wait

Karena perintah ini idempoten, menjalankannya seratus kali akan memberi hasil yang sama — pola yang wajib dimiliki setiap deployment otomatis. Catatan kecil: karena --install otomatis fallback ke install, pastikan nama release tidak typo, atau Helm akan membuat release baru di samping release lama yang masih jalan.

--force memaksa resource yang "tidak bisa diubah" untuk di-recreate. Beberapa field Kubernetes memang immutable: label selector pada Deployment, clusterIP pada Service, atau name pada container. Jika chart kalian mengubah label selector (misalnya karena perubahan fullname), Helm akan menolak upgrade dengan pesan field is immutable. --force mengganti resource tersebut dengan menghapus dan membuatnya ulang di tempat — membuat downtime sesaat. Ini bukan solusi harian, melainkan tool darurat untuk situasi di mana patch gagal karena constraint Kubernetes.

--recreate-pods memaksa semua Pod dihapus dan dibuat ulang saat upgrade. Ini adalah mode "hammer": berguna jika chart kalian tidak mendukung rolling update dengan benar (misalnya Pod yang tidak punya readiness probe, atau stateful workload yang sensitif terhadap hostname). Harga yang dibayar adalah downtime total selama Pod baru tidak ready — jadi gunakan hanya ketika --wait gagal karena Pod lama tidak pernah siap digantikan.

Recreate Pod untuk workload non-rolling

helm upgrade frontend bitnami/nginx --recreate-pods --timeout 10m

#`--reuse-values` vs `--reset-values`: Mengelola Values Lama

Salah satu sumber kebingungan terbesar adalah apa yang terjadi pada values saat upgrade. Helm mengingat "values terakhir yang di-set" dan me-replay-nya pada setiap upgrade, lalu menggabungkannya dengan nilai baru dari -f/--set. Perilaku ini menguntungkan — kalian tidak perlu mengulang semua --set sebelumnya — tapi juga menjebak.

Masalahnya muncul di CI/CD yang memakai pola ini: pipeline pertama dijalankan dengan --set image.tag=1.26.0, lalu pipeline kedua hanya memakai --set replicaCount=5 tanpa menyebut image. Karena Helm mereplay nilai lama, image tag akan "mengikuti" dari pipeline sebelumnya — kadang justru menaikkan chart version sementara image tertinggal di versi lama. Ini adalah penyebab klasik "kenapa image tidak pernah berubah padahal saya sudah upgrade?".

Untuk mengendalikan perilaku ini, Helm menyediakan dua flag yang saling bertentangan:

--reset-values: buang semua values yang di-set pada upgrade sebelumnya, lalu mulai dari values.yaml bawaan chart + input baru. Gunakan saat kalian ingin "reset" konfigurasi ke kondisi pabrik atau saat source of truth values ada di file -f yang selalu lengkap.
--reuse-values: pakai persis values dari release sebelumnya dan hanya terapkan input baru di atasnya. Berguna untuk perubahan kecil tanpa menyentuh yang lain.

Reset values sebelum upgrade

helm upgrade frontend bitnami/nginx \
  --reset-values \
  --values values.yaml \
  --set image.tag=1.27.0

Warning

Kombinasi --reuse-values dengan interpolasi secret di template sangat berbahaya. Beberapa chart meng-render Secret dari nilai di values (misalnya password). Karena values lama direplay dan helm history menyimpan seluruh render manifest, nilai rahasia yang pernah di-set akan tetap tersimpan di dalam Secret release di cluster. Pastikan tim kalian sepakat: di production, source of truth adalah file values yang di-commit, bukan --set ephemeral di command line.

#Upgrade yang Aman: `--wait`, `--timeout`, `--atomic`

Upgrade default Helm hanya "mengirimkan" manifest ke cluster lalu mengembalikan status — ia tidak menunggu aplikasi benar-benar berjalan. Di produksi, ini seperti menekan tombol dan pergi begitu saja tanpa mengecek apakah lift benar-benar datang. Tiga opsi ini membuat upgrade sadar kondisi:

--wait: Helm menunggu hingga seluruh resource dianggap ready (Pod dalam Ready, Job selesai, Service punya endpoint) sebelum upgrade dinyatakan berhasil. Jika sampai timeout belum ready, upgrade ditandai failed.
--timeout: batas waktu tunggu, default 5 menit. Untuk aplikasi yang boot lambat, naikkan ke 10m atau 15m. Terlalu rendah membuat upgrade gagal padahal sebenarnya hanya butuh waktu.
--atomic: upgrade yang auto-rollback. Jika ada kegagalan — termasuk kegagalan --wait — Helm otomatis me-rollback ke revision terakhir yang berhasil dan menghapus resource hasil upgrade yang gagal. Ini adalah flag paling penting untuk deployment production: kalian mendapatkan "rencana B" secara gratis.

Upgrade atomic: rollback otomatis jika gagal

helm upgrade --install frontend bitnami/nginx \
  --namespace web \
  --set image.tag=1.27.0 \
  --wait --timeout 10m \
  --atomic

Bayangkan ini seperti parasut cadangan: --wait memastikan kalian tidak mendarat tanpa cek, dan --atomic membuka parasut otomatis saat pendaratan mulai meleset. Bukan berarti kalian boleh sembrono — --atomic tidak menyembuhkan konfigurasi yang salah, ia hanya mengembalikan ke kondisi sebelumnya.

#Revision, Riwayat & Rollback

Setiap kali sebuah release di-install, di-upgrade, atau di-rollback, Helm menyimpan revision baru. Revision adalah snapshot manifest lengkap hasil render, disimpan sebagai Secret di namespace release. Inilah alasan mengapa rollback bisa "memutar waktu" dengan andal: Helm tidak perlu mengingat apa yang kalian ketik, cukup membaca snapshot revision sebelumnya.

Untuk melihat riwayat:

helm history frontend -n web

REVISION	UPDATED                 	STATUS    	CHART        	APP VERSION	DESCRIPTION
1       	Sat Aug  2 10:12:01 2026	deployed  	nginx-19.0.0 	1.27.0     	Install complete
2       	Sat Aug  2 11:40:22 2026	deployed  	nginx-19.0.1 	1.27.1     	Upgrade complete
3       	Sat Aug  2 12:15:47 2026	failed    	nginx-19.0.1 	1.27.1     	Upgrade "frontend" failed
4       	Sat Aug  2 12:20:03 2026	deployed  	nginx-19.0.1 	1.27.1     	Rollback to 2

Perhatikan detail penting: setelah upgrade gagal di revision 3, helm rollback frontend 2 mengembalikan manifest ke kondisi revision 2 — tetapi karena ini operasi yang mengubah release, ia menjadi revision 4, bukan "mengulang" revision 2. Revision lama ditandai superseded; hanya revision terakhir yang berstatus deployed atau failed. Rollback juga memakai three-way merge yang sama: manifest target dibandingkan dengan manifest lama dan kondisi live, sehingga resource yang dihapus di revision 3 akan dibuat ulang, dan resource yang baru ditambahkan di revision 3 akan dihapus.

Rollback ke revision yang sehat

helm rollback frontend 2 --namespace web --wait --timeout 10m

Tip

Gunakan --history-max saat install untuk membatasi jumlah revision yang disimpan, misalnya --history-max 10. Setiap revision disimpan sebagai Secret lengkap — tanpa batasan, release yang di-upgrade ratusan kali akan menumpuk ratusan Secret di namespace, membebani API server dan kubectl get secrets. Dan karena helm rollback hanya membaca revision yang tersimpan, menyimpan 3–10 revision terakhir sudah cukup untuk recovery normal.

#Praktik Terbaik Upgrade di Production

Mekanisme hanyalah alat; yang menyelamatkan produksi adalah proses. Beberapa praktik yang berlaku di tim-tim serius:

Uji upgrade di staging dulu. Jalankan alur yang sama persis — chart version, values, dan flag — di environment staging sebelum menyentuh production. Banyak chart punya perbedaan halus antar environment (storage class, Ingress host, image pull dari registry internal).
Backup sebelum upgrade. Sebelum upgrade besar, simpan manifest dan values revision terakhir: helm get manifest frontend --namespace web > backup-frontend.yaml. Ini memberi kalian jaring pengaman tambahan di luar Secret revision.
Monitor selama dan setelah upgrade. Pantau kubectl get pods -n web -w, kubectl get events --watch, serta metrik aplikasi (error rate, latency, disk) minimal 10–15 menit setelah upgrade, bukan hanya saat "status success". Deployment success tidak berarti bisnis sukses.
Siapkan rencana rollback lebih dulu. Tulis runbook: "jika error rate naik X%, jalankan helm rollback frontend <revision sehat>". Saat insiden terjadi, otak manusia tidak berpikir jernih — keputusan yang sudah ditulis akan dieksekusi.
Perkecil lead time per perubahan. Upgrade kecil yang sering lebih mudah di-rollback daripada perubahan raksasa. Kalau bisnis error, kalian bisa pinpoint penyebabnya ke satu perubahan yang baru saja dilakukan.
Gunakan window yang aman. Untuk aplikasi yang melayani traffic tinggi, jadwalkan upgrade di jam sepi dan gunakan --atomic agar kegagalan tidak meninggalkan release dalam kondisi setengah mati.

#Alur Upgrade Lengkap

Berikut alur nyata yang bisa kalian praktikkan — dari upgrade dengan values baru, memeriksa riwayat, hingga rollback ketika ditemukan anomali:

helm upgrade --install frontend bitnami/nginx \
  --namespace web \
  --version 19.0.1 \
  --values values.yaml \
  --set image.tag=1.27.0 \
  --set resources.requests.cpu=250m \
  --wait --timeout 10m --atomic

Setelah rollback, selalu konfirmasi dengan helm history dan helm status frontend --namespace web — pastikan status kembali deployed, Pod ready, dan lalu investigasi kenapa upgrade pertama gagal sebelum mencoba lagi. Rollback bukan solusi, ia adalah jeda aman untuk berpikir.

Important

Satu-satunya yang lebih buruk daripada upgrade gagal adalah upgrade gagal tanpa riwayat yang jelas. Biasakan setiap perintah helm upgrade dan helm rollback dijalankan dari satu orang/tim yang sama (idealnya via pipeline CI/CD yang logged), karena hanya satu yang boleh mengubah release pada satu waktu. Dua engineer yang menjalankan upgrade bersamaan pada release yang sama akan saling menimpa revision dan menciptakan kondisi yang sangat sulit di-debug.

#Penutup

Pada episode 5 ini kita telah mempelajari bahwa helm upgrade bukan sekadar "apply YAML baru", melainkan operasi three-way merge yang membandingkan revision lama, manifest baru, dan kondisi live cluster. Kita membedah flag kunci: --install untuk upsert dari CI/CD, --force dan --recreate-pods untuk menangani resource immutable dan workload non-rolling, --reset-values vs --reuse-values untuk mengendalikan replay values lama, serta --wait, --timeout, dan --atomic yang membuat upgrade sadar kondisi dan bisa auto-rollback. Kita juga memahami mekanisme revision di balik helm history dan helm rollback, plus praktik terbaik: uji di staging, backup sebelum upgrade, monitor setelah upgrade, dan runbook rollback yang ditulis sebelum insiden.

Inti yang harus kalian bawa:

Upgrade release = three-way strategic merge: perubahan minimal, idempoten, dan deterministik.
--atomic + --wait + --timeout adalah trio wajib untuk upgrade production.
Replay values lama bisa menipu; pilih --reset-values atau --reuse-values secara sadar, dan jadikan file values yang di-commit sebagai source of truth.
Rollback membaca snapshot revision, bukan ingatan; batasi riwayat dengan --history-max.
Rencana rollback ditulis sebelum insiden, bukan saat insiden.

Di episode 6 selanjutnya kita akan menyelami tema yang sebenarnya menjadi jembatan antara memakai chart dan membangun chart: konfigurasi chart dengan values. Kita akan membedah hierarki precedence (values.yaml default < file -f < --set), berbagai cara menyetel values, struktur file values untuk data kompleks, serta pola values-dev.yaml, values-staging.yaml, dan values-prod.yaml yang dipakai tim production. Sampai jumpa di episode 6!