Kurze Einführung in Kustomize

Hinweis.: Dieser Artikel wurde von Scott Lowe verfasst, einem erfahrenen IT-Ingenieur und Autor von sieben Fachbüchern, vorwiegend über VMware vSphere. Momentan arbeitet er bei der Tochtergesellschaft von VMware - Heptio (2016 übernommen) und spezialisiert sich auf Cloud Computing und Kubernetes. Der Text bietet eine prägnante und verständliche Einführung in die Konfigurationsverwaltung für Kubernetes mit Hilfe von Kustomize, das kürzlich Teil von K8s wurde.

Kustomize ist ein Werkzeug, das es den Nutzern ermöglicht, "einfache, templatefreie YAML-Dateien für verschiedene Zwecke anzupassen, während das originale YAML unberührt und weiterhin nutzbar bleibt" (Beschreibung direkt aus dem kustomize Repository auf GitHub). Kustomize kann direkt ausgeführt werden oder, beginnend mit Kubernetes 1.14, über kubectl -k , um auf dessen Funktionen zuzugreifen (obwohl ab Kubernetes 1.15 das separate Binärprogramm neuer ist als die in kubectl integrierten Funktionen). (Hinweis.: Mit dem kürzlichen Release von Kubernetes 1.16 kustomize wird unterstützt ist es jetzt auch in der kubeadm Utility verfügbar.) In diesem Beitrag möchte ich die Leser in die Grundlagen von kustomize einführen.

In seiner einfachsten Form ist kustomize lediglich eine Sammlung von Ressourcen (YAML-Dateien, die Kubernetes-Objekte definieren: Deployments, Services usw.) plus eine Liste von Anweisungen, welche Änderungen an diesen Ressourcen vorgenommen werden sollen. Ähnlich wie make ein Set von Anweisungen verwendet, das in Makefileenthalten ist, und Docker ein Container basierend auf Anweisungen aus Dockerfile, verwendet kustomize kustomization.yaml zum Speichern von Vorgaben dazu, 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, alle möglichen Felder in der Datei zu erläutern kustomization.yaml (darüber ist bereits gut geschrieben hier), aber ich werde eine kurze Erklärung zu einem bestimmten Beispiel geben:

• Feld resources zeigt an, welche Ressourcen kustomize ändern wird. In diesem Fall wird es nach 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-) zu dem Attribut name aller Ressourcen hinzuzufügen, die im Feld resourcesdefiniert sind. Somit, wenn im Deployment name mit dem Wert nginx-deployment, wird kustomize daraus dev-nginx-deployment machen..
• Feld namespace weist kustomize an, den angegebenen Namensraum zu allen Ressourcen hinzuzufügen. In diesem Fall werden Deployment und Service im Namensraum platziert. Entwicklung.
• Schließlich enthält das Feld commonLabels eine Reihe von Labels, die zu allen Ressourcen hinzugefügt werden. In unserem Beispiel wird kustomize den Ressourcen ein Label mit dem Namen zuweisen environment und dem Wert Entwicklung.

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

Hinweis.: Eine Abbildung aus der Dokumentation des Projekts zur "einfachen" Verwendung von kustomize

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

kustomize build . > custom-config.yaml

Die Ausgaben sind deterministisch (bei gleichen Eingabewerten werden die gleichen Ergebnisse ausgegeben), daher ist es nicht notwendig, das Ergebnis in einer Datei zu speichern. 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 von Kubernetes) erfolgen. Beachten Sie jedoch, dass das separate kustomize-Paket schneller aktualisiert wird als die integrierte Version in kubectl (zumindest ist das bei der Veröffentlichung von Kubernetes 1.15 der Fall).

Leser könnten sich fragen: „Warum all diese Komplexität, wenn man die Dateien direkt bearbeiten kann?“. Eine gute Frage. In unserem Beispiel ist es tatsächlich möglich, kann die Dateien deployment.yaml und service.yaml direkt zu bearbeiten, aber was ist, wenn sie ein Fork eines Projekts sind? Änderungen an den Dateien direkt vorzunehmen, erschwert (oder macht es überhaupt unmöglich) das Rebase des Forks, wenn Änderungen an der Quelle vorgenommen werden. Der Einsatz von kustomize ermöglicht es, diese Änderungen zentral in einer Datei zu verwalten kustomization.yaml, während die Originaldateien unberührt bleiben und das Rebase der ursprünglichen Dateien bei Bedarf erleichtert wird.

Die Vorteile von kustomize werden in komplexeren Anwendungsfällen offensichtlich. Im obigen Beispiel kustomization.yaml liegen die Ressourcen im gleichen Verzeichnis. Kustomize unterstützt jedoch auch Anwendungsfälle, in denen es eine Basis-Konfiguration und viele ihrer Varianten, auch bekannt als overlays, gibt. Zum Beispiel möchte der Benutzer ein Deployment und einen Service für nginx, die ich als Beispiel verwendet habe, nehmen und Entwicklungs-, Staging- und Produktionsvarianten (oder -versionen) dieser Dateien erstellen. Dazu benötigt er die oben erwähnten Overlays und die Basisressourcen selbst.

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

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

In der Datei base/kustomization.yaml Benutzer geben im Feld resources einfach die Ressourcen an, die kustomize einfügen soll.

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

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

Gleichzeitig könnte die Datei overlays/prod/kustomization.yaml völlig anders aussehen:

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

Wenn der Benutzer kustomize build . im Verzeichnis overlays/dev, ausführt, generiert kustomize die Entwicklungsvariante. Wenn jedoch kustomize build . im Verzeichnis overlays/prod ausgeführt wird - ergibt sich die Produktionsvariante. Und das alles geschieht, ohne dass Änderungen an den ursprünglichen (Basis) vorgenommen werden. Dateien und alles wird auf deklarative und deterministische Weise verwaltet. Sie können die Basiskonfiguration und Overlay-Verzeichnisse direkt in das Versionskontrollsystem übernehmen, in dem Wissen, dass die gewünschte Konfiguration jederzeit anhand dieser Dateien reproduziert werden kann.

Hinweis.: Illustration aus der Projektdokumentation zur Verwendung von Overlays in Kustomize

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

Zusätzliche Ressourcen

Es gibt viele ausgezeichnete Artikel und Veröffentlichungen zu Kustomize. Hier sind einige, die ich als besonders hilfreich empfunden habe:

• Basiskonfiguration YAML für verschiedene Umgebungen prod/test mit Kustomize anpassen;
• Kustomize – Der richtige Weg zur Template-Erstellung in Kubernetes;
• Deklarative Verwaltung von Kubernetes-Objekten mit Kustomize;
• Anpassung von upstream Helm Charts mit Kustomize.

Hinweis.: Außerdem kann ich einen Linkblock empfehlen, der veröffentlicht wurde als Ressourcen auf der Website des Tools sowie die nachfolgenden Videos mit den neuesten Vorträgen über Kustomize.

Wenn Sie Fragen oder Vorschläge zur Verbesserung dieses Materials haben, bin ich immer offen für Feedback. Sie können mich im Twitter oder über Kubernetes Slack-Kanal. Viel Spaß beim Anpassen Ihrer Manifeste mit Kustomize!

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

• «Werkzeuge für Entwickler von Anwendungen, die in Kubernetes laufen»;
• «Kubernetes 1.14: Überblick über die wichtigsten Neuerungen»;
• «Die fünf wichtigsten Erkenntnisse vom Helm Summit 2019 in Amsterdam»;
• «Praktische Einführung in den Paketmanager für Kubernetes – Helm».

Quelle: habr.com