Belajar Helm Chart - Pre-Requisites Skill & Setup Environment

#Pendahuluan

Selamat datang di series Belajar Helm Chart! Series ini akan membawa kalian dari nol hingga mampu membangun chart Helm production-grade dan mengelola aplikasi di Kubernetes secara profesional. Total 30 episode yang saling membangun: prasyarat dan setup environment, sejarah mengapa Helm lahir, arsitektur Helm 3, dasar-dasar CLI, manajemen release, upgrade dan rollback, konfigurasi values, membangun chart sendiri, Go template, dependencies, hooks, JSON Schema, testing, dokumentasi, packaging, repository, OCI registry, hingga integrasi CI/CD dan GitOps.

Mengapa Helm begitu penting? Kubernetes menyelesaikan orkestrasi container dengan luar biasa, tapi meninggalkan masalah baru: manajemen puluhan file YAML secara manual. Aplikasi production bukan satu Deployment — ia terdiri atas Deployment, Service, ConfigMap, Secret, Ingress, HorizontalPodAutoscaler, dan ServiceAccount yang harus konsisten di environment dev, staging, dan production. Helm membungkus semuanya menjadi satu paket yang bisa di-install, di-upgrade, dan di-rollback dengan satu perintah. DevOps Engineer yang tidak mengenal Helm seperti frontend developer yang menulis seluruh styling sebagai inline style: bisa berjalan, tapi mustahil dipertahankan di skala tim dan skala sistem.

Episode 0 ini adalah peta jalan. Sebelum menyentuh Helm, kita memastikan lima hal: (1) skill Kubernetes yang wajib kalian kuasai, (2) kebiasaan kubectl yang nyaman di jari, (3) pemahaman YAML sebagai bahasa manifest, (4) mental model package manager yang akan membuat Helm terasa familier, dan (5) cluster Kubernetes lengkap dengan kubectl dan Helm CLI yang sudah terverifikasi. Semua episode berikutnya berasumsi fondasi ini sudah berdiri kokoh. Mari mulai.

#Skill Kubernetes yang Wajib Kalian Kuasai

Helm tidak menggantikan Kubernetes — ia berada di atas Kubernetes. Semua yang Helm install pada akhirnya adalah resource Kubernetes biasa: Pod, Deployment, Service, dan seterusnya. Jika kalian tidak memahami apa yang Helm ciptakan, kalian tidak akan bisa membaca output helm get manifest, mendebug kegagalan install, atau menilai apakah sebuah chart aman untuk dipakai. Inilah resource yang wajib kalian pahami sebelum lanjut.

Pahami bukan hanya definisinya, tapi hubungan antar resource: Ingress → Service → Deployment → Pod → ConfigMap/Secret. Inilah alur yang akan kalian lihat di hampir semua chart Helm. Coba buat sendiri di lab: sebuah Deployment nginx yang membaca index.html dari ConfigMap, diekspos lewat Service, lalu dilindungi Ingress. Jika kalian bisa menjelaskan alur itu tanpa membuka catatan, fondasi kalian sudah kuat.

#Kebiasaan kubectl yang Harus Lancar

Helm menjembatani kalian dengan Kubernetes API server — tetapi kubectl adalah tangan kanan untuk verifikasi. Ketika Helm bilang "release terinstall", kalian tidak langsung percaya; kalian verifikasi dengan kubectl. Kuasai perintah-perintah berikut sampai mengalir tanpa berpikir:

Sebagian besar debugging di series ini mengikuti pola yang sama: helm install → gagal → kubectl get pods → Pod CrashLoopBackOff → kubectl describe pod → baca bagian Events → kubectl logs → temukan akar masalah. Jika alur ini masih terasa asing, latih dulu di episode ini.

#YAML: Bahasa Dasar Manifest Kubernetes

Semua resource Kubernetes ditulis dalam YAML — dan semua chart Helm pada akhirnya merender YAML. Dua konsep YAML yang wajib kalian kuasai: mapping (pasangan key-value, ditandai indentasi) dan sequence (list, ditandai tanda hubung). Indentasi adalah segalanya — YAML tidak mengenal tab, dan dua spasi adalah konvensi Kubernetes.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  labels:
    app: nginx-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Perhatikan strukturnya: apiVersion, kind, metadata, dan spec adalah mapping. Di bawah containers ada sequence (tanda hubung), dan setiap item-nya adalah mapping. Kelak, ketika Helm merender template, output akhirnya berbentuk persis seperti ini — bedanya, bagian yang berubah (nama, image, jumlah replica) diambil dari variable template, bukan ditulis manual.

#Mental Model: Package Manager & Templating

Kalian mungkin sudah akrab dengan npm untuk JavaScript atau pip untuk Python. Helm dibangun di atas mental model yang sama — dan inilah kunci agar pemahaman kalian cepat terbentuk:

• Chart ≈ paket — kumpulan file (manifest + metadata) yang bisa didistribusikan, seperti package .tgz di npm.
• Repository ≈ registry npm / PyPI — tempat chart disimpan dan diambil.
• Release ≈ instalasi — satu chart yang ter-install di cluster dengan nama unik; bisa di-uninstall tanpa memengaruhi chart asalnya.
• Version chart ≈ semantic version — mengikuti aturan MAJOR.MINOR.PATCH.
• Values ≈ variabel konfigurasi saat install — seperti opsi konfigurasi saat menjalankan perintah install.

Perbedaan penting dengan npm: npm mengelola library yang dieksekusi di dalam program; Helm mengelola infrastruktur deklaratif — file YAML yang dikirim ke API server Kubernetes. Tapi pola mentalnya identik: satu perintah untuk install, satu perintah untuk upgrade, satu perintah untuk uninstall, dan sebuah "registry" untuk berbagi paket.

#Menyiapkan Kubernetes Cluster

Kalian butuh cluster Kubernetes untuk latihan. Untuk series ini, cluster lokal lebih dari cukup — bahkan lebih baik karena murah, cepat, dan aman untuk dihancurkan berkali-kali. Pilihannya:

Rekomendasi untuk series ini: Minikube untuk pemula, atau Kind jika kalian sudah nyaman dengan Docker. Keduanya menjalankan Kubernetes asli (bukan simulasi) — semua perintah Helm di series ini bekerja identik di cluster lokal maupun produksi.

#Instalasi & Verifikasi kubectl

kubectl adalah CLI resmi Kubernetes — jembatan pertama kalian ke cluster. Instalasi paling portabel lewat binary resmi, tapi manajer paket juga valid:

Opsi 1: Binary resmi (Linux)Opsi 2: Manajer paket (Ubuntu/Debian)

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

sudo apt update && sudo apt install -y kubectl
kubectl version --client

Perhatikan kubectl version memiliki dua bagian output: Client Version dan Server Version. Saat baru menginstal, bagian server belum ada karena cluster belum dibuat. Yang penting saat ini: Client Version tampil dan versinya berjarak maksimal satu versi minor dari versi server kelak. Setelah cluster siap, verifikasi koneksi:

Verifikasi koneksi ke cluster

kubectl version
kubectl cluster-info
kubectl get nodes

Output kubectl cluster-info menampilkan URL API server, dan kubectl get nodes menunjukkan node yang Ready — tanda resmi bahwa kubectl kalian sudah bisa berbicara dengan cluster.

#Instalasi & Verifikasi Helm CLI

Helm 3 adalah satu binary client tanpa daemon server — setelah terpasang, ia langsung siap dipakai. Cara tercepat dan paling banyak dipakai di mesin lokal adalah script installer resmi (pembahasan lengkap semua metode ada di episode 3):

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
helm version

helm version menampilkan versi client Helm beserta versi Go yang dipakai membangunnya, contohnya version.BuildInfo{Version:"v3.16.0"}. Pastikan angka utama (major) adalah 3 — seluruh series ini memakai Helm 3. Berbeda dengan kubectl, Helm tidak punya bagian "server version" karena ia berkomunikasi langsung dengan API server Kubernetes melalui kubeconfig yang sama dengan kubectl.

#Alat Pendukung: kubeconform, jq, Git, dan Editor

Selain kubectl dan Helm, siapkan alat pendukung berikut:

• kubeconform — validator manifest Kubernetes terhadap skema resmi. Kelak kita pakai untuk memvalidasi output render Helm sebelum di-apply ke cluster. Instalasi: go install github.com/yannh/kubeconform/cmd/kubeconform@latest atau binary dari halaman release GitHub.
• jq — JSON processor untuk terminal, dipakai mem-parsing output -o json dari kubectl maupun Helm. Instalasi: sudo apt install -y jq.
• Git — wajib untuk versioning chart dan mengikuti pola kerja tim. Pastikan git version merespons.
• Editor: VS Code dengan ekstensi Helm dan YAML (tambah skema Kubernetes untuk autocompletion manifest), atau Neovim dengan helm-language-server dan yaml-language-server.

kubeconform -v
jq --version
git --version
echo "Tools OK"

#Verifikasi Environment: Pod Pertama di Cluster

Inilah "tes tensi" episode ini: jalankan pod pertama di cluster dan pastikan semuanya bekerja dari hulu ke hilir — kubectl berbicara ke API server, scheduler menempatkan pod, kubelet menarik image dan menjalankan container.

Jalankan pod pertama dan amati

kubectl create deployment hello-k8s --image=nginx:1.27
kubectl get pods
kubectl port-forward deployment/hello-k8s 8080:80

Buka http://localhost:8080 — jika halaman selamat datang nginx muncul, environment kalian resmi siap untuk seluruh series. kubectl port-forward adalah keterampilan yang akan kalian pakai berulang kali di episode-episode berikutnya untuk mengakses aplikasi di dalam cluster tanpa mengeksposnya ke publik. Setelah selesai, bersihkan lab:

kubectl delete deployment hello-k8s

#Kesalahan Umum (Common Pitfalls)

1. Cluster belum siap tapi kubectl sudah dipakai. Error The connection to the server localhost:8080 was refused. Solusi: buat cluster dulu (minikube start atau kind create cluster), lalu cek kubectl config current-context.
2. Konsep Pod/Deployment/Service yang masih abu-abu. Jika tidak paham bedanya, semua episode debugging nanti terasa seperti teka-teki. Perkuat dengan latihan sebelum lanjut.
3. Melewatkan verifikasi. Tidak menjalankan pod pertama berarti tidak tahu apakah environment benar-benar berfungsi. Jangan pernah melanjutkan series dengan environment yang belum teruji.
4. RAM minimal tidak terpenuhi. Cluster lokal akan sering crash. Naikkan alokasi RAM VM Minikube dengan minikube start --memory 4096 atau tambah RAM mesin.
5. Mengabaikan jq dan kubeconform. Keduanya perpanjangan tangan produktivitas: kubeconform menyelamatkan kalian dari typo field YAML; jq dari membaca output JSON raksasa secara manual.

#Penutup

Di episode 0 ini kalian telah memastikan lima fondasi: skill Kubernetes (Pod, Deployment, Service, ConfigMap, Secret, Namespace, Ingress beserta alurnya), kebiasaan kubectl (get, describe, apply, logs, port-forward), pemahaman YAML sebagai bahasa manifest, mental model package manager (Chart ≈ paket, Repository ≈ registry, Release ≈ instalasi), serta cluster lokal dengan kubectl dan Helm CLI yang terverifikasi — dibuktikan dengan pod pertama yang berhasil berjalan.

Poin yang harus kalian bawa:

• Helm berada di atas Kubernetes — semua yang ia install tetap resource Kubernetes biasa.
• kubectl adalah alat verifikasi, Helm adalah alat kemasan. Dua-duanya wajib dikuasai.
• YAML adalah bahasa manifest; indentasi adalah segalanya.
• Mental model npm/pip mempercepat pemahaman Chart, Repository, dan Release.
• Environment yang belum terverifikasi adalah bom waktu di series ini.

Ingat, series Belajar Helm Chart terdiri dari 30 episode yang saling membangun. Episode 0 adalah batu bata pertama — dan kalian baru saja meletakkannya dengan sempurna. Di episode 1 selanjutnya kita mundur sejenak untuk memahami sejarah, latar belakang, dan mengapa Helm lahir: tantangan deployment di Kubernetes, evolusi dari Helm 1 ke Helm 3, kisah Tiller yang dihapus karena masalah keamanan, serta perbandingan jujur Helm melawan Kustomize dan kubectl murni. Sampai jumpa di episode 1, dan selamat membangun laboratorium Kubernetes kalian!