Belajar Helm Chart - Instalasi & Manajemen Release

#Pendahuluan

Setelah di episode 3 kita berhasil melakukan deployment pertama dengan helm install, pada episode kali ini kita memperdalam penguasaan manajemen release — keterampilan yang membedakan pemakai Helm dari administrator Helm. Kita akan membedah flag-flag instalasi yang menentukan perilaku saat gagal (--wait, --timeout, --atomic), strategi penamaan release, teknik dry-run dan debugging sebelum menembak produksi, cara membaca informasi release (helm list, helm status, helm get), memahami peta status release yang sering menjadi teka-teki, dan menutup dengan uninstall yang bersih.

Mengapa episode ini penting? Karena sebagian besar insiden produksi bukan berawal dari chart yang salah, melainkan dari keputusan yang diambil saat operasi: install tanpa timeout sehingga proses menggantung sepanjang malam, upgrade yang tidak diuji dry-run lalu menimpa yang sedang berjalan, atau uninstall yang dilakukan tanpa memahami apa yang ikut terhapus. Menguasai manajemen release berarti kalian bisa menjawab tiga pertanyaan yang selalu ditanyakan di dunia kerja: apa yang sedang berjalan, apakah instalasinya aman, dan bagaimana membatalkannya jika tidak.

#Pembahasan Utama

#Instalasi Chart: Dasar dan Opsi Penting

Bentuk paling dasar helm install sudah kalian pakai di episode 3: helm install <release-name> <chart>. Namun install untuk production memerlukan lebih banyak kontrol. Inilah flag yang paling sering dipakai:

helm install web bitnami/nginx \
  --namespace web \
  --wait \
  --timeout 5m \
  --atomic

• --namespace <ns> — namespace tempat release di-install (sekali lagi: state release tersimpan di namespace ini). Gunakan --create-namespace jika belum ada.
• --wait — Helm menunggu semua resource benar-benar siap (Pod Running dan Ready, Service punya endpoint) sebelum menandai release sebagai deployed. Tanpa ini, helm install selesai begitu manifest terkirim — tidak peduli aplikasinya crash.
• --timeout <durasi> — batas waktu menunggu (default 5 menit). Format: 300s, 5m, 1h.
• --atomic — kombinasi paling penting: jika install gagal melewati --wait, Helm otomatis melakukan rollback dan menghapus seluruh resource yang baru dibuat. Release kembali ke kondisi tidak ada, bukan tersisa setengah jadi.

Ada satu variasi flag yang perlu dipahami: --install pada helm upgrade (dibahas dalam di episode 5) memungkinkan perintah yang sama bertindak sebagai install jika release belum ada. Untuk episode ini, fokus pada instalasi murni.

#Strategi Penamaan Release

Nama release adalah identitas yang dipakai seluruh perintah manajemen. Beberapa strategi yang lazim di lapangan:

• Nama aplikasi + environment — web-dev, web-prod. Jelas, tapi release terpisah untuk environment yang sama.
• Nama aplikasi saja — web, dengan environment dipisah lewat namespace (web di ns dev dan web di ns prod). Strategi ini memanfaatkan fakta bahwa nama release hanya perlu unik dalam satu namespace.
• Nama random — helm install <random> bitnami/nginx tanpa nama menghasilkan nama acak (mis. kindly-otter), berguna untuk eksperimen cepat.

Prinsip pentingnya: release-name unik per namespace, bukan per cluster. Kalian bisa punya web di namespace dev dan web di namespace prod secara bersamaan — keduanya release yang berbeda dan independen. Pilih konvensi yang konsisten di tim kalian, dan jangan mengubahnya di tengah jalan.

#Dry-Run & Debugging

Sebelum menembakkan sesuatu ke cluster nyata, Helm memberi kalian kemampuan untuk melihat hasil tanpa apply. Inilah senjata utama debugging — dan dua perintah yang wajib dikuasai:

helm install web bitnami/nginx --namespace web --create-namespace --dry-run

helm install web bitnami/nginx --namespace web --create-namespace --dry-run --debug

• --dry-run — merender seluruh template, menampilkan hasilnya, dan tidak mengirim apa pun ke API server. Output menampilkan perintah yang akan dijalankan dan manifest YAML lengkap yang akan di-install.
• --debug — melakukan dry-run yang lebih dalam: menampilkan proses yang terjadi di client, hook yang terdaftar, dan pesan dari sisi server. Wajib dipakai saat install gagal dengan error yang tidak jelas.

NAME: web
LAST DEPLOYED: Sun Aug 02 20:00:00 2026
NAMESPACE: web
STATUS: pending-install
REVISION: 1
TEST SUITE: None
 
NOTES:
...

Perhatikan STATUS: pending-install — inilah status saat install belum tuntas, dan salah satu dari daftar status yang akan kita bedah sebentar lagi. Gunakan --dry-run sebelum setiap perubahan yang berisiko: kalian akan melihat manifest persis seperti yang akan dikirim, termasuk efek override values — tanpa risiko merusak yang sedang berjalan.

#Melihat Status & Informasi Release

Setelah release ada, tiga perintah ini adalah jendela kalian ke kondisinya.

helm list — daftar semua release. Tanpa flag, hanya menampilkan release di namespace saat ini (default default):

helm list
helm list -A
helm list -n web
helm list -A --filter web

• -A / --all-namespaces — tampilkan release dari semua namespace. Tanpa ini, release di namespace web tidak terlihat dari namespace lain — sumber kebingungan klasik.
• --filter — pencarian parsial berdasarkan nama release.
• --status — filter berdasarkan status, misalnya helm list --status failed.

helm status <release> — kondisi lengkap satu release: status, revisi, namespace, waktu deploy, dan notes. Inilah perintah pertama saat debugging.

helm get <subcommand> <release> — menelusuri detail dari sisi data:

helm get manifest web
helm get values web
kubectl get secrets -n web | grep sh.helm

helm get manifest adalah jawaban atas pertanyaan paling umum di dunia Helm: "sebenarnya apa yang berjalan di cluster ini?" Semuanya tercetak di sini — dibaca langsung dari Secret release.

#Di Balik Layar: Tempat Helm Menyimpan State

Kalian sudah dua kali melihat istilah "state release" tanpa penjelasan — mari kita buka tutupnya, karena memahami ini mencegah sekelompok misteri yang mengganggu. Helm 3 menyimpan seluruh riwayat release di dalam Kubernetes Secret, bukan di database eksternal, bukan di dalam memory, dan bukan di file lokal. Ini adalah salah satu alasan utama kenapa Tiller dihapus: tidak ada daemon yang menyimpan state, sehingga siapa pun dengan akses kubectl bisa membaca dan memulihkan state kapan saja.

kubectl get secrets -n web | grep sh.helm
web.v1   helm.sh/release.v1   1      25s

Perhatikan pola penamaannya: web.v1 — nama release diikuti nomor revisi. Setiap revisi menyimpan Secret-nya sendiri; web.v1 adalah revisi pertama, web.v2 muncul setelah upgrade pertama (episode 5), dan seterusnya. Tipe Secret helm.sh/release.v1 menandakan data di dalamnya adalah serialisasi release Helm. Karena berbentuk Secret (bukan ConfigMap), data di dalamnya di-encode base64 — bukan enkripsi, hanya encoding. Siapa pun dengan akses list/get pada namespace bisa membaca manifest lengkap dari Secret ini.

Dua implikasi praktis dari desain ini:

1. State release bisa di-recover dari cluster. Jika mesin kalian hilang atau ~/.kube/config berubah, seluruh riwayat release tetap aman di cluster — helm list, helm history, bahkan rollback tetap berfungsi selama cluster dan Secret-nya ada. Tidak ada file cache lokal yang harus dicadangkan.
2. Namespace adalah batas keamanan. State release hidup di namespace tempat release di-install. Memberikan akses kubectl ke namespace berarti memberikan akses untuk membaca dan memodifikasi state Helm di namespace itu — perhatikan saat merancang RBAC (akan dibahas di episode 20).

Karena itu juga, helm uninstall tanpa --keep-history menghapus Secret-Scret ini — dan begitu Secret terhapus, riwayat release hilang permanen, tidak bisa di-recover. Inilah alasan utama --keep-history direkomendasikan untuk environment yang diaudit.

#Release Lifecycle & Status

Setiap release bergerak melalui status yang mencerminkan tahap hidupnya. Pahami peta ini, karena hampir semua troubleshooting Helm dimulai dari membaca status:

Alur normal sebuah release: pending-install → deployed (revisi 1) → saat upgrade, revisi 1 berubah superseded, revisi 2 pending-upgrade → deployed. Riwayat lengkap semua revisi bisa dilihat dengan helm history web — alat yang akan menjadi pusat episode 5 saat kita membahas rollback.

#Uninstall & Cleanup

Menghapus release adalah kebalikan dari install: Helm mengirim perintah delete untuk setiap resource yang ada di manifest release, lalu menghapus Secret state-nya (kecuali diminta menyimpan riwayat).

helm uninstall web -n web
helm list -A
kubectl get all -n web

helm uninstall web -n web menghapus seluruh resource release dan state-nya. Verifikasi pembersihan dengan kubectl get all -n web — namespace kosong (atau hilang jika dibuat lewat --create-namespace). Perhatikan bahwa helm list tidak lagi menampilkan release tersebut.

Jika kalian ingin menyimpan riwayat — misalnya untuk audit atau rollback — gunakan --keep-history:

helm uninstall web -n web --keep-history
helm list -n web --all
helm history web -n web

Dengan --keep-history, release tetap tercatat berstatus uninstalled beserta seluruh revision history-nya — dan masih bisa di-rollback kapan pun. Trade-off-nya: Secret penyimpanan state tetap tersimpan di cluster. Untuk environment production yang diaudit, --keep-history adalah kebiasaan yang baik; untuk eksperimen, hapus bersih tanpa flag ini.

#Kesalahan Umum

1. Release tidak terlihat di helm list. Kemungkinan besar namespace salah atau status tersaring (superseded/uninstalled). Periksa dengan helm list -A --all.
2. Install menggantung tanpa --wait. Release menunggu resource yang tidak pernah siap. Gunakan --wait --timeout 5m dan amati kubectl get events -n <ns>.
3. Lupa --atomic lalu install gagal. Release tertinggal berstatus failed dengan resource setengah hidup. Bersihkan dengan helm uninstall atau mulai ulang dengan --atomic.
4. Menyalahkan --force. --force (di upgrade) tidak menyelesaikan masalah aplikasi — ia hanya memaksa recreate pod. Debug dulu dengan --dry-run --debug.
5. Uninstall tanpa verifikasi. Menghapus release tapi tidak mengecek sisa resource yang dibuat di luar chart (misalnya PVC). Selalu kubectl get all,ingress,pvc -n <ns> setelah uninstall.

#Penutup

Pada episode 4 ini kalian telah menguasai manajemen release Helm dari hulu ke hilir: instalasi dengan kontrol penuh (--namespace, --wait, --timeout, --atomic), strategi penamaan release yang unik per namespace, dry-run dan debugging yang mencegah kesalahan sebelum terjadi, membaca informasi release (helm list, helm status, helm get), memahami peta lifecycle status dari pending-install hingga uninstalled, serta uninstall yang bersih dengan opsi --keep-history.

Inti yang harus kalian bawa:

• --wait --timeout --atomic adalah triad instalasi aman untuk produksi dan CI/CD.
• --dry-run --debug selalu dipakai sebelum perubahan berisiko.
• Nama release unik per namespace; helm list -A --all untuk melihat semuanya.
• Status superseded/uninstalled tidak muncul di helm list default — jangan panik.
• Uninstall hanya menghapus resource milik chart — verifikasi selalu dengan kubectl.

Sekarang kalian bisa meng-install, memeriksa, dan menghapus release dengan percaya diri. Di episode 5 selanjutnya kita membahas siklus hidup yang paling sering dipakai sehari-hari: upgrade, rollback, dan riwayat release — dari helm upgrade --install, opsi --reuse-values vs --reset-values, hingga membaca helm history dan memutuskan kapan harus rollback. Sampai jumpa di episode 5!