Lernhelm

Kapitel 4. Eine Tabelle erstellen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Diagramme sind das Herzstück von Helm. Du kannst sie nicht nur in einem Kubernetes-Cluster installieren oder die Instanzen der installierten Diagramme verwalten, sondern auch neue Diagramme erstellen oder bestehende ändern. In den nächsten drei Kapiteln werden wir viele Details über Diagramme behandeln, z. B. die Erstellung von Diagrammen, die Elemente darin, Templating von Kubernetes-Manifesten, das Testen von Diagrammen, Abhängigkeiten und vieles mehr.

In diesem Kapitel erfährst du, wie du ein neues Diagramm erstellst und lernst die vielen Bestandteile eines Diagramms kennen. Dazu gehört auch die Verwendung verschiedener integrierter Befehle, die dir bei der Erstellung von Diagrammen helfen können.

Charts sind die Pakete, mit denen Helm arbeitet. Sie sind konzeptionell ähnlich wie Debian-Pakete, die von APT verwendet werden, oder Formula, die von Homebrew für macOS genutzt wird. Bei der konzeptionellen Ähnlichkeit hören die Gemeinsamkeiten aber auch schon auf. Charts wurden entwickelt, um Kubernetes als Plattform zu nutzen, die ihren eigenen, einzigartigen Stil hat. Das Herzstück von Charts sind Templates zur Erstellung von Kubernetes-Manifesten, die in einem Cluster installiert und verwaltet werden können.

Bevor wir uns in Kapitel 5 mit Templates beschäftigen, wollen wir zunächst ein einfaches, voll funktionsfähiges Diagramm erstellen. Dazu werden wir uns ein Beispieldiagramm namens Amboss ansehen. Anhand dieses Diagramms lernst du, wie Helm ein Diagramm erstellt, wie Diagramme und die darin enthaltenen Dateien strukturiert sind, wie man Diagramme verpackt und wie man Diagramme lintet. Verweise auf die Online-Quelle für dieses Diagramm unter https://github.com/Masterminds/learning-helm/tree/main/chapter4/anvil.

Der Befehl zur Diagrammerstellung

Helm enthält den Befehl create, der es dir leicht macht, ein eigenes Diagramm zu erstellen, und der eine gute Möglichkeit für den Anfang ist. Mit diesem Befehl wird ein neues Nginx-Diagramm mit einem Namen deiner Wahl erstellt, das den bewährten Methoden für ein Diagrammlayout folgt. Da Kubernetes-Cluster unterschiedliche Methoden haben können, um eine Anwendung zu exponieren, macht dieses Diagramm die Art und Weise, wie Nginx dem Netzwerkverkehr ausgesetzt wird, konfigurierbar, sodass es in einer Vielzahl von Clustern exponiert werden kann.

Der Befehl create erstellt für dich ein Diagramm mit allen erforderlichen Diagrammstrukturen und Dateien. Diese Dateien sind dokumentiert, damit du verstehst, was benötigt wird, und die Templates zeigen, wie mehrere Kubernetes-Manifeste zusammenarbeiten, um eine Anwendung bereitzustellen. Außerdem kannst du dieses Diagramm sofort installieren und testen.

In diesem Kapitel werden wir uns eine Beispielanwendung namens Amboss ansehen. Es ist eine einfache Anwendung, die dir den Aufbau eines Diagramms zeigt und dir die Möglichkeit gibt, ein Diagramm für eine andere Anwendung zu ändern. Um das neue Diagramm zu erstellen, führe den folgenden Befehl in einer Eingabeaufforderung aus:

$ helm create anvil

Dadurch wird eine neue Karte in einem Unterverzeichnis deines aktuellen Verzeichnisses mit dem Namen Amboss erstellt.

Unterschiedliche Ausgangspunkte

Nginx ist ein guter Ausgangspunkt, um die Teile eines Diagramms und grundlegende zustandslose Dienste zu zeigen. Wenn du jedoch regelmäßig Diagramme erstellst, die nicht dem Nginx-Modell folgen, wäre ein anderer Ausgangspunkt hilfreicher. Zu diesem Zweck hat Helm eine Funktion namens Starter Packs, die helm create nutzen kann, um einen anderen Ausgangspunkt für die Erstellung eines Diagramms zu schaffen. Dies wird in Kapitel 6 behandelt.

Die neue Karte ist ein Verzeichnis, das eine Reihe von Dateien und Ordnern enthält. Das sind nicht alle Dateien und Ordner - du wirst in den nächsten Kapiteln noch einige entdecken. Dies sind die grundlegenden Dateien, die für eine funktionierende Karte benötigt werden:

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

Die Datei Chart.yaml enthält Metadaten und einige Funktionssteuerungen für das Diagramm.

Abhängige Diagramme können optional im Verzeichnis charts abgelegt werden. Abhängigkeiten von Diagrammen werden in Kapitel 6 behandelt. Im Moment ist dieses Verzeichnis noch leer.

Templates, die zur Erstellung von Kubernetes-Manifesten verwendet werden, werden im Verzeichnis templates gespeichert.

Die Datei NOTES.txt ist eine spezielle Vorlage. Wenn eine Karte installiert wird, wird die NOTES.txt-Vorlage gerendert und angezeigt, anstatt in einem Cluster installiert zu werden.

Templates können Tests enthalten, die nicht im Rahmen der Befehle install oder upgrade installiert werden. Diese Tabelle enthält einen Test, der vom Befehl helm test verwendet wird. Die Tests werden in Kapitel 6 behandelt.

Die Standardwerte, die an die Templates übergeben werden, wenn Helm die Manifeste rendert, stehen in der Datei values.yaml. Wenn du ein Diagramm instanziierst, können diese Werteüberschrieben werden.

Du kannst diese neu erstellte Karte ohne Änderungen installieren, indem du den folgenden Befehl ausführst:

$ helm install myapp anvil

Wenn du diesen Befehl ausführst, erstellt Helm eine Instanz des Charts im Cluster mit dem Namen myapp. Er installiert sie mit der aktuell konfigurierten Verbindung und dem Kontext, den du für Kubernetes verwendest. Helm verwendet dieselbe Konfiguration wie kubectl, die Kommandozeilenanwendung für Kubernetes. In diesem Befehl ist das letzte Argument von anvil das Verzeichnis, in dem sich die Karte befindet.

Die Ausgabe dieses Befehls enthält den Inhalt, der durch das Rendern der Vorlage NOTES.txt erzeugt wurde, wie hier gezeigt:

NAME: myapp
LAST DEPLOYED: Sun Apr  5 08:12:59 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default ↵
    -l "app.kubernetes.io/name=anvil,app.kubernetes.io/instance=myapp" ↵
    -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:80

Der Abschnitt NOTES enthält Informationen zur Verbindung mit der Anwendung. Je nachdem, welche Werte du dem Diagramm bei der Instanziierung übergibst, können diese Informationen sehr unterschiedlich sein. Dieses Diagramm kann so konfiguriert werden, dass es eine ClusterIP, einen NodePort, einen LoadBalancer und einen Ingress verwendet, um eine Anwendung zu präsentieren. Standardmäßig wird eine ClusterIP verwendet.

Wenn du den Anweisungen in den Hinweisen folgst, wirst du die Standard-Nginx-Webseite sehen, die dir zeigt, dass es läuft (siehe Abbildung 4-1).

Abbildung 4-1. Standard-Nginx-Webseite, wenn du die laufende Anwendung besuchst

Die Methoden zur Offenlegung der Anwendung sind an integrierte Kubernetes-Ressourcentypen und nicht an Funktionen der Anwendung gebunden. Das macht sie für deine eigenen Anwendungen übertragbar. Zu den Methoden für die Offenlegung von Anwendungen gehören:

ClusterIP

Eine Konfigurationsoption des Ressourcentyps Kubernetes Service, die den Dienst auf einer internen IP-Adresse auf Clusterebene zugänglich macht.

NodePort

Eine alternative Option für Kubernetes Service Ressourcen, die den Dienst auf einem statischen Port jedes Knotens exponiert. Eine ClusterIP wird ebenfalls automatisch erstellt.

LoadBalancer

Eine Kubernetes Service Konfigurationsoption, die eine Anwendung extern über einen vom Hosting-Anbieter bereitgestellten Load Balancer zugänglich macht.

Ingress

Ingress-Ressourcen sind zusätzliche Ressourcen zu Services, die einen Dienst über HTTP und HTTPS zur Verfügung stellen. Damit dies funktioniert, ist ein Ingress Controller wie ingress-nginx erforderlich.

Wenn du diese Karte zu Testzwecken in deinem Cluster installiert hast, kannst du die Instanz aus deinem Cluster löschen, indem du folgenden Befehl ausführst:

$ helm delete myapp

Hinweis

Bei der Installation des Charts wird als Image für Nginx standardmäßig die neueste Version des Images aus den Docker Official Images verwendet. Wenn der Kubernetes-Cluster, mit dem du arbeitest, keinen Zugang zu hub.docker.com hat, kannst du das Image nicht installieren. Dann musst du das Image auf ein Image einstellen, auf das dein Cluster Zugriff hat.

Nachdem wir nun ein funktionierendes Diagramm erstellt haben, wollen wir uns den Inhalt ansehen und ihn für die Amboss-Anwendung anpassen.

Die Datei Chart.yaml

Im Anvil-Verzeichnis findest du eine Datei namens Chart.yaml. Die Datei Chart.yaml informiert Helm und andere Werkzeuge über dein Diagramm. Zu den anderen Tools gehören Kubeapps (ein On-Premise-Katalog und ein Anwendungsinstallationsprogramm), der Artifact Hub (eine Auflistung von Cloud-nativen Artefakten) und viele andere.

Wenn du die Datei Chart.yaml öffnest, siehst du den in Beispiel 4-1 dargestellten Inhalt.

Beispiel 4-1. Die erzeugte Chart.yaml-Datei

apiVersion: v2 
name: anvil 
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into ↵
  versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer.↵
  They're included as
# a dependency of application charts to inject those utilities and functions ↵
  into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be ↵
  deployed.
type: application

# This is the chart version. This version number should be incremented each ↵
  time you make changes
# to the chart and its templates, including the app version.
version: 0.1.0 

# This is the version number of the application being deployed. This version ↵
  number should be
# incremented each time you make changes to the application. Versions are not ↵
  expected to
# follow Semantic Versioning. They should reflect the version the application ↵
  is using.
appVersion: 1.16.0

Die apiVersion teilt Helm mit, welche Struktur das Diagramm verwendet. Eine apiVerison von v2 ist für Helm v3 gedacht.

Der Name wird verwendet, um die Karte an verschiedenen Stellen zu identifizieren.

Diagramme können viele Versionen haben. Helm verwendet die Versionsinformationen, um die Diagramme zu ordnen und zu identifizieren.

Diese Chart.yaml-Datei enthält zahlreiche Schlüssel, von denen nur drei erforderlich sind. Die Eigenschaft apiVersion teilt Helm mit, um welche Version eines Diagramms es sich handelt. Helm v3 kann mit Diagrammen arbeiten, deren apiVersion v1 oder v2 ist. v1 sind Diagramme, die für frühere Versionen von Helm entwickelt wurden. Wenn deine Diagramme mit Helm v3 oder einer neueren Version funktionieren sollen, solltest du den Wert v2 verwenden. Der Wert name wird normalerweise als Teil des Namens für Kubernetes-Ressourcen verwendet. Das bedeutet, dass die Namen auf klein geschriebene alphanumerische Zeichen, - und . beschränkt sind und mit einem alphanumerischen Zeichen beginnen und enden müssen. Namen bestehen in der Regel aus alphanumerischen Kleinbuchstaben. Der letzte erforderliche Schlüssel istversionund enthält die Version der Karte. Es wird erwartet, dass die Versionen der semantischen Versionierung folgen, die in Kapitel 2 behandelt wurde.

Du wirst feststellen, dass der Stil einer Chart.yaml-Datei ähnlich ist, sich aber leicht von dem der Kubernetes-Manifeste unterscheidet. Chart.yaml-Dateien haben nicht das gleiche Format wie benutzerdefinierte Ressourcen, enthalten aber einige der gleichen Eigenschaften. Die ursprünglichen Chart.yaml-Dateien wurden 2015 entwickelt, lange bevor es benutzerdefinierte Kubernetes-Ressourcen-Definitionen gab. Helm hat sich zwar in den Hauptversionen weiterentwickelt, aber ein gewisses Maß an Abwärtskompatibilität beibehalten, um die Nutzer nicht zu sehr zu stören. Dies hat zu Unterschieden zwischen dem Chart.yaml-Dateiformat und den Kubernetes-Manifesten geführt.

Chart.yaml-Dateien enthalten auch beschreibende Informationen, die für die Darstellung in Benutzeroberflächen nützlich sind. Das Feld description in Beispiel 4-1 ist ein solches Feld, aber du kannst noch weitere Felder hinzufügen, wie zum Beispiel das folgende:

• home ist eine URL zur Homepage der Karte oder des Projekts.

• icon ist ein Bild (z. B. eine PNG- oder SVG-Datei) in Form einer URL.

• maintainers enthält eine Liste der Betreuer. Jeder Betreuer auf der Liste kann einen Namen, eine E-Mail und eine URL haben.

• keywords kann eine Liste von Schlüsselwörtern über das Projekt enthalten.

• sources ist für eine Liste von URLs zum Quellcode für das Projekt oder die Karte.

Eine vollständige Beschreibung der Eigenschaften in der Datei Chart.yaml findest du in Anhang A.

Die generierte Datei Chart.yaml kann für die Anvil-Anwendung angepasst werden. Mit den folgenden Änderungen werden die erforderlichen Felder aktualisiert, einige beschreibende Dateien hinzugefügt und Kommentare entfernt:

apiVersion: v2
name: anvil
description: A surprise to catch something speedy.
version: 0.1.0
appVersion: 9.17.49
icon: https://wile.example.com/anvil.svg
keywords:
  - road runner
  - anvil
home: https://wile.example.com/
sources:
  - https://github.com/Masterminds/learning-helm/tree/main/chapter4/anvil
maintainers:
  - name: ACME Corp
    email: [e-mail]
  - name: Wile E. Coyote
    email: [e-mail]

Eine Eigenschaft, die in der generierten Datei Chart.yaml enthalten war, aber nicht in der Datei für Anvil, ist type. Anvil ist eine Anwendung, die den Standardwert für das Feld type vorgibt, daher ist das Feld type nicht erforderlich. Die andere Art von Diagramm ist ein Bibliotheksdiagramm, das in Kapitel 7 behandelt wird.

Die Eigenschaft appVersion ist einzigartig. Sie ist beschreibend und wird regelmäßig in den Templates verwendet. Die Eigenschaft appVersion steht für die Version der primären oder kombinierten Anwendung. Wenn es sich bei der verpackten Anwendung zum Beispiel um WordPress handelt, ist es die Version von WordPress.

Tipp

Die Eigenschaft icon ist eine URL, und die kann Daten-URLs enthalten. Mit Daten-URLs kannst du kleine Dateien in URL-Form einbetten. Das ist besonders nützlich, wenn das Logo eine kleine SVG-Datei ist. Wenn ein Diagramm möglicherweise in einer On-Premise-Umgebung betrieben wird oder du nicht möchtest, dass die Benutzeroberfläche ständig eine Datei von deinem Webserver herunterlädt, ist eine Daten-URL eine gute Wahl.

Templates ändern

Um dieses Diagramm für die Anvil-Anwendung oder deine eigene benutzerdefinierte Anwendung ändern zu können, musst du Templates verstehen und ändern. Die Templates, die mit dem Befehl helm create erstellt werden, lassen Nginx standardmäßig als zustandslose Anwendung laufen. In dem Beispiel, das wir durcharbeiten, muss Nginx durch Anvil ersetzt werden.

Helm ist in der Programmiersprache Go geschrieben, und Go enthält Vorlagenpakete. Helm nutzt das Textvorlagenpaket als Grundlage für seine Templates. Diese Templating-Sprache ähnelt anderen Templating-Sprachen und umfasst Schleifen, Wenn-dann-Logik, Funktionen und mehr. Es folgt ein Beispiel für ein Template einer YAML-Datei:

product: {{ .Values.product | default "rocket" | quote }}

In dieser YAML-Datei gibt es einen Schlüsselnamen product. Der Wert wird mit Hilfe einer Vorlage erzeugt. {{ und }} sind die öffnenden und schließenden Klammern, um die Vorlagenlogik ein- und auszuschalten. Die Templating-Logik besteht aus drei Teilen, die durch | getrennt sind. Dies wird als Pipeline bezeichnet und funktioniert genauso wie eine Pipeline in Unix-basierten Systemen. Der Wert oder die Ausgabe einer Funktion auf der linken Seite wird als letztes Argument an das nächste Element in der Pipeline weitergegeben. In diesem Fall beginnt die Pipeline mit dem Wert der Eigenschaft in .Values.product. Dieser stammt aus dem Datenobjekt, das beim Rendern der Templates übergeben wird. Der Wert dieser Daten wird als letztes Argument an die Funktion default weitergegeben, die eine der von Helm bereitgestellten Funktionen ist. Wenn der übergebene Wert leer ist, verwendet die Funktion default den Standardwert von "rocket", um sicherzustellen, dass ein Wert vorhanden ist. Dieser wird dann an die Funktion quote gesendet, die sicherstellt, dass die Zeichenfolge in Anführungszeichen eingeschlossen wird, bevor sie in die Vorlage geschrieben wird.

Das . am Anfang von .Values.product ist wichtig. Dies wird als das Stammobjekt im aktuellen Bereich betrachtet. .Values ist eine Eigenschaft des Stammobjekts.

Der Einsatz

Helm-Diagramme können Templates für jeden Kubernetes-Ressourcentyp enthalten, den du verwenden kannst. Dazu gehören StatefulSets, Jobs, PersistentVolumeClaims, Services, und viele mehr. Das mit helm create erstellte Diagramm dient dazu, einen zustandslosen Dienst als Kubernetes Deployment auszuführen. Die Beispielanwendung, die wir hier für Anvil verwenden, ist eine zustandslose Anwendung, was bedeutet, dass sie gut als Deployment funktioniert.

Um die Vorlage Deployment zu verstehen, können wir einen Blick auf die deployment.yaml-Datei im templates-Verzeichnis der Karte werfen. Das Folgende ist die Templating-Version von Deployment bis zum Abschnitt spec:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "anvil.fullname" . }}
  labels:
    {{- include "anvil.labels" . | nindent 4 }}

Dies sieht dem Anfang eines Kubernetes-Manifests sehr ähnlich. Es hat ein apiVersion, das kind und metadata. Sobald du die metadata aufrufst, wirst du feststellen, dass das Templating beginnt.

Tipp

Wenn du mit der Struktur von Kubernetes Deployments nicht vertraut bist, kannst du sie in der Kubernetes-Dokumentation nachlesen.

Die Funktion include template ermöglicht es, die Ausgabe einer Vorlage in eine andere Vorlage einzubinden, und das funktioniert in Pipelines. Das erste Argument der Funktion include ist der Name der zu verwendenden Vorlage. Als zweites Argument wird . übergeben, das Stammobjekt. Dieses wird übergeben, damit die Eigenschaften und Funktionen des Stammobjekts in der aufgerufenen Vorlage verwendet werden können.

anvil.fullname und anvil.labels sind zwei wiederverwendbare Templates, die über die Datei _helpers.tpl in das Diagramm eingebunden sind. (Das _ am Anfang des Namens sorgt dafür, dass sie in den Verzeichnislisten ganz oben angezeigt werden, damit du sie unter deinen Templates leicht finden kannst; Helm rendert sie nicht in Kubernetes-Manifeste, stellt aber die darin enthaltenen Templates zur Verfügung.) anvil.fullname liefert einen Namen, der auf dem bei der Instanziierung des Diagramms gewählten Namen basiert, und anvil.labels liefert Labels, die den bewährten Methoden von Kubernetes entsprechen. Die Funktionen werden in Kapitel 5 ausführlicher behandelt.

Nach dem metadata Abschnitt der Vorlage folgt der spec Abschnitt, der wie folgt lautet:

spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "anvil.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "anvil.selectorLabels" . | nindent 8 }}
    spec:
    {{- with .Values.imagePullSecrets }}
      imagePullSecrets:
        {{- toYaml . | nindent 8 }}
    {{- end }}
      serviceAccountName: {{ include "anvil.serviceAccountName" . }}
      securityContext:
        {{- toYaml .Values.podSecurityContext | nindent 8 }}
      containers:
        - name: {{ .Chart.Name }}
          securityContext:
            {{- toYaml .Values.securityContext | nindent 12 }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default↵
            .Chart.AppVersion }}" 
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
      {{- with .Values.nodeSelector }}
      nodeSelector:
        {{- toYaml . | nindent 8 }}
      {{- end }}
    {{- with .Values.affinity }}
      affinity:
        {{- toYaml . | nindent 8 }}
    {{- end }}
    {{- with .Values.tolerations }}
      tolerations:
        {{- toYaml . | nindent 8 }}
    {{- end }}

Der Ort und die Version des Container-Images sind über Werte konfigurierbar.

Der Abschnitt spec schließt den Einsatz ab. Der größte Teil dieses Abschnitts besteht aus dem Ausfüllen der Daten mit den Eigenschaften auf .Values. Es gibt ein paar Elemente, die fest kodiert sind, z. B. die Ports, über die die Anwendung zugänglich ist. Anvil wird über HTTP auf Port 80 bereitgestellt, so dass wir den Port nicht ändern müssen. Wenn deine Container auf anderen Ports bereitgestellt werden, musst du hier Änderungen vornehmen.

Der Wert von image für den Container wird mit values festgelegt. Der Ort des Bildes ist hier nicht fest kodiert. Das ist nützlich, wenn der Speicherort des Bildes bei der Instanziierung eines Diagramms auf einen anderen Speicherort festgelegt werden soll. Das bedeutet, dass wir den Ort in den Standardwerten ändern müssen.

Die Eigenschaften auf .Values werden anhand einer Reihe von Faktoren errechnet. Die Standardwerte und der Startpunkt basieren auf den Werten, die in der Datei values.yaml in der Tabelle angegeben sind. Die Datei values.yaml wird im nächsten Abschnitt behandelt. Diese Werte können durch Werte überschrieben werden, die bei der Instanziierung des Diagramms eingegeben werden. Das helm CLI verfügt über Flags, um Werte direkt zu übergeben (z. B. --set, --set-file und --set-string) oder um eine Datei mit Werten zu übergeben (z. B. -f oder --values). Die Werte werden zusammengeführt, wobei die Werte, die später übergeben werden, Vorrang haben.

Templates sind ein großes Thema und machen in der Regel den größten Teil eines Diagramms aus. Kapitel 5 ist den Templates gewidmet.

Verwendung der Wertedatei

Wenn jemand eine Anwendung in einem Kubernetes-Cluster aus einem Diagramm instanziiert, muss er nicht alle Werte angeben, die in den Templates verwendet werden. Wenn sie das täten, wäre es für die Benutzer schwierig. An dieser Stelle kommt die Datei values.yaml ins Spiel.

Diagramme enthalten eine Datei values.yaml, die sich neben der Datei Chart.yaml im Stammverzeichnis eines Diagramms befindet. Die Datei values.yaml enthält die Standardwerte, die vom Diagramm verwendet werden, und ist eine Art Dokumentation für die benutzerdefinierten Werte, die an ein Diagramm übergeben werden können.

values.yaml ist eine unstrukturierte YAML-Datei. Es gibt einige gängige und nützliche Praktiken, auf die wir gleich eingehen werden, aber das Format der YAML-Datei ist nicht vorgeschrieben. So können Diagrammersteller eine Struktur und Informationen bereitstellen, die für sie gut funktionieren. Eine values.yaml-Datei kann zahlreiche Dinge enthalten, von der einfachen Ersetzung von Kubernetes-Manifest-Eigenschaften bis hin zu Elementen, die für anwendungsspezifische Geschäftslogik benötigt werden.

Container-Images

Der öffnende Teil der Datei values.yaml, die von helm create erstellt wird, enthält die Image-Informationen zusammen mit einer Öffnungsdokumentation und Informationen über Replikate:

# Default values for anvil.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: ghcr.io/masterminds/learning-helm/anvil-app 
  pullPolicy: IfNotPresent 
  # Overrides the image tag whose default is the chart version.
  tag: "" 

imagePullSecrets: [] 

Der Standort des Bildes. Es wurde aktualisiert, um den Standort von Anvil wiederzugeben.

Eine Richtlinie von IfNotPresent bedeutet, dass das Image in der verwendeten Version im Kubernetes-Cluster zwischengespeichert wird. Always ist eine weitere Option, die den Cache umgeht und immer aus dem Repository herunterlädt.

In der Standardeinstellung verwendet diese Karte das Tag appVersion. Wenn ein Bild-Tag angegeben wird, wird es anstelle des appVersion verwendet.

Eine Liste von Pull-Secrets wird verwendet, wenn Anmeldedaten für den Zugriff auf einen Container-Registrierungsort benötigt werden, der mit einem Benutzernamen und einem Passwort geschützt ist.

Dieses Diagramm und die Werte stellen eine Anwendung dar, die als ein einziges Bild gebündelt ist. Die in der Datei values.yaml verwendeten Muster sind darauf abgestimmt. Es gibt zum Beispiel nur einen Speicherort für ein Bild. Wenn deine Anwendungen mehrere Images haben, würde jedes Image einen Abschnitt haben, der viele der Informationen hier enthält. Dazu gehört auch replicaCount, das die Nummer von replicas angibt, die Kubernetes bei derErstellung von Deployment verwenden wird.

Der Abschnitt image enthält Details über das Image. repository enthält den Speicherort des zu verwendenden Images, während pullPolicy Kubernetes mitteilt, wie oft es die Images abrufen oder zwischenspeichern soll. Wenn ein bewegliches Tag, wie stable, verwendet wird, sollte pullPolicy auf Always gesetzt werden, damit Änderungen übernommen werden. Da eine Version verwendet wird, wird der Standardwert pullPolicy auf IfNotPresent gesetzt, damit eine gecachte Version verwendet werden kann, falls verfügbar. Die Eigenschaft tag bietet die Möglichkeit, ein anderes Tag zu setzen als das in der Datei Chart.yaml festgelegte appVersion.

Du wirst feststellen, dass es keine Methode gibt, um einen Digest zu setzen, wenn du ein Bild abrufst. Digests können unterschiedlich sein, wenn sich Images in verschiedenen Repositories befinden. Wenn zum Beispiel das Anvil-Image von Docker Hub nach Quay, einem anderen Image-Repository, kopiert wird, würde sich der Digest für dasselbe Image ändern, auch wenn Tag und Inhalt gleich bleiben. In Kapitel 5 findest du ein Beispiel dafür, wie du eine Übersicht in ein Diagramm einfügen kannst, falls dies gewünscht ist.

Wenn du ein Image aus einer Container-Registry mit Zugriffskontrollen ziehen musst, muss Kubernetes wissen, wie das geht. Dies geschieht durch die Verwendung von Pull Secrets. imagePullSecrets ermöglicht es dir, die Namen von Pull Secrets mit Zugriff auf private Registries aufzulisten. Schau in der Dokumentation nach, wie du ein Pull-Secret erstellst.

Das erstellte Diagramm enthält einige Sicherheitsaspekte, die aktiviert oder anders konfiguriert werden können. Standardmäßig wird ein Dienstkonto für die Diagramminstanz erstellt, während die anderen Optionen optional sind. Die folgende Grafik wird von helmerstelltcreate:

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname ↵
    template
  name:

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

Du wirst feststellen, dass die meisten Eigenschaften in der Konfiguration Kommentare sind und nicht aktiv sind. Wenn das Diagramm mit den Werten als Kommentar dargestellt wird, gibt es keinen Wert für diese Eigenschaften. Der Wert ist leer. Durch die Struktur und die Werte als Kommentare dokumentiert das Diagramm die Struktur und die Standardwerte, die verwendet werden können, aber es aktiviert diese Funktionen nicht.

Dienste offenlegen

Im nächsten Abschnitt der Datei values.yaml geht es darum, die Anwendung für andere zugänglich zu machen:

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths: []
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

In Kubernetes gibt es zwei eingebaute Objekte, die du verwenden kannst, um Anwendungen bereitzustellen. Das erste ist Service. Mit der Eigenschaft service kannst du den Typ von Service auswählen. Standardmäßig wird ClusterIP verwendet, aber auch andere Optionen wie NodePort undLoadBalancer können verwendet werden. Die wenigen YAML-Zeilen im Abschnitt service werden mit der generierten Vorlage service.yaml kombiniert, um ein vollständiges Servicemanifest zu erstellen, das in Kubernetes hochgeladen wird.

Das zweite eingebaute Objekt ist das Ingress Manifest, das mit einem Service gepaart werden kann. Die Ingress Konfiguration bietet eine Möglichkeit, ein in Diagrammen häufig anzutreffendes Muster zu zeigen: die Verwendung einer enabled Eigenschaft zum Ein- und Ausschalten von Funktionen. In diesem Fall ist ingress.enabled auf false gesetzt. Wenn Helm die Templates rendert und einen Wert von false sieht, wird das Ingress Manifest übersprungen. Das liegt an der Verwendung einer if Logikanweisung in der Ingress Vorlage, die sich in der generierten ingress.yaml Datei befindet.

Ingress-Kontrolleure

Für ein funktionierendes Ingress-Setup brauchst du mehr als eine Ingress Ressource in Kubernetes. Die Ingress Ressource, die du in ein Diagramm einbinden kannst, verbindet den Ingress-Controller mit einem Service. Du musst einen Ingress-Controller in deinem Cluster haben, da er nicht standardmäßig enthalten ist. Die Kubernetes-Gemeinschaft stellt den Nginx Ingress Controller zur Verfügung, der eine gute Standardoption darstellt.

Ressourcen-Grenzen

Wenn du Anwendungen in der Produktion laufen lässt, ist es eine gute Praxis, Ressourcenlimits zu setzen. Dadurch wird verhindert, dass z. B. ein Speicherleck in einem Container andere Container beeinträchtigt. Wenn ein Diagrammautor ein Diagramm erstellt, das andere nutzen sollen, weiß er vielleicht nicht, wo es installiert wird und wie viele Ressourcen dort zur Verfügung stehen. Könnte es von einem Entwickler oder jemandem, der das Diagramm testet, auf einem Laptop installiert werden? Oder wird sie auf großen Produktionsservern installiert? Um mit diesen unterschiedlichen Umgebungen umzugehen, empfiehlt es sich, Ressourcenbeschränkungen festzulegen und sie dann in Kommentare umzuwandeln. Das kannst du im nächsten Abschnitt der Datei values.yaml nachlesen:

resources: {}
  # We usually recommend not to specify default resources and to leave this as
  # a conscious choice for the user. This also increases chances charts run on
  # environments with little resources, such as Minikube. If you do want to
  # specify resources, uncomment the following lines, adjust them as necessary,
  # and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

Diejenigen, die Anwendungen installieren, verwenden diese Zahlen als Empfehlungen, wenn sie ein Diagramm einrichten. Diese Zahlen sind die Standardwerte, die für ein einfaches Nginx-Setup festgelegt wurden, so wie es erstellt wurde. Sie funktionieren für die Anvil-Anwendung. Wenn deine Anwendung andere Werte benötigt, musst du diese aktualisieren.

Arbeitslasten haben die Möglichkeit, über die Einstellungen Knotenauswahl, Toleranzen und Affinität genau festzulegen, wo sie in einem Cluster ausgeführt werden. Obwohl diese erweiterten Funktionen oft nicht genutzt werden, ist es eine gute Idee, sie für diejenigen, die sie benötigen, in eine Tabelle aufzunehmen. Die generierte Datei values.yaml und die Templates berücksichtigen dies. Im folgenden Beispiel werden YAML-Schlüssel für diese erweitertenFunktionen erzeugt. Die Werte sind standardmäßig leer, wobei davon ausgegangen wird, dass die Person, die die Karte installiert, die Werte entsprechend ihrer Installation einstellt:

nodeSelector: {}

tolerations: []

affinity: {}

Verpacken der Karte

Du kannst die Dateien und Verzeichnisse einer Karte in eine einzige Archivdatei packen. Das ist aus vielen Gründen nützlich, unter anderem:

• Zur Weitergabe an andere Personen. Einer der wichtigsten Aspekte eines Paketmanagers ist, dass jemand, der sich mit einer Anwendung auskennt, diese paketieren kann, damit andere, die die Plattform oder die Anwendung nicht so gut kennen, sie ausführen können.

• Wenn eine Version einer Anwendung einen Testprozess in mehreren Umgebungen durchlaufen muss. Ein Beispiel für diesen Prozess ist, wenn es Entwicklungs-, Qualitätssicherungs- (QS) und Produktionsumgebungen gibt und die Anwendung die QS bestehen muss, bevor sie in Produktion geht.

• Bei der Entwicklung einer Multiservice-Anwendung müssen die Entwickler Dienste ausführen, die von anderen Entwicklern erstellt oder anderweitig betreut wurden.

In jeder dieser Situationen ist es oft einfacher, eine einzelne Datei für die Karte weiterzugeben als eine Verzeichnisstruktur.

Diagrammversionen bringen eine weitere Schwierigkeit in die Art und Weise, wie du Diagramme verteilst und verbrauchst. Es kann sein, dass du oder jemand, der dein Diagramm nutzt, verschiedene Versionen des Diagramms verwenden muss. Deshalb ist es sinnvoll, verschiedene Versionen mit Hilfe von Chart Repositories oder Open Container Initiative (OCI) Registries (siehe Kapitel 7) zu speichern und gemeinsam zu nutzen. In diesen Umgebungen ist das Speichern und Freigeben vieler Dateien in einer Sammlung von Verzeichnisstrukturen für jede Version alles andere als einfach.

Helm hat die Möglichkeit, ein Kartenarchiv zu erstellen. Jedes Kartenarchiv ist eine gzipped TAR-Datei mit der Erweiterung .tgz. Jedes Werkzeug, das gzipped TAR-Dateien erstellen, entpacken und anderweitig bearbeiten kann, funktioniert mit Helms Diagrammarchiven.

Wenn Helm die Archivdateien erzeugt, werden sie nach dem Musterchart name-version.tgz benannt. Helm erwartet dasselbe Muster, wenn sie konsumiert werden. Der chart name ist der Name, den du in der Chart.yaml-Datei findest, und die version ist die Diagrammversion. So können mehrere Versionen desselben Charts nebeneinander gespeichert werden. Du kannst Anvil als Archiv verpacken, indem du ausführst:

$ helm package anvil

In diesem Fall ist anvil der Pfad zu dem Verzeichnis, in dem sich die Amboss-Diagrammquelle befindet. Standardmäßig legt der Befehl helm package das Archiv in dem Verzeichnis ab, in dem du dich befunden hast, als du den Befehl ausgeführt hast.

Es gibt einige nützliche Flaggen, die du beim Verpacken einer Karte verwenden kannst:

--dependency-update (-u)

Weist Helm an, die abhängigen Diagramme vor der Erstellung des Archivs zu aktualisieren. Dadurch wird die Datei Chart.lock aktualisiert und eine Kopie der abhängigen Diagramme in das Verzeichnis Chart gelegt. Abhängigkeiten werden in Kapitel 6 ausführlicher behandelt.

--destination (-d)

Ermöglicht es dir, den Speicherort für das Diagrammarchiv festzulegen, wenn dieser nicht mit dem aktuellen Arbeitsverzeichnis übereinstimmt.

--app-version

Kann verwendet werden, um dieappVersion Eigenschaft der Datei Chart.yaml zu setzen. Dies ist besonders nützlich, wenn du für jede neue Version deiner Anwendung, die im Container läuft, eine neue Version des Diagramms erstellst und es keine weiteren Änderungen am Diagramm gibt. Die Automatisierung kann ein Flag wie dieses als Teil des Prozesses zur Erstellung der neuen Version verwenden.

--version

Aktualisiert die Version der Karte. Dies ist nützlich, wenn du die appVersion über die Kommandozeile als Teil des Prozesses zum Verpacken einer Karte aktualisierst.

Flaggen für Pretty Good Privacy (PGP) Signierkarten

Helm-Karten können kryptografisch signiert und verifiziert werden. Der Befehl package hat Flags für den Signierteil des Prozesses, während Befehle wie install und upgrade Flags für den Verifizierungsteil des Prozesses haben. Kapitel 6 behandelt diesen Prozess.

Manchmal befinden sich in einem Kartenverzeichnis Dateien, die du nicht in das Kartenarchiv aufnehmen möchtest. Optional kann es in einem Diagrammverzeichnis eine .helmignore-Datei geben. Diese ist ähnlich wie eine .gitignore-Datei für Git. Der zuvor verwendete Befehl helm create hat eine Datei mit folgendem Inhalt erstellt:

# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*.orig
*~
# Various IDEs
.project
.idea/
*.tmproj
.vscode/

Viele dieser Erweiterungen und Muster kommen dir vielleicht bekannt vor, weil sie aus verschiedenen Versionskontrollsystemen und Code-Editoren stammen.

Wenn das Diagrammarchiv erstellt wird, möchtest du normalerweise Elemente wie die Daten deines Versionskontrollsystems nicht mit einbeziehen. In der Datei .helmignore kannst du festlegen, was übersprungen werden soll. Diese Datei muss sich auf der obersten Ebene des Diagramms befinden.

Helm ist so konzipiert, dass es mit Archivdateien auf die gleiche Weise arbeitet wie mit Verzeichnisstrukturen. Befehle wie helm install und helm lint, auf die wir gleich noch eingehen werden, können mit einer Archivdatei genauso umgehen wie mit einem Verzeichnis.

Linting-Tabellen

Bei der Entwicklung von Diagrammen, insbesondere bei der Arbeit mit YAML-Vorlagen, kann man leicht einen Fehler machen oder etwas übersehen. Um dir zu helfen, Fehler, Bugs, Stilprobleme und andere verdächtige Elemente zu finden, enthält der Helm-Client einen Linter. Dieser Linter kann während der Diagrammentwicklung und als Teil des Testprozesses verwendet werden.

Um den Linter zu benutzen, verwende den Befehl lint auf einer Karte als Verzeichnis oder als gepacktes Archiv:

$ helm lint anvil
==> Linting anvil

1 chart(s) linted, 0 chart(s) failed

Die erste Zeile ist der Befehl, den du ausführst, während die folgenden Zeilen von Helm ausgegeben werden. In diesem Fall gab es keine Probleme. Du kannst diesen Befehl auch auf eine Archivdatei wie die im vorherigen Abschnitt anwenden. Dazu änderst du das Argument anvil, das auf den Speicherort der Karte gesetzt ist, in die Archivdatei anvil-0.1.0.tgz.

Mit diesem Befehl kannst du mehrere Diagramme mit einem einzigen Befehl färben. Wenn du zum Beispiel ein zweites Diagramm namens mychart hast und es neben anvil färben möchtest, kannst du den folgenden Befehl ausführen:

$ helm lint anvil mychart

Helm bietet drei Stufen von Rückmeldungen zu Diagrammen an: Info, Warnung und Fehler. Rückmeldungen auf der Info-Ebene sind informativ; Diagramme können mit Rückmeldungen auf der Info-Ebene installiert werden. Rückmeldungen auf der Info-Ebene führen dazu, dass Helm einen Exit-Code von 0 erhält. Rückmeldungen auf der Fehler-Ebene bedeuten, dass ein Problem mit dem Diagramm vorliegt. Wenn ein Diagramm ein ungültiges Manifest für Kubernetes erzeugt, z.B. weil YAML ungültig ist, erzeugt Helm einen Fehler. Fehler führen dazu, dass Helm einen Exit-Code ungleich Null hat, was nützlich ist, um Probleme in automatisierten Testwerkzeugen zu erkennen. In der Mitte befinden sich Warnmeldungen. Diese Meldungen beziehen sich auf Erkenntnisse, die zu Problemen führen können. Standardmäßig haben Warnmeldungen bei Helm einen Exit-Code von 0, aber Helm fügt ein --strict Flag hinzu, das dafür sorgt, dass die Exit-Codes ungleich Null sind. Du kannst wählen, wie du sie in der Automatisierung behandeln willst.

Exit Codes

Wenn eine Anwendung beendet wird, übergibt sie einen Code oder Status an den Elternteil, der sie ausgeführt hat. Wenn du Helm ausführst, ist das normalerweise das Betriebssystem, die Eingabeaufforderung oder die Shell. Ein Exit-Status von Null bedeutet, dass die Anwendung ohne Probleme beendet wurde. Ein Exit-Status ungleich Null bedeutet, dass es ein Problem gab. Automatisierte Testsysteme verwenden oft Exit-Codes, um zu wissen, wann sie fortfahren oder aufhören sollen. Wenn eine Anwendung, die für automatisierte Tests verwendet wird, einen Exit-Code ungleich Null zurückgibt, werden die automatisierten Prozesse in der Regel beendet und der Benutzer über einen Fehler informiert.

In diesem Fall gab es keine Probleme mit dem Amboss-Diagramm. Ein Standarddiagramm, das von helm create erstellt wurde, enthält eine einzige Info-Meldung über eine fehlende icon Eigenschaft in der Datei Chart.yaml. Dies ist ein Hinweis auf Info-Ebene, damit die Benutzer wissen, dass das Symbol fehlt. Das fehlende Symbol hat keinen Einfluss auf die Funktionsweise des Diagramms, aber es wirkt sich auf die Darstellung in den Benutzeroberflächen aus.

Fazit

Ein einfaches Diagramm für deine Anwendung zu erstellen, ist ganz einfach, wenn du den Befehl helm create verwendest. Auch wenn deine Anwendungen komplizierter sind, kann die Struktur von Diagrammen sie aufnehmen, und der Befehl helm create kann dir dabei helfen. Mit ein paar kleinen Änderungen, die du in diesem Kapitel vorgenommen hast, kannst du das Anvil-Diagramm mit helm install installieren und sehen, wie die benutzerdefinierte Anwendung in deinem Cluster läuft. Du kannst den gleichen Ablauf verwenden, um deine eigenen Charts zu erstellen.

Im nächsten Kapitel lernst du, wie du Templates erstellst, wobei der Schwerpunkt darauf liegt, wie die Template-Sprache funktioniert und wie du sie auf die in Diagrammen gespeicherten Kubernetes-Templates anwenden kannst. Templates sind in der Regel der größte Teil eines Diagramms, auf den du die meiste Zeit verwenden wirst. Wenn du verstehst, welche Möglichkeiten dir bei der Erstellung von Templates zur Verfügung stehen, wird die Entwicklung von Templates schneller und einfacher.