🥇Kurze Einführung in Kustomize

Anmerkung des Übersetzers.: Der Artikel wurde von Scott Lowe geschrieben – einem erfahrenen IT-Ingenieur, der Autor und Mitautor von sieben gedruckten Büchern (hauptsächlich über VMware vSphere) ist. Derzeit arbeitet er bei dessen Tochtergesellschaft VMware – Heptio (2016 übernommen), spezialisiert auf Cloud-Computing und Kubernetes. Der Text dient als prägnante und leicht verständliche Einführung in das Konfigurationsmanagement für Kubernetes mithilfe der Technologie Kustomize, die kürzlich in K8s integriert wurde.

Kustomize ist ein Tool, das es Benutzern ermöglicht, "einfache, unformatierte YAML-Dateien für verschiedene Zwecke anzupassen und das ursprüngliche YAML unverändert und nutzbar zu lassen" (Beschreibung direkt aus dem Kustomize-Repository auf GitHub). Kustomize kann direkt ausgeführt oder, beginnend mit Kubernetes 1.14, verwendet werden kubectl -k um auf seine Funktionen zuzugreifen (obwohl bei Kubernetes 1.15 das separate Binary neuer ist als die in kubectl integrierten Möglichkeiten). (Anmerkung des Übersetzers.: Mit dem kürzlichen Release Kubernetes 1.16 kustomize wird unterstützt ist es auch in der kubeadm-Utility verfügbar.) In dieser Veröffentlichung möchte ich die Leser mit den Grundlagen von Kustomize vertrautmachen.

In seiner einfachsten Form ist Kustomize nur eine Sammlung von Ressourcen (YAML-Dateien, die Kubernetes-Objekte definieren: Deployments, Services usw.) sowie eine Liste von Anweisungen, welche Änderungen an diesen Ressourcen vorzunehmen sind. Ähnlich wie make einen Satz von Anweisungen nutzt, die in Makefile, und Docker ein Container auf Basis der Anweisungen aus Dockerfile, verwendet Kustomize kustomization.yaml um die Anweisungen zu speichern, welche Änderungen der Benutzer an der Ressourcensammlung vornehmen möchte.

Hier ist ein Beispiel für eine Datei kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Ich werde nicht versuchen, über alle möglichen Felder in der Datei zu sprechen kustomization.yaml (darüber ist schon viel geschrieben worden hier), aber ich werde eine kurze Erklärung zu einem speziellen Beispiel geben:

Feld resources zeigt an, welche Ressourcen Kustomize ändern wird. In diesem Fall wird es Ressourcen in den Dateien deployment.yaml und service.yaml in seinem Verzeichnis suchen (vollständige oder relative Pfade können bei Bedarf angegeben werden).
Feld namePrefix weist Kustomize an, ein bestimmtes Präfix (in diesem Fall – dev-) zum Attribut name aller Ressourcen, die im Feld resourcesdefiniert sind, hinzuzufügen. Wenn es im Deployment einen gibt name mit dem Wert nginx-deployment, wird Kustomize es in dev-nginx-deployment.
Feld Namespace umbenennen und weist Kustomize an, den angegebenen Namespace zu allen Ressourcen hinzuzufügen. In diesem Fall werden Deployment und Service in den Namespace Entwicklung.
Endlich, das Feld commonLabels enthält eine Reihe von Labels, die allen Ressourcen hinzugefügt werden. In unserem Beispiel wird kustomize den Ressourcen das Label mit dem Namen zuweisen Umgebung und mit dem Wert. Entwicklung.

Wenn der Benutzer kustomize build . in einem Verzeichnis mit der Datei kustomization.yaml und den erforderlichen Ressourcen (d.h. Dateien deployment.yaml und service.yaml), erhält er einen Text mit den Änderungen, die in kustomization.yaml.

Anmerkung des Übersetzers.: Abbildung aus der Dokumentation des Projekts über die "einfache" Verwendung von kustomize

Die Ausgabe kann umgeleitet werden, wenn Änderungen festgehalten werden sollen:

kustomize build . > custom-config.yaml

Die Ausgaben sind deterministisch (bei denselben Eingabedaten erhält man dieselben Ergebnisse), weshalb das Ergebnis nicht in einer Datei gespeichert werden muss. Stattdessen kann es direkt an einen anderen Befehl übergeben werden:

kustomize build . | kubectl apply -f -

Zugriff auf die Funktionen von kustomize kann auch über kubectl -k (ab Version 1.14 Kubernetes) erfolgen. Beachten Sie jedoch, dass das separate Paket kustomize schneller aktualisiert wird als das in kubectl integrierte (zumindest gilt dies für die Kubernetes-Version 1.15).

Leser könnten fragen: „Warum all diese Komplexität, wenn man die Dateien direkt bearbeiten kann?“. Gute Frage. In unserem Beispiel könnte man tatsächlich kann man Dateien deployment.yaml und service.yaml direkt bearbeiten, aber was, wenn sie ein Fork eines anderen Projekts sind? Direkte Änderungen an den Dateien erschweren (wenn nicht unmöglich machen) das Rebasieren des Forks, wenn Änderungen in die Quelle eingeführt werden. Die Verwendung von kustomize ermöglicht es, diese Änderungen in einer Datei zu zentralisieren kustomization.yaml, wobei die Originaldateien unberührt bleiben und somit ein Rebase der Ausgangsdateien bei Bedarf erleichtert wird.

Die Vorteile von kustomize werden in komplexeren Anwendungsfällen offensichtlich. In dem obigen Beispiel kustomization.yaml und die Ressourcen befinden sich im selben Verzeichnis. kustomize unterstützt jedoch Nutzungsszenarien, in denen es eine Basis-Konfiguration und mehrere Varianten davon gibt, auch bekannt als kubectl create cronjob. Zum Beispiel möchte der Benutzer das Deployment und den Service für nginx, die ich als Beispiel verwendet habe, nehmen und Development-, Staging- und Produktionsversionen (oder Varianten) dieser Dateien erstellen. Dazu benötigt er die oben genannten Overlays und die grundlegenden Ressourcen selbst.

Um die Idee von Overlays und Basishilfsmitteln zu veranschaulichen (Basisressourcen), nehmen wir an, dass die Verzeichnisse die folgende Struktur haben:

- basis
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

In der Datei basis/kustomization.yaml Benutzer verwenden das Feld resources um die Ressourcen zu deklarieren, die kustomize einbeziehen soll.

In jeder der Dateien overlays/{dev,staging,prod}/kustomization.yaml verweisen Benutzer auf die Basis-Konfiguration im Feld resources, und geben dann spezifische Änderungen für diese Umgebung. Zum Beispiel könnte die Datei overlays/dev/kustomization.yaml wie das zuvor gegebene Beispiel aussehen:

resources:
- ../../basis
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

Während die Datei overlays/prod/kustomization.yaml völlig anders sein kann:

resources:
- ../../basis
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

Wenn der Benutzer kustomize build . im Verzeichnis overlays/dev, wird kustomize eine Entwicklungsvariante generieren. Wenn jedoch kustomize build . im Verzeichnis overlays/prod ausgeführt wird, ergibt sich eine Produktionsvariante. Und das alles geschieht, ohne Änderungen an den ursprünglichen (Basis) Dateien vorzunehmen, und das alles deklarativ und deterministisch. Man kann die Basis-Konfiguration und die Overlay-Verzeichnisse direkt in ein Versionskontrollsystem einpflegen, in dem Wissen, dass man jederzeit auf Grundlage dieser Dateien die benötigte Konfiguration reproduzieren kann.

Anmerkung des Übersetzers.: Illustration aus der Dokumentation des Projekts zur Verwendung von Overlays in kustomize

Kustomize kann viel mehr, als in diesem Artikel beschrieben ist. Ich hoffe jedoch, dass er eine gute Einführung bietet.

Zusätzliche Ressourcen

Es gibt viele gute Artikel und Publikationen über kustomize. Hier sind einige, die ich als besonders hilfreich erachte:

Anmerkung des Übersetzers.: Es wird auch empfohlen, einen Block von Links zu empfehlen, veröffentlicht auf Ressourcen der Website des Dienstprogramms, sowie eine Sammlung von Videos mit den neuesten Vorträgen über kustomize.

Wenn Sie Fragen oder Vorschläge zur Verbesserung dieses Materials haben, stehe ich jederzeit für Feedback zur Verfügung. Sie erreichen mich im Twitter oder auf Slack-Kanal Kubernetes. Viel Spaß beim Modifizieren Ihrer Manifeste mit kustomize!

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

Quelle: habr.com