Kapitel 4. Anpassen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Das Deployment in einen Kubernetes-Cluster ist, kurz gesagt, die Anwendung einiger YAML-Dateien und die Überprüfung des Ergebnisses.

Der schwierige Teil ist die Entwicklung der ersten Version der YAML-Dateien; danach werden in der Regel nur noch kleine Änderungen vorgenommen, wie z.B. die Aktualisierung der Container-Image-Tag-Version, die Anzahl der Replikate oder ein neuer Konfigurationswert. Eine Möglichkeit ist, diese Änderungen direkt in den YAML-Dateien vorzunehmen - das funktioniert, aber jeder Fehler in dieser Version (Änderung der falschen Zeile, versehentliches Löschen von etwas, Einfügen eines falschen Leerzeichens) kann katastrophale Folgen haben.

Aus diesem Grund gibt es Tools, mit denen du Basis-Kubernetes-Manifeste (die sich selten ändern) und spezifische Dateien (vielleicht eine für jede Umgebung) für die Einstellung der Parameter, die sich häufiger ändern, definieren kannst. Eines dieser Tools ist Kustomize.

In diesem Kapitel lernst du, wie du mit Kustomize Kubernetes-Ressourcendateien ohne Templating und ohne DSL verwalten kannst.

Der erste Schritt besteht darin, ein Kustomize-Projekt zu erstellen und es in einem Kubernetes-Cluster einzusetzen (siehe Rezept 4.1).

Nach der ersten Bereitstellung wird die Anwendung automatisch mit einem neuen Container-Image, einem neuen Konfigurationswert oder einem anderen Feld, wie z. B. der Replikat-Nummer, aktualisiert (siehe Rezepte 4.2 und4.3).

Wenn du mehrere Betriebsumgebungen hast (z. B. Staging, Produktion usw.), musst du sie auf ähnliche Weise verwalten. Mit Kustomize kannst du jedoch für jede Umgebung eine Reihe von Werten festlegen (siehe Rezept 4.4).

Die Konfigurationswerte der Anwendung sind Eigenschaften, die in der Regel als Kubernetes ConfigMap abgebildet werden. Jede Änderung (und die daraus resultierende Aktualisierung auf dem Cluster) auf einer ConfigMap löst kein rollierendes Update der Anwendung aus, was bedeutet, dass die Anwendung mit der vorherigen Version läuft, bis du sie manuell neu startest.

Kustomize bietet einige Funktionen, um automatisch ein Rolling Update durchzuführen, wenn sich die ConfigMap einer Anwendung ändert (siehe Rezept 4.5).

4.1 Kustomize für die Bereitstellung von Kubernetes-Ressourcen verwenden

Problem

Du möchtest mehrere Kubernetes-Ressourcen auf einmal bereitstellen.

Lösung

Verwende Kustomize, um zu konfigurieren, welche Ressourcen bereitgestellt werden sollen.

Die Bereitstellung einer Anwendung in einem Kubernetes-Cluster ist nicht so trivial wie die Anwendung einer YAML/JSON-Datei, die ein Kubernetes-Objekt Deployment enthält. Normalerweise müssen andere Kubernetes-Objekte wie Service, Ingress, ConfigMaps usw. definiert werden, was die Verwaltung und Aktualisierung dieser Ressourcen etwas komplizierter macht (je mehr Ressourcen verwaltet werden müssen, desto größer ist die Gefahr, dass die falsche aktualisiert wird) und auch die Anwendung in einem Cluster (sollen wir mehrere kubectl -Befehle ausführen?).

Kustomize ist ein CLI-Tool, das in integriert ist, dem kubectl Tool zur Verwaltung, Anpassung und Anwendung von Kubernetes-Ressourcen ohne Templates.

Mit Kustomize musst du ein Basisverzeichnis mit Standard-Kubernetes-Ressourcendateien anlegen (es sind keine Platzhalter erforderlich) und eine kustomization.yaml-Datei erstellen, in der Ressourcen und Anpassungen deklariert werden, wie du in Abbildung 4-1 sehen kannst.

Lass uns eine einfache Webseite mit HTML-, JavaScript- und CSS-Dateien einrichten.

Öffne zunächst ein Terminalfenster und erstelle ein Verzeichnis mit dem Namen pacman, dann erstelle drei Kubernetes-Ressourcen Dateien, um eine Namespace, eine Deployment und eine Service mit folgendem Inhalt zu erstellen.

Der Namensraum unter pacman/namespace.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: pacman

Die Verteilungsdatei unter pacman/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pacman-kikd
  namespace: pacman
  labels:
    app.kubernetes.io/name: pacman-kikd
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
          - image: lordofthejars/pacman-kikd:1.0.0
            imagePullPolicy: Always
            name: pacman-kikd
            ports:
              - containerPort: 8080
                name: http
                protocol: TCP

Die Dienstdatei unter pacman/service.yaml:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  ports:
    - name: http
      port: 8080
      targetPort: 8080
  selector:
    app.kubernetes.io/name: pacman-kikd

Beachte , dass diese Dateien Kubernetes-Dateien sind, die du problemlos auf einen Kubernetes-Cluster anwenden kannst, da keine Sonderzeichen oder Platzhalter verwendet werden.

Der zweite Schritt ist die Erstellung der Datei kustomization.yaml im pacman-Verzeichnis, die die Liste der Ressourcen enthält, die zur Anwendung gehören und bei der Ausführung von Kustomize angewendet werden:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization 
resources: 
- ./namespace.yaml
- ./deployment.yaml
- ./service.yaml

: Anpassungsdatei
: Ressourcen, die zur Anwendung gehören, werden in der Reihenfolge "Tiefe zuerst" verarbeitet

Unter können wir die Anpassungsdatei auf einen laufenden Cluster anwenden, indem wir den folgenden Befehl ausführen:

kubectl apply --dry-run=client -o yaml \ 
              -k ./

: Druckt das Ergebnis des Anpassungslaufs, ohne das Ergebnis an den Cluster zu senden
: Mit der Option -k wird kubectl so eingestellt, dass die Anpassungsdatei verwendet wird
: Verzeichnis mit der übergeordneten Datei kustomization.yaml

Hinweis

Wir gehen davon aus, dass du bereits einen Minikube-Cluster wie in Rezept 2.3 gezeigt gestartet hast.

Die Ausgabe ist die YAML-Datei, die an den Server gesendet werden würde, wenn die Option dry-run nicht verwendet würde:

apiVersion: v1
items: 
- apiVersion: v1
  kind: Namespace 
  metadata:
    name: pacman
- apiVersion: v1
  kind: Service 
  metadata:
    labels:
      app.kubernetes.io/name: pacman-kikd
    name: pacman-kikd
    namespace: pacman
  spec:
    ports:
    - name: http
      port: 8080
      targetPort: 8080
    selector:
      app.kubernetes.io/name: pacman-kikd
- apiVersion: apps/v1
  kind: Deployment 
  metadata:
    labels:
      app.kubernetes.io/name: pacman-kikd
    name: pacman-kikd
    namespace: pacman
  spec:
    replicas: 1
    selector:
      matchLabels:
        app.kubernetes.io/name: pacman-kikd
    template:
      metadata:
        labels:
          app.kubernetes.io/name: pacman-kikd
      spec:
        containers:
        - image: lordofthejars/pacman-kikd:1.0.0
          imagePullPolicy: Always
          name: pacman-kikd
          ports:
          - containerPort: 8080
            name: http
            protocol: TCP
kind: List
metadata: {}

: Liste aller in kustomization.yaml definierten Kubernetes-Objekte, die angewendet werden sollen
: Das Namensraum-Dokument
: Das Dienstleistungsdokument
: Das Dokument zum Einsatz

Diskussion

Der Bereich resources unterstützt verschiedene Eingaben, zusätzlich zum direkten Setzen der YAML-Dateien.

Du kannst zum Beispiel ein Basisverzeichnis mit seiner eigenen kustomization.yaml und Kubernetes-Ressourcen-Dateien festlegen und es von einer anderen kustomization.yaml-Datei in einem anderen Verzeichnis referenzieren.

Gegeben sei die folgende Verzeichnisstruktur:

.
├── base
│   ├── kustomization.yaml
│   └── deployment.yaml
├── kustomization.yaml
├── configmap.yaml

Und die Kustomization-Definitionen im Basisverzeichnis:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml

Du wirst sehen, dass das Stammverzeichnis einen Link zum Basisverzeichnis und eine ConfigMap Definition hat:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./base
- ./configmap.yaml

Wenn du also die Root-Kustomisierungsdatei anwendest, werden automatisch die Ressourcen angewendet, die in der Basis-Kustomisierungsdatei definiert sind.

Außerdem kann resources über eine URL, die dem HashiCorp-URL-Format entspricht, auf externe Assets verweisen. Wir verweisen zum Beispiel auf ein GitHub-Repository, indem wir die URL angeben:

resources:
- github.com/lordofthejars/mysql 
- github.com/lordofthejars/mysql?ref=test

: Repository mit einer kustomization.yaml-Datei auf der Stammebene
: Repository mit einer kustomization.yaml-Datei auf Root-Ebene im Zweig test

Du hast die Anwendung einer Kustomize-Datei mit kubectl gesehen, aber Kustomize kommt auch mit einem eigenen CLI-Tool, das eine Reihe von Befehlen zur Interaktion mit Kustomize-Ressourcen bietet.

Der entsprechende Befehl zum Erstellen von Kustomize-Ressourcen unter Verwendung von kustomize anstelle von kubectl lautet:

kustomize build

Und die Ausgabe ist:

apiVersion: v1
kind: Namespace
metadata:
  name: pacman
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  selector:
    app.kubernetes.io/name: pacman-kikd
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.0.0
        imagePullPolicy: Always
        name: pacman-kikd
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

Wenn du diese von kustomize erzeugte Ausgabe auf den Cluster anwenden möchtest, führe den folgenden Befehl aus:

kustomize build . | kubectl apply -f -

Siehe auch

4.2 Aktualisieren des Container-Images in Kustomize

Problem

Du möchtest das Container-Image aus einer Bereitstellungsdatei mit Kustomize aktualisieren.

Lösung

Verwende den Abschnitt images , um das Container-Image zu aktualisieren.

Einer der wichtigsten und meistgenutzten Vorgänge bei der Softwareentwicklung ist das Aktualisieren der Anwendung auf eine neuere Version, entweder mit einer Fehlerbehebung oder mit einer neuen Funktion. In Kubernetes bedeutet das, dass du ein neues Container-Image erstellen und es mit Hilfe des tag Abschnitts (<registry>/<username>/<project>:<tag>) entsprechend benennen musst.

Gegeben ist die folgende partielle Einsatzdatei:

spec:
    containers:
        - image: lordofthejars/pacman-kikd:1.0.0 
        imagePullPolicy: Always
        name: pacman-kikd

: Dienst 1.0.0 wird eingesetzt

Wir können das Versions-Tag auf 1.0.1 aktualisieren, indem wir den images Abschnitt in der kustomization.yaml Datei verwenden:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./namespace.yaml
- ./deployment.yaml
- ./service.yaml
images: 
- name: lordofthejars/pacman-kikd 
  newTag: 1.0.1

: images Abschnitt
: Legt den Namen des zu aktualisierenden Bildes fest
: Setzt den neuen Tag-Wert für das Bild

Verwende kubectl in dry-run oder kustomize, um zu überprüfen, ob die Ausgabe der Deployment-Datei die neue Tag-Version enthält. Führe in einem Terminalfenster den folgenden Befehl aus:

kustomize build

Die Ausgabe des vorangegangenen Befehls ist:

...
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.0.1 
        imagePullPolicy: Always
        name: pacman-kikd
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

: Version in der Datei kustomize.yaml eingestellt

Hinweis

Kustomize ist nicht aufdringlich, was bedeutet, dass die ursprüngliche deployment.yaml-Datei immer noch das ursprüngliche Tag (1.0.0) enthält.

Diskussion

Eine Möglichkeit, das Feld newTag zu aktualisieren, ist die Bearbeitung der Datei kustomization.yaml, aber du kannst auch das Tool kustomize für diesen Zweck verwenden.

Führe den folgenden Befehl in demselben Verzeichnis wie die Datei kustomization.yaml aus:

kustomize edit set image lordofthejars/pacman-kikd:1.0.2

Überprüfe den Inhalt der Datei kustomization.yaml, um zu sehen, ob das Feld newTag aktualisiert wurde:

...
images:
- name: lordofthejars/pacman-kikd
  newTag: 1.0.2

4.3 Aktualisieren beliebiger Kubernetes-Felder in Kustomize

Problem

Du möchtest ein Feld (z.B. die Anzahl der Replikate) mit Kustomize aktualisieren.

Lösung

Verwende den Abschnitt patches, um eine Änderung mit der JSON Patch-Spezifikation anzugeben.

Im vorherigen Rezept hast du gesehen, wie du das Container-Image-Tag aktualisieren kannst. Manchmal kannst du aber auch andere Parameter wie die Anzahl der Replikate ändern oder Anmerkungen, Beschriftungen, Grenzen usw. hinzufügen.

Um diese Szenarien abzudecken, unterstützt Kustomize die Verwendung von JSON Patch, um jede Kubernetes-Ressource zu ändern, die als Kustomize-Ressource definiert ist. Um es zu verwenden, musst du den JSON Patch-Ausdruck angeben, der angewendet werden soll, und die Ressource, auf die der Patch angewendet werden soll.

Wir können zum Beispiel die Anzahl der Replikate in der folgenden partiellen Bereitstellungsdatei von einem auf drei ändern:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pacman-kikd
  namespace: pacman
  labels:
    app.kubernetes.io/name: pacman-kikd
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
...

Als Erstes aktualisieren wir die Datei kustomization.yaml, um die Anzahl der Replikate zu ändern, die in der Bereitstellungsdatei definiert sind:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
patches: 
  - target: 
      version: v1
      group: apps
      kind: Deployment
      name: pacman-kikd
      namespace: pacman
    patch: |- 
      - op: replace 
        path: /spec/replicas 
        value: 3

: Patch-Ressource.
: target Abschnitt legt fest, welches Kubernetes-Objekt geändert werden muss. Diese Werte stimmen mit der zuvor erstellten Deployment-Datei überein.
: Patch-Ausdruck.
: Änderung eines Wertes.
: Pfad zu dem zu ändernden Feld.
: Neuer Wert.

Verwende schließlich kubectl in dry-run oder kustomize, um zu überprüfen, ob die Ausgabe der Deployment-Datei die neue Tag-Version enthält. Führe in einem Terminal-Fenster den folgenden Befehl aus:

kustomize build

Die Ausgabe des vorangegangenen Befehls ist:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
...

Tipp

Der Wert der Replikate kann auch über das Feld replicas in der Datei kustomization.yaml aktualisiert werden.

Die entsprechende Kustomize-Datei, die das Feld replicas verwendet, wird im folgenden Ausschnitt gezeigt:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
replicas:
- name: pacman-kikd 
  count: 3 
resources:
- deployment.yaml

: Einsatz zur Aktualisierung der Replikate
: Neuer Wert replicas

Mit Kustomize kannst du nicht nur einen Wert ändern, sondern auch Werte hinzufügen (oder löschen). Sehen wir uns an, wie man ein neues Etikett hinzufügt:

...
patches:
  - target:
      version: v1
      group: apps
      kind: Deployment
      name: pacman-kikd
      namespace: pacman
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 3
      - op: add 
        path: /metadata/labels/testkey 
        value: testvalue

: Fügt ein neues Feld mit dem Wert
: Pfad mit dem Feld, das hinzugefügt werden soll
: Der zu setzende Wert

Das Ergebnis der Anwendung der Datei ist:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
    testkey: testvalue 
  name: pacman-kikd
  namespace: pacman
spec:
  replicas: 3
  selector:
...

: Etikett hinzugefügt

Diskussion

Anstatt einen JSON Patch-Ausdruck einzubetten, kannst du eine YAML-Datei mit einem Patch-Ausdruck erstellen und auf diesen über das Feld path anstelle von patch verweisen.

Erstelle eine externe Patch-Datei mit dem Namen external_patch, die den JSON Patch-Ausdruck enthält:

- op: replace
  path: /spec/replicas
  value: 3
- op: add
  path: /metadata/labels/testkey
  value: testvalue

Und ändere das Feld patch in path, das auf die Patchdatei zeigt:

...
patches:
  - target:
      version: v1
      group: apps
      kind: Deployment
      name: pacman-kikd
      namespace: pacman
    path: external_patch.yaml

: Pfad zur externen Patch-Datei

Neben dem JSON-Patch-Ausdruck unterstützt Kustomize auch Strategic Merge Patch, um Kubernetes-Ressourcen zu verändern. Ein Strategic Merge Patch (oder SMP) ist eine unvollständige YAML-Datei, die mit einer vollständigen YAML-Datei zusammengeführt wird.

Um ein Container-Image zu aktualisieren, ist nur eine minimale Bereitstellungsdatei mit Informationen zum Containernamen erforderlich:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
patches:
  - target:
      labelSelector: "app.kubernetes.io/name=pacman-kikd" 
    patch: |- 
      apiVersion: apps/v1 
      kind: Deployment
      metadata:
        name: pacman-kikd
      spec:
        template:
          spec:
            containers:
              - name: pacman-kikd
                image: lordofthejars/pacman-kikd:1.2.0

: Das Ziel wird mit dem Etikett ausgewählt
: Der Patch ist intelligent genug, um zu erkennen, ob es sich um einen SMP- oder JSON-Patch handelt.
: Dies ist eine minimale Einsatzdatei
: Legt nur das zu ändernde Feld fest, der Rest bleibt unverändert

Die erzeugte Ausgabe ist die ursprüngliche deployment.yaml-Datei, aber mit dem neuen Container-Image :

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: pacman
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.2.0
        imagePullPolicy: Always
...

Tipp

path wird ebenfalls unterstützt.

Siehe auch

4.4 Einsatz in mehreren Umgebungen

Problem

Du möchtest die gleiche Anwendung in verschiedenen Namensräumen mit Kustomize einsetzen.

Lösung

Verwende das Feld namespace , um den Ziel-Namensraum festzulegen.

In manchen Fällen ist es sinnvoll, die Anwendung in verschiedenen Namensräumen bereitzustellen, z. B. wenn ein Namensraum als Staging-Umgebung und ein anderer als Produktions-Namensraum verwendet wird. In beiden Fällen sind die Kubernetes-Basisdateien dieselben, mit minimalen Änderungen wie dem bereitgestellten Namensraum, einigen Konfigurationsparametern oder der Containerversion, um nur einige zu nennen. Abbildung 4-2 zeigt ein Beispiel.

kustomize ermöglicht es dir, mehrere Änderungen mit einem anderen Namensraum als Overlays auf einer gemeinsamen Basis zu definieren, indem du das Feld namespace verwendest. Für dieses Beispiel werden alle Basis-Kubernetes-Ressourcen in das Verzeichnis base gelegt und ein neues Verzeichnis für die Anpassungen der einzelnen Umgebungen erstellt:

.
├── base 
│  ├── deployment.yaml
│  └── kustomization.yaml
├── production
│   └── kustomization.yaml 
└── staging
    └── kustomization.yaml

: Basisdateien
: Spezifische Änderungen in der Produktionsumgebung
: Spezifische Änderungen in der Staging-Umgebung

Die Basis-Kustomisierungsdatei enthält einen Verweis auf ihre Ressourcen:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml

Es gibt eine Anpassungsdatei mit einigen Parametern für jedes Umgebungsverzeichnis. Diese verweisen auf das Basisverzeichnis, den Namensraum, der in die Kubernetes-Ressourcen injiziert werden soll, und schließlich auf das zu deployende Image, das in der Produktion 1.1.0 und im Staging 1.2.0-beta ist.

Der Inhalt der kustomization.yaml für die Staging-Umgebung ist in der folgenden Liste aufgeführt:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base 
namespace: staging 
images:
- name: lordofthejars/pacman-kikd
  newTag: 1.2.0-beta

: Verweise auf das Basisverzeichnis
: Setzt den Namensraum auf Staging
: Setzt das Container-Tag für die Staging-Umgebung

Die Anpassungsdatei für die Produktion ähnelt der Staging-Datei, ändert aber den Namensraum und das Tag:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base
namespace: prod 
images:
- name: lordofthejars/pacman-kikd
  newTag: 1.1.0

: Legt den Namensraum für die Produktion fest
: Setzt das Container-Tag für die Produktionsumgebung

Wenn du kustomize ausführst, erhältst du je nach Verzeichnis, in dem du es ausführst, unterschiedliche Ausgaben. Wenn du zum Beispiel kustomize build im Staging-Verzeichnis ausführst, erhältst du eine andere Ausgabe:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: staging 
spec:
  replicas: 1
...
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.2.0-beta 
...

: Namensraumwert wird injiziert
: Container-Tag für die Staging-Umgebung wird injiziert

Wenn du es aber im Produktionsverzeichnis ausführst, wird die Ausgabe an die Produktionskonfiguration angepasst:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
  namespace: prod 
spec:
  replicas: 1
...
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.1.0 
...

: Injiziert den Produktionsnamensraum
: Container-Tag für die Produktionsumgebung

Diskussion

Kustomize kann einen Wert an die Namen aller Ressourcen und Referenzen anhängen. Das ist nützlich, wenn je nach Umgebung ein anderer Name in der Ressource erforderlich ist oder um die eingesetzte Version im Namen festzulegen:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base
namespace: staging
namePrefix: staging- 
nameSuffix: -v1-2-0 
images:
- name: lordofthejars/pacman-kikd
  newTag: 1.2.0-beta

: Präfix zum Voranstellen
: Suffix zum Anhängen

Und das Ergebnis sieht wie folgt aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: staging-pacman-kikd-v1-2-0 
  namespace: staging
spec:
...

: Neuer Name von der Einsatzdatei

4.5 Erzeugen von ConfigMaps in Kustomize

Problem

Du möchtest Kubernetes ConfigMaps mit Kustomize erstellen.

Lösung

Nutze das ConfigMapGenerator Feature-Feld, um eine Kubernetes ConfigMap Ressource on the fly zu erstellen.

Kustomize bietet zwei Möglichkeiten, eine ConfigMap als Kustomize-Ressource hinzuzufügen: entweder durch Deklaration einer ConfigMap wie jede andere Ressource oder durch Deklaration einer ConfigMap aus einer ConfigMapGenerator.

Während die Verwendung von ConfigMap als Ressource keinen anderen Vorteil bietet als die Befüllung von Kubernetes-Ressourcen wie jede andere Ressource, fügt ConfigMapGenerator automatisch einen Hash an den Metadatennamen ConfigMap an und ändert auch die Bereitstellungsdatei mit dem neuen Hash. Diese minimale Änderung hat tiefgreifende Auswirkungen auf den Lebenszyklus der Anwendung, wie wir gleich im Beispiel sehen werden.

Betrachten wir eine Anwendung, die in Kubernetes läuft und mit ConfigMapkonfiguriert wurde, z. B. ein Parameter für die Zeitüberschreitung der Datenbankverbindung. Wir haben beschlossen, diese Zahl irgendwann zu erhöhen, also wird die Datei ConfigMap auf diesen neuen Wert geändert und wir stellen die Anwendung erneut bereit. Da ConfigMap die einzige geänderte Datei ist, wird kein rollierendes Update der Anwendung durchgeführt. Es muss ein manuelles rollierendes Update der Anwendung ausgelöst werden, um die Änderung an die Anwendung weiterzugeben.Abbildung 4-3 zeigt, was geändert wird, wenn ein ConfigMap Objekt aktualisiert wird.

Wenn ConfigMapGenerator die ConfigMap verwaltet, ändert jede Änderung an der Konfigurationsdatei auch die Bereitstellungsressource Kubernetes. Da sich auch die Bereitstellungsdatei geändert hat, wird ein automatisches Rolling Update ausgelöst, wenn die Ressourcen angewendet werden, wie in Abbildung 4-4 dargestellt.

Außerdem können bei der Verwendung von ConfigMapGenerator mehrere Konfigurationsdateien in einer einzigen ConfigMap zusammengefasst werden, was ein perfekter Anwendungsfall ist, wenn jede Umgebung unterschiedliche Konfigurationsdateien hat.

Change of a ConfigMap using ConfigMapGenerator

Beginnen wir mit einem einfachen Beispiel, indem wir den Abschnitt ConfigMapGenerator in der Datei kustomization.yaml hinzufügen.

Die Bereitstellungsdatei ähnelt der in den vorherigen Abschnitten dieses Kapitels verwendeten Datei, enthält aber den Abschnitt volumes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pacman-kikd
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.0.0
        imagePullPolicy: Always
        name: pacman-kikd
        volumeMounts:
        - name: config
          mountPath: /config
      volumes:
      - name: config
        configMap:
          name: pacman-configmap

: ConfigMap Name wird in der Datei kustomization.yaml verwendet

Die Konfigurationseigenschaften sind in die Datei kustomization.yaml eingebettet. Beachte, dass das Objekt ConfigMap während der Erstellung der kustomization-Datei erstellt wird:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
configMapGenerator:
- name: pacman-configmap 
  literals:	
  - db-timeout=2000 
  - db-username=Ada

: Name des ConfigMap Satzes in der Bereitstellungsdatei
: Bettet Konfigurationswerte in die Datei ein
: Setzt ein Schlüssel/Wert-Paar für die Eigenschaften

kustomize build

Die Ausgabe des vorangegangenen Befehls ist eine neue ConfigMap mit den in kustomization.yaml festgelegten Konfigurationswerten. Außerdem wird der Name der ConfigMap durch Anhängen eines Hashes sowohl in der erzeugten ConfigMap als auch in der Bereitstellung aktualisiert:

apiVersion: v1
data: 
  db-timeout: "2000"
  db-username: Ada
kind: ConfigMap
metadata:
  name: pacman-configmap-96kb69b6t4 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: pacman-kikd
  template:
    metadata:
      labels:
        app.kubernetes.io/name: pacman-kikd
    spec:
      containers:
      - image: lordofthejars/pacman-kikd:1.0.0
        imagePullPolicy: Always
        name: pacman-kikd
        volumeMounts:
        - mountPath: /config
          name: config
      volumes:
      - configMap:
          name: pacman-configmap-96kb69b6t4 
        name: config

: ConfigMap mit Eigenschaften
: Name mit Raute
: Das Feld "Name" wird auf das Feld mit der Raute aktualisiert, das eine rollierende Aktualisierung auslöst.

Da der Hash für jede Änderung der Konfigurationseigenschaften berechnet wird, führt eine Änderung dieser Eigenschaften zu einer Änderung der Ausgabe und damit zu einer rollierenden Aktualisierung der Anwendung. Öffne die Datei kustomization.yaml und aktualisiere das db-timeout Literal von 2000 auf 1000 und führe kustomize build erneut aus. Beachte die Änderung des ConfigMap Namens mit einem neuen Hash-Wert:

apiVersion: v1
data:
  db-timeout: "1000"
  db-username: Ada
kind: ConfigMap
metadata:
  name: pacman-configmap-6952t58tb4 
---
apiVersion: apps/v1
kind: Deployment
...
    volumes:
      - configMap:
          name: pacman-configmap-6952t58tb4
        name: config

: Neuer Hash-Wert

Diskussion

ConfigMapGenerator unterstützt auch das Zusammenführen von Konfigurationseigenschaften aus verschiedenen Quellen.

Erstelle eine neue Datei kustomization.yaml im Verzeichnis dev_literals, indem du es als das vorherige Verzeichnis einstellst und den Wert db-username überschreibst:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../literals 
configMapGenerator:
- name: pacman-configmap
  behavior: merge 
  literals:
  - db-username=Alexandra

: Basisverzeichnis
: Eigenschaften zusammenführen (kann auch create oder replace sein)
: Überschriebener Wert

Wenn du den Befehl kustomize build ausführst, wird eine ConfigMap erstellt, die eine Zusammenführung beider Konfigurationseigenschaften enthält:

apiVersion: v1
data:
  db-timeout: "1000" 
  db-username: Alexandra 
kind: ConfigMap
metadata:
  name: pacman-configmap-ttfdfdk5t8
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
...

: Erbt von base
: Überschreibt den Wert

Unter kannst du nicht nur Konfigurationseigenschaften als Literale festlegen, sondern sie auch als .properties-Dateien definieren.

Erstelle eine Datei connection.properties mit zwei Eigenschaften darin:

db-url=prod:4321/db
db-username=ada

Die Datei kustomization.yaml verwendet das Feld files anstelle von literals:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ./deployment.yaml
configMapGenerator:
- name: pacman-configmap
  files: 
  - ./connection.properties

: Legt eine Liste der zu lesenden Dateien fest
: Pfad zur Eigenschaftsdatei

Wenn du ausführst, erzeugt der Befehl kustomize build eine ConfigMap, die den Namen der Datei als Schlüssel und den Wert als Inhalt der Datei enthält:

apiVersion: v1
data:
  connection.properties: |-
    db-url=prod:4321/db
    db-username=ada
kind: ConfigMap
metadata:
  name: pacman-configmap-g9dm2gtt77
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: pacman-kikd
  name: pacman-kikd
...

Siehe auch

Kustomize bietet eine ähnliche Möglichkeit, mit Kubernetes Secrets umzugehen. Aber wie wir in Kapitel 8 sehen werden, ist der beste Weg, mit Kubernetes Secrets umzugehen, die Verwendung von Sealed Secrets.

4.6 Schlussgedanken

Kustomize ist ein einfaches Tool, das ohne Templating auskommt. Es ermöglicht dir, einfache YAML-Dateien zu definieren und Werte entweder mit einer Merge-Strategie oder mit JSON Patch-Ausdrücken zu überschreiben. Die Struktur eines Projekts ist frei, da du das Verzeichnislayout festlegen kannst, mit dem du dich am wohlsten fühlst; die einzige Voraussetzung ist das Vorhandensein einer kustomization.yaml-Datei.

Es gibt aber noch ein weiteres bekanntes Tool zur Verwaltung von Kubernetes-Ressourcen-Dateien, das unserer Meinung nach etwas komplizierter, aber auch leistungsfähiger ist, vor allem, wenn die zu deployende Anwendung/der zu deployende Dienst mehrere Abhängigkeiten hat, wie z.B. Datenbanken, Mailserver, Caches, usw. Dieses Tool ist Helm, und wir werden es in Kapitel 5 behandeln.

Get GitOps Kochbuch now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

GitOps Kochbuch by Natale Vinto, Alex Soto Bueno

Kapitel 4. Anpassen

4.1 Kustomize für die Bereitstellung von Kubernetes-Ressourcen verwenden

Problem

Lösung

Abbildung 4-1. Kustomize Layout

Hinweis

Diskussion

Siehe auch

4.2 Aktualisieren des Container-Images in Kustomize

Problem

Lösung

Hinweis

Diskussion

4.3 Aktualisieren beliebiger Kubernetes-Felder in Kustomize

Problem

Lösung

Tipp

Diskussion

Tipp

Siehe auch

4.4 Einsatz in mehreren Umgebungen

Problem

Lösung

Abbildung 4-2. Kustomize Layout

Diskussion

4.5 Erzeugen von ConfigMaps in Kustomize

Problem

Lösung

Abbildung 4-3. Änderung einer `ConfigMap`

Abbildung 4-4. Änderung einer `ConfigMap` mit `ConfigMapGenerator`

Diskussion

Siehe auch

4.6 Schlussgedanken

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly

Kapitel 4. Anpassen

4.1 Kustomize für die Bereitstellung von Kubernetes-Ressourcen verwenden

Problem

Lösung

Abbildung 4-1. Kustomize Layout

Hinweis

Diskussion

Siehe auch

4.2 Aktualisieren des Container-Images in Kustomize

Problem

Lösung

Hinweis

Diskussion

4.3 Aktualisieren beliebiger Kubernetes-Felder in Kustomize

Problem

Lösung

Tipp

Diskussion

Tipp

Siehe auch

4.4 Einsatz in mehreren Umgebungen

Problem

Lösung

Abbildung 4-2. Kustomize Layout

Diskussion

4.5 Erzeugen von ConfigMaps in Kustomize

Problem

Lösung

Abbildung 4-3. Änderung einer ConfigMap

Abbildung 4-4. Änderung einer ConfigMap mit ConfigMapGenerator

Diskussion

Siehe auch

4.6 Schlussgedanken

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly

Abbildung 4-3. Änderung einer `ConfigMap`

Abbildung 4-4. Änderung einer `ConfigMap` mit `ConfigMapGenerator`