Eine kurze Einführung in Kustomize

Notiz. übersetzen: Der Artikel wurde von Scott Lowe verfasst, einem Ingenieur mit umfangreicher IT-Erfahrung, der Autor/Co-Autor von sieben gedruckten Büchern (hauptsächlich über VMware vSphere) ist. Heute arbeitet er für deren VMware-Tochter Heptio (2016 übernommen) und ist auf Cloud Computing und Kubernetes spezialisiert. Der Text selbst dient als prägnante und leicht verständliche Einführung in das Konfigurationsmanagement für Kubernetes mithilfe von Technologie Anpassen, das seit kurzem Teil von K8s ist.

Kustomize ist ein Tool, das es Benutzern ermöglicht, „einfache, vorlagenfreie YAML-Dateien für verschiedene Zwecke anzupassen, wobei das ursprüngliche YAML intakt und verwendbar bleibt“ (Beschreibung direkt übernommen von Kustomize-Repository auf GitHub). Kustomize kann direkt ausgeführt oder ab Kubernetes 1.14 verwendet werden kubectl -k um auf seine Funktionalität zuzugreifen (obwohl ab Kubernetes 1.15 die separate Binärdatei neuer ist als die in kubectl integrierten Funktionen). (Notiz. übersetzen: Und mit der jüngsten Veröffentlichung Kubernetes 1.16 anpassen unterstützt durch auch im Dienstprogramm kubeadm.) In diesem Beitrag möchte ich den Lesern die Grundlagen von Kustomize näherbringen.

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 für Änderungen, die an diesen Ressourcen vorgenommen werden müssen. Genauso wie make den darin enthaltenen Befehlssatz verwendet Makefile, und Docker erstellt den Container basierend auf den Anweisungen von Dockerfile, Verwendungsmöglichkeiten anpassen kustomization.yaml um Anweisungen darüber zu speichern, welche Änderungen der Benutzer an einer Reihe von Ressourcen vornehmen möchte.

Hier ist eine Beispieldatei kustomization.yaml:

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

Ich werde nicht versuchen, auf alle möglichen Felder in der Datei einzugehen. kustomization.yaml (Darüber ist gut geschrieben hier), aber ich werde eine kurze Erläuterung eines konkreten Beispiels geben:

• Feld resources gibt an, was (welche Ressourcen) kustomize ändern wird. In diesem Fall wird nach Ressourcen in Dateien gesucht deployment.yaml и service.yaml in Ihrem Verzeichnis (bei Bedarf können Sie vollständige oder relative Pfade angeben).
• Feld namePrefix weist kustomize an, ein bestimmtes Präfix hinzuzufügen (in diesem Fall - dev-) zuschreiben name alle im Feld definierten Ressourcen resources. Also, wenn die Bereitstellung hat name mit Bedeutung nginx-deployment, Anpassen wird es schaffen dev-nginx-deployment.
• Feld namespace weist kustomize an, den angegebenen Namespace allen Ressourcen hinzuzufügen. In diesem Fall fallen Bereitstellung und Dienst in den Namespace development.
• Endlich das Feld commonLabels enthält eine Reihe von Beschriftungen, die allen Ressourcen hinzugefügt werden. In unserem Beispiel weist kustomize den Ressourcen eine Bezeichnung mit dem Namen zu environment und Bedeutung development.

Wenn der Benutzer dies tut kustomize build . im Verzeichnis mit der Datei kustomization.yaml und die notwendigen Ressourcen (d. h. Dateien). deployment.yaml и service.yaml), dann erhält es am Ausgang einen Text mit den in angegebenen Änderungen kustomization.yaml.

Notiz. übersetzen: Illustration aus der Projektdokumentation zur „einfachen“ Nutzung von kustomize

Die Ausgabe kann umgeleitet werden, wenn Änderungen festgeschrieben werden müssen:

kustomize build . > custom-config.yaml

Die Ausgabedaten sind deterministisch (die gleichen Eingabedaten führen zu den gleichen Ausgabeergebnissen), sodass Sie das Ergebnis nicht in einer Datei speichern müssen. Stattdessen kann es direkt an einen anderen Befehl übergeben werden:

kustomize build . | kubectl apply -f -

Auf die Kustomize-Funktionen kann auch über zugegriffen werden kubectl -k (seit Kubernetes Version 1.14). Bedenken Sie jedoch, dass das eigenständige kustomize-Paket schneller aktualisiert wird als das integrierte kubectl-Paket (zumindest ist dies bei der Kubernetes-Version 1.15 der Fall).

Leser fragen sich vielleicht: „Warum diese ganze Komplexität, wenn man die Dateien direkt bearbeiten kann?“ Tolle Frage. In unserem Beispiel tatsächlich kann man Dateien ändern deployment.yaml и service.yaml direkt, aber was ist, wenn sie ein Zweig des Projekts eines anderen sind? Das direkte Ändern von Dateien macht es schwierig (wenn nicht unmöglich), einen Fork neu zu starten, wenn Änderungen am Ursprung/der Quelle vorgenommen werden. Mit kustomize können Sie diese Änderungen in einer Datei zentralisieren kustomization.yaml, wodurch die Originaldateien intakt bleiben und es somit bei Bedarf einfacher ist, die Originaldateien neu zu basieren.

Die Vorteile von kustomize zeigen sich bei komplexeren Anwendungsfällen. Im obigen Beispiel kustomization.yaml und die Ressourcen befinden sich im selben Verzeichnis. Kustomize unterstützt jedoch Anwendungsfälle, bei denen es eine Basiskonfiguration und viele Varianten davon gibt, auch bekannt als Overlays. Ein Benutzer wollte beispielsweise „Deployment and Service for nginx“, das ich als Beispiel verwendet habe, Entwicklungs-, Staging- und Produktionsversionen (oder Varianten) dieser Dateien erstellen. Dazu benötigt er die oben genannten Overlays und tatsächlich die Grundressourcen selbst.

Zur Veranschaulichung der Idee von Überlagerungen und zugrunde liegenden Ressourcen (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

Im Ordner base/kustomization.yaml Benutzer, die das Feld nutzen resources Deklarieren Sie einfach die Ressourcen, die Kustomize enthalten soll.

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

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

In diesem Fall die Datei overlays/prod/kustomization.yaml könnte ganz anders sein:

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

Wenn der Benutzer ausgeführt wird kustomize build . im Katalog overlays/devkustomize generiert die Entwicklungsoption. Wenn du läufst kustomize build . im Katalog overlays/prod - Sie erhalten die Produktionsoption. Und das alles – ohne Änderungen am Original vorzunehmen (Base) Dateien, alles auf deklarative und deterministische Weise. Sie können die Basiskonfiguration und die Overlay-Verzeichnisse direkt der Versionskontrolle übergeben und wissen, dass Sie auf der Grundlage dieser Dateien jederzeit die gewünschte Konfiguration reproduzieren können.

Notiz. übersetzen: Illustration aus der Projektdokumentation zur Verwendung von Overlays in Kustomize

Anpassen kann viel mehr als das, was in diesem Artikel behandelt wird. Ich hoffe jedoch, dass es als guter Einstieg dient.

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 Produktions-/Testumgebungen mit Kustomize;
• Kustomize – Der richtige Weg, Vorlagen in Kubernetes zu erstellen;
• Deklarative Verwaltung von Kubernetes-Objekten mit Customize;
• Anpassen von Upstream-Helmdiagrammen mit Anpassen.

Notiz. übersetzen: Sie können auch einen Linkblock empfehlen, der als veröffentlicht wurde Ressourcen auf der Website des Versorgungsunternehmens, gefolgt von einer Sammlung von Videos mit den neuesten Berichten über kustomize.

Wenn Sie Fragen oder Vorschläge zur Verbesserung dieses Materials haben, bin ich jederzeit offen für Feedback. Sie können mich unter kontaktieren Twitter oder Kubernetes Slack-Kanal. Viel Spaß beim Modifizieren Ihrer Manifeste mit kustomize!

PS vom Übersetzer

Lesen Sie auch auf unserem Blog:

• «Tools für Entwickler von Anwendungen, die auf Kubernetes ausgeführt werden";
• «Kubernetes 1.14: Highlights der Neuerungen";
• «Fünf Hauptergebnisse des Helm Summit 2019 in Amsterdam";
• «Praktisch mit dem Kubernetes Package Manager – Helm".

Source: habr.com