Helm-Charts effektiv nutzen: Verwendung von Kustomize zur Verwaltung von Kubernetes-Deployments

Operations-Teams müssen das Deployment von Anwendungen automatisieren, und Helm ist die Industriestandardlösung für die Bereitstellung in Kubernetes. Wie viele Software-Anbieter bieten auch wir Helm-Charts für die Installation von Artifactoryund anderen JFrog DevOps-Plattformprodukten an, die für die Standard-/Empfehlungskonfigurationen ausgelegt sind, die die meisten Teams benötigen. Diese Vorlagen bieten dem Kunden einen begrenzten Satz von Konfigurationsoptionen.

Wenn Sie Ihr Artifactory, Xray oder andere Deployments auf eigene Art und Weise anpassen möchten, können Sie das Diagramm abspalten, um Ihre eigene angepasste Version zu erstellen. Allerdings wird Ihre benutzerdefinierte Version jedes Mal, wenn JFrog sein Helm-Chart aktualisiert, nicht mehr synchronisiert und veraltet sein. Um Ihre Version auf dem neuesten Stand zu halten, müssten Sie bei jedem Update die Integration erneut durchführen.

Wie können Sie ein Helm-Chart ohne Abspaltung anpassen? Genau dafür hat Google Kustomize geschaffen. In diesem Beitrag – und auch in einem kommenden Webinar – zeigen wir Ihnen, wie Sie Kustomize-Overlays verwenden können, um benutzerdefinierte Deployments durchzuführen, während Sie immer die neueste Helm-Chart Version Ihres Anbieters verwenden.

Vorlagen im Vergleich zu Overlays

Eine Vorlage ist ein Formular, das Platzhalter enthält, die von einem automatisierten Prozess geparst werden, um sie durch Werte zu ersetzen. Sie ist für eine bestimmte Funktion ausgelegt und markiert die Stellen, an denen Sie die Angaben machen müssen. Wenn Sie schon einmal "Mad Libs" gespielt haben, wird Ihnen dieses Ausfüllen von Lückentext bekannt vorkommen.

Als Entwickler werden Sie erkennen, dass Vorlagen und Wertangaben wie Makros und ihre Variablen oder Unterprogramme und ihre Parameter sind.

Ein Overlay ist ein Satz von Ersetzungszeichenfolgen. Textblöcke in der Originaldatei werden vollständig durch neue Textblöcke ersetzt.

Was ist der Unterschied?

  • Eine Vorlage muss sorgfältig vorbereitet werden, um spezifische Informationen an wichtigen Stellen abzufragen. Wenn Sie eine Vorlage verwenden, sind Sie darauf beschränkt, nur die Elemente zu ändern, die die Vorlage zur Verfügung stellt.
  • Für ein Overlay muss die Originaldatei nicht in irgendeiner Weise vorbereitet werden. Sie können jeden Teil komplett austauschen.

HelloWorld Helm-Chart

Da die Helm-Charts von Artifactory ziemlich komplex sind, lassen Sie uns ein sehr einfaches Beispiel verwenden. Hier lässt die Vorlage ein Argument für den Firmennamen zu.

$ cat templates/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  restartPolicy: Never
  containers:
  - name: hello
    image: alpine
    env:
    command: ["/bin/sh","-c"]
    args: ["/bin/echo Hello! My company name is {{ .Values.companyName}}"]

 

Die Werte für die Argumente der Vorlage stehen in der Datei values.yaml.

$ cat values.yaml
companyName: ABC Company

 

Lassen Sie uns installieren und sehen, wie es funktioniert.

$ Helm install helloworld .
NAME: helloworld
LAST DEPLOYED: Mon May 18 16:53:14 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST-SUITE: None

$ kubectl logs -f helloworld
Hello! My company name is ABC Company

 

Klasse! Das hat gut funktioniert, und wurde an die Kunden geliefert. Einer der Kunden wünscht jedoch, den Namen des Mitarbeiters und den Namen der Abteilung einzufügen, damit das Ergebnis folgt aussieht:

My name is John. I work for the Accounting department. Our company name is ABC Company.

Okay, ganz einfach – man könnte das Helm-Chart aufspalten und die Helm-Vorlage wie folgt ändern:

    args: ["/bin/echo My name is {{ .Values.employeeName}}. I work for {{ .Values.employeeDepartment}}. Our company name is {{.Values.companyName}}"]

 

Dann werden neue Werte in der werte.yaml -Datei hinzugefügt.

$ cat values.yaml
employeeName: Gary
employeeDepartment: Marketing
companyName: ABC Company

 

Aber, wie wir festgestellt haben, ist die Abspaltung jetzt nicht mehr synchron mit dem Original. An dieser Stelle kommt Kustomize zur Hilfe.

Überlagern mit Kustomize

Kustomize ermöglicht es Ihnen, eigene Anpassungen in yaml-Dateien zu überlagern. In unserem Beispiel kann der Kunde Anpassungen entsprechend seiner Bedürfnisse vornehmen, ohne eine private, nicht wartungsfähige Abspaltung von Charts zu erstellen.

Zunächst erstellt der Kunde eine kustomization.yaml -Datei.

patchesJson6902:
- target:
    version: v1
    kind: Pod
    name: helloworld
  patch: |-
    - op: replace
      path: /spec/containers/0/args
      value: ["/bin/echo My name is {{ .Values.employeeName}}. I work for {{ .Values.employeeDepartment}}. Our company name is {{ .Values.companyName}}"]
resources:
- templates/pod.yaml

 

Jetzt können wir Kustomize anweisen, unser Overlay anzuwenden.

$ mkdir templates_new
$ kustomize build -o templates_new

$ cat templates_new/~g_v1_pod_helloworld.yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  containers:
  - args:
    - /bin/echo My name is {{ .Values.employeeName}}. I work for {{ .Values.employeeDepartment}}
      department. Our company name is {{ .Values.companyName}}
    command:
    - /bin/sh
    - -c
    image: alpine
    name: hello
  restartPolicy: Never

 

Wir werden zunächst die ursprüngliche Vorlage durch unsere neue Vorlage ersetzen, sie dann mit Helm installieren und verifizieren.

$ mv templates templates_old

$ mv templates_new/ templates

$ Helm delete helloworld
release "helloworld" uninstalled

$ Helm install helloworld .
NAME: helloworld
LAST DEPLOYED: Tue May 19 14:27:18 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST-SUITE: None

$ kubectl logs -f helloworld
My name is Gary. I work for Marketing department. Our company name is ABC Company 

 

Klasse! Dies entspricht der Anforderung unseres Kunden.

Zuerst die Vorlage, dann das Overlay

Im vorherigen Beispiel haben wir Kustomize verwendet, um unsere Helm-Vorlage so zu ändern, dass sie neue Werte akzeptiert. Dann haben wir diese Version mit helm install verwendet, um die App bereitzustellen.

Es gibt jedoch Szenarien, in denen diese Reihenfolge nicht ideal ist. Stattdessen möchten Sie vielleicht die Chart-Vorlage zuerst lokal rendern, und dann Ihr Kustomize-Overlay anwenden, wenn Sie die App bereitstellen.

Dies kann am besten funktionieren, wenn Sie dieselbe App in mehreren Umgebungen bereitstellen müssen, jedoch mit übergreifenden Belangen wie Labels, Sicherheit oder Metering. Zum Beispiel könnten Sie für jede Umgebung unterschiedliche Kombinationen von Anforderungen haben:

Umgebung Labels Sicherheit Metering
Entwicklung Ja Nein Nein
Test Ja Nein Ja
Produktion Ja Ja Ja

 

Ebenso müssen Sie möglicherweise Ports oder den Zugriff für jede dieser Umgebungen anpassen. In diesen Szenarien kann es flexibler sein, ein anderes Kustomize-Overlay auf das gleiche gerenderte Helm-Chart für jede Umgebung anzuwenden.

Zu diesem Zweck bietet das kubectl-Kommandozeilenprogramm die apply -k -Option. Diese Funktion wendet Kustomize anhand von kustomization.yaml -Dateien in den Verzeichnissen an.

Lassen Sie uns zunächst das Helm-Chart unter Verwendung des helm template-Befehls lokal rendern . Dadurch wird eine YAML-Datei mit allen aufgelösten Werten ausgegeben, die wir in einer lokalen Datei erfassen.

$ mkdir templates_new
$ helm template . > templates_new/pod.yaml

$ $ cat templates_new/pod.yaml
---
# Source: helloworld/templates/~g_v1_pod_helloworld.yaml
apiVersion: v1
kind: Pod
metadata:
  name: helloworld
spec:
  containers:
  - args:
    - /bin/echo My name is Gary. I work for Marketing
      department. Our company name is ABC Company
    command:
    - /bin/sh
    - -c
    env: null
    image: alpine
    name: hello
  restartPolicy: Never

 

Erstellen Sie eine neue Kustomization-Datei, um wie folgt Labels zu unserem Pod hinzuzufügen:

$ cat templates_new/kustomization.yaml
commonLabels:
  app: helloworld
resources:
- templates_new/pod.yaml

 

Lassen Sie uns nun kubectl apply -k verwenden, unser Chart mit neuen Labels zu installieren:

$ helm delete helloworld

$ kubectl apply -k templates_new/.
pod/helloworld created

$ kubectl get pods
NAME         READY   STATUS      RESTARTS   AGE
helloworld   0/1     Completed   0          10s

$ kubectl describe pod helloworld
Name:         helloworld
Namespace:    default
Priority:     0
Node:         docker-desktop/192.168.65.3
Start Time:   Mon, 22 Jun 2020 16:22:11 -0700
Labels:       app=helloworld
Annotations:  Status:  Succeeded
...
...

 

Es hat geklappt! Jetzt sind wir in der Lage, das Helm-Chart eines beliebigen Anbieters zu übernehmen und unsere eigenen Anpassungen hinzuzufügen, während wir weiterhin Updates von Upstream-Diagrammen übernehmen.

Tiefer in das Thema eintauchen

JFrogs Helm-Charts sind ziemlich komplex, und wir mussten oft mehrere Versionen für unseren internen Gebrauch pflegen. Der Einsatz von Kustomize hat uns geholfen, die manuelle Bearbeitung von Charts zu vermeiden und unsere CI/CD-Prozesse stärker zu automatisieren.

Möchten Sie mehr erfahren? Sehen Sie sich die Aufzeichnung unseres Webinars an, in dem es darum geht, Wie Artifactory mit Kustomize und Helm aufgerüstet wird. Wir freuen uns darauf, unsere Erfahrungen mit Ihnen zu teilen und Ihnen zu helfen, Ihre Deployments besser zu verwalten!