Es ist nicht einfach eine Anwendung auf mehreren Kubernetes-Clustern bereitzustellen, die beispielsweise eine abweichende Konfiguration erfordert. Kubernetes Manifeste sind deklarativ und bieten keine Möglichkeit, Bedingungen oder Variablen zu verwenden. Das ist eine gute und eine schlechte Sache zugleich.
Der gute Wunsch eine Templating Engine für diese Aufgabe einzusetzen istallerdings schnell gefasst, sonst muss Du alle Kubernetes Manifeste für dieverschiedenen Cluster duplizieren.
Mit dem Werkzeug Helm kannst Du zusätzlich deine gesamte Kubernetes-Anwendung als Paket zusammenstellen und für andere in einem eigenen Repository, Chart Museum oder auf dem Helm Hub bereitstellen.
Helm bietet ein Management aller Manifeste einer Anwendungen als Chart-Paket an. Helm benutzt die Go Templating Engine und die erweiteren Funktionen der Sprig Library.

Installation

Für den Start muss Helm auf Deinem Client installiert werden.

Auf einem Mac gelingt die Installation auf der Basis von Homebrew folgendermaßen:

$ brew install kubernetes-helm

\

Auf einem Linux-System ist die Installation mit folgendem Script möglich:

$ curl -LO https://git.io/get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.sh

Ansonsten für eine kurze Verweildauer kann auch der folgender einzeiler benutz werden

$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash

Weitere Installationsmöglichkeiten findest Du hier.

\

In den meisten Kubernetes Clustern ist die Zugangskontrolle RBAC aktiv und dementsprechend muss für die Installation der serverseitigen Komponente Tiller von Helm ein ServiceAccount im Cluster eingerichtet werden. Nach kurzer Zeit ist der Service Tiller dann verfügbar und der Einsatz von Helm kann beginnen. Die hier erteilten globalen Rechte sind für den Produktionsbetrieb nicht geeignet. Mehr zum Thema Sicherheit rund um Helm findtest Du in diesem Blog Artikel von Virtuslab oder in der Helm Dokumentation.

\

Um Tiller die benötigten Rechte zu geben könnt ihr ein Manifest anlegen welches einen ServicAccount und eine Cluster Berechtigung beinhaltet um Tiller die Rechte einzuräumen.

Dafür könnt Ihr ein YAML file mit dem Namen tiller-rbac.yaml anlegen.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

Anschließend könnt ihr das Manifest mit kubectl deployen.

$ kubectl apply -f tiller-rbac.yaml

Anstelle von Manifesten könnt ihr auch direkt kubectl nutzen mit den folgenden zwei Befehlen:

$ kubectl create serviceaccount tiller -n kube-system 
$ kubectl create clusterrolebinding tiller --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

Nun muss der aktuelle Tiller noch den erzeugten ServiceAccount zugewiesen bekommen. Dafür kann der Parameter --service-account bei helm init genutzt werden. Zur gleichen Zeit kann man dann auch den Tiller mit --upgrade im helm cli command schon mal auf die gleiche Version des Helm clients bringen.

$ helm init --service-account tiller --upgrade
$ sleep 10
$ helm version

\

Erzeugen eines einfachen Service Deployments

Im ersten Schritt ist Helm in der Lage für einen Standard Service in Kubernetes die notwendigen Manifest Dateien zu erzeugen. Ein solches Paketverzeichnis wird als Chart bezeichnet.

$ helm create whoami

\

Die Metadaten werden in der Datei Chart.yaml beschrieben. Hier werden die Version, Herkunft, Autoren und eine Beschreibung hinterlegt. Im Verzeichnis templates werden die Manifest-Templates gespeichert. Die Default-Parameter für die Ersetzung werden in der Datei values.yaml gespeichert. Die Parameter können durch weitere Argumente oder Dateien beim Aufruf des Werkzeuges Helm überschrieben werden.

├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

\

Wenn wir z.B. statt nginx lieber unseren bee42 whoami Service starten wollen, können wir das mit folgenden Parametern überschreiben und in den Kubernetes-Cluster installieren:

$ cd whoami

Nun erzeugen wir unsere eigene values Datei values-whoami.yaml um unseren whoami Service zu starten.

image:
  repository: bee42/whoami
  tag: 2.1.0
  pullPolicy: IfNotPresent

Daraufhin kann dann auch das Ausrollen unseres eigenen helm charts mit folgendem Befehl passieren:

$ helm install --name whoami --namespace dev-whoami -f values-whoami.yaml .

\

Nun wird ein Release des Services whoami in dem neuen Namespace dev-whoami erzeugt. Alle Releases können mit dem Befehl helm ls aufgelistet werden und mit dem Befehl helm status kannst Du dich über den Status aller Manifeste des Charts informieren.
Im Standard-Chart befindet sich noch die Datei NOTES.txt die Dir Tipps zur Anwendungen des Services vermittelt. Im konkreten Fall kannst Du dir einen whoami Pod heraussuchen und einen lokalen Test des Services über den Port 8080 durchführen.

$ helm status whoami

LAST DEPLOYED: Wed Apr 24 15:34:13 2019
NAMESPACE: dev-whoami
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME    READY  UP-TO-DATE  AVAILABLE  AGE
whoami  1/1    1           1          8s

==> v1/Pod(related)
NAME                     READY  STATUS   RESTARTS  AGE
whoami-6648f65868-bsz6x  1/1    Running  0         8s

==> v1/Service
NAME    TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)  AGE
whoami  ClusterIP  10.100.90.22  <none>       80/TCP   8s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace whoami \
  -l "app.kubernetes.io/name=whoami,app.kubernetes.io/instance=whoami" \
  -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

\

Jederzeit kann ein Upgrade des Charts durchgeführt werden. Alle Manifests die Veränderungen erfahren, werden dann erneut übertragen. Um eine neuere Version der Anwendung zu installieren reicht es den Parameter image.tag zu überschreiben.

$ helm upgrade whoami --set image.tag=2.2.0 -f values-whoami.yaml .

\

Mit dem Befehl rollback kannst Du ein altes Release wiederherstellen. Der Befehl delete löscht ein Release. Die Ressourcen verschwinden, aber die Konfiguration ist weiterhin gespeichert und kann reaktiviert werden. Die Beschreibung kann durch die Option helm delete --purge <RELEASE> entgültig entfernt werden.

Fazit

Helm ist ein sehr hilfreiches Werkzeug zur Verwaltung und Erzeugung von Kubernetes Manifesten.
Das Besondere an Helm ist, dass viele vorgefertigte Helm Charts existieren. Auf dem Helm Hub sind weitere veröffentlicht. Das erleichtert die Bereitstellung von Datenbanken, CI-Systemen, Caches, Monitoring, Ingress Proxies und Anwendungen enorm.

Auf unserem Kubernetes Poster sind noch mehr Informationen zu Helm visualisiert.

Happy Helming!

Die bee42 crew