Eine kurze Einführung in Kustomize

Hinweis perev. : Der Artikel wurde von Scott Lowe verfasst, einem leitenden IT-Ingenieur, der sieben gedruckte Bücher (hauptsächlich für VMware vSphere) verfasst / mitverfasst hat. Derzeit arbeitet er bei der VMware-Tochter Heptio (2016 erworben), die sich auf Cloud Computing und Kubernetes spezialisiert hat. Der Text selbst dient als umfassende und leicht verständliche Einführung in das Konfigurationsmanagement für Kubernetes mithilfe der Kustomize- Technologie, die kürzlich in K8s enthalten war.



Kustomize ist ein Tool, mit dem Benutzer "einfache und vorlagenfreie YAML-Dateien für verschiedene Zwecke anpassen können, wobei die ursprüngliche YAML intakt und verwendbar bleibt" (die Beschreibung wird direkt aus dem kustomize-Repository auf GitHub ausgeliehen ). Kustomize kann direkt ausgeführt werden oder ab Kubernetes 1.14 kubectl -k um auf seine Funktionen zuzugreifen (obwohl ab Kubernetes 1.15 eine separate Binärdatei neuer ist als die in kubectl integrierten Funktionen). ( Hinweis : Mit der aktuellen Version von Kubernetes 1.16 wird kustomize auch im Dienstprogramm kubeadm unterstützt .) In diesem Beitrag möchte ich den Lesern die Grundlagen von kustomize vorstellen.

In seiner einfachsten Form / Anwendung ist kustomize einfach eine Sammlung von Ressourcen (YAML-Dateien, die Kubernetes-Objekte definieren: Bereitstellungen, Dienste usw.) sowie eine Liste von Anweisungen zu den Änderungen, die an diesen Ressourcen vorgenommen werden müssen. So wie make den im Makefile enthaltenen Befehlssatz verwendet und Docker Dockerfile Container basierend auf Anweisungen aus dem Dockerfile , verwendet kustomization.yaml , um Anweisungen darüber zu speichern, welche Änderungen der Benutzer am Ressourcensatz vornehmen möchte.

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

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

Ich werde nicht versuchen, über alle möglichen Felder in der Datei kustomization.yaml zu sprechen (dies ist hier gut geschrieben), aber ich werde eine kurze Erklärung eines bestimmten Beispiels geben:

• Das Feld resources gibt an, welche (welche Ressourcen) kustomize sich ändern wird. In diesem Fall sucht es in seinem Verzeichnis nach Ressourcen in den Dateien service.yaml und service.yaml (bei Bedarf können Sie vollständige oder relative Pfade angeben).
• Das Feld namePrefix weist kustomize an, dem Attribut name aller im Feld resources definierten resources ein bestimmtes Präfix (in diesem Fall dev- ) hinzuzufügen. Wenn es in Deployment einen name mit dem Wert nginx-deployment deploy gibt, macht kustomize daraus dev-nginx-deployment deploy.
• Das namespace Feld weist kustomize an, den angegebenen Namespace allen Ressourcen hinzuzufügen. In diesem Fall fallen Bereitstellung und Dienst in den development .
• Schließlich enthält das Feld commonLabels eine Reihe von Beschriftungen, die allen Ressourcen hinzugefügt werden. In unserem Beispiel weist kustomize den Ressourcen mit der Namensumgebung und der Wertentwicklung eine Bezeichnung zu.

Wenn der Benutzer kustomize build . Im Verzeichnis mit der Datei kustomization.yaml und den erforderlichen Ressourcen (d. kustomization.yaml deployment.yaml und service.yaml Dateien) erhält es bei der Ausgabe den Text mit den in kustomization.yaml registrierten kustomization.yaml .


Hinweis perev. : Illustration aus der Projektdokumentation für die „einfache“ Verwendung von kustomize

Die Ausgabe kann umgeleitet werden, wenn Sie die Änderungen festschreiben müssen:

 kustomize build . > custom-config.yaml 

Die Ausgabe ist deterministisch (mit derselben Eingabe wird dieselbe Ausgabe erhalten), sodass Sie das Ergebnis nicht in einer Datei speichern können. Stattdessen können Sie es sofort an einen anderen Befehl übergeben:

 kustomize build . | kubectl apply -f - 

Auf Kustomize-Funktionen kann auch über kubectl -k zugegriffen werden (seit Version 1.14 von Kubernetes). Beachten Sie jedoch, dass ein separates kustomize-Paket schneller aktualisiert wird als ein in kubectl integriertes (zumindest ist dies bei der Veröffentlichung von Kubernetes 1.15 der Fall).

Leser können fragen: "Warum all diese Schwierigkeiten, wenn Sie Dateien direkt bearbeiten können?". Gute Frage. In unserem Beispiel ist es wirklich möglich, die Dateien service.yaml und service.yaml direkt zu ändern. Was ist jedoch, wenn sie eine Abzweigung des Projekts eines anderen sind? Das direkte Ändern von Dateien macht es schwierig (wenn nicht gar unmöglich), die Verzweigung neu zu starten, wenn Änderungen an der Quelle / Quelle vorgenommen werden. Mit kustomize können Sie diese Änderungen in der Datei kustomization.yaml zentralisieren, die Originaldateien intakt lassen und so das erneute Basieren der Quelldateien bei Bedarf vereinfachen.

Die Vorteile von kustomize werden in komplexeren Anwendungsfällen deutlich. Im obigen Beispiel befinden sich kustomization.yaml und resources im selben Verzeichnis. Kustomize unterstützt jedoch Verwendungsszenarien, wenn eine Grundkonfiguration und viele ihrer Varianten vorhanden sind, die auch als Overlays bezeichnet werden . Ein Benutzer wollte beispielsweise Deployment and Service für nginx, das ich als Beispiel verwendet habe, verwenden und Entwicklungs-, Staging- und Produktionsversionen (oder Varianten) dieser Dateien erstellen. Dazu benötigt er die oben genannten Overlays und in der Tat die grundlegenden Ressourcen selbst.

Angenommen, Verzeichnisse haben die folgende Struktur, um die Idee von Überlagerungen und Basisressourcen zu veranschaulichen:

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

In der base/kustomization.yaml Benutzer einfach das resources base/kustomization.yaml um die resources zu deklarieren, die kustomize aktivieren soll.

In jeder der overlays/{dev,staging,prod}/kustomization.yaml verweisen Benutzer auf die Grundkonfiguration im Feld resources und geben dann die spezifischen Änderungen für diese Umgebung an . Beispielsweise könnte die overlays/dev/kustomization.yaml wie im vorherigen Beispiel aussehen:

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

Gleichzeitig kann die overlays/prod/kustomization.yaml völlig anders sein:

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

Wenn der Benutzer kustomize build . Im overlays/dev generiert kustomize eine Entwicklungsoption. Wenn Sie kustomize build . Im Verzeichnis overlays/prod Sie die Produktionsoption. Und das alles - ohne Änderungen an den Originaldateien (Basisdateien) und auf deklarative und deterministische Weise. Sie können die Grundkonfigurations- und Overlay-Verzeichnisse direkt an das Versionskontrollsystem übergeben, da Sie wissen, dass Sie basierend auf diesen Dateien die gewünschte Konfiguration jederzeit reproduzieren können.


Hinweis perev. : Abbildung aus der Projektdokumentation zur Verwendung von Overlays in kustomize

Kustomize kann viel mehr als in diesem Artikel beschrieben. Ich hoffe jedoch, dass dies eine gute Einführung sein wird.

Zusätzliche Ressourcen

Es gibt viele gute Artikel und Veröffentlichungen über kustomize. Hier sind einige, die ich besonders nützlich fand:

• Ändern Sie die Basis-YAML-Konfiguration für verschiedene Umgebungen mit Kustomize .
• Kustomize - Der richtige Weg, um in Kubernetes Vorlagen zu erstellen .
• Deklarative Verwaltung von Kubernetes-Objekten mit Kustomize ;
• Anpassen von Upstream-Helmdiagrammen mit Kustomize .

Hinweis perev. : Sie können auch den als Ressourcen auf der Dienstprogramm-Website veröffentlichten Linkblock und die nachfolgende Sammlung von Videos mit den neuesten Berichten zu kustomize empfehlen.

Wenn Sie Fragen oder Anregungen zur Verbesserung dieses Materials haben, bin ich immer offen für Rückmeldungen. Sie können mich auf Twitter oder über den Kubernetes Slack-Kanal kontaktieren. Viel Spaß beim Ändern Ihrer Manifeste mit kustomize!

PS vom Übersetzer

Lesen Sie auch in unserem Blog:

• " Tools für Anwendungsentwickler, die auf Kubernetes ausgeführt werden ";
• „ Kubernetes 1.14: Ein Überblick über wichtige Innovationen “;
• „Die fünf wichtigsten Ergebnisse des Helmgipfels 2019 in Amsterdam “;
• " Eine praktische Einführung in den Paketmanager für Kubernetes - Helm ."