Fundamental Helm Chart - Mengapa Ia Ada, Sejarah, dan Konsep Inti

#Pengenalan

Helm Charts ada karena manifest Kubernetes itu verbose, repetitif, dan sulit dikelola dalam skala besar. Ketika Anda menerapkan aplikasi ke Kubernetes, Anda menulis file YAML yang mendefinisikan pod, service, deployment, dan banyak lagi. Tetapi apa yang terjadi ketika Anda perlu menerapkan aplikasi yang sama di berbagai lingkungan? Atau ketika Anda perlu berbagi aplikasi dengan orang lain? Atau ketika Anda perlu mengelola puluhan layanan yang saling bergantung?

Helm menyelesaikan masalah ini dengan memperlakukan aplikasi Kubernetes sebagai paket. Ini adalah package manager untuk Kubernetes, mirip dengan npm untuk Node.js atau pip untuk Python. Helm Charts adalah manifest Kubernetes yang dapat digunakan kembali, bertemplat yang dapat diversi, dibagikan, dan digunakan secara konsisten.

Dalam artikel ini, kami akan mengeksplorasi mengapa Helm ada, sejarahnya, masalah yang dipecahkannya, dan cara menggunakannya secara efektif dalam skenario dunia nyata.

#Daftar Isi

#Mengapa Helm Charts Ada

#Masalah Manifest Kubernetes

Sebelum Helm, mengelola aplikasi Kubernetes berarti menangani beberapa masalah sulit:

1. Pengulangan - Menulis struktur YAML yang sama untuk setiap deployment
2. Manajemen konfigurasi - Nilai berbeda untuk dev, staging, dan produksi
3. Manajemen dependensi - Mengkoordinasikan deployment layanan terkait
4. Versioning - Tidak ada cara bawaan untuk memversi rilis aplikasi
5. Berbagi - Sulit untuk berbagi aplikasi dengan tim lain atau komunitas
6. Update - Prosedur rollback dan upgrade yang kompleks
7. Templating - Tidak ada cara untuk parameterisasi manifest tanpa alat eksternal

Tim baik menulis script khusus, menggunakan kustomize, atau mengelola ratusan file YAML secara manual. Ini rawan kesalahan dan tidak skalabel.

#Jawaban Helm

Helm menyediakan:

• Templating - Gunakan template Go untuk parameterisasi manifest
• Packaging - Bundel sumber daya terkait menjadi satu unit
• Versioning - Lacak versi aplikasi dan rilis
• Manajemen dependensi - Deklarasikan dan kelola dependensi layanan
• Repositories - Bagikan dan temukan chart secara publik atau pribadi
• Manajemen lifecycle - Install, upgrade, rollback dengan perintah tunggal
• Manajemen nilai - Ganti konfigurasi tanpa mengedit template

Filosofinya: aplikasi Kubernetes harus semudah menginstal software di laptop Anda.

#Sejarah dan Evolusi

#Helm v1 (2015-2016)

Helm dimulai sebagai proyek sampingan di Deis (kemudian diakuisisi oleh Microsoft) pada tahun 2015. Tujuan awal sederhana: buat package manager untuk Kubernetes. Helm awal bersifat eksperimental dan memiliki keterbatasan.

Karakteristik utama:

• Templating dasar dengan template Go
• Struktur chart sederhana
• Manajemen dependensi terbatas
• Tidak ada sistem repository bawaan
• Tiller (komponen server) diperlukan untuk deployment

#Helm v2 (2016-2020)

Helm v2 menjadi standar. Ini memperkenalkan:

• Tiller - Komponen server yang berjalan di cluster
• Releases - Instance bernama dari chart
• Repositories - Registry pusat untuk berbagi chart
• Hooks - Aksi pre/post deployment
• Subcharts - Manajemen dependensi
• Values files - Manajemen konfigurasi

Helm v2 kuat tetapi memiliki masalah. Tiller memerlukan izin di seluruh cluster, menciptakan kekhawatiran keamanan. Arsitekturnya kompleks.

#Helm v3 (2019-Sekarang)

Helm v3 adalah redesign besar yang mengatasi masalah v2:

• Menghapus Tiller - Arsitektur hanya klien, tidak ada komponen server
• Keamanan lebih baik - Menggunakan kubeconfig untuk autentikasi
• Manajemen dependensi lebih baik - File Chart.lock yang lebih bersih
• Pelacakan rilis disederhanakan - Menggunakan secret Kubernetes bukan ConfigMaps
• Validasi ditingkatkan - Pesan kesalahan dan validasi yang lebih baik

Helm v3 adalah standar saat ini dan yang akan kami fokuskan.

#Mengapa Helm Penting Hari Ini

Meskipun kompleksitas Kubernetes, Helm tetap penting karena:

1. Standardisasi - Cara umum untuk mengemas dan berbagi aplikasi
2. Ekosistem - Ribuan chart publik tersedia
3. Kesederhanaan - Mengurangi boilerplate dan konfigurasi manual
4. Konsistensi - Proses deployment yang sama di berbagai lingkungan
5. Komunitas - Komunitas besar dan dokumentasi ekstensif

#Konsep Inti

#Charts

Chart adalah paket manifest Kubernetes. Ini adalah direktori dengan struktur spesifik yang berisi:

• Chart.yaml - Metadata (nama, versi, deskripsi)
• values.yaml - Nilai konfigurasi default
• templates/ - File template Go untuk sumber daya Kubernetes
• charts/ - Chart dependensi (subcharts)
• README.md - Dokumentasi
• LICENSE - Informasi lisensi

Chart diversi dan dapat disimpan di repository.

#Releases

Release adalah instance yang berjalan dari Chart. Ketika Anda menginstal Chart, Helm membuat Release. Anda dapat memiliki beberapa Release dari Chart yang sama dengan konfigurasi berbeda.

Contoh: Anda mungkin memiliki tiga Release dari Chart nginx - satu untuk dev, satu untuk staging, satu untuk produksi.

#Values

Values adalah parameter konfigurasi yang menyesuaikan Chart. Mereka didefinisikan dalam values.yaml dan dapat diganti saat install/upgrade.

Values menggunakan notasi titik untuk akses bersarang: image.repository, image.tag, replicaCount.

#Templates

Templates adalah file template Go yang menghasilkan manifest Kubernetes. Mereka menggunakan variabel, kondisional, loop, dan fungsi untuk membuat YAML dinamis.

Contoh template:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: app
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

#Repositories

Repositories adalah koleksi Charts. Mereka mirip dengan registry npm atau registry Docker. Anda dapat menambahkan repository publik atau menghosting yang pribadi.

Repository publik umum:

• Bitnami - Chart siap produksi
• Stable - Chart Kubernetes resmi (deprecated)
• Jetstack - Cert-manager dan alat terkait
• Prometheus Community - Stack monitoring

#Hooks

Hooks adalah aksi yang berjalan pada titik spesifik dalam lifecycle rilis:

• pre-install - Sebelum instalasi chart
• post-install - Setelah instalasi chart
• pre-upgrade - Sebelum upgrade
• post-upgrade - Setelah upgrade
• pre-delete - Sebelum penghapusan
• post-delete - Setelah penghapusan
• pre-rollback - Sebelum rollback
• post-rollback - Setelah rollback

Hooks berguna untuk migrasi database, pembersihan, atau validasi.

#Subcharts

Subcharts adalah Charts yang bergantung pada Charts lain. Mereka dideklarasikan dalam Chart.yaml dan disimpan di direktori charts/.

Ini memungkinkan:

• Reusability - Bagikan komponen umum
• Modularity - Pisahkan kekhawatiran
• Versioning - Kontrol versi dependensi

#Cara Kerja Helm

#Rendering Template

Ketika Anda menginstal Chart, Helm:

1. Membaca struktur Chart
2. Memuat nilai dari values.yaml dan override baris perintah
3. Render template menggunakan mesin template Go
4. Validasi manifest yang dihasilkan
5. Kirim manifest ke API Kubernetes

#Manajemen Release

Helm melacak Releases menggunakan secret Kubernetes. Setiap Release memiliki:

• Name - Pengidentifikasi unik
• Namespace - Namespace Kubernetes
• Status - deployed, superseded, failed, dll
• Revision - Nomor versi rilis
• Chart - Nama dan versi chart
• Values - Konfigurasi yang digunakan

Ini memungkinkan upgrade dan rollback.

#Resolusi Dependensi

Helm menyelesaikan dependensi dengan:

1. Membaca dependensi Chart.yaml
2. Mengunduh chart yang diperlukan
3. Menggabungkan nilai dari parent dan subcharts
4. Render semua template dalam urutan dependensi

#Implementasi Praktis

#Menginstal Helm

Di Linux/macOS:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Verifikasi instalasi:

helm version

#Menambahkan Repositories

Tambahkan repository Bitnami:

helm repo add bitnami https://charts.bitnami.com/bitnami

Update repositories:

helm repo update

Daftar repositories:

helm repo list

#Mencari Charts

Cari chart yang tersedia:

helm search repo nginx

Dapatkan informasi chart:

helm show chart bitnami/nginx

Lihat nilai default:

helm show values bitnami/nginx

#Menginstal Chart

Instal dengan nilai default:

helm install my-nginx bitnami/nginx

Instal dengan nilai khusus:

helm install my-nginx bitnami/nginx \
  --set replicaCount=3 \
  --set image.tag=1.25

Instal dari file nilai:

helm install my-nginx bitnami/nginx -f values.yaml

#Mengelola Releases

Daftar releases:

helm list

Dapatkan status rilis:

helm status my-nginx

Lihat nilai rilis:

helm get values my-nginx

#Upgrade Releases

Upgrade ke versi baru:

helm upgrade my-nginx bitnami/nginx \
  --set replicaCount=5

#Rollback

Rollback ke rilis sebelumnya:

helm rollback my-nginx 1

#Uninstalling

Hapus rilis:

helm uninstall my-nginx

#Membuat Chart Pertama Anda

#Struktur Chart

Buat chart baru:

helm create my-app

Ini menghasilkan:

my-app/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl
│   └── NOTES.txt
└── README.md

#Chart.yaml

Tentukan metadata chart:

Chart.yaml

apiVersion: v2
name: my-app
description: A Helm chart for my application
type: application
version: 1.0.0
appVersion: "1.0"
maintainers:
  - name: Your Name
    email: your@email.com

#values.yaml

Tentukan konfigurasi default:

values.yaml

replicaCount: 3
 
image:
  repository: myregistry/my-app
  tag: "1.0"
  pullPolicy: IfNotPresent
 
service:
  type: ClusterIP
  port: 80
  targetPort: 8080
 
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: my-app.example.com
      paths:
        - path: /
          pathType: Prefix
 
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi
 
autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

Expand code

#Template Deployment

Buat templates/deployment.yaml:

templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-app.fullname" . }}
  labels:
    {{- include "my-app.labels" . | nindent 4 }}
spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicaCount }}
  {{- end }}
  selector:
    matchLabels:
      {{- include "my-app.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-app.selectorLabels" . | nindent 8 }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - name: http
          containerPort: {{ .Values.service.targetPort }}
          protocol: TCP
        resources:
          {{- toYaml .Values.resources | nindent 12 }}

Expand code

#Template Service

Buat templates/service.yaml:

templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ include "my-app.fullname" . }}
  labels:
    {{- include "my-app.labels" . | nindent 4 }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "my-app.selectorLabels" . | nindent 4 }}

#Validasi Chart

Lint chart:

helm lint my-app

Dry-run untuk melihat manifest yang dihasilkan:

helm install my-app ./my-app --dry-run --debug

#Kesalahan Umum dan Jebakan

#Kesalahan 1: Hardcoding Values

Masalah: Nilai dikodekan keras dalam template, membuat chart tidak fleksibel.

Mengapa terjadi: Developer lupa untuk parameterisasi konfigurasi.

Solusi: Pindahkan semua nilai yang dapat dikonfigurasi ke values.yaml:

Baik - parameterisasi

replicaCount: {{ .Values.replicaCount }}

Bukan:

Buruk - hardcoded

replicaCount: 3

#Kesalahan 2: Mengabaikan Konvensi Helm

Masalah: Chart tidak mengikuti konvensi Helm, membingungkan pengguna.

Mengapa terjadi: Developer membuat chart tanpa mempelajari contoh.

Solusi: Ikuti praktik terbaik Helm:

• Gunakan _helpers.tpl untuk helper template
• Beri nama template secara konsisten
• Dokumentasikan nilai dalam komentar
• Gunakan label standar

#Kesalahan 3: Batas Sumber Daya Hilang

Masalah: Pod mengonsumsi sumber daya tanpa batas, menyebabkan ketidakstabilan cluster.

Mengapa terjadi: Batas sumber daya dilupakan selama pengembangan.

Solusi: Selalu tentukan permintaan dan batas sumber daya:

Chart dengan batas sumber daya

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

#Kesalahan 4: Tidak Memversi Charts

Masalah: Perubahan chart tidak dilacak, membuat rollback sulit.

Mengapa terjadi: Developer memperbarui chart tanpa menaikkan versi.

Solusi: Ikuti semantic versioning:

Chart.yaml dengan versioning

version: 1.2.3
appVersion: "2.0"

Naikkan versi untuk setiap rilis.

#Kesalahan 5: Manajemen Dependensi Kompleks

Masalah: Terlalu banyak subcharts menciptakan beban pemeliharaan.

Mengapa terjadi: Developer mencoba membuat satu chart melakukan segalanya.

Solusi: Jaga chart tetap fokus dan sederhana. Gunakan subcharts untuk komponen yang benar-benar dapat digunakan kembali.

#Praktik Terbaik

#1. Gunakan Semantic Versioning

Ikuti semver untuk versi chart:

Chart.yaml dengan semver

version: 1.2.3
appVersion: "2.0.1"

• Major - Perubahan breaking
• Minor - Fitur baru, backward compatible
• Patch - Bug fixes

#2. Dokumentasikan Semuanya

Sertakan dokumentasi komprehensif:

Chart.yaml dengan dokumentasi

apiVersion: v2
name: my-app
description: A production-ready application
home: https://github.com/myorg/my-app
sources:
  - https://github.com/myorg/my-app
maintainers:
  - name: Your Name
    email: your@email.com
keywords:
  - app
  - production

#3. Gunakan Helm Hooks untuk Manajemen Lifecycle

Jalankan migrasi database sebelum deployment:

Pre-install hook untuk migrasi

apiVersion: batch/v1
kind: Job
metadata:
  name: {{ include "my-app.fullname" . }}-migrate
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "-5"
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        command: ["./migrate.sh"]
      restartPolicy: Never

#4. Implementasikan Health Checks

Tentukan liveness dan readiness probes:

Deployment dengan health checks

containers:
- name: app
  image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
  livenessProbe:
    httpGet:
      path: /health
      port: http
    initialDelaySeconds: 30
    periodSeconds: 10
  readinessProbe:
    httpGet:
      path: /ready
      port: http
    initialDelaySeconds: 5
    periodSeconds: 5

#5. Gunakan ConfigMaps dan Secrets

Pisahkan konfigurasi dari kode:

Template ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-app.fullname" . }}-config
data:
  app.conf: |
    {{ .Values.appConfig | nindent 4 }}

#6. Test Charts Secara Menyeluruh

Gunakan helm test untuk validasi:

Template test pod

apiVersion: v1
kind: Pod
metadata:
  name: "{{ include \"my-app.fullname\" . }}-test\"
  annotations:
    "helm.sh/hook": test
spec:
  containers:
  - name: test
    image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
    command: ["./test.sh"]
  restartPolicy: Never

#Kapan TIDAK Menggunakan Helm

#Helm tidak ideal untuk:

1. Deployment layanan tunggal sederhana - Overkill untuk aplikasi dasar
2. Aplikasi yang sangat dikustomisasi - Terlalu banyak kompleksitas templating
3. Tim yang tidak familiar dengan Kubernetes - Menambah lapisan kompleksitas lain
4. Aplikasi yang memerlukan kustomisasi ekstensif - Pertimbangkan Kustomize sebagai gantinya

#Kapan Helm bersinar:

• Aplikasi multi-service
• Berbagi aplikasi dengan orang lain
• Mengelola berbagai lingkungan
• Manajemen dependensi kompleks
• Deployment produksi

#Kasus Penggunaan Dunia Nyata: Platform Microservices

Mari kita bangun contoh praktis - platform microservices dengan API gateway, user service, product service, dan database PostgreSQL.

#Gambaran Arsitektur

┌─────────────────────────────────────────┐
│      Kubernetes Cluster                 │
├─────────────────────────────────────────┤
│  Ingress (nginx)                        │
│  ↓                                      │
│  API Gateway (Kong)                     │
│  ↓                                      │
│  ┌──────────────┬──────────────┐        │
│  │ User Service │ Product Svc  │        │
│  └──────────────┴──────────────┘        │
│  ↓                                      │
│  PostgreSQL Database                    │
└─────────────────────────────────────────┘

#Struktur Chart

microservices-platform/
├── Chart.yaml
├── values.yaml
├── charts/
│   ├── api-gateway/
│   ├── user-service/
│   ├── product-service/
│   └── postgresql/
├── templates/
│   ├── namespace.yaml
│   ├── configmap.yaml
│   └── secrets.yaml
└── README.md

#Chart.yaml Utama

Chart.yaml

apiVersion: v2
name: microservices-platform
description: A complete microservices platform
type: application
version: 1.0.0
appVersion: "1.0"
dependencies:
  - name: api-gateway
    version: "1.0.0"
    repository: "file://../api-gateway"
  - name: user-service
    version: "1.0.0"
    repository: "file://../user-service"
  - name: product-service
    version: "1.0.0"
    repository: "file://../product-service"
  - name: postgresql
    version: "12.0.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
maintainers:
  - name: Platform Team
    email: platform@company.com

Expand code

#values.yaml Utama

values.yaml

namespace: microservices
 
# API Gateway
api-gateway:
  enabled: true
  replicaCount: 2
  image:
    repository: myregistry/api-gateway
    tag: "1.0"
  service:
    type: LoadBalancer
    port: 80
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi
 
# User Service
user-service:
  enabled: true
  replicaCount: 2
  image:
    repository: myregistry/user-service
    tag: "1.0"
  database:
    host: postgresql
    port: 5432
    name: users_db
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi
 
# Product Service
product-service:
  enabled: true
  replicaCount: 2
  image:
    repository: myregistry/product-service
    tag: "1.0"
  database:
    host: postgresql
    port: 5432
    name: products_db
  resources:
    limits:
      cpu: 500m
      memory: 512Mi
    requests:
      cpu: 250m
      memory: 256Mi
 
# PostgreSQL
postgresql:
  enabled: true
  auth:
    username: postgres
    password: changeme
    postgresPassword: changeme
  primary:
    persistence:
      enabled: true
      size: 10Gi
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi
    requests:
      cpu: 500m
      memory: 512Mi

Expand code

#Template Namespace

templates/namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: {{ .Values.namespace }}

#Template ConfigMap

templates/configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: platform-config
  namespace: {{ .Values.namespace }}
data:
  api-gateway-url: "http://api-gateway:80"
  user-service-url: "http://user-service:8080"
  product-service-url: "http://product-service:8080"
  database-host: "{{ .Values.postgresql.primary.service.name }}"
  database-port: "5432"

#Langkah-Langkah Deployment

1. Buat struktur chart:

helm create microservices-platform

2. Buat subchart untuk API Gateway:

cd microservices-platform/charts
helm create api-gateway

Ulangi untuk user-service dan product-service.

3. Update Chart.yaml dengan dependensi:

cd ..
helm dependency update

4. Validasi chart:

helm lint microservices-platform

5. Dry-run instalasi:

helm install platform ./microservices-platform --dry-run --debug

6. Instal chart:

helm install platform ./microservices-platform \
  --namespace microservices \
  --create-namespace

7. Verifikasi instalasi:

helm status platform -n microservices

8. Lihat sumber daya yang digunakan:

kubectl get all -n microservices

#Penskalaan Layanan

Skalakan user service ke 5 replika:

helm upgrade platform ./microservices-platform \
  --set user-service.replicaCount=5 \
  -n microservices

#Memperbarui Versi Aplikasi

Deploy versi baru dari product service:

helm upgrade platform ./microservices-platform \
  --set product-service.image.tag=1.1 \
  -n microservices

#Rollback

Rollback ke rilis sebelumnya:

helm rollback platform 1 -n microservices

#Monitoring

Periksa riwayat rilis:

helm history platform -n microservices

Lihat nilai saat ini:

helm get values platform -n microservices

Lihat manifest yang dihasilkan:

helm get manifest platform -n microservices

#Kesimpulan

Helm Charts ada karena aplikasi Kubernetes memerlukan packaging, versioning, dan manajemen lifecycle. Mereka mengubah Kubernetes dari platform orkestrasi tingkat rendah menjadi sistem manajemen paket.

Meskipun Kubernetes kuat, Helm membuatnya dapat diakses. Ini mengurangi boilerplate, memungkinkan penggunaan kembali kode, dan menyediakan cara standar untuk menerapkan aplikasi.

Poin-poin kunci yang perlu diambil:

• Charts adalah paket manifest Kubernetes dengan templating
• Releases adalah instance yang berjalan dari charts
• Values parameterisasi charts untuk lingkungan berbeda
• Repositories memungkinkan berbagi dan penemuan
• Helm v3 menghapus Tiller untuk keamanan yang lebih baik
• Charts mengikuti konvensi dan praktik terbaik

Mulai dengan chart yang ada dari Bitnami atau repository lain. Pelajari struktur dengan memeriksa contoh dunia nyata. Kemudian buat chart Anda sendiri untuk aplikasi Anda.

Untuk contoh platform microservices, Anda sekarang memiliki template siap produksi. Sesuaikan dengan persyaratan spesifik Anda, tambahkan monitoring dan logging, implementasikan manajemen secret yang tepat, dan Anda siap untuk deploy.

Helm bukan hanya alat - ini adalah filosofi: aplikasi harus semudah menginstal software di laptop Anda.