Wat we ermee bouwen
Een service die op Kubernetes draait is niet één ding — het is een deployment, een service, een ingress, een autoscaler en een set secrets die het allemaal met elkaar eens moeten zijn. Helm maakt van die verzameling één chart met waarden, zodat een omgeving een values-bestand is in plaats van een map vol bijna identieke manifesten die uit elkaar lopen.
Het praktische voordeel is dat een release één beoordeelbaar, versiebeheerd object wordt. Je ziet wat er tussen twee uitrollen veranderde, promoveert dezelfde chart met andere waarden van staging naar productie, en draait het geheel als eenheid terug als een uitrol misgaat — in plaats van vijf resources met de hand ongedaan te maken terwijl de site plat ligt.
Waar het past
Deze site gaat zo de deur uit. De chart draagt de deployment, de ingress, de horizontal pod autoscaler, de image-pull-secrets en de applicatiesecrets, en CI past hem toe nadat het container-image is gebouwd en gepusht.
Wanneer we het aanraden
Zodra je meer dan één omgeving of meer dan één service hebt. Dat is het punt waarop met de hand onderhouden manifesten uiteen beginnen te lopen en niemand meer zeker weet welk cluster bij welk bestand hoort.
Voor één service in één omgeving zijn gewone manifesten in Git makkelijker te lezen en één sjabloontaal minder om te debuggen. Helms templating is werkelijk onhandig — whitespacegevoelige YAML gegenereerd door Go-templates — dus het hoort iets op te leveren. Bij één deployment doet het dat niet.