Nach dem
Shell-Operator stellen wir seinen älteren Bruder vor - den
Addon-Operator . Dies ist ein Open Source-Projekt, mit dem Systemkomponenten im Kubernetes-Cluster installiert werden, das als allgemeines Wort bezeichnet werden kann - Add-Ons.
Warum überhaupt Ergänzungen?
Es ist kein Geheimnis, dass Kubernetes kein All-in-One-Endprodukt ist und verschiedene Ergänzungen erforderlich sind, um einen „erwachsenen“ Cluster aufzubauen. Der Addon-Operator hilft bei der Installation, Konfiguration und Aktualisierung dieser Add-Ons.
Der Bedarf an zusätzlichen Komponenten im Cluster wird in einem
Bericht von Kollegen
driusha offengelegt . Kurz gesagt, die Situation bei Kubernetes im Moment ist, dass Sie für eine einfache Installation mit sofort einsatzbereiten Komponenten herumspielen können, für Entwickler und Tests Ingress hinzufügen können, aber für eine vollständige Installation, bei der Sie sagen können, dass Ihre Produktion bereit ist, müssen Sie hinzufügen Ein Dutzend verschiedene Add-Ons: etwas für die Überwachung, etwas für Protokolle, Ingress und Cert-Manager nicht vergessen, Hostgruppen auswählen, Netzwerkrichtlinien hinzufügen, Saison mit Sysctl- und Pod-Autoscaler-Einstellungen ...
Was sind die Besonderheiten der Arbeit mit ihnen?
Wie die Praxis zeigt, ist der Fall nicht auf eine Installation beschränkt. Für eine komfortable Arbeit mit dem Cluster müssen die Add-Ons aktualisiert, deaktiviert (aus dem Cluster gelöscht) werden, und Sie möchten etwas testen, bevor Sie es im Produktionscluster installieren.
Vielleicht reicht Ansible hier aus? Möglicherweise. Aber
vollwertige Ergänzungen leben im allgemeinen Fall nicht ohne Einstellungen . Diese Einstellungen können je nach Clusteroption variieren (aws, gce, azure, bare-metal, do, ...). Einige Einstellungen können nicht im Voraus festgelegt werden - sie müssen vom Cluster bezogen werden. Und der Cluster ist nicht statisch: Für einige Einstellungen müssen Sie die Änderungen befolgen. Und hier fehlt Ansible bereits: Wir brauchen ein Programm, das in einem Cluster lebt, d. H. Kubernetes-Betreiber.
Diejenigen, die den
Shell-Operator in Betrieb ausprobiert haben, werden sagen, dass die Aufgaben der Installation und Aktualisierung von Add-Ons und Tracking-Einstellungen mit Hilfe von
Hooks für den Shell-Operator vollständig gelöst werden können. Sie können ein Skript schreiben, das bedingte
kubectl apply und überwacht, z. B. ConfigMap, in dem die Einstellungen gespeichert werden. Dies ist ungefähr das, was in Addon-Operator implementiert ist.
Wie ist das im Addon-Operator organisiert?
Bei der Erstellung einer neuen Lösung gingen wir von folgenden Prinzipien aus:
- Das Add-On-Installationsprogramm muss Vorlagen und deklarative Konfiguration unterstützen . Wir machen keine magischen Skripte, die Add-Ons installieren. Der Addon-Operator verwendet Helm, um Add-Ons zu installieren. Zur Installation müssen Sie ein Diagramm erstellen und die Werte markieren, die für die Konfiguration verwendet werden.
- Einstellungen können während der Installation generiert , vom Cluster abgerufen oder durch Überwachung der Clusterressourcen aktualisiert werden. Diese Operationen können mithilfe von Hooks implementiert werden.
- Einstellungen können in einem Cluster gespeichert werden . Um die Einstellungen im Cluster zu speichern, wird ein ConfigMap / Addon-Operator erstellt und der Addon-Operator überwacht die Änderungen dieser ConfigMap. Der Addon-Operator ermöglicht Hooks den Zugriff auf Einstellungen mithilfe einfacher Konventionen.
- Das Hinzufügen hängt von den Einstellungen ab . Wenn sich die Einstellungen geändert haben, rollt der Addon-Operator das Helm-Diagramm mit neuen Werten aus. Die Vereinigung des Helm-Diagramms, die Werte dafür und die Hooks, die wir als Modul bezeichnet haben (siehe unten für weitere Details).
- Inszenierung . Keine Magic Release Skripte. Der Aktualisierungsmechanismus ähnelt einer regulären Anwendung: Sammeln Sie Add-Ons und Addon-Operatoren in einem Image, testen Sie sie und rollen Sie sie aus.
- Kontrolle über das Ergebnis . Der Addon-Operator kann Metriken für Prometheus angeben.
Was ist das Addon im Addon-Operator?
Ein Zusatz kann als alles betrachtet werden, was dem Cluster neue Funktionen hinzufügt. Die Installation von Ingress ist beispielsweise ein hervorragendes Beispiel für ein Add-On. Es kann sich um einen beliebigen Bediener oder Controller mit einer eigenen CRD handeln: Prometheus-Operator, Cert-Manager, Kube-Controller-Manager usw. Oder eine kleine, aber vereinfachende Operation - zum Beispiel ein geheimer Kopierer, das Kopieren von Registrierungsgeheimnissen in neue Namespaces oder ein Sysctl-Tuner, der Sysctl-Parameter auf neuen Knoten konfiguriert.
Der Addon-Operator bietet verschiedene Konzepte für die Implementierung von Add-Ons:
- Das Helm-Diagramm wird verwendet, um verschiedene Software im Cluster zu installieren - zum Beispiel Prometheus, Grafana, Nginx-Ingress. Wenn die erforderliche Komponente über ein Helmdiagramm verfügt, ist die Installation mit dem Addon-Operator sehr einfach.
- Wertspeicher . Helmdiagramme haben normalerweise viele verschiedene Einstellungen, die sich im Laufe der Zeit ändern können. Der Addon-Operator unterstützt die Speicherung dieser Einstellungen und kann deren Änderungen überwachen, um das Helm-Diagramm mit neuen Werten zurückzusetzen.
- Hooks sind ausführbare Dateien, die der Addon-Operator für Ereignisse ausführt und die auf den Wertespeicher zugreifen. Der Hook kann Änderungen im Cluster überwachen und Werte im Wertespeicher aktualisieren. Das heißt, Mithilfe von Hooks können Sie eine Ermittlung durchführen, um beim Start oder nach einem Zeitplan Werte aus dem Cluster zu erfassen, oder eine kontinuierliche Ermittlung durchführen, indem Sie durch Änderungen im Cluster Werte aus dem Cluster erfassen.
- Ein Modul ist eine Vereinigung eines Helmdiagramms, Wertespeicher und Hooks. Module können ein- und ausgeschaltet werden. Durch Deaktivieren eines Moduls werden alle Versionen des Helm-Diagramms entfernt. Module können sich dynamisch einschalten, z. B. wenn alle benötigten Module enthalten sind oder wenn die Erkennung die erforderlichen Parameter in Hooks gefunden hat - dies erfolgt mithilfe eines Hilfsskripts.
- Globale Hooks Dies sind "eigenständige" Hooks, sie sind nicht in den Modulen enthalten und haben Zugriff auf den globalen Wertespeicher, dessen Werte allen Hooks in den Modulen zur Verfügung stehen.
Wie arbeiten diese Teile zusammen? Betrachten Sie das Bild aus der Dokumentation:
Zwei Arbeitsszenarien:
- Ein globaler Hook wird durch ein Ereignis ausgelöst, beispielsweise wenn sich eine Ressource in einem Cluster ändert. Dieser Hook verarbeitet die Änderungen und schreibt die neuen Werte in den globalen Wertespeicher. Der Addon-Operator bemerkt, dass sich der globale Speicher geändert hat, und startet alle Module. Jedes Modul bestimmt anhand seiner Hooks, ob es aktiviert werden muss, und aktualisiert seinen Wertespeicher. Wenn das Modul aktiviert ist, startet der Addon-Operator die Installation des Helm-Diagramms. In diesem Fall sind die Werte aus dem Modulspeicher und aus dem globalen Speicher für das Helm-Diagramm zugänglich.
- Das zweite Szenario ist einfacher: Ein Modul-Hook wird durch ein Ereignis ausgelöst und ändert die Werte im Modulwertspeicher. Der Addon-Operator bemerkt dies und startet das Helm-Diagramm mit aktualisierten Werten.
Das Add-On kann als einzelner Hook oder als ein Helm-Diagramm oder
sogar als mehrere abhängige Module implementiert werden - dies hängt von der Komplexität der im Cluster installierten Komponente und von der gewünschten Konfigurationsflexibilität ab. Zum Beispiel gibt es im Repository (
/ examples ) einen zusätzlichen sysctl-tuner, der sowohl als einfaches Modul mit einem Hook und einem Helm-Diagramm als auch unter Verwendung des Wertespeichers implementiert ist, der das Hinzufügen von Einstellungen durch Bearbeiten von ConfigMap ermöglicht.
Lieferung aktualisieren
Ein paar Worte zur Organisation von Komponentenupdates, die der Addon-Operator installiert.
Um den Addon-Operator in einem Cluster auszuführen, müssen Sie
ein Bild mit Ergänzungen in Form von Hook- und Helm-Diagrammdateien
sammeln , die
addon-operator Binärdatei hinzufügen und alles, was für Hooks benötigt wird:
bash ,
kubectl ,
jq ,
python usw. Darüber hinaus kann dieses Image als reguläre Anwendung im Cluster bereitgestellt werden, und höchstwahrscheinlich möchten Sie dieses oder jenes Tagging-Schema organisieren. Wenn nur wenige Cluster vorhanden sind, ist möglicherweise der gleiche Ansatz wie bei Anwendungen geeignet: Eine neue Version, eine neue Version, gehen Sie alle Cluster durch und korrigieren Sie das Image für Pods. Bei einem Rollout auf eine spürbare Anzahl von Clustern war das Konzept der Selbsterneuerung aus dem Kanal für uns jedoch besser geeignet.
Wir haben es so arrangiert:
- Ein Kanal ist im Wesentlichen eine Kennung, die von jedem festgelegt werden kann (z. B. dev / stage / ea / stabile).
- Der Kanalname ist das Bild-Tag. Wenn Sie Aktualisierungen für den Kanal bereitstellen müssen, wird ein neues Bild gesammelt und mit dem Namen des Kanals versehen.
- Wenn ein neues Bild in der Registrierung angezeigt wird, wird der Addon-Operator neu gestartet und beginnt mit dem neuen Bild.
Dies ist keine bewährte Methode, wie in der
Kubernetes-Dokumentation beschrieben . Dies wird nicht empfohlen, es handelt sich jedoch um eine
reguläre Anwendung, die in einem Cluster ausgeführt wird . Im Fall des Addon-Operators besteht eine Anwendung aus vielen Bereitstellungen, die über Cluster verteilt sind, und die Selbstaktualisierung ist sehr hilfreich und vereinfacht das Leben.
Kanäle helfen
beim Testen : Wenn es einen Hilfscluster gibt, können Sie ihn auf dem
stage konfigurieren und Aktualisierungen durchführen, bevor Sie ihn auf
ea und
stable Kanäle
ea . Wenn ein Fehler mit dem Cluster auf dem
ea Kanal auftritt, können Sie ihn auf
stable umschalten, während eine Untersuchung des Problems mit diesem Cluster ausgeführt wird. Wenn der Cluster vom aktiven Support zurückgezogen wird, wechselt er zu seinem "eingefrorenen" Kanal - zum Beispiel "
freeze-2019-03-20 .
Zusätzlich zum Aktualisieren von Hooks und Helmdiagrammen müssen Sie möglicherweise
eine Komponente eines Drittanbieters aktualisieren . Sie haben beispielsweise einen Fehler im bedingten Knotenexporter festgestellt und sogar herausgefunden, wie dieser gepatcht werden kann. Dann haben wir PR geöffnet und warten, bis eine neue Version alle Cluster durchläuft und die Version des Images erhöht. Um nicht unbegrenzt zu warten, können Sie Ihren Node-Exporter abholen und zu ihm wechseln, bevor Sie die PR akzeptieren.
Im Allgemeinen kann dies ohne Addon-Operator erfolgen, aber mit Addon-Operator wird das Modul zur Installation des Node-Exporters in einem Repository angezeigt. Sie können die Docker-Datei behalten, um Ihr Image genau dort zu erstellen. Dies wird für alle Teilnehmer des Prozesses einfacher, dies zu verstehen passiert ... Und wenn es mehrere Cluster gibt, wird es einfacher, sowohl Ihre PR zu testen als auch eine neue Version zu erstellen!
Diese Organisation von Komponentenaktualisierungen funktioniert bei uns erfolgreich, Sie können jedoch jedes andere geeignete Schema implementieren, da
in diesem Fall der Addon-Operator eine einfache Binärdatei ist .
Fazit
Mit den in Addon-operator implementierten Prinzipien können Sie einen transparenten Prozess zum Erstellen, Testen, Installieren und Aktualisieren von Add-Ons in einem Cluster erstellen, ähnlich wie bei der Entwicklung normaler Anwendungen.
Add-Ons für Addon-Operatoren im Format von Modulen (Helm-Chart + Hooks) können öffentlich hochgeladen werden. Wir, die Firma Flant, planen, unsere Erfolge im Sommer in Form solcher Ergänzungen darzulegen. Nehmen Sie an der Entwicklung auf GitHub (
Shell-Operator ,
Addon-Operator ) teil, versuchen Sie, Ihre Addition anhand von
Beispielen und
Dokumentationen vorzunehmen, warten Sie auf die Neuigkeiten im Habré und auf unserem
YouTube-Kanal !
AKTUALISIERT (14. Juni) : Wenn Sie englischsprachige Kollegen haben, die möglicherweise an dem Addon-Operator interessiert sind, finden Sie die entsprechende Ankündigung in unserem Blog auf Medium .PS
Lesen Sie auch in unserem Blog: