Kubernetes-applicaties beheren met Helm

Dit is standaard, open-source Kubernetes-tooling, niet specifiek voor één provider. Het werkt op dezelfde manier op een cluster dat draait op Bare Metal Compute, Flexible VPS of Private Cloud, of waar dan ook.

Waarom een package manager voor Kubernetes

Een matig complexe applicatie heeft al snel een tiental of meer Kubernetes-manifests nodig: deployments, services, config maps, secrets, een ingress, misschien een persistent volume claim. Dat allemaal met de hand schrijven en onderhouden voor elke omgeving wordt snel repetitief, en omgevingen groeien makkelijk uit elkaar. Helm lost dat op door je de manifests één keer te laten templaten, als chart, en per omgeving of per installatie een andere set values op te geven.

Charts versus releases

• Chart. Het package zelf: een directory (of gepackaged archief) met getemplatete Kubernetes-manifests, een Chart.yaml met metadata, en een standaard values.yaml. Charts kun je zelf schrijven, uit een publieke chart repository halen, of allebei: veel populaire applicaties leveren een officiële Helm chart.
• Release. Een specifieke, benoemde instantie van een chart, geïnstalleerd in een cluster met een bepaalde set values. Je kunt dezelfde chart meerdere keren installeren onder verschillende release-namen, bijvoorbeeld aparte releases van dezelfde applicatie in staging en productie, of meerdere tenants van dezelfde tool.

Basiscommando's voor de levenscyclus

Een chart uit een repository installeren, met een naam voor de release:

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

helm install my-app bitnami/nginx \
  --namespace shop \
  --create-namespace \
  -f values.yaml

Controleren wat er op dit moment geïnstalleerd is, en de geschiedenis van een release:

helm list --namespace shop
helm history my-app --namespace shop

Een release upgraden, of het nu om een nieuwe chart-versie, een nieuwe image tag of gewijzigde configuratie gaat, gebeurt via hetzelfde values-bestand-patroon:

helm upgrade my-app bitnami/nginx \
  --namespace shop \
  -f values.yaml

Blijkt een upgrade kapot te zijn, dan zet helm rollback de release terug naar een eerdere revisie, zonder dat je de oude manifests met de hand hoeft te reconstrueren:

# roll back to the previous revision
helm rollback my-app --namespace shop

# roll back to a specific revision number, from helm history
helm rollback my-app 3 --namespace shop

Een release volledig verwijderen:

helm uninstall my-app --namespace shop

values.yaml en configuratie-overrides

De standaard values.yaml van een chart definieert elke configureerbare instelling: replica count, image tag, resource limits, of een ingress aan staat, enzovoort, met verstandige standaardwaarden. In plaats van de chart zelf te bewerken, override je alleen de values die voor jouw installatie anders moeten zijn:

replicaCount: 3

image:
  repository: my-registry.example.com/shop-frontend
  tag: "1.4.2"

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

ingress:
  enabled: true
  hosts:
    - host: shop.example.com

Een apart values-bestand per omgeving aanhouden, values-staging.yaml, values-production.yaml, is een gangbare manier om één chart in meerdere omgevingen te hergebruiken en tegelijk de verschillen daartussen expliciet en version-controlled te houden, in plaats van verspreid over handmatige kubectl edit-wijzigingen.