Helm (Kubernetes)

Voor macOS met Homebrew:

brew install helm

2. Voeg een Helm-repository toe

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

Bitnami onderhoudt een catalogus met geteste en productieklare charts voor databases, CMS-systemen en monitoringtools.

3. Zoek een chart

helm search repo bitnami | grep nginx

Deze opdracht toont alle beschikbare nginx-charts in de Bitnami-repository.

4. Installeer een chart

helm install mijn-nginx bitnami/nginx --namespace productie --create-namespace

Deze opdracht installeert de nginx-chart in de namespace `productie`. Helm maakt de namespace automatisch aan en deployt alle Kubernetes-manifesten uit de chart.

5. Configureer een chart met values

Maak een bestand `values-prod.yaml`:

replicaCount: 3
image:
  tag: "1.25.3"
service:
  type: LoadBalancer
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Installeer met aangepaste configuratie:

helm install mijn-app ./helm-chart --values values-prod.yaml

Dezelfde chart werkt nu in ontwikkel-, test- en productieomgevingen met verschillende configuraties via het `values.yaml`-bestand.

6. Upgrade een release

helm upgrade mijn-nginx bitnami/nginx --namespace productie --atomic

De `--atomic`-vlag draait de upgrade automatisch terug bij een mislukking, wat de betrouwbaarheid van deployments vergroot.

7. OCI-registries gebruiken

Helm 3.14 en hoger ondersteunt OCI-artifacts. Sla charts op in containerregistries:

helm registry login registry-1.docker.io --username uw-gebruikersnaam
helm package ./mijn-chart
helm push mijn-chart-1.0.0.tgz oci://registry-1.docker.io/bitnamicharts

OCI-ondersteuning betekent dat charts naast container images in hetzelfde beveiligde ecosysteem worden beheerd. Docker Hardened Images bieden charts met SLSA Level 3-compliance, SBOMs en getekende attestations via Sigstore-tooling zoals Cosign.

8. Verwijder een release

helm uninstall mijn-nginx --namespace productie

Deze opdracht verwijdert alle Kubernetes-resources die bij de release horen.

Verificatie

Controleer of de installatie correct is uitgevoerd:

helm list --namespace productie
kubectl get pods --namespace productie
kubectl get svc --namespace productie

De `helm list`-opdracht toont alle actieve releases. `kubectl get pods` en `kubectl get svc` bevestigen dat de pods draaien en services beschikbaar zijn.

Veelgestelde problemen

1. Helm kan geen verbinding maken met het cluster

Controleer uw kubeconfig:

kubectl config current-context
kubectl cluster-info

Als kubectl werkt maar Helm niet, controleer dan de Helm-omgevingsvariabelen:

echo $KUBECONFIG
helm version --client

2. Upgrade mislukt en de release staat in "failed" status

helm rollback mijn-nginx 1 --namespace productie

Dit draait de release terug naar revisie 1. Gebruik `helm history mijn-nginx --namespace productie` om alle revisies te bekijken.

3. Chart-installatie faalt met "manifest is not valid"

Valideer de chart-syntax:

helm lint ./mijn-chart
helm template ./mijn-chart --debug

`helm template` rendert de manifesten lokaal zonder ze te deployen, wat helpt bij het opsporen van fouten in templates.

Helm 3 versus Helm 2

Helm 3, aangekondigd op 13 november 2019, verwijderde Tiller, de server-side component uit Helm 2. Dit vereenvoudigde de architectuur en verbeterde de beveiliging omdat er geen langlopende service met uitgebreide rechten meer nodig was in het cluster. Helm 3 introduceerde betere RBAC-ondersteuning, verbeterde upgrade- en rollbackmechanismen en een robuustere templating-engine.

Helm als CNCF-project

Helm begon in 2015 bij Deis, een startup die developer-tools voor cloudplatforms bouwde. De eerste commit in de Git-repository dateert van 19 oktober 2015. Helm Classic werd gepubliceerd tijdens de inaugurele KubeCon in november 2015. In januari 2016 fuseerde Helm Classic met Google's Kubernetes Deployment Manager en werd onderdeel van het Kubernetes-ecosysteem. Na de overname van Deis door Microsoft in 2017 bleef het project zich ontwikkelen met focus op stabiliteit en veiligheid.

In juni 2018 promoveerde Helm van subproject naar volwaardig CNCF-project, met dezelfde status als Prometheus, Envoy en etcd. Op 30 april 2020 werd Helm een "graduate" project — het tiende project dat deze status behaalde. Helm v4.0.0 verscheen op 12 november 2025 tijdens KubeCon + CloudNativeCon North America.

Helm-charts structuur

Een chart bevat alle Kubernetes-manifesten die nodig zijn voor een applicatie: deployments, services, ingresses, configmaps en secrets. Charts zijn hiërarchisch opgebouwd en kunnen andere charts als afhankelijkheden bevatten. De directorystructuur van een chart:

mijn-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl
└── charts/
    └── afhankelijkheid-1.0.0.tgz

`Chart.yaml` bevat metadata zoals naam en versie. `values.yaml` definieert standaardconfiguratie. Templates in de `templates/`-map gebruiken Go-templating en kunnen worden aangepast met values.

Helm en software supply chain

Helm-charts als OCI-artifacts ondersteunen moderne security-praktijken. Docker Hardened Images bevatten charts die voldoen aan SLSA Level 3, met uitgebreide SBOMs en getekende attestations via Cosign. Deze attestations verifiëren wat er in de chart zit, hoe die is gebouwd en of die voldoet aan beveiligingsbeleid. Docker Hub slaat charts op via de `config`-property in het image manifest.

Docker Compose Bridge zet compose-bestanden om naar Kubernetes-manifesten of Helm-charts, waardoor applicaties uit lokale Docker-omgevingen naar Kubernetes migreren. Compose Bridge configureert automatisch model-endpoints voor LLMs en Docker Model Runner.

Freelens, een community-gebaseerde Kubernetes IDE, biedt grafische ondersteuning voor Helm. Gebruikers installeren, upgraden en beheren charts via een dashboard zonder de CLI te gebruiken, met real-time clusterstatus en ingebouwde terminaltoegang.

Helm blijft zich ontwikkelen binnen de CNCF en de integratie met OCI-registries, security-tooling en grafische interfaces groeit gestaag — de vraag is welke nieuwe workflows de volgende major-versie mogelijk maakt.