Part 034 — Helm

Part sebelumnya membahas Docker dan Kubernetes security supply chain.

Part ini membahas Helm sebagai packaging dan templating mechanism untuk Kubernetes manifests. Dalam enterprise Java/JAX-RS system, Helm sering menjadi layer yang menentukan bagaimana Deployment, Service, Ingress, ConfigMap, Secret reference, ServiceAccount, HPA, PDB, dan NetworkPolicy dirender per environment.

Helm bukan sekadar alat install. Helm adalah abstraction layer. Abstraction layer yang baik membuat deployment konsisten. Abstraction layer yang buruk menyembunyikan manifest production sampai sulit direview.

CSG note: jangan mengasumsikan CSG memakai Helm, chart repository tertentu, chart structure tertentu, values hierarchy tertentu, Argo CD Helm integration tertentu, atau release naming convention tertentu. Semua detail harus diverifikasi di repository deployment, Helm chart, values file, GitOps configuration, CI/CD pipeline, dan diskusi dengan platform/SRE/backend team.

1. Core Concept

Helm adalah package manager dan template renderer untuk Kubernetes.

Input utama:

Chart templates + values -> rendered Kubernetes manifests

Helm chart biasanya berisi:

my-service-chart/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml
    configmap.yaml
    hpa.yaml
    pdb.yaml
    serviceaccount.yaml
    _helpers.tpl

Mental model:

Helm does not remove Kubernetes complexity.
Helm moves Kubernetes complexity into templates and values.

Karena itu review Helm tidak cukup melihat values.yaml. Kita harus melihat hasil render final.

2. Why Helm Exists

Tanpa Helm, environment berbeda sering menghasilkan manifest copy-paste:

k8s/dev/deployment.yaml
k8s/staging/deployment.yaml
k8s/prod/deployment.yaml

Masalahnya:

• drift antar environment,
• perubahan harus diulang di banyak file,
• typo mudah terjadi,
• policy sulit distandardisasi,
• upgrade sulit dikontrol.

Helm membantu dengan:

• reusable templates,
• parameterized values,
• package/version chart,
• release tracking,
• dependency chart,
• upgrade/rollback history,
• integration dengan GitOps/CI.

Tetapi Helm juga bisa membuat masalah:

• template terlalu kompleks,
• values terlalu dalam,
• default berbahaya,
• production override tidak terlihat,
• secret tersimpan di values,
• conditional logic sulit dipahami,
• rendered manifest tidak pernah direview.

3. Chart.yaml

Chart.yaml berisi metadata chart.

Contoh:

apiVersion: v2
name: quote-order-service
description: Java JAX-RS service for quote/order domain
type: application
version: 1.3.0
appVersion: "2.8.4"

Bedakan:

Anti-pattern:

Chart version, app version, image tag, and Git commit all drift without traceability.

Review harus memastikan ada hubungan jelas antara:

source commit -> image digest/tag -> appVersion -> Helm release -> running pod

4. values.yaml

values.yaml adalah default configuration untuk chart.

Contoh:

replicaCount: 2

image:
  repository: registry.example.com/quote-order-service
  tag: "2.8.4"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: quote-order.example.com
      paths:
        - path: /
          pathType: Prefix

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

Values harus diperlakukan sebagai API chart.

Pertanyaan review:

• apakah nama values jelas,
• apakah default aman,
• apakah prod override eksplisit,
• apakah schema/validation ada,
• apakah values terlalu nested,
• apakah values membuat manifest invalid jika kosong,
• apakah secret disimpan langsung di values.

5. Templates

Template Helm menggunakan Go template syntax.

Contoh sederhana:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "service.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

Template harus menghasilkan manifest yang:

• valid,
• predictable,
• readable setelah render,
• tidak menyembunyikan security risk,
• tidak membuat conditional branch liar,
• tidak bergantung pada default yang tidak aman.

Anti-pattern:

{{- if .Values.everything.enabled }}
# huge block with security, ingress, hpa, secret, and deployment mixed together
{{- end }}

Masalahnya: reviewer sulit tahu apa yang benar-benar dirender.

6. Helper Templates

_helpers.tpl biasa dipakai untuk reusable naming/label logic.

Contoh:

{{- define "service.labels" -}}
app.kubernetes.io/name: {{ include "service.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Helper yang baik:

• membuat label konsisten,
• mengurangi duplikasi,
• memusatkan naming convention,
• menjaga selector stabil.

Helper yang buruk:

• terlalu pintar,
• membuat nama resource berubah saat upgrade,
• memasukkan logic environment kompleks,
• membuat selector berubah tanpa sadar.

Selector stability sangat penting. Jika selector Deployment berubah sembarangan, rollout bisa gagal atau membuat ReplicaSet baru yang tidak sesuai ekspektasi.

7. Release and Revision

Helm release adalah instance chart yang diinstall ke namespace.

Konsep penting:

Lifecycle:

helm install -> release revision 1
helm upgrade -> release revision 2
helm rollback -> previous revision

Dalam GitOps, Helm mungkin tidak dijalankan manual oleh engineer, tetapi oleh Argo CD/Flux/controller. Tetap konsep release/rendering berlaku.

8. Upgrade and Rollback

Helm upgrade melakukan render chart baru lalu apply manifest.

Risk saat upgrade:

• immutable field berubah,
• selector berubah,
• resource name berubah,
• Service targetPort berubah,
• ingress annotation berubah,
• probe menjadi terlalu agresif,
• Secret/ConfigMap berubah tanpa rollout,
• CRD dependency tidak compatible,
• values production salah override.

Rollback tidak selalu menyelesaikan semua hal.

Contoh:

• database migration sudah irreversible,
• CRD schema berubah,
• PVC/data state berubah,
• external resource berubah,
• secret sudah dirotasi,
• traffic/certificate/DNS berubah.

Mental model:

Helm rollback can revert manifests.
It cannot always revert external state or data migrations.

9. Dependency Charts

Helm chart bisa memiliki dependencies.

Contoh:

dependencies:
  - name: redis
    version: 18.x.x
    repository: https://example.com/charts
    condition: redis.enabled

Dependency chart bisa berguna untuk local/dev environment, tetapi berisiko untuk production jika dependency stateful dikelola sembarangan.

Untuk enterprise production, hati-hati saat chart aplikasi ikut menginstall:

• PostgreSQL,
• Kafka,
• RabbitMQ,
• Redis,
• Camunda,
• Elasticsearch/OpenSearch,
• observability stack.

Pertanyaan review:

Apakah dependency ini benar-benar bagian dari release aplikasi?
Atau seharusnya dikelola platform/data team sebagai shared/managed dependency?

10. Environment-Specific Values

Pattern umum:

values.yaml
values-dev.yaml
values-staging.yaml
values-prod.yaml

Atau GitOps overlay per environment:

environments/dev/values.yaml
environments/staging/values.yaml
environments/prod/values.yaml

Values per environment biasanya mengubah:

• replica count,
• resource request/limit,
• ingress host,
• secret reference,
• config values,
• autoscaling threshold,
• node selector/toleration,
• feature flags,
• external dependency endpoint,
• observability config.

Risiko utama:

Dev and staging are not production-like enough to catch production failure.

Jangan membuat prod sebagai satu-satunya environment yang memakai:

• NetworkPolicy,
• private endpoint,
• Workload Identity/IRSA,
• strict resource limit,
• real ingress path,
• real TLS mode,
• real secret manager integration.

Kalau itu terjadi, staging tidak menguji deployment reality.

11. Secret Values Risk

Jangan menyimpan secret plaintext di values file.

Anti-pattern:

database:
  username: app_user
  password: super-secret-password

Masalah:

• tersimpan di Git,
• muncul di PR,
• muncul di CI logs,
• bisa masuk Helm release history,
• bisa terbaca oleh siapa pun yang punya akses repo/release.

Pattern lebih aman:

database:
  existingSecret: quote-order-db-secret
  usernameKey: username
  passwordKey: password

Atau gunakan External Secrets/secret manager integration sesuai standard platform.

Review penting:

Values should reference secrets, not contain secrets.

12. ConfigMap and Secret Rollout Problem

Jika ConfigMap/Secret berubah, pod tidak selalu restart otomatis.

Pattern umum Helm:

metadata:
  annotations:
    checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Tujuannya: perubahan ConfigMap mengubah pod template annotation sehingga Deployment rollout.

Namun hati-hati:

• checksum harus mencakup config yang benar,
• secret checksum tidak boleh bocor sebagai data sensitif,
• reload vs restart harus jelas,
• immutable config pattern perlu disepakati.

Pertanyaan review:

Jika value config berubah, apakah pod akan memakai config baru?
Dengan restart, reload, atau tidak sama sekali?

13. Image Configuration in Helm

Image config harus jelas:

image:
  repository: registry.example.com/service
  tag: "2.8.4"
  digest: ""
  pullPolicy: IfNotPresent

Untuk production, pertimbangkan digest pinning:

image:
  repository: registry.example.com/service
  digest: sha256:abc123...

Review:

• jangan default latest,
• jangan allow empty tag yang jatuh ke latest,
• digest lebih deterministik,
• pullPolicy harus sesuai tag strategy,
• imagePullSecrets jika diperlukan,
• registry environment harus jelas.

Anti-pattern:

image:
  tag: latest
  pullPolicy: Always

Ini terlihat nyaman, tetapi membuat deployment sulit diaudit.

14. Helm for Java/JAX-RS Deployment

Chart Java/JAX-RS sebaiknya mengontrol minimal:

• Deployment,
• Service,
• ConfigMap reference,
• Secret reference,
• ServiceAccount,
• probes,
• resources,
• lifecycle hooks,
• ingress/gateway route,
• HPA,
• PDB,
• NetworkPolicy jika standard,
• pod securityContext,
• container securityContext,
• topology spread/affinity jika perlu.

Values penting:

java:
  opts: "-XX:MaxRAMPercentage=70 -XX:InitialRAMPercentage=40"

server:
  port: 8080
  managementPort: 8081

probes:
  readiness:
    path: /health/ready
  liveness:
    path: /health/live
  startup:
    path: /health/startup

shutdown:
  terminationGracePeriodSeconds: 45
  preStopSleepSeconds: 10

Jangan membuat chart terlalu Java-specific jika chart dipakai lintas stack. Tetapi untuk platform internal Java, standardisasi seperti ini bisa sangat membantu.

15. Probes in Helm

Probe values harus aman.

Anti-pattern:

livenessProbe:
  path: /health
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 1

Masalah:

• slow JVM startup bisa restart loop,
• endpoint /health mungkin mengecek dependency eksternal,
• timeout terlalu kecil,
• readiness/liveness tidak dibedakan.

Chart harus mendukung:

• startupProbe untuk Java warmup,
• readinessProbe untuk traffic eligibility,
• livenessProbe untuk deadlock/hung process,
• per-environment override,
• sane defaults.

16. Resources in Helm

Resource values harus eksplisit.

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "2Gi"

Anti-pattern:

resources: {}

Masalah:

• scheduler tidak punya signal capacity,
• HPA CPU utilization bisa tidak bekerja sesuai harapan,
• pod bisa BestEffort,
• eviction risk meningkat,
• cost attribution buruk.

Untuk Java, resource values harus sinkron dengan JVM memory options.

memory limit != heap size

Chart sebaiknya memudahkan konfigurasi JVM container-aware options.

17. Security Context in Helm

Chart harus memiliki default security yang aman.

Contoh:

podSecurityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

Namun read-only root filesystem butuh kesiapan aplikasi:

• writable temp directory,
• log ke stdout/stderr,
• no write to app directory,
• mounted emptyDir jika perlu.

Review chart harus memastikan security default tidak hanya ada di values, tetapi benar-benar dirender ke manifest.

18. Service and Ingress in Helm

Service values:

service:
  type: ClusterIP
  port: 80
  targetPort: http

Ingress values:

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: service.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: service-tls
      hosts:
        - service.example.com

Review:

• targetPort cocok dengan container port,
• named port stabil,
• ingress class benar,
• TLS secret/cert management jelas,
• rewrite annotation tidak merusak path JAX-RS,
• timeout ingress sesuai request duration,
• forwarded headers dipahami aplikasi.

19. HPA and PDB in Helm

Chart production sebaiknya mendukung HPA dan PDB.

HPA:

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

PDB:

podDisruptionBudget:
  enabled: true
  minAvailable: 1

Review:

• HPA tidak aktif jika replica fixed tanpa alasan,
• minReplicas cukup untuk availability,
• PDB tidak memblokir node drain total,
• PDB cocok dengan replica count,
• metric scaling cocok dengan workload,
• consumer scaling mempertimbangkan partition/queue semantics.

20. Helm Diff, Template, Lint, Test

Sebelum apply, biasakan melihat hasil render.

Command penting:

helm lint ./chart
helm template my-release ./chart -f values-prod.yaml
helm diff upgrade my-release ./chart -f values-prod.yaml
helm upgrade --install my-release ./chart -f values-prod.yaml
helm test my-release

Dalam GitOps, command manual mungkin diganti oleh pipeline/controller, tetapi prinsipnya sama:

Review rendered manifest, not only template source.

Hal yang dicari di diff:

• selector berubah,
• resource name berubah,
• ingress host/path berubah,
• image tag/digest berubah,
• env var berubah,
• Secret/ConfigMap reference berubah,
• resource limit berubah,
• probe berubah,
• ServiceAccount/RBAC berubah,
• HPA/PDB berubah,
• NetworkPolicy berubah,
• securityContext berubah.

21. Helm with GitOps

Dalam Argo CD/Flux, Helm bisa dipakai sebagai render engine.

Flow:

Git repo contains chart + values
  -> GitOps controller renders chart
  -> controller applies manifests
  -> controller monitors drift

Review GitOps + Helm:

• source repo jelas,
• values per environment jelas,
• chart version pinned,
• dependency update controlled,
• rendered manifest bisa diinspeksi,
• sync wave/order jelas,
• secret handling aman,
• manual helm upgrade tidak bypass GitOps,
• drift detection aktif.

Anti-pattern:

Sometimes deploy with Argo CD, sometimes helm upgrade manually.

Ini membuat source of truth tidak jelas.

22. Failure Modes

23. Debugging Workflow

Saat Helm deployment bermasalah:

1. Render manifest locally or via pipeline artifact
2. Compare intended values with actual values
3. Inspect Kubernetes events
4. Inspect Helm release/revision if Helm manages release directly
5. Inspect GitOps sync status if GitOps manages release
6. Compare rendered manifest with live object
7. Check immutable field/selector/resource name changes
8. Check pod rollout, probes, image pull, config/secret references
9. Check service endpoints and ingress route
10. Roll back only after understanding external state impact

Commands:

helm get values <release> -n <namespace>
helm get manifest <release> -n <namespace>
helm history <release> -n <namespace>
helm status <release> -n <namespace>
kubectl describe deployment <name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Jika GitOps dipakai, gunakan UI/CLI GitOps untuk melihat rendered manifests dan sync error.

24. Helm Review Checklist

Chart Structure

• Chart.yaml jelas.
• Chart version dan app version tidak membingungkan.
• Templates terpisah per resource.
• Helper template tidak terlalu kompleks.
• Naming convention stabil.
• Labels/annotations konsisten.

Values

• Default values aman.
• Production values eksplisit.
• Tidak ada plaintext secret.
• Required values divalidasi.
• Values tidak terlalu nested/ambigu.
• Environment override mudah direview.

Image

• Registry/repository benar.
• Tidak memakai latest untuk production.
• Tag/digest traceable.
• Pull secret jika diperlukan.
• Image pull policy sesuai strategy.

Deployment

• Probes benar dan tidak agresif.
• Resource request/limit eksplisit.
• JVM options sesuai memory limit.
• Graceful shutdown configured.
• Security context aman.
• Config/Secret reference benar.

Networking

• Service targetPort cocok.
• Named port stabil.
• Ingress host/path benar.
• TLS config benar.
• Timeout/rewrite/headers dipahami.
• NetworkPolicy jika diperlukan.

Operations

• HPA/PDB sesuai workload.
• Helm diff direview.
• Rendered manifest tersedia.
• Rollback plan jelas.
• GitOps source of truth jelas.
• Manual hotfix process jelas.

25. Internal Verification Checklist

Untuk konteks CSG/team, verifikasi:

• Apakah service memakai Helm atau Kustomize atau kombinasi.
• Lokasi chart repository.
• Lokasi values per environment.
• Siapa owner chart.
• Apakah chart generic platform chart atau service-specific chart.
• Apakah Argo CD/Flux merender Helm chart.
• Apakah manual helm upgrade diperbolehkan.
• Bagaimana image tag/digest di-update.
• Apakah secrets pernah muncul di values.
• Apakah Helm release history menyimpan data sensitif.
• Apakah Helm diff menjadi bagian PR/pipeline.
• Apakah chart lint/test dijalankan.
• Apakah rendered manifest direview saat PR.
• Bagaimana rollback dilakukan.
• Bagaimana values prod dilindungi.
• Apakah ada standard label/annotation/resource/probe/security context.

26. Senior Engineer Mental Model

Saat mereview Helm, jangan hanya bertanya:

Apakah values-nya benar?

Tanyakan:

Manifest final apa yang akan masuk cluster?
Apakah manifest itu aman, observable, rollbackable, dan production-ready?
Apakah perubahan values ini mengubah traffic, identity, security, resource, atau rollout behavior?
Apakah Git tetap menjadi source of truth?

Helm yang baik membuat standard deployment lebih mudah.

Helm yang buruk membuat production behavior tersembunyi di balik template logic.

27. Practical Summary

Hal paling penting:

• Review hasil render, bukan hanya template.
• Jangan simpan secret plaintext di values.
• Jangan gunakan latest untuk production.
• Jaga selector dan resource name tetap stabil.
• Pastikan ConfigMap/Secret change memicu rollout atau reload yang jelas.
• Pastikan values prod eksplisit dan mudah diaudit.
• Gunakan Helm diff sebelum apply.
• Pahami batas rollback Helm.
• Jangan campur manual Helm upgrade dengan GitOps tanpa prosedur jelas.
• Treat Helm chart as production deployment code.