Kubernetes Helm Charts 2026: Packaging, Deployment en Sollicitatievragen

Kubernetes Helm Charts vereenvoudigen applicatie-deployment door alle Kubernetes-resources te bundelen in één enkel, geversioneerd artefact. Helm 3, de huidige stabiele release, elimineert de noodzaak voor Tiller en introduceert OCI-registry-ondersteuning, waardoor chartdistributie veiliger en gestandaardiseerder wordt. Deze tutorial behandelt chart-creatie, templating, deployment-strategieën en de meest voorkomende sollicitatievragen die door hiring-teams worden gesteld.

De Helm Chart Structuur en Componenten Begrijpen

Een Helm chart is een directory met een voorgedefinieerde structuur. De chartnaam wordt de directorynaam, en elk bestand dient een specifiek doel in het packaging- en deploymentproces.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

De apiVersion: v2 geeft Helm 3-compatibiliteit aan. Het version-veld houdt chartwijzigingen bij, terwijl appVersion de versie van de gedeployde applicatie weergeeft. Dependencies declareren andere charts die deze chart nodig heeft, met optionele condities om ze in of uit te schakelen.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Values definiëren configuratie-standaardwaarden die gebruikers tijdens installatie overschrijven. Het nesten van waarden onder betekenisvolle sleutels houdt configuraties georganiseerd en zelfdocumenterend.

Kubernetes Deployments Maken met Helm Templates

Helm templates gebruiken Go templating met Sprig-functies om Kubernetes-manifesten dynamisch te genereren. Het {{ .Values }}-object biedt toegang tot de inhoud van values.yaml, terwijl {{ .Release }} deployment-metadata bevat.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

De nindent-functie voegt een newline en indentatie toe, cruciaal voor YAML-generatie. Het gebruik van include met benoemde templates (gedefinieerd in _helpers.tpl) houdt templates DRY en onderhoudbaar.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

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

Helper-templates standaardiseren naamgevingsconventies en labels over alle resources, wat consistentie garandeert met Kubernetes-aanbevolen labels.

Helm Chart Dependencies en Subcharts

Complexe applicaties zijn vaak afhankelijk van databases, caches of message queues. Helm dependencies maken het mogelijk deze als subcharts in te bedden, automatisch beheerd tijdens installatie.

# Update dependencies before packaging
helm dependency update ./my-application

# Build dependencies (creates charts/ directory)
helm dependency build ./my-application

Het helm dependency update-commando downloadt dependencies naar de charts/-directory. Conditionele dependencies gebruiken values om inclusie te controleren:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Dit patroon maakt omgevingsspecifieke configuraties mogelijk waarbij productie beheerde services gebruikt terwijl ontwikkeling in-cluster databases gebruikt.

Helm Charts Deployen met Release Management

Helm houdt deployments bij als releases, wat geversioneerde rollbacks en upgrades mogelijk maakt. Elke release onderhoudt een historie voor auditing en recovery.

# Install a chart with custom values
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Upgrade an existing release
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

De --atomic-flag zorgt ervoor dat mislukte upgrades automatisch worden teruggedraaid. De --timeout-flag stelt in hoe lang Helm wacht tot resources klaar zijn voordat het een fout declareert.

# View release history
helm history my-release -n production

# Rollback to previous revision
helm rollback my-release 2 -n production

# Uninstall a release
helm uninstall my-release -n production --keep-history

De --keep-history-flag bewaart release-records zelfs na de-installatie, nuttig voor compliance en debugging.

Helm Chart Testing- en Validatiestrategieën

Het testen van Helm charts vóór deployment vangt templatefouten en configuratieproblemen vroegtijdig op. Helm biedt ingebouwde tools voor linting en dry-run testing.

# Lint chart for errors and best practices
helm lint ./my-application

# Render templates locally without deploying
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run against cluster API
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

Het helm template-commando rendert manifesten lokaal, nuttig voor CI-pipelines die gegenereerde YAML valideren. De --dry-run-flag stuurt manifesten naar de Kubernetes API-server voor validatie zonder resources te creëren.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Helm hooks met helm.sh/hook: test worden uitgevoerd na helm test my-release, waarbij gevalideerd wordt dat deployments correct werken na installatie.

Geavanceerde Helm Templating Technieken

Productie-charts vereisen conditionele logica, loops en datatransformatie. Sprig-functies breiden Go-templates uit met utilities voor stringmanipulatie, encoding en flow control.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

De range-functie itereert over maps en lijsten. De b64enc-functie codeert waarden in base64 voor Kubernetes secrets. Pipe-operators koppelen functies aan elkaar voor datatransformatie.

Helm Charts Sollicitatievragen en Antwoorden

Technische sollicitatiegesprekken testen vaak Helm-kennis door conceptuele en praktische vragen. De volgende behandelen de meest gestelde onderwerpen.

Wat is het verschil tussen helm install en helm upgrade --install?

helm install creëert een nieuwe release en faalt als de release al bestaat. helm upgrade --install (met de --install-flag) creëert een nieuwe release als er geen bestaat, of upgradet deze als er wel een is. CI/CD-pipelines gebruiken typisch helm upgrade --install voor idempotente deployments.

Hoe worden gevoelige gegevens doorgegeven aan Helm charts?

Er zijn drie benaderingen: externe secret managers (Vault, AWS Secrets Manager), versleutelde values-bestanden (SOPS, sealed-secrets), of Kubernetes secrets die buiten Helm worden gecreëerd en gerefereerd in templates. Het opslaan van secrets in platte-tekst values.yaml-bestanden die naar versiebeheer worden gecommit, moet worden vermeden.

Wat zijn Helm hooks en wanneer moeten ze worden gebruikt?

Hooks worden uitgevoerd op specifieke punten in de release-levenscyclus: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback en test. Veelvoorkomende toepassingen zijn databasemigraties vóór upgrades, het versturen van notificaties na deployments, of het uitvoeren van integratietests.

Hoe wordt chartversioning behandeld?

Het version-veld in Chart.yaml houdt chartwijzigingen bij met semantic versioning. Het appVersion-veld houdt de versie van de gedeployde applicatie bij. De version moet worden verhoogd bij elke chartwijziging, zelfs als de applicatieversie hetzelfde blijft.

Wat is het doel van .helmignore?

Vergelijkbaar met .gitignore, sluit .helmignore bestanden uit van chartpackaging. Typische entries zijn *.tgz (vermijdt het verpakken van eerdere builds), .git/, *.md-documentatie die niet nodig is tijdens runtime, en CI-configuratiebestanden.

Voor meer Kubernetes-sollicitatievoorbereiding kunnen de modules Kubernetes Basics en Kubernetes Advanced op SharpSkill worden verkend.

Conclusie

Praktische inzichten voor het werken met Helm charts:

• Structureer charts met duidelijke scheiding tussen Chart.yaml-metadata, values.yaml-standaardwaarden en de templates-directory met Kubernetes-manifesten
• Gebruik helper-templates in _helpers.tpl om naamgeving en labels over alle resources te standaardiseren
• Beheer dependencies via Chart.yaml met conditionele enablement voor omgevingsspecifieke configuraties
• Test charts met helm lint, helm template en helm install --dry-run voordat ze naar productie worden gedeployed
• Houd releases bij met betekenisvolle namen en gebruik de --atomic-flag voor automatische rollback bij mislukte upgrades
• Sla secrets op in externe managers in plaats van in platte-tekst values-bestanden