Satu aplikasi di Kubernetes biasanya butuh Deployment, Service, Ingress, ConfigMap, Secret, HorizontalPodAutoscaler, dan sering kali lebih. Kalikan dengan staging dan production yang masing-masing punya jumlah replika, domain, dan resource berbeda, dan menyalin file YAML secara manual cepat sekali jadi sumber kesalahan. Helm membungkus manifest itu menjadi chart dengan variabel, memasangnya sebagai release, dan menyimpan riwayat yang bisa di-rollback. Berikut cara memakainya dengan baik.
Konsep Utama
| Istilah | Arti |
|---|---|
| Chart | Folder berisi Chart.yaml, file values.yaml, dan direktori templates berisi manifest Kubernetes |
| Values | Pengaturan seperti tag image, jumlah replika, dan domain yang mengisi template |
| Template | Manifest dengan placeholder Go template, misalnya {{ .Values.image.tag }} |
| Release | Satu salinan chart yang terpasang di sebuah namespace, dengan nama dan riwayat revisinya sendiri |
| Repository | Tempat menerbitkan chart, bisa berupa chart repository klasik atau OCI registry |
Helm bisa dipakai dengan dua cara. Memasang chart yang dikelola pihak lain, seperti ingress-nginx, cert-manager, atau operator database, lalu cukup menulis values sendiri. Atau menulis chart untuk aplikasi sendiri. Sebagian besar tim melakukan keduanya.
Menulis Chart untuk Aplikasi Sendiri
- 1Jalankan helm create my-app untuk mendapat struktur awal, lalu hapus template yang tidak dibutuhkan. Anggap chart hasil generate sebagai kerangka yang perlu dipangkas.
- 2Isi values.yaml dengan nilai default yang masuk akal dan beri komentar penjelasan untuk setiap value.
- 3Buat logika template tetap sederhana. Helper di _helpers.tpl untuk nama dan label memang berguna, tapi kondisi bersarang yang dalam membuat chart sulit dibaca.
- 4Jadikan resource request dan limit, liveness dan readiness probe, serta securityContext sebagai default di chart, supaya semua environment mendapatkannya.
- 5Tambahkan annotation checksum dari ConfigMap ke Deployment supaya Pod di-restart ketika konfigurasi berubah.
- 6Tambahkan file values.schema.json supaya Helm menolak values dengan tipe yang salah atau field wajib yang kosong sebelum ada yang ter-deploy.
Satu Chart untuk Beberapa Environment
Pakai satu chart dan satu file values per environment, misalnya values-staging.yaml dan values-production.yaml, yang hanya berisi perbedaannya: jumlah replika, domain, resource, dan feature flag. Deploy dengan helm upgrade --install my-app ./chart -f values-production.yaml --set image.tag=$GIT_SHA. Pakai tag image yang tidak berubah seperti SHA commit, supaya setiap revisi menunjuk tepat ke satu build dan rollback mengembalikan image yang sama.
Upgrade dan Rollback
- Pakai helm upgrade --install supaya perintah yang sama bisa dipakai untuk deploy pertama dan semua deploy berikutnya.
- Tambahkan --atomic di Helm 3, yang di Helm 4 berganti nama menjadi --rollback-on-failure, supaya Helm menunggu Pod siap dan otomatis rollback kalau gagal.
- Jalankan helm diff upgrade dari plugin helm-diff di CI untuk menampilkan persis apa yang akan berubah sebelum diterapkan.
- Pakai helm history my-app untuk melihat revisi sebelumnya, dan helm rollback my-app dengan nomor revisi untuk kembali.
- Ingat bahwa rollback hanya mengembalikan manifest. Migrasi database butuh rencana tersendiri yang tetap kompatibel dengan versi sebelumnya.
Jauhkan Secret dari File Values
Menaruh password database di values-production.yaml memang menggoda. File itu akan masuk ke Git, ke log CI, dan ke data release yang disimpan Helm di cluster. Simpan secret di secret manager seperti AWS Secrets Manager, Google Secret Manager, atau Vault, lalu sinkronkan ke Kubernetes dengan External Secrets Operator. Cara lain, enkripsi secret di Git dengan Sealed Secrets atau SOPS. Dengan begitu chart cukup menyebut nama Secret tanpa pernah memuat isinya.
Testing Chart di CI
- helm lint menangkap kesalahan struktur dan values yang hilang.
- helm template merender manifest supaya bisa diperiksa dengan kubeconform terhadap skema Kubernetes.
- Scanner kebijakan dan keamanan seperti Checkov, Trivy, atau Kyverno CLI menandai container yang berjalan sebagai root, limit yang tidak dipasang, dan masalah sejenis.
- Deploy ke cluster sementara dengan kind untuk chart yang dipakai banyak tim.
Helm atau Kustomize?
Kustomize sudah ada di dalam kubectl, memakai YAML biasa, lalu menerapkan patch per environment tanpa bahasa template. Kustomize cocok untuk tim yang ingin manifest-nya tetap mudah dibaca sebagai YAML Kubernetes biasa. Helm cocok untuk aplikasi yang dipasang berkali-kali dengan pengaturan berbeda, butuh packaging dan versioning, atau dibagikan ke tim lain. Keduanya masuk materi CKAD, dan keduanya juga bisa digabung: tool GitOps seperti Argo CD dan Flux bisa men-deploy Helm chart dengan patch Kustomize di atasnya.
Chart yang bagus itu membosankan. Siapa pun di tim bisa membacanya, dan file values-nya sudah menjelaskan semua perbedaan antar environment.
Pelatihan CKAD kami mencakup lab Helm dan Kustomize langsung di cluster sungguhan, mulai dari menulis chart pertama sampai upgrade, rollback, dan konfigurasi per environment.
Poin penting
- Helm membungkus manifest Kubernetes menjadi chart dengan values, dan mencatat setiap release supaya bisa di-rollback.
- Pakai satu chart dan file values kecil per environment, lalu deploy dengan tag image yang tidak berubah.
- Pakai helm upgrade --install dengan rollback otomatis saat gagal, dan review hasil helm diff di CI sebelum diterapkan.
- Simpan secret di secret manager atau dalam bentuk terenkripsi di Git, jangan di file values biasa.
- Jalankan lint, render, dan validasi chart di CI, dan pakai Kustomize kalau YAML biasa dengan patch sudah cukup.
