Nach Wir präsentieren seinen großen Bruder — . Es handelt sich um ein Open Source-Projekt, das zur Installation von Systemkomponenten in einem Kubernetes-Cluster verwendet wird, die wir allgemein als Ergänzungen bezeichnen können.
Warum überhaupt irgendwelche Ergänzungen?
Es ist kein Geheimnis, dass Kubernetes kein fertiges All-in-One-Produkt ist, und für den Aufbau eines 'reifen' Clusters sind verschiedene Ergänzungen erforderlich. Der Addon-Operator hilft dabei, diese Ergänzungen zu installieren, zu konfigurieren und aktuell zu halten.
Die Notwendigkeit zusätzlicher Komponenten im Cluster wird in Kollegen deutlich. Kurz gesagt, die Situation bei Kubernetes ist derzeit so, dass man für eine einfache Installation zum Ausprobieren mit den Standardkomponenten auskommen kann, für Entwickler und Tester jedoch Ingress hinzufügen sollte. Für eine vollständige Installation, bei der man sagen kann 'Ihre Produktion ist bereit', müssen etwa ein Dutzend verschiedener Ergänzungen hinzugefügt werden: etwas zur Überwachung, etwas für Logs, nicht vergessen Ingress und Cert-Manager, Knoten-Pools festlegen, Netzwerkrichtlinien hinzufügen, mit Sysctl-Einstellungen und einem Pod-Autoscaler würzen…
Was ist die spezielle Handhabung dieser Komponenten?
Wie die Erfahrungen zeigen, bleibt es nicht bei einer einzigen Installation. Für eine reibungslose Arbeit mit dem Cluster müssen Ergänzungen aktualisiert, deaktiviert (aus dem Cluster entfernt) werden, und einige möchten vielleicht vor der Installation im Produktionscluster getestet werden.
Aber reicht hier vielleicht Ansible aus? Möglicherweise. Doch vollständige Ergänzungen leben in der Regel nicht ohne Konfigurationen.Diese Konfigurationen können je nach Cluster-Variante (AWS, GCE, Azure, Bare-Metal, DO, ...) variieren. Einige Einstellungen können nicht im Voraus festgelegt werden — sie müssen aus dem Cluster abgerufen werden. Und der Cluster ist nicht statisch: Für einige Einstellungen müssen die Änderungen überwacht werden. Hier reicht Ansible nicht aus: Es benötigt ein Programm, das im Cluster lebt, also einen Kubernetes Operator.
Diejenigen, die es ausprobiert haben, , werden sagen, dass die Aufgaben der Installation und Aktualisierung von Erweiterungen und die Überwachung der Konfigurationen durchaus mit Hilfe von für den Shell-Operator gelöst werden können. Man kann ein Skript schreiben, das eine bedingte kubectl apply und beispielsweise über ConfigMap wacht, wo die Konfigurationen gespeichert werden. Etwas Ähnliches ist im addon-operator umgesetzt.
Wie ist das im addon-operator organisiert?
Bei der Erstellung einer neuen Lösung gingen wir von folgenden Grundsätzen aus:
- Der Addon-Installer muss unterstützen Template- und deklarative Konfiguration. Wir erstellen keine magischen Skripte, die Add-ons installieren. Der Addon-Operator verwendet Helm zur Installation von Add-ons. Um zu installieren, muss ein Chart erstellt und Werte definiert werden, die zur Konfiguration verwendet werden.
- Einstellungen können bei der Installation generiert werden, sie können aus dem Cluster abgerufen werden, oder Updates erhalten, indem die Ressourcen des Clusters überwacht werden. Diese Operationen können durch Hooks realisiert werden.
- Einstellungen können im Cluster gespeichert werden. Um die Einstellungen im Cluster zu speichern, wird ein ConfigMap/addon-operator erstellt, und der Addon-Operator überwacht Änderungen an diesem ConfigMap. Der Addon-Operator gewährt Hooks Zugriff auf die Einstellungen mittels einfacher Vereinbarungen.
- Das Add-on hängt von den Einstellungen ab. Wenn sich die Einstellungen ändern, rollt der Addon-Operator das Helm-Chart mit neuen Werten aus. Die Kombination von Helm-Chart, Werten dafür und Hooks haben wir als Modul bezeichnet (mehr dazu siehe unten).
- Staging. Es gibt keine magischen Release-Skripte. Der Aktualisierungsmechanismus ähnelt einem normalen Anwendung — Add-ons und der Addon-Operator werden in ein Image gepackt, getaggt und bereitgestellt.
- Ergebnisüberprüfung. Der Addon-Operator kann Metriken für Prometheus bereitstellen.
Was ist ein Add-on in der Addon-Operator-Anwendung?
Ein Add-on kann alles sein, was dem Cluster neue Funktionen hinzufügt. Beispielsweise ist die Installation von Ingress ein hervorragendes Beispiel für ein Add-on. Dies kann jeder Operator oder Controller mit seinem eigenen CRD sein: prometheus-operator, cert-manager, kube-controller-manager usw. Oder etwas Kleines, das den Betrieb vereinfacht – zum Beispiel ein Secret-Copier, der Registry-Secrets in neue Namensräume kopiert, oder ein Sysctl-Tuner, der Sysctl-Parameter auf neuen Knoten anpasst.
Zur Implementierung von Add-ons bietet der Addon-Operator mehrere Konzepte an:
- Helm-Chart wird verwendet, um verschiedene Software im Cluster zu installieren – beispielsweise Prometheus, Grafana, nginx-ingress. Wenn die benötigte Komponente ein Helm-Chart hat, ist es sehr einfach, sie mit dem Addon-Operator zu installieren.
- Values-Store. Helm-Charts verfügen normalerweise über 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 nachverfolgen, um das Helm-Chart mit neuen Werten neu zu installieren.
- Hooks — dies sind ausführbare Dateien, die vom Addon-Operator bei Ereignissen gestartet werden und auf den Werte-Speicher zugreifen. Ein Hook kann Änderungen im Cluster überwachen und die Werte im Werte-Speicher aktualisieren. Das bedeutet, mit Hooks können Sie Discovery durchführen, um Werte aus dem Cluster beim Start oder nach einem Zeitplan zu sammeln, oder Continuous Discovery, indem Sie Werte aus dem Cluster bei Änderungen im Cluster sammeln.
- Modul — dies ist eine Kombination aus Helm-Chart, Werte-Speicher und Hooks. Module können aktiviert oder deaktiviert werden. Das Deaktivieren eines Moduls bedeutet, dass alle Releases des Helm-Charts entfernt werden. Module können sich dynamisch selbst aktivieren, beispielsweise wenn alle benötigten Module aktiviert sind oder wenn Discovery in den Hooks die erforderlichen Parameter gefunden hat – dies geschieht mit einem unterstützenden enabled-Skript.
- Globale Hooks. Dies sind Hooks, die "für sich allein stehen"; sie sind nicht in Modulen enthalten und haben Zugriff auf den globalen Werte-Speicher, dessen Werte allen Hooks in den Modulen zugänglich sind.
Wie arbeiten diese Teile zusammen? Betrachten Sie das Bild aus der Dokumentation:
Es gibt zwei Arbeits-Szenarien:
- Ein globaler Hook wird durch ein Ereignis ausgelöst – zum Beispiel bei Änderungen an einer Ressource im Cluster. Dieser Hook verarbeitet die Änderungen und speichert die neuen Werte im globalen Speichersystem. Der Addon-Operator bemerkt, dass sich der globale Speicher geändert hat, und startet alle Module. Jedes Modul entscheidet mithilfe seiner Hooks, ob es aktiviert werden soll, und aktualisiert seinen eigenen Speicher. Wenn das Modul aktiviert ist, startet der Addon-Operator die Installation des Helm-Charts. Dem Helm-Chart stehen dabei die Werte aus dem Modulspeicher und dem globalen Speicher zur Verfügung.
- Im zweiten Szenario ist es einfacher: Der modulare Hook wird durch ein Ereignis ausgelöst, ändert die Werte im Modulspeicher. Der Addon-Operator bemerkt dies und startet das Helm-Chart mit den aktualisierten Werten.
Ein Addon kann als ein einzelner Hook oder als ein Helm-Chart oder sogar als mehrere abhängige Module umgesetzt werden. Das hängt von der Komplexität des im Cluster installierten Elements und vom erforderlichen Grad an Flexibilität der Einstellungen ab. Zum Beispiel im Repository () gibt es ein sysctl-tuner-Addon, das sowohl als einfaches Modul mit Hook und Helm-Chart als auch mit einem Values-Storage implementiert ist, was die Möglichkeit bietet, Einstellungen durch Bearbeitung des ConfigMaps hinzuzufügen.
Lieferung von Updates
Einige Worte zur Organisation der Updates für die Komponenten, die der Addon-Operator installiert.
Um den Addon-Operator im Cluster zu starten, müssen Sie ein Image mit Addons erstellen in Form von Hook-Dateien und Helm-Charts, die binären Dateien hinzufügen addon-operator und alles, was für die Hooks benötigt wird: bash, kubectl, jq, Python usw. Dieses Image kann dann im Cluster wie eine normale Anwendung bereitgestellt werden, und wahrscheinlich möchten Sie eine Art von Tagging-Schema organisieren. Wenn es nur wenige Cluster gibt, kann der gleiche Ansatz wie bei Anwendungen genügen: neue Version, neuer Release, alle Cluster durchgehen und das Image bei den Pods anpassen. Wenn es sich jedoch um eine signifikante Anzahl von Clustern handelt, haben wir ein Selbstaktualisierungskonzept aus dem Kanal bevorzugt.
Bei uns ist das so geregelt:
- Der Kanal ist im Grunde genommen ein Identifikator, den man beliebig festlegen kann (zum Beispiel dev/stage/ea/stable).
- Der Kanalname ist das Tag des Images. Wenn Updates in den Kanal deployt werden sollen, wird ein neues Image erstellt und mit dem Kanalnamen getaggt.
- Wenn ein neues Image im Registry verfügbar ist, wird der Addon-Operator neu gestartet und mit dem neuen Image gestartet.
Das ist nicht die beste Praxis, wie in der beschrieben. Es wird nicht empfohlen, so vorzugehen, aber es handelt sich um eine gewöhnliche Anwendung, die in einem einzigen Cluster lebt.Im Fall des Addon-Operators ist die Anwendung eine Vielzahl von Deployments, die über Cluster verteilt sind, und die Selbstaktualisierung erleichtert das Leben erheblich.
Kanäle helfen auch bei Tests:Wenn ein Hilfscluster vorhanden ist, kann es auf den Kanal "stage" konfiguriert werden, um Updates vor der Bereitstellung in die Kanäle "ea" und "stable"zu testen. Wenn es im Cluster, das auf dem Kanal "ea" ein Problem gibt, kann es auf "stable"umgeschaltet werden, während das Problem mit diesem Cluster untersucht wird. Wenn der Cluster aus der aktiven Unterstützung genommen wird, wechselt er auf seinen "starren" Kanal – zum Beispiel, "freeze-2019-03-20"..
Zusätzlich zu den Updates für Hooks und Helm-Charts kann es notwendig sein, auch eine externe Komponente zu aktualisieren.. Zum Beispiel haben Sie einen Fehler im node-exporter bemerkt und sogar eine Möglichkeit gefunden, ihn zu patchen. Danach haben Sie einen PR geöffnet und warten auf die nächste Version, um durch alle Cluster zu gehen und die Version des Images zu aktualisieren. Um nicht auf unbestimmte Zeit zu warten, können Sie Ihren eigenen node-exporter kompilieren und bis zur Annahme des PR darauf wechseln.
Im Grunde kann man das auch ohne Addon-Operator machen, aber mit dem Addon-Operator wird das Modul zur Installation des node-exporters in einem einzigen Repository sichtbar, das Dockerfile zur Erstellung Ihres eigenen Images kann dort ebenfalls aufbewahrt werden, und es wird für alle Beteiligten einfacher zu verstehen, was passiert … Wenn es mehrere Cluster gibt, wird es sowohl einfacher, Ihren PR zu testen als auch die neue Version zu implementieren!
Dieses System zur Aktualisierung von Komponenten funktioniert bei uns gut, aber man kann auch jede andere geeignete Methode implementieren — denn in diesem Fall ist der Addon-Operator eine einfache Binärdatei..
Fazit
Die Prinzipien, die im Addon-Operator umgesetzt sind, ermöglichen einen transparenten Prozess zur Erstellung, Testung, Installation und Aktualisierung von Erweiterungen im Cluster, ähnlich den Prozessen der Entwicklung herkömmlicher Anwendungen.
Modularer Addon-Operator (Helm-Chart + Hooks) kann öffentlich bereitgestellt werden. Wir, die Firma Flant, planen, im Laufe des Sommers unsere Entwicklungen in Form solcher Add-ons zu veröffentlichen. Begleiten Sie die Entwicklung auf GitHub (, ), probieren Sie, Ihr eigenes Add-on basierend auf und , und bleiben Sie auf dem Laufenden mit Neuigkeiten auf Habr und unserem !
P.S.
Lesen Sie auch in unserem Blog:
- «»;
- «».
Quelle: habr.com
