Folgende wir stellen seinen älteren Bruder vor - . Hierbei handelt es sich um ein Open-Source-Projekt, das zur Installation von Systemkomponenten in einem Kubernetes-Cluster verwendet wird, die als Add-ons bezeichnet werden können.
Warum überhaupt Ergänzungen?
Es ist kein Geheimnis, dass Kubernetes kein fertiges All-in-One-Produkt ist und für den Aufbau eines „erwachsenen“ Clusters verschiedene Ergänzungen erforderlich sind. Der Add-on-Operator hilft Ihnen bei der Installation, Konfiguration und Aktualisierung dieser Add-ons.
Der Bedarf an zusätzlichen Komponenten im Cluster wird in offengelegt Kolleginnen und Kollegen . Kurz gesagt, die Situation bei Kubernetes ist derzeit so, dass man für eine einfache „Play-Around“-Installation mit den sofort einsatzbereiten Komponenten auskommt, für Entwickler und Tests kann man Ingress hinzufügen, aber für eine vollständige Installation ungefähr das Sie können sagen „Ihre Produktion ist bereit“, Sie müssen ein Dutzend verschiedener Add-ons hinzufügen: etwas für die Überwachung, etwas für die Protokollierung, vergessen Sie nicht Ingress und Cert-Manager, wählen Sie Knotengruppen aus, fügen Sie Netzwerkrichtlinien hinzu, Saison mit Sysctl- und Pod-Autoscaler-Einstellungen ...
Was sind die Besonderheiten der Zusammenarbeit mit ihnen?
Wie die Praxis zeigt, ist die Angelegenheit nicht auf eine Installation beschränkt. Um problemlos mit dem Cluster arbeiten zu können, müssen Add-ons aktualisiert und deaktiviert (aus dem Cluster entfernt) werden. Einige davon sollten Sie testen, bevor Sie sie im Produktionscluster installieren.
Vielleicht reicht Ansible hier aus? Vielleicht. Aber Im Allgemeinen leben vollwertige Add-Ons nicht ohne Einstellungen. Diese Einstellungen können je nach Clustervariante (aws, gce, azure, bare-metal, do, ...) unterschiedlich sein. Einige Einstellungen können nicht im Voraus festgelegt werden; sie müssen vom Cluster bezogen werden. Und der Cluster ist nicht statisch: Bei einigen Einstellungen müssen Sie Änderungen überwachen. Und hier fehlt Ansible schon: Man braucht ein Programm, das in einem Cluster lebt, also Kubernetes-Betreiber.
Diejenigen, die es bei der Arbeit versucht haben Sie werden sagen, dass die Aufgaben der Installation und Aktualisierung von Add-Ons und Überwachungseinstellungen vollständig mit gelöst werden können für Shell-Operator. Sie können ein Skript schreiben, das eine Bedingung ausführt kubectl apply und überwachen Sie beispielsweise ConfigMap, wo die Einstellungen gespeichert werden. Dies ist ungefähr das, was im Addon-Operator implementiert ist.
Wie ist das im Addon-Operator organisiert?
Bei der Erstellung einer neuen Lösung sind wir von folgenden Grundsätzen ausgegangen:
- Das Add-on-Installationsprogramm muss unterstützen Templating und deklarative Konfiguration. Wir erstellen keine magischen Skripte, die Add-ons installieren. Der Addon-Betreiber verwendet Helm, um Addons zu installieren. Zur Installation müssen Sie ein Diagramm erstellen und die Werte auswählen, die für die Konfiguration verwendet werden.
- Einstellungen können sein bei der Installation generieren, Sie können sein vom Cluster bekommenOder Updates erhalten, Überwachung der Clusterressourcen. Diese Operationen können mithilfe von Hooks implementiert werden.
- Einstellungen können sein in einem Cluster speichern. Um Einstellungen im Cluster zu speichern, wird ein ConfigMap/Addon-Operator erstellt und der Addon-Operator überwacht Änderungen an dieser ConfigMap. Der Addon-Operator gewährt Hooks mithilfe einfacher Konventionen Zugriff auf Einstellungen.
- Die Zugabe hängt von den Einstellungen ab. Wenn sich die Einstellungen geändert haben, rollt der Addon-Operator das Helm-Chart mit neuen Werten aus. Wir haben die Kombination aus dem Helm-Diagramm, den Werten dafür und den Hooks als Modul bezeichnet (weitere Einzelheiten siehe unten).
- Inszenierung. Es gibt keine Magic-Release-Skripte. Der Update-Mechanismus ähnelt einer regulären Anwendung: Sammeln Sie Add-ons und Add-on-Operatoren in einem Image, markieren Sie sie und führen Sie sie aus.
- Ergebniskontrolle. Addon-Operator kann Metriken für Prometheus bereitstellen.
Was ist Padding im Addon-Operator?
Als Ergänzung kann alles angesehen werden, was dem Cluster neue Funktionen hinzufügt. Beispielsweise ist die Installation von Ingress ein großartiges Beispiel für ein Add-on. Dies kann jeder Operator oder Controller mit eigenem CRD sein: prometheus-operator, cert-manager, kube-controller-manager usw. Oder etwas Kleines, aber einfacher zu verwenden – zum Beispiel ein Secret Copier, der Registrierungsgeheimnisse in neue Namespaces kopiert, oder ein Sysctl-Tuner, der Sysctl-Parameter auf neuen Knoten konfiguriert.
Um Add-ons zu implementieren, bietet der Addon-Operator mehrere Konzepte:
- Helmkarte Wird verwendet, um verschiedene Software im Cluster zu installieren – zum Beispiel Prometheus, Grafana, Nginx-Ingress. Wenn die erforderliche Komponente über ein Helm-Chart verfügt, ist die Installation mit dem Addon-Operator sehr einfach.
- Wertespeicher. Helmdiagramme verfügen normalerweise über viele verschiedene Einstellungen, die sich im Laufe der Zeit ändern können. Der Addon-Operator unterstützt das Speichern dieser Einstellungen und kann deren Änderungen überwachen, um das Helm-Diagramm mit neuen Werten neu zu installieren.
- Haken sind ausführbare Dateien, die der Addon-Operator bei Ereignissen ausführt und die auf den Wertespeicher zugreifen. Der Hook kann Änderungen im Cluster überwachen und die Werte im Wertespeicher aktualisieren. Diese. Mithilfe von Hooks können Sie eine Erkennung durchführen, um beim Start oder nach einem Zeitplan Werte aus dem Cluster zu sammeln, oder Sie können eine kontinuierliche Erkennung durchführen und Werte aus dem Cluster basierend auf Änderungen im Cluster sammeln.
- Modul ist eine Kombination aus einem Helm-Chart, einem Wertespeicher und Hooks. Module können aktiviert oder deaktiviert werden. Das Deaktivieren eines Moduls bedeutet das Löschen aller Helm-Chart-Releases. Module können sich selbst dynamisch aktivieren, beispielsweise wenn alle benötigten Module aktiviert sind oder wenn die Erkennung die erforderlichen Parameter in den Hooks gefunden hat – dies geschieht mithilfe eines Hilfsskripts.
- Globale Haken. Dabei handelt es sich um Hooks „für sich“, sie sind nicht in Modulen enthalten und haben Zugriff auf einen globalen Wertespeicher, dessen Werte allen Hooks in Modulen zur Verfügung stehen.
Wie arbeiten diese Teile zusammen? Schauen wir uns das Bild aus der Dokumentation an:
Es gibt zwei Arbeitsszenarien:
- Der globale Hook wird durch ein Ereignis ausgelöst – beispielsweise wenn sich eine Ressource im Cluster ändert. Dieser Hook verarbeitet die Änderungen und schreibt die neuen Werte in den globalen Wertespeicher. Der Addon-Betreiber bemerkt, dass sich der globale Speicher geändert hat und startet alle Module. Jedes Modul bestimmt mithilfe seiner Hooks, ob es aktiviert werden muss, und aktualisiert seinen Wertespeicher. Wenn das Modul aktiviert ist, startet der Addon-Operator die Installation des Helm-Charts. In diesem Fall hat das Helm-Chart Zugriff auf Werte aus dem Modulspeicher und aus dem globalen Speicher.
- Das zweite Szenario ist einfacher: Ein Modul-Hook wird durch ein Ereignis ausgelöst und ändert Werte im Wertespeicher des Moduls. Der Addon-Operator bemerkt dies und startet das Helm-Chart mit aktualisierten Werten.
Der Zusatz kann als ein einzelner Hook oder als ein Helm-Chart implementiert werden auch als mehrere abhängige Module – Dies hängt von der Komplexität der im Cluster installierten Komponente und vom gewünschten Grad an Konfigurationsflexibilität ab. Zum Beispiel im Repository () gibt es ein sysctl-tuner-Add-on, das sowohl als einfaches Modul mit einem Hook und einem Helm-Chart implementiert ist als auch den Wertespeicher verwendet, der das Hinzufügen von Einstellungen durch Bearbeiten von ConfigMap ermöglicht.
Lieferung von Updates
Ein paar Worte zur Organisation von Komponentenaktualisierungen, die der Addon-Betreiber installiert.
Um den Addon-Operator in einem Cluster auszuführen, benötigen Sie Erstellen Sie ein Image mit Ergänzungen Fügen Sie in Form von Hook- und Helm-Chart-Dateien eine Binärdatei hinzu addon-operator und alles, was Sie für Haken brauchen: bash, kubectl, jq, python usw. Dann kann dieses Image als reguläre Anwendung im Cluster bereitgestellt werden, und höchstwahrscheinlich möchten Sie das eine oder andere Tagging-Schema organisieren. Bei wenigen Clustern kann der gleiche Ansatz wie bei Anwendungen geeignet sein: neues Release, neue Version, zu allen Clustern gehen und das Image der Pods korrigieren. Bei einem Rollout auf eine erhebliche Anzahl von Clustern war für uns jedoch das Konzept der Selbstaktualisierung über einen Kanal geeigneter.
So machen wir es:
- Ein Kanal ist im Wesentlichen eine Kennung, die auf alles gesetzt werden kann (z. B. dev/stage/ea/stable).
- Der Kanalname ist das Bild-Tag. Wenn Sie Updates für einen Kanal einführen müssen, wird ein neues Bild zusammengestellt und mit dem Kanalnamen versehen.
- Wenn ein neues Image in der Registrierung erscheint, wird der Addon-Operator neu gestartet und mit dem neuen Image gestartet.
Dies ist keine bewährte Vorgehensweise, wie in beschrieben . Es wird nicht empfohlen, dies zu tun, aber wir reden darüber eine reguläre Anwendung, die sich im selben Cluster befindet. Im Fall eines Add-on-Operators besteht eine Anwendung aus vielen über Cluster verstreuten Bereitstellungen, und die Selbstaktualisierung hilft sehr und macht das Leben einfacher.
Kanäle helfen und beim Testen: Wenn ein Hilfscluster vorhanden ist, können Sie ihn für den Kanal konfigurieren stage und aktualisieren Sie es, bevor Sie es auf den Kanälen bereitstellen ea и stable. Wenn mit einem Cluster auf dem Kanal ea Ist ein Fehler aufgetreten, können Sie darauf umschalten stable, während das Problem mit diesem Cluster untersucht wird. Wenn der Cluster aus der aktiven Unterstützung genommen wird, wechselt er in seinen „eingefrorenen“ Kanal – zum Beispiel freeze-2019-03-20.
Zusätzlich zum Aktualisieren von Hooks und Helm-Charts benötigen Sie möglicherweise Folgendes Update und Drittanbieterkomponente. Sie haben beispielsweise einen Fehler im bedingten Node-Exporter bemerkt und sogar herausgefunden, wie Sie ihn beheben können. Als nächstes haben Sie die PR geöffnet und warten darauf, dass die neue Version alle Cluster durchläuft und die Version des Images erhöht. Um nicht endlos zu warten, können Sie Ihren Node-Exporter erstellen und zu ihm wechseln, bevor Sie den PR akzeptieren.
Im Allgemeinen ist dies ohne Addon-Operator möglich, aber mit Addon-Operator ist das Modul zur Installation von Node-Exporter in einem Repository sichtbar, die Docker-Datei zum Erstellen Ihres Images kann direkt dort gespeichert werden, was für alle Teilnehmer einfacher wird der Prozess, um zu verstehen, was passiert ... Und wenn es mehrere Cluster gibt, wird es einfacher, sowohl Ihre PR zu testen als auch eine neue Version auszurollen!
Diese Organisation der Komponentenaktualisierung funktioniert bei uns erfolgreich, es ist aber auch jedes andere geeignete Schema umsetzbar In diesem Fall ist der Addon-Operator eine einfache Binärdatei.
Abschluss
Die im Addon-Operator implementierten Prinzipien ermöglichen es Ihnen, einen transparenten Prozess zum Erstellen, Testen, Installieren und Aktualisieren von Add-Ons in einem Cluster aufzubauen, ähnlich den Entwicklungsprozessen regulärer Anwendungen.
Add-ons für Addon-Operator im Modulformat (Helm-Chart + Hooks) können öffentlich verfügbar gemacht werden. Wir, die Firma Flant, planen, unsere Entwicklungen in Form solcher Ergänzungen im Laufe des Sommers zu veröffentlichen. Nehmen Sie an der Entwicklung auf GitHub teil (, ), versuchen Sie, Ihre eigene Ergänzung basierend auf zu erstellen и , warten Sie auf Neuigkeiten zu Habré und auf unserem !
PS
Lesen Sie auch auf unserem Blog:
- «";
- «".
Source: habr.com