Helm of Kustomize? Wanneer welke

Twee tools, één probleem: hoe configureer je Kubernetes-manifests voor meerdere omgevingen zonder alles te kopiëren? Helm en Kustomize geven elk een ander antwoord op die vraag. Welke je nodig hebt, hangt af van wat je deployt.

Wat Helm doet

Helm is een package manager voor Kubernetes. Je installeert een chart, geeft een values.yaml mee, en Helm rendert de uiteindelijke manifests via Go-templates. Het grote voordeel: voor veelgebruikte software als ingress-nginx, cert-manager of Prometheus bestaat al een kant-en-klare chart. Je hoeft het wiel niet opnieuw uit te vinden.

De keerzijde is dat Helm-templates snel complex worden. Zodra je {{- if .Values.ingress.enabled }} begint te nesten in een loop met een range en een toYaml, ben je bezig met een template-taal die niemand echt leuk vindt. Helm lost een reëel probleem op, maar de oplossing heeft zijn eigen overhead.

Wat Kustomize doet

Kustomize werkt anders. Je schrijft gewone Kubernetes-YAML, definieert dat als een base, en schrijft vervolgens overlays die patches toepassen per omgeving. Geen template-taal, geen Go-syntax. Alleen YAML op YAML.

Het grote voordeel is leesbaarheid: je base is altijd geldig Kubernetes-YAML en je patch laat precies zien wat er per omgeving afwijkt. Kustomize is ook ingebouwd in kubectl (via kubectl apply -k), dus je hebt niets extra’s nodig.

De beperking is dat Kustomize geen goede oplossing is voor third-party software die al een Helm-chart heeft. Je kunt Helm-output wel renderen en dan als base gebruiken, maar dat is omslachtig.

Het verschil in één zin

Helm is beter voor software die iemand anders heeft verpakt. Kustomize is beter voor je eigen applicaties die je zelf beheert.

Hoe teams dit in de praktijk combineren

De meeste teams die serieus met Kubernetes werken, gebruiken beide. Helm voor alles wat van buiten komt: ingress-controllers, cert-manager, monitoring-stacks, operators. Kustomize voor de eigen applicaties, waarbij base de gedeelde configuratie bevat en overlays de verschillen per omgeving (development, staging, productie).

In een GitOps-setup met FluxCD of ArgoCD werkt dit goed: Flux ondersteunt beide tools natively. ArgoCD ook. Je hoeft geen keuze te maken als de tools complementair zijn.

Wanneer je alleen Helm gebruikt

Als je team bijna alleen third-party software deployt, of als je charts publiceert voor anderen, is Helm de logische keuze. Helm heeft ook beter lifecycle-beheer: helm upgrade, helm rollback, helm history. Voor een platform-team dat tools aan interne teams levert, is dat relevant.

Wanneer je alleen Kustomize gebruikt

Kleine teams die geen third-party charts nodig hebben, of teams die Helm’s template-overhead als een dealbreaker zien, werken prima met alleen Kustomize. Zeker als de applicaties eenvoudig zijn en de omgevingsverschillen beperkt blijven tot image-tags, replica-counts en environment-variabelen.

Wat je moet leren

Als je Helm of Kustomize wilt leren, of ze allebei in een productiecontext wilt toepassen, is een goede Kubernetes-training de snelste route. Zoek naar trainingen die deploystrategie behandelen, niet alleen de basiscommando’s.

Bekijk het aanbod op ict-trainingen.com voor Kubernetes-trainingen die Helm en Kustomize meenemen.

De juiste keuze tussen Helm en Kustomize is bijna altijd: gebruik ze allebei, maar voor verschillende dingen.