Helm

Helm er Kubernetes' pakkehåndtering og løser et konkret problem: en produktionsklar applikation i Kubernetes kræver typisk ti eller flere manifester (Deployment, Service, Ingress, ConfigMap, Secret, HPA), og de skal holdes synkroniseret på tværs af dev, staging og produktion. Helm pakker dem i et chart og lader dig installere, opgradere og rulle en hel applikation tilbage med én kommando, på samme måde som apt eller npm styrer afhængigheder i deres økosystemer. Projektet blev en del af CNCF i 2018 og er i dag standardværktøjet til at distribuere Kubernetes-applikationer.

Et Helm chart har en fast mappestruktur. Chart.yaml beskriver metadata som navn, version og afhængigheder. values.yaml indeholder standardkonfiguration, der kan overskrives ved installation. templates/-mappen indeholder Kubernetes-manifester skrevet med Go template-syntaks, hvor udtryk som .Values.replicaCount indsætter værdier fra values.yaml ved render-tid. helm template viser det færdige output uden at deploye noget, hvilket er uvurderligt til debugging.

Artifact Hub er det centrale sted at finde offentlige charts, fra databaser som PostgreSQL og Redis til hele observability-stakke som Prometheus og Grafana. Med helm repo add tilføjer du et repository, og helm install deployer en release ud fra ét chart. Bitnami har historisk vedligeholdt nogle af de mest brugte charts, men flere populære registries er begyndt at kræve betalt adgang, så det er værd at tjekke et charts kilde og vedligeholdelsesstatus, før man bygger produktion på det.

Hver helm install opretter en release med et eget navn og en revisionshistorik. helm upgrade opdaterer en eksisterende release med nye værdier eller en ny chart-version, og helm rollback vender øjeblikkeligt tilbage til en tidligere revision, hvis noget går galt. Det gør Helm til et naturligt redskab i en Continuous Delivery-pipeline, hvor deployment til flere miljøer bliver et spørgsmål om at pege på forskellige values-filer i stedet for at duplikere YAML.

Store applikationer bruger ofte umbrella charts: et overordnet chart, der har flere subcharts som afhængigheder, defineret i Chart.yaml under dependencies. En mikroservice-platform kan have ét chart per service og et root-chart, der samler dem og deler fælles værdier. values-filer struktureres typisk per miljø (values-dev.yaml, values-prod.yaml), og --set bør kun bruges til engangsoverskrivninger i CI, aldrig til permanent konfiguration, fordi det ikke er versionsstyret.

Helm hooks lader dig køre Kubernetes Jobs på bestemte tidspunkter i en releases livscyklus, som pre-install til at oprette en databasemigration eller post-upgrade til at rydde op i gamle ressourcer. Mange teams kombinerer Helm med ArgoCD eller Flux, hvor ArgoCD kalder helm template og applicerer resultatet deklarativt via Git. Det giver Helms pakkehåndtering kombineret med GitOps' auditerbarhed. Kustomize er det mest almindelige alternativ til Helm og bruges ofte side om side: Helm til tredjeparts-charts, Kustomize til organisationens egne overlays.

Helm 2 krævede en server-komponent i clusteret ved navn Tiller, som havde brede rettigheder og var en tilbagevendende sikkerhedsbekymring: enhver, der kunne tale med Tiller, kunne effektivt administrere hele clusteret. Helm 3, udgivet i 2019, fjernede Tiller helt. Helm-klienten taler nu direkte med Kubernetes API'en via den samme RBAC og de samme legitimationsoplysninger, som brugeren allerede har, hvilket gjorde værktøjet markant enklere at sikre og er en af de vigtigste grunde til, at Helm 3 i dag er det eneste relevante valg.

Chart-testing (ct) er et community-værktøj, der linter og installerer charts i et midlertidigt cluster som en del af CI, før de merges til et repository. Det fanger fejl som manglende default-værdier, ugyldig YAML efter templating, eller charts der ikke overholder semantic versioning. Kombineret med helm lint og helm template i en pipeline bliver et charts kvalitet valideret på samme måde som applikationskode: automatisk, ved hvert pull request, før noget rammer et rigtigt cluster.

Helm 3 understøtter også OCI-registries som lagringssted for charts, hvilket betyder at et chart kan pushes og pulles fra det samme container-registry som applikationens Docker-images, for eksempel GitHub Container Registry eller AWS ECR. For organisationer, der allerede har investeret i registry-infrastruktur til images, fjerner det behovet for et separat chart-repository og forenkler adgangsstyringen, fordi de samme credentials og de samme netværksregler gælder for begge artefakttyper.

Sammenlignet med at anvende rå YAML-manifester direkte med kubectl apply, giver Helm en klar fordel ved parameterisering og versionering, men det er ikke gratis: templating-laget tilføjer endnu et abstraktionsniveau, der kan gøre fejlsøgning sværere, fordi den fejl, du ser i clusteret, ofte skal spores tilbage gennem et renderet template til den oprindelige values-fil. Mindre teams med få, simple applikationer klarer sig ofte fint med Kustomize eller rene manifester og bør ikke indføre Helm alene for konsistensens skyld.

Almindelige faldgruber inkluderer at gemme secrets direkte i values.yaml, hvilket havner i klartekst i Git. Brug i stedet Sealed Secrets, External Secrets Operator eller Vault til at injicere hemmeligheder ved runtime. Kør helm lint før hver release for at fange syntaksfejl, pin altid til specifikke chart-versioner i stedet for latest, og brug helm test til at validere, at en release faktisk virker efter deployment. Et velholdt Helm-setup gør det trivielt at genskabe hele applikationsstakken i et nyt cluster på minutter.