Belajar Helm Chart - Sejarah, Latar Belakang & Mengapa Membutuhkan Helm

#Pendahuluan

Setelah di episode 0 kita memastikan environment siap — skill dasar Kubernetes, kebiasaan kubectl, cluster lokal yang berjalan, dan helm version yang merespons — pada episode kali ini kita mundur sejenak untuk menjawab pertanyaan yang jarang diajukan tapi sangat menentukan: dari mana Helm berasal, dan mengapa ia dibutuhkan?

Pertanyaan ini bukan trivia sejarah. Memahami latar belakang Helm menjawab tiga pertanyaan praktis yang akan menghantui kalian sepanjang karier: (1) mengapa tim yang mendeploy aplikasi production dengan kubectl apply murni selalu kehabisan waktu untuk hal-hal yang berulang, (2) apa sebenarnya yang dipecahkan Helm dan apa yang tidak — sehingga kalian tahu kapan memakainya dan kapan tidak, dan (3) mengapa masalah keamanan Tiller menjadi titik balik yang mengubah desain Helm selamanya. Seperti memahami sejarah sebuah bahasa pemrograman, memahami sejarah Helm membuat kalian bukan hanya bisa mengetik perintah, tapi tahu mengapa desainnya seperti itu.

Di episode ini kita akan membedah tantangan deployment di Kubernetes, menelusuri evolusi dari Helm 1 hingga Helm 3, membedah mengapa Tiller dihapus, memahami konsep Chart, Release, dan Repository, serta menutup dengan perbandingan jujur antara Helm, Kustomize, kubectl murni, dan Kubernetes Operator.

#Tantangan Deployment di Kubernetes

Kubernetes menyelesaikan orkestrasi container dengan luar biasa — tetapi pada saat yang sama menciptakan paradoks baru: infrastruktur deklaratif yang sangat banyak. Sebelum Kubernetes, mendeploy satu aplikasi cukup "jalankan proses ini". Dengan Kubernetes, satu aplikasi adalah kumpulan manifest yang saling terkait. Semakin besar tim dan sistem, semakin terasa berat beban manualnya.

#Mengelola Puluhan File YAML

Aplikasi production bukan satu Deployment. Ia adalah Deployment, Service, ConfigMap, Secret, Ingress, HorizontalPodAutoscaler, ServiceAccount, NetworkPolicy, dan mungkin beberapa Job — setiap resource butuh satu file (atau banyak bagian dalam satu file). Sekarang kalikan dengan jumlah environment: dev, staging, production. Kalian dengan cepat memiliki puluhan hingga ratusan file YAML yang saling menyalin. Bukan hanya jumlahnya — masalahnya adalah fragmentasi: mengubah satu nilai (misalnya jumlah replica) berarti mengedit file di tiga environment berbeda, dan risiko lupa satu saja selalu mengintai.

#Konfigurasi yang Berbeda Antar Environment

Environment tidak pernah identik. Production butuh replica lebih banyak, image tag yang sama tapi dengan resource limits lebih besar, hostname berbeda untuk Ingress, dan kredensial database yang berbeda di setiap environment. Tanpa alat yang tepat, kalian berakhir dengan tiga salinan manifest yang hampir sama — dan "hampir" itulah sumber bug klasik: perbedaan satu baris yang tidak disadari siapa pun. Masalah ini sama persis dengan "dependency hell" yang melahirkan Docker, hanya pindah ke level konfigurasi.

#Versioning, Rollback, dan Lifecycle

Git men-versioning kode dengan baik, tapi mendeploy versi aplikasi bukan hanya soal git checkout. Aplikasi punya lifecycle: install, upgrade, dan hapus — dan masing-masing punya status tersendiri. kubectl apply memang menyimpan konfigurasi terakhir, tapi rollback di dunia kubectl murni berarti "mengembalikan file ke versi lama lalu apply lagi" — manual, rawan kesalahan, dan tanpa jejak audit. Tim yang pernah malam-malam men-debug "siapa yang mengubah apa tadi siang" tahu persis betapa menyakitkannya masalah ini.

#Dependency Management dan Konsistensi Tim

Aplikasi modern bergantung pada komponen lain: ingress controller, cert-manager, Prometheus, database. Komponen-komponen ini sebenarnya aplikasi juga — dengan cara deploy masing-masing. Mengelolanya secara manual berarti setiap tim menyalin dokumentasi instalasi yang panjang dan mengikuti langkah yang bisa saja berbeda antar orang. Konsistensi antar tim hilang: satu tim menginstall nginx-ingress dengan parameter A, tim lain dengan parameter B, dan ketika terjadi masalah, tidak ada dua engineer yang menyetujui "apa yang sebenarnya berjalan di cluster".

#Evolusi Helm: Dari Deis hingga CNCF Graduated

Helm tidak muncul dalam satu malam. Ia mengalami tiga generasi besar, masing-masing lahir dari pelajaran generasi sebelumnya.

#Helm 1 (Deis, 2015)

Helm berawal pada tahun 2015 sebagai proyek bernama Deployment Manager dari tim Deis — perusahaan yang fokus pada PaaS open-source. Ide awalnya sederhana: mengemas aplikasi beserta semua manifest Kubernetes-nya menjadi satu paket yang bisa dipakai ulang. Proyek ini kemudian berganti nama menjadi Helm, mengadopsi pola package manager klasik: paket disebut chart, diambil dari registry yang disebut repository, dan hasil instalasinya disebut release. Helm 1 punya keterbatasan besar — arsitekturnya belum matang dan adopsinya masih kecil — tapi meletakkan fondasi konseptual yang bertahan sampai sekarang.

#Helm 2 dan Tiller (2016)

Helm 2 dirilis pada 2016 dengan perubahan arsitektur besar: diperkenalkan Tiller, sebuah daemon server yang berjalan di dalam cluster dan menjadi perantara antara client Helm dan Kubernetes API server. User menjalankan helm install, client mengirim chart ke Tiller, dan Tiller yang berinteraksi dengan API server — sekaligus menyimpan state release di dalam ConfigMaps.

Desain ini mengadopsi pola client-server klasik, tapi membawa masalah keamanan yang serius. Karena Tiller berjalan di dalam cluster dengan hak istimewa penuh, setiap user yang bisa berkomunikasi dengan Tiller secara efektif mendapatkan kendali penuh atas seluruh cluster — tanpa ada mekanisme RBAC granular di antara keduanya. Tiller menjadi titik kegagalan keamanan yang terus menjadi perhatian: ia adalah kredensial cluster yang berjalan di dalam cluster itu sendiri, dan praktik terbaik keamanan "least privilege" sulit diterapkan. Masalah ini bukan hipotetis — banyak organisasi menolak Helm 2 justru karena Tiller.

#Helm 3: Tillerless (2019)

Helm 3 dirilis pada November 2019 dengan keputusan paling berani: menghapus Tiller sepenuhnya. Client Helm kini berkomunikasi langsung dengan Kubernetes API server, menggunakan kredensial dan RBAC dari kubeconfig yang sama dengan kubectl. Release disimpan dalam Secret (bukan ConfigMap) di namespace tempat aplikasi di-install — bukan di namespace kube-system lagi. Konsekuensinya: keamanan mengikuti prinsip standar Kubernetes, eksperimen lebih mudah (client lokal bisa memakai aksesnya sendiri), dan tidak ada lagi daemon pusat yang perlu dipelihara.

#CNCF Graduated (2020)

Helm diterima menjadi project CNCF (Cloud Native Computing Foundation) pada 2018 dengan status incubating, dan mencapai status graduated pada April 2020 — tanda kedewasaan proyek: governance yang stabil, adopsi luas, dan keamanan yang teruji. Saat ini Helm adalah standar de facto untuk packaging aplikasi di ekosistem Kubernetes, dengan ribuan chart publik di Artifact Hub.

#Apa Itu Helm?

Helm adalah package manager untuk Kubernetes. Tiga konsep intinya perlu kalian hafal sejak sekarang:

• Chart — paket yang berisi sekumpulan file yang mendeskripsikan resource Kubernetes beserta metadata-nya. Chart adalah artefak yang bisa didistribusikan, di-versioning, dan dipakai ulang.
• Release — satu instance chart yang ter-install ke cluster dengan nama unik. Satu chart bisa menghasilkan banyak release; setiap release punya state dan riwayat (revision) sendiri.
• Repository — tempat chart disimpan dan diambil, seperti registry npm atau PyPI. Bisa berupa server HTTP/HTTPS sederhana maupun OCI registry.

Bayangkan Helm sebagai npm untuk Kubernetes: alih-alih meng-install library JavaScript ke dalam node_modules, kalian meng-install aplikasi lengkap ke dalam cluster dengan semua manifest, konfigurasi, dan dependensinya — sebagai satu unit yang bisa di-upgrade, di-rollback, dan di-uninstall.

Satu hal yang membedakan Helm dari kebanyakan package manager: dependensi antar chart. Sebuah chart bisa mendeklarasikan dependency ke chart lain di dalam Chart.yaml-nya — misalnya chart aplikasi yang bergantung pada chart database. Saat install, Helm menarik semua dependency tersebut bersama-sama, dan versinya dikunci di file Chart.lock sehingga setiap orang membangun chart yang identik. Inilah yang membuat instalasi "WordPress + MariaDB" menjadi satu perintah tunggal, bukan dua aplikasi yang disatukan secara manual.

#Mengapa Helm Dibutuhkan

Manfaat Helm menjawab satu per satu tantangan yang kita bedah di awal:

• Deployment yang disederhanakan — satu perintah helm install menggantikan puluhan langkah kubectl apply yang menyalin file.
• Paket yang reusable — chart bisa dipakai ulang lintas environment dan lintas proyek; sekali dibuat, dipakai berkali-kali.
• Versioning — chart dan release punya versi dan revision, sehingga tim tahu persis apa yang berjalan.
• Rollback yang mudah — helm rollback mengembalikan aplikasi ke revision sebelumnya tanpa memulihkan file secara manual.
• Konfigurasi terpusat — nilai konfigurasi (jumlah replica, image tag, hostname) didefinisikan terpisah dari manifest, diubah per environment lewat file values.
• Ekosistem community — ribuan chart siap pakai di Artifact Hub: database, ingress controller, monitoring, message queue — di-install dalam hitungan menit.

Untuk melihat manfaat ini secara konkret, bayangkan mendeploy WordPress beserta database-nya di cluster. Tanpa Helm, kalian mengelola dua aplikasi terpisah: manifest WordPress (Deployment, Service, Ingress, ConfigMap) dan manifest MariaDB (StatefulSet, Service, PVC, Secret), lalu menyelaraskan keduanya secara manual — termasuk versi, kredensial, dan urutan deploy. Dengan Helm, keduanya adalah satu chart dengan dependency yang sudah dideklarasikan:

kubectl apply -f wordpress/deployment.yaml -f wordpress/service.yaml
kubectl apply -f wordpress/configmap.yaml -f wordpress/ingress.yaml
kubectl apply -f mariadb/statefulset.yaml -f mariadb/service.yaml
kubectl apply -f mariadb/pvc.yaml -f mariadb/secret.yaml

helm install blog bitnami/wordpress
helm upgrade blog bitnami/wordpress --set wordpress.replicaCount=3
helm rollback blog 1

Satu chart, satu perintah, satu titik kontrol untuk seluruh siklus hidup — dan versi yang sama yang sudah dipakai jutaan orang di dunia nyata. Inilah kekuatan yang membuat tim-tim besar mengadopsi Helm sebagai standar packaging: bukan sekadar templating, melainkan memindahkan beban mental dari "mengelola file" ke "mengelola aplikasi".

#Helm vs Alternatif

Helm bukan satu-satunya jawaban — dan memahami posisinya membuat kalian memakai alat yang tepat di tempat yang tepat. Mari bandingkan tiga pendekatan untuk pekerjaan yang sama: mendeploy nginx dengan tiga replica.

kubectl apply -f deployment.yaml -f service.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../base
patches:
  - path: patch-replicas.yaml

helm install nginx bitnami/nginx --set replicaCount=3

Helm vs kubectl apply — kubectl apply murni sempurna untuk beberapa file statis yang jarang berubah. Begitu kalian punya banyak environment, konfigurasi berparameter, dan kebutuhan rollback, kubectl murni tidak memberi alat apa pun untuk mengelolanya. Helm ada justru untuk momen itu.

Helm vs Kustomize — Kustomize (kini bawaan kubectl) mengubah manifest lewat overlay dan patches: base yang sama, overlay per environment. Ia deklaratif, tanpa bahasa templating, dan lebih mudah dipelajari. Perbedaan kuncinya: Kustomize tidak mengemas dan tidak mengelola lifecycle — ia tidak punya konsep release, revision, rollback, atau dependency. Helm punya semuanya, plus bahasa templating (Go template) yang lebih kuat. Banyak tim memakai keduanya sekaligus: Kustomize untuk kustomisasi, Helm untuk packaging.

Helm vs Kubernetes Operator — Operator adalah controller yang mengelola aplikasi kompleks (misalnya database) secara terus-menerus: scaling, backup, upgrade otomatis. Helm adalah alat install — ia mendeploy dan mengelola lifecycle dasar, tapi tidak mengawasi aplikasi berjalan. Jawabannya bukan "salah satu", melainkan "keduanya": banyak operator (misalnya Prometheus Operator) justru di-install memakai Helm.

#Penutup

Pada episode 1 ini kita telah memahami akar masalah deployment di Kubernetes: puluhan file YAML yang terfragmentasi, konfigurasi yang berbeda antar environment, versioning dan rollback yang manual, dependency management yang tidak konsisten, serta hilangnya konsistensi antar tim. Kita juga menelusuri evolusi Helm — dari Deis 2015 (Helm 1), Tiller 2016 (Helm 2) yang kemudian dihapus karena masalah RBAC dan keamanan, hingga Helm 3 yang Tillerless pada 2019 dan diadopsi CNCF sebagai graduated project pada 2020. Kita menutup dengan perbandingan jujur: kubectl untuk manifest statis, Kustomize untuk kustomisasi tanpa packaging, dan Helm untuk packaging plus lifecycle.

Inti yang harus kalian bawa:

• Helm lahir dari manajemen state aplikasi, bukan sekadar "mengurangi jumlah file YAML".
• Tiller dihapus karena menjadi titik kegagalan keamanan — Helm 3 berkomunikasi langsung dengan API server memakai RBAC standar Kubernetes.
• Chart (paket), Release (instance ter-deploy), Repository (registry) adalah tiga konsep inti Helm.
• Helm memberi versioning, rollback, dan dependency yang tidak dimiliki kubectl murni maupun Kustomize.
• Gunakan Helm saat butuh packaging & lifecycle; jangan gunakan untuk manifest yang cukup dikelola langsung.

Sekarang kalian tahu mengapa Helm ada. Di episode 2 selanjutnya kita akan membedah arsitektur dan konsep inti Helm 3: bagaimana client-only bekerja tanpa Tiller, bagaimana release disimpan di dalam Secret, struktur direktori chart yang benar, dan mekanisme three-way strategic merge patch di balik upgrade dan rollback. Sampai jumpa di episode 2!