Belajar Helm Chart - Konfigurasi Chart dengan Values

#Pendahuluan

Setelah di episode 5 sebelumnya kita membahas upgrade, rollback, dan riwayat release — bagaimana perubahan diterapkan dengan aman pada release yang sudah berjalan — pada episode kali ini kita mundur setengah langkah untuk membedah bahan bakar utama seluruh operasi Helm: values.

Mengapa topik ini penting? Bayangkan chart seperti sebuah aplikasi dengan banyak pengaturan, dan values adalah panel kontrolnya — seluruh tombol dan dial yang menentukan perilaku aplikasi. Di dunia nyata, sebagian besar pekerjaan harian seorang DevOps/Platform engineer dengan Helm bukan menulis template Go, melainkan meracik file values yang tepat untuk environment tertentu: berapa replica untuk production, image tag mana yang harus dideploy ke staging, berapa besar CPU yang dialokasikan untuk service X. Kesalahan paling umum di produksi bukan karena template rusak, tapi karena values salah — image salah tag, secret ke-override, atau resource limit yang membuat Pod di-evict. Memahami hierarki precedence dan cara kerja penggabungan values adalah pembeda antara "helm install yang kebetulan jalan" dan "helm install yang bisa dikelola ratusan release".

Di episode ini kita akan membedah hierarki precedence values, berbagai cara menyetel nilai dari CLI, aturan penggabungan beberapa file, struktur file values untuk tipe data kompleks, contoh konfigurasi umum, dan yang terpenting: strategi values per environment yang dipakai tim production.

#Pembahasan Utama

#Hierarki Precedence Values

Helm menentukan nilai akhir sebuah parameter dari tiga lapisan, dari prioritas terendah ke tertinggi:

Aturan praktisnya: semakin spesifik semakin menang. --set menang atas file, file menang atas default chart. Analoginya seperti mengatur AC di gedung: values.yaml adalah suhu default seluruh gedung, file values adalah pengaturan per lantai, dan --set adalah tombol manual yang kalian putar sekarang juga untuk ruangan ini.

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

Pada contoh di atas, image.tag dari --set menimpa nilai image.tag di values.yaml, yang menimpa nilai default di values.yaml bawaan chart. Parameter lain yang tidak disentuh sama sekali jatuh ke nilai terendah yang tersedia.

#Menyetel Values dari CLI: --set, --set-string, --set-file

Tiga flag ini adalah cara Helm menerima nilai langsung dari command line — senjata utama di pipeline CI/CD.

--set mengikuti sintaks path dengan titik, dan bisa menggabungkan beberapa nilai sekaligus dengan koma:

helm upgrade --install frontend bitnami/nginx \
  --set image.tag=1.27.0,replicaCount=3 \
  --set resources.requests.cpu=250m,resources.requests.memory=512Mi

Nilai yang berbentuk angka (seperti 3 dan 250m) dan true/false akan diinterpretasikan sebagai tipe datanya, bukan string. List bisa ditulis dengan kurung kurawal: --set providers={gcp,aws,azure} menghasilkan list tiga item. Nilai yang mengandung koma atau karakter khusus perlu di-escape, dan untuk key yang mengandung titik literal, gunakan backslash: --set nodeSelector."kubernetes\.io/os"=linux.

--set-string memaksa setiap nilai diperlakukan sebagai string, apa pun bentuknya. Ini penting untuk nilai yang tampak numerik tapi harus menjadi string — misalnya kode versi 1.0 yang akan kehilangan nol di belakang jika diparsing sebagai angka, atau nomor telepon.

helm upgrade --install frontend bitnami/nginx \
  --set-string app.version=1.0 \
  --set-string http.cors.origins="https://a.com,https://b.com"

--set-file membaca isi sebuah file sebagai nilai — biasanya untuk menanamkan content file (misalnya konfigurasi nginx.conf atau kunci publik) langsung ke template yang dirender sebagai multiline string:

helm upgrade --install frontend bitnami/nginx \
  --set-file nginx.conf=/etc/nginx/custom.conf

#Beberapa File Values & Urutan Penggabungan

Helm menerima banyak file -f, dan file yang disebut belakangan menang atas file yang disebut lebih dulu. Nilai default chart selalu menjadi lapisan paling bawah, di bawah semua file:

helm upgrade --install frontend bitnami/nginx \
  --namespace web \
  --values values-common.yaml \
  --values values-web.yaml \
  --values secrets-placeholder.yaml

Alur bacaannya: render dimulai dari values.yaml chart → timpa dengan values-common.yaml → timpa lagi dengan values-web.yaml → timpa dengan secrets-placeholder.yaml. Pemetaan deep merge berlaku: jika values-common.yaml menetapkan replicaCount: 2 dan values-web.yaml menetapkan replicaCount: 5, hasil akhirnya 5 — tapi jika values-web.yaml hanya menyetel image.tag, nilai replicaCount dari values-common.yaml tetap dipertahankan.

Pola "base + override" ini adalah fondasi strategi environment yang akan kita bahas sebentar lagi. Bayangkan seperti memasak dengan resep dasar lalu menyesuaikan bumbu per menu: file pertama berisi bahan yang sama untuk semua menu, file berikutnya hanya berisi perbedaan untuk menu tertentu.

#Struktur File Values: Nested YAML, List, Data Kompleks

File values adalah YAML biasa, dan karena YAML mendukung struktur bersarang, values bisa menampung konfigurasi yang sangat ekspresif:

replicaCount: 3
 
image:
  repository: ghcr.io/company/frontend
  tag: "1.27.0"
  pullPolicy: IfNotPresent
 
resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 1Gi
 
service:
  type: ClusterIP
  port: 80
  annotations:
    prometheus.io/scrape: "true"
 
ingress:
  enabled: true
  hosts:
    - host: app.company.com
      paths:
        - path: /
          pathType: Prefix
 
env:
  LOG_LEVEL: info
  ALLOWED_ORIGINS:
    - https://web.company.com
    - https://api.company.com
 
labels:
  team: platform
  cost-center: core

Perhatikan tipe-tipe yang muncul: nested map (resources.requests.cpu), list of maps (ingress.hosts dengan elemen berisi host dan paths), list of strings (env.ALLOWED_ORIGINS), dan boolean/string yang disengaja — nilai tag: "1.27.0" dikutip agar tidak diinterpretasikan sebagai angka. Konsistensi tipe ini penting karena template mengaksesnya dengan .Values.<path> dan error tipe adalah salah satu penyebab paling umum helm template gagal di render.

#Konfigurasi Umum pada Chart Production

Meski tiap chart berbeda, ada lima kelompok konfigurasi yang hampir selalu di-set saat mendeploy aplikasi production:

• Image & tag — registry, nama image, tag versi, dan pullPolicy. Pastikan tag adalah string, dan untuk production sebaiknya pullPolicy: IfNotPresent (image lokal sudah ter-pull) atau Always untuk commit hash yang sering berubah.
• Resource limits/requests — ini yang pertama ditanya reviewer production: berapa CPU dan memori yang dijamin (requests) dan maksimum (limits). Requests menentukan penjadwalan Pod, limits menentukan kapan kernel/kubernetes membatasi.
• Replica count — jumlah Pod; naik untuk high availability, turun di development untuk hemat resource.
• Service type — ClusterIP (internal), NodePort (akses dari luar via port node), LoadBalancer (cloud LB), atau ClusterIP + Ingress (pola paling umum).
• Ingress host — domain publik + TLS; biasanya inilah yang paling berbeda antar environment.

Semua ini hanyalah interface — chart yang baik mendokumentasikannya di README dan values.yaml bawaan dengan komentar. Tugas kalian sebagai pengguna chart adalah memilih nilai yang tepat per environment.

#Values per Environment: values-dev, values-staging, values-prod

Chart itu satu, environment banyak. Nilai yang sama untuk production (replica 6, memory 2Gi, host app.company.com) jelas tidak cocok untuk development (replica 1, memory 256Mi, host app-dev.company.com). Pola standar industri adalah memisahkan perbedaan itu ke file values per environment:

replicaCount: 1
image:
  tag: "dev"
  pullPolicy: Always
resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    cpu: 250m
    memory: 512Mi
ingress:
  enabled: true
  hosts:
    - host: app-dev.company.com

replicaCount: 2
image:
  tag: "staging"
  pullPolicy: Always
resources:
  requests:
    cpu: 200m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 1Gi
ingress:
  enabled: true
  hosts:
    - host: app-staging.company.com

replicaCount: 6
image:
  tag: "1.27.0"
  pullPolicy: IfNotPresent
resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: "2"
    memory: 2Gi
ingress:
  enabled: true
  hosts:
    - host: app.company.com

Cara memakainya di CI/CD sederhana: helm upgrade --install frontend ... --values values-prod.yaml. Perhatikan bahwa file per environment hanya berisi perbedaan — nilai yang sama semua environment cukup diletakkan di values.yaml bawaan chart atau di file values-common.yaml yang dimuat lebih dulu.

Beberapa strategi organisasi yang dipakai tim production:

• File values per environment di repo aplikasi. Satu direktori berisi values-dev.yaml, values-staging.yaml, values-prod.yaml, plus values-common.yaml sebagai basis. Sederhana, transparan, dan bisa di-review dalam satu PR.
• Override tipis dengan --set di pipeline. Nilai yang benar-benar spesifik build (image tag hasil CI, git commit SHA) di-set langsung, sementara konfigurasi statis diletakkan di file. Contoh: --set image.tag=$CI_COMMIT_SHA.
• Secret tidak pernah masuk ke file values biasa. Nilai rahasia (password, token, kunci) ditangani terpisah — melalui Secret Kubernetes, Vault, External Secrets, atau mekanisme yang akan kita bahas di series keamanan. File values yang di-commit hanya berisi placeholder.
• Satu chart, banyak release. Untuk environment yang benar-benar berbeda (misalnya cluster berbeda), beberapa tim membuat release terpisah per namespace dengan nama berbeda (frontend-prod, frontend-staging) — release yang sama pada chart yang sama, nilai yang berbeda.

#Memverifikasi Values yang Berlaku

Setelah memahami cara menyetel values, satu disiplin yang sering dilewatkan: memverifikasi apa yang benar-benar berlaku. Karena precedence bisa mengaburkan dari mana sebuah nilai berasal, jangan pernah menebak hasil akhir — tanyakan langsung ke release:

helm get values frontend --namespace web
helm get values frontend --namespace web --all

Perintah pertama hanya menampilkan nilai yang berbeda dari default chart (yang di-set via -f/--set); opsi --all menampilkan seluruh nilai efektif setelah penggabungan — inilah "kebenaran final" yang akan dirender oleh template. Untuk melengkapi audit, helm get manifest frontend --namespace web menampilkan manifest hasil render yang sebenarnya dikirim ke cluster.

Kapan ini penting? Dua momen kritis. Pertama, setelah upgrade — untuk memastikan override yang kalian pikir berhasil ternyata tidak ditimpa file lain yang disebut belakangan. Kedua, saat meneruskan release antar engineer: sebelum menyentuh release orang lain, baca dulu helm get values-nya agar kalian tidak menginjak nilai yang sengaja disetel sebelumnya. Ini adalah kebiasaan audit yang sama seperti membaca diff sebelum merge — murah, tapi menyelamatkan banyak insiden.

#Penutup

Pada episode 6 ini kita telah membedah bahwa values adalah lapisan konfigurasi yang ditentukan oleh hierarki precedence: values.yaml bawaan chart sebagai dasar, file -f sebagai override sedang, dan --set/--set-string/--set-file sebagai override tertinggi. Kita mempelajari aturan penggabungan — deep merge untuk map, replace total untuk list — cara menyetel nilai dari CLI dengan aman, struktur file values untuk nested YAML dan data kompleks, lima kelompok konfigurasi umum (image, resource, replica, service type, ingress host), serta strategi values-dev.yaml, values-staging.yaml, dan values-prod.yaml dengan pola base + override.

Inti yang harus kalian bawa:

• Semakin spesifik sumber values, semakin tinggi prioritasnya: default < file < --set.
• List diganti seluruhnya, bukan digabung; map digabung secara deep.
• --set-string untuk nilai yang harus string; --set-file untuk menanamkan content file.
• File values yang disebut belakangan menang; pakai pola base + per-environment.
• Secret tidak pernah di-commit dalam file values; pisahkan nilai rahasia dari konfigurasi biasa.

Sekarang kalian paham cara mengendalikan chart dari luar. Di episode 7 selanjutnya kita membalik perspektif — dari pengguna chart menjadi penulis chart: membuat chart pertama. Kita akan membedah helm create, struktur direktori yang dihasilkan, file Chart.yaml sebagai metadata, desain values.yaml yang baik, template dasar Deployment/Service/ConfigMap, serta cara menguji chart dengan helm lint, helm template, dan helm install --dry-run. Sampai jumpa di episode 7!