🥇Die Funktionsweise von Helm und seine Fallstricke

Konzept für einen Typhon-Frachtträger, Anton Swanepoel

Mein Name ist Dmitrij Sugrobov, ich bin Entwickler bei ‚Leroy Merlin‘. In diesem Artikel werde ich erläutern, warum Helm notwendig ist, wie es die Arbeit mit Kubernetes vereinfacht, was sich in der dritten Version geändert hat und wie man damit Anwendungen in der Produktion ohne Ausfallzeiten aktualisieren kann.

Dies ist eine Zusammenfassung basierend auf einem Vortrag auf der Konferenz @Kubernetes Conference indem Mail.ru Cloud Solutions — Wenn Sie nicht lesen möchten, schauen Sie sich das Video an.

Warum wir Kubernetes in der Produktion verwenden

‚Leroy Merlin‘ ist führend im DIY-Einzelhandel in Russland und Europa. In unserem Unternehmen sind über einhundert Entwickler tätig, 33.000 interne Mitarbeiter und eine riesige Anzahl von Menschen, die unsere Baumärkte und unsere Website besuchen. Um sie alle glücklich zu machen, haben wir beschlossen, uns an standardisierte Ansätze in der Branche zu halten. Neue Anwendungen entwickeln wir unter Verwendung einer Mikroservices-Architektur; zur Isolierung von Umgebungen und zur korrekten Bereitstellung verwenden wir Container; und zur Orchestrierung setzen wir Kubernetes ein. Die Kosten für die Nutzung von Orchestratoren sinken schnell: Die Anzahl der Ingenieure, die mit der Technologie vertraut sind, wächst auf dem Markt, und es kommen Anbieter hinzu, die Kubernetes als Service anbieten.

Alles, was Kubernetes tut, kann selbstverständlich auch auf andere Weise erreicht werden, zum Beispiel indem man ein Skript für Jenkins und docker-compose verwendet, aber warum das Leben komplizierter machen, wenn es eine fertige und zuverlässige Lösung gibt? Deshalb sind wir zu Kubernetes gekommen und verwenden es seit einem Jahr in der Produktion. Aktuell haben wir vierundzwanzig Kubernetes-Cluster, der älteste davon ist über ein Jahr alt und enthält etwa zweihundert Pods.

Der Fluch einer Vielzahl von YAML-Dateien in Kubernetes

Um einen Mikroservice in Kubernetes zu starten, erstellen wir mindestens fünf YAML-Dateien: für Deployment, Service, Ingress, ConfigMap, Secrets — und senden sie an den Cluster. Für die nächste Anwendung schreiben wir dasselbe Paket von YAMLs, für die dritte noch eins und so weiter. Wenn wir die Anzahl der Dokumente mit der Anzahl der Umgebungen multiplizieren, kommen wir bereits auf Hunderte von Dateien, und das ohne die dynamischen Umgebungen zu berücksichtigen.

Adam Reese, Hauptverantwortlicher für Helm, führte den Begriff „Entwicklungszyklus in Kubernetes“ ein, der so aussieht:

Copy YAML — YAML-Datei kopieren.
Paste YAML — sie einfügen.
Fix Indents — Einrückungen korrigieren.
Repeat — wiederholen.

Diese Methode ist zwar praktikabel, erfordert jedoch viele Kopiervorgänge mit YAML-Dateien. Um diesen Zyklus zu ändern, wurde Helm erfunden.

Was ist Helm

Erstens, Helm — Paketmanager, der hilft, die benötigten Programme zu finden und zu installieren. Um zum Beispiel MongoDB zu installieren, muss man nicht auf die offizielle Website gehen und die Binärdateien herunterladen, es genügt, den Befehl auszuführen helm install stable/mongodb.

Zweitens, Helm — Template-Engine, hilft, Dateien zu parametrisieren. Kommen wir zur Situation mit YAML-Dateien in Kubernetes zurück. Es ist einfacher, die gleiche YAML-Datei zu schreiben, einige Platzhalter hinzuzufügen, die Helm mit Werten füllt. Das heißt, anstelle eines großen Satzes von YAML-Dateien gibt es eine Sammlung von Vorlagen, in die die benötigten Werte zu gegebener Zeit eingesetzt werden.

Drittens, Helm — Master für die Bereitstellung. Mit ihm kann man Anwendungen installieren, zurücksetzen und aktualisieren. Lassen Sie uns anschauen, wie das funktioniert.

So verwenden Sie Helm für die Bereitstellung eigener Anwendungen

Wir installieren den Helm-Client auf dem Computer, indem wir der offiziellen Anleitung. Dann erstellen wir eine Sammlung von YAML-Dateien. Anstatt konkrete Werte anzugeben, lassen wir Platzhalter, die später von Helm mit Informationen gefüllt werden. Diese Sammlung von Dateien nennt man Helm Chart. Man kann sie auf drei Arten an den Konsolen-Client von Helm senden:

einen Ordner mit Vorlagen angeben;
in ein .tar-Archiv packen und darauf verweisen;
die Vorlage in ein entferntes Repository legen und einen Link zum Repository im Helm-Client hinzufügen.

Außerdem wird eine Datei mit Werten benötigt — values.yaml. Die Daten daraus werden im Template eingesetzt. Lassen Sie uns auch diese erstellen.

In der zweiten Version von Helm gibt es eine zusätzliche Serveranwendung — Tiller. Sie hängt außerhalb von Kubernetes und wartet auf Anfragen vom Helm-Client, und bei einem Aufruf setzt sie die benötigten Werte in das Template ein und sendet es an Kubernetes.

Helm 3 ist einfacher aufgebaut: Anstatt die Templates auf dem Server zu verarbeiten, wird die Information jetzt vollständig auf der Seite des Helm-Clients verarbeitet und direkt an die Kubernetes API gesendet. Diese Vereinfachung erhöht die Sicherheit des Clusters und erleichtert das Rollout.

Wie das alles funktioniert

Wir führen den Befehl aus helm install. Wir geben den Namen der Anwendungs-Release an, geben den Pfad zu values.yaml an. Am Ende geben wir das Repository an, in dem das Chart liegt, und den Namen des Charts. Im Beispiel sind das „lmru“ und „bestchart“.

helm install --name bestapp --values values.yaml lmru/bestchart

Die Ausführung des Befehls ist nur einmal möglich, bei einer Wiederholung wird stattdessen install sollte benutzt werden upgrade. Zur Vereinfachung kann man anstelle von zwei Befehlen den Befehl upgrade mit dem zusätzlichen Schlüssel --install. Bei der ersten Ausführung wird Helm den Befehl zum Installieren des Releases senden und wird ihn in der Folge aktualisieren.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Fallstricke beim Deployen neuer Versionen der Anwendung mit Helm

An dieser Stelle der Erzählung spiele ich mit dem Saal in 'Wer wird Millionär?', und wir klären, wie man Helm dazu bringt, die Version der Anwendung zu aktualisieren. Video ansehen.

Als ich die Funktionsweise von Helm studierte, war ich über das merkwürdige Verhalten überrascht, das auftrat, wenn ich versuchte, die Versionen von laufenden Anwendungen zu aktualisieren. Den Anwendungscode aktualisiert, ein neues Bild im Docker-Registry hochgeladen, den Befehl zum Deployen geschickt – und es passierte nichts. Unten sind einige nicht ganz erfolgreiche Methoden zum Aktualisieren von Anwendungen. Wenn man jede davon näher betrachtet, beginnt man, das innere Funktionieren des Werkzeugs und die Gründe für solch unerwartetes Verhalten zu verstehen.

Methode 1. Keine Informationen seit dem letzten Start ändern

Wie es heißt Offizielle Website Helm, 'Kubernetes-Charts können groß und komplex sein, daher versucht Helm, nicht unnötig einzugreifen'. Daher wird beim Aktualisieren der neuesten Version des Anwendungsbildes im Docker-Registry und ausführen des Befehls helm upgrade, nichts passieren. Helm wird denken, dass sich nichts geändert hat, und es ist nicht nötig, Kubernetes den Befehl zur Aktualisierung der Anwendung zu senden.

Hier und weiter wird das Tag 'latest' nur als Beispiel gezeigt. Beim Angabe dieses Tags wird Kubernetes das Bild jedes Mal aus dem Docker-Registry herunterladen, unabhängig von der Einstellung 'imagePullPolicy'. Die Verwendung von 'latest' in der Produktion ist unerwünscht und kann Nebenwirkungen haben.

Methode 2. LABEL im Image aktualisieren

Wie im gleichen Dokumentation, 'Helm wird die Anwendung nur aktualisieren, wenn sie sich seit dem letzten Release geändert hat'. Eine logische Option dafür wäre die Aktualisierung des LABELs im Docker-Image selbst. Allerdings sieht Helm nicht in die Anwendungsbilder hinein und hat keine Ahnung von irgendwelchen Änderungen darin. Dementsprechend, wenn LABELs im Bild aktualisiert werden, wird Helm nichts davon erfahren, und der Befehl zur Aktualisierung der Anwendung in Kubernetes wird nicht gesendet.

Methode 3. Den Schlüssel verwenden --force

Lass uns die Handbücher zu Rate ziehen und nach dem nötigen Schlüssel suchen. Der Schlüssel, der am meisten Sinn macht, ist die Schlüsseloption. --force. Trotz des sprechenden Namens weicht das Verhalten von den Erwartungen ab. Statt ein erzwungenes Update der Anwendung durchzuführen, ist der eigentliche Zweck die Wiederherstellung einer im Status FAILED befindlichen Version. Wenn dieser Schlüssel nicht verwendet wird, müssen die Befehle nacheinander ausgeführt werden. helm delete && helm install --replace. Stattdessen wird vorgeschlagen, den Schlüssel --force, der die abwechselnde Ausführung dieser Befehle automatisiert, zu verwenden. Weitere Informationen finden Sie in diesem Pull-Request.. Um Helm dennoch dazu zu bringen, die Version der Anwendung zu aktualisieren, ist leider dieser Schlüssel nicht geeignet.

Methode 4. Labels direkt in Kubernetes ändern

Das direkte Update des Labels im Cluster mit dem Befehl kubectl edit ist keine gute Idee. Diese Aktion führt zu Inkonsistenzen zwischen der laufenden Anwendung und dem, was ursprünglich zur Bereitstellung gesendet wurde. Das Verhalten von Helm bei der Bereitstellung weicht in diesem Fall von seiner Version ab: Helm 2 wird nichts tun, während Helm 3 die neue Version der Anwendung bereitstellt. Um die Gründe zu verstehen, ist es notwendig zu wissen, wie Helm funktioniert.

Wie Helm funktioniert

Um festzustellen, ob sich die Anwendung seit dem letzten Release geändert hat, kann Helm auf Folgendes zurückgreifen:

die laufende Anwendung in Kubernetes;
neue values.yaml und aktuelles Chart;
interne Informationen von Helm über Releases.

Für die Neugierigen: Wo speichert Helm die internen Informationen über Releases?Durch den Befehl helm history, erhalten wir alle Informationen über die Versionen, die mit Helm installiert wurden.

Es gibt auch detaillierte Informationen zu den gesendeten Vorlagen und Werten. Wir können sie anfordern:

In der zweiten Version von Helm befinden sich diese Informationen im selben Namespace, in dem Tiller läuft (standardmäßig kube-system), in einer ConfigMap, die mit dem Label „OWNER=TILLER“ gekennzeichnet ist:

Mit dem Erscheinen der dritten Version von Helm wurden die Informationen in Secrets verschoben, und zwar in denselben Namespace, in dem die Anwendung läuft. Dadurch wurde es möglich, mehrere Anwendungen in verschiedenen Namespaces mit demselben Release-Namen gleichzeitig auszuführen. In der zweiten Version war dies ein großes Problem, da Namespaces isoliert sind, aber sich gegenseitig beeinflussen können.

Die zweite Version von Helm verwendet bei der Überprüfung, ob ein Update erforderlich ist, nur zwei Informationsquellen: das, was ihr jetzt bereitgestellt wurde, und die internen Informationen über die Releases, die in der ConfigMap gespeichert sind.

Der dritte Helm verwendet die Strategie des Three-Way-Merge: Zusätzlich zu den vorhandenen Informationen berücksichtigt er auch die Anwendung, die gerade in Kubernetes läuft.

Aus diesem Grund wird die alte Version von Helm nichts tun, da sie die Informationen der Anwendung im Cluster nicht berücksichtigt, während Helm 3 Änderungen erhält und die neue Anwendung für das Deployment sendet.

Methode 5. Verwenden Sie den Schlüssel —recreate-pods

Mit dem Schlüssel --recreate-pods kann das erreicht werden, was ursprünglich mit dem Schlüssel geplant war. --forceDie Container werden neu gestartet und, gemäß der Policy imagePullPolicy: Always für das Tag latest (darüber in der Fußnote oben), wird Kubernetes die neue Version des Images herunterladen und starten. Das geschieht nicht auf die beste Art: Ohne Berücksichtigung des StrategyType des Deployments schaltet es abrupt alle alten Instanzen der Anwendung ab und beginnt, neue zu starten. Während des Neustarts wird das System nicht funktionieren, und die Benutzer werden darunter leiden.

Auch im Kubernetes selbst gab es dieses Problem lange Zeit. Und nach 4 Jahren seit der Entdeckung Issue, wurde das Problem behoben, und seit Version 1.15 von Kubernetes gibt es die Möglichkeit, diese Pods rolling-restart.

Helm schaltet einfach alle Anwendungen aus und startet daneben neue Container. Das sollte in der Produktion nicht gemacht werden, um einen Stillstand der Anwendung zu vermeiden. Das ist nur für Entwicklungszwecke notwendig und kann nur in Stage-Umgebungen durchgeführt werden.

Wie aktualisiere ich die Version der Anwendung mit Helm?

Wir werden die Werte ändern, die an Helm gesendet werden. In der Regel sind dies die Werte, die anstelle des Tags des Images eingesetzt werden. Im Fall von latest, das häufig für nicht produktive Umgebungen verwendet wird, ist die zu ändernde Information die Annotation, die für Kubernetes nutzlos ist, aber für Helm ein Signal zum Aktualisieren der Anwendung darstellt. Möglichkeiten zur Ausfüllung des Wertes der Annotation:

Zufälliger Wert mithilfe der Standardfunktion — {{ randAlphaNum 6 }}.
Es gibt einen Schönheitsfehler: Nach jedem Deployment mit einem Chart, der solch eine Variable enthält, wird der Wert der Annotation einzigartig sein, und Helm wird annehmen, dass es Änderungen gibt. Das bedeutet, wir werden die Anwendung immer neu starten, auch wenn wir ihre Version nicht geändert haben. Das ist nicht kritisch, da es keine Stillstände geben wird, aber dennoch unangenehm.
Aktuelles Datum und Uhrzeit — {{ .Release.Date }}.
Die Variante ähnelt dem zufälligen Wert mit einer ständig einzigartigen Variablen.
Eine bessere Methode ist die Verwendung von Prüfziffern. Das ist der SHA des Images oder der SHA des letzten Commits in Git — {{ .Values.sha }}.
Diese müssen berechnet und an den Helm-Client auf der aufrufenden Seite gesendet werden, zum Beispiel in Jenkins. Wenn sich die Anwendung ändert, ändert sich auch die Prüfziffer. Folglich wird Helm die Anwendung nur dann aktualisieren, wenn es nötig ist.

Fassen wir unsere Versuche zusammen

Helm nimmt Änderungen auf die am wenigsten invasive Weise vor, daher führt jede Änderung auf der Ebene des Anwendungsimages im Docker Registry nicht zu einem Update: Nach Ausführung des Befehls passiert nichts.
Schlüssel --force wird zur Wiederherstellung problematischer Releases verwendet und steht nicht im Zusammenhang mit einem erzwungenen Update.
Schlüssel --recreate-pods erzwingt die Aktualisierung von Anwendungen, tut dies jedoch auf eine gewaltsame Weise: Es schaltet abrupt alle Container aus. Davon leiden die Benutzer, im produktiven Betrieb sollte man das nicht tun.
Direkt Änderungen am Kubernetes-Cluster mit dem Befehl kubectl edit sind nicht erforderlich: Wir würden die Konsistenz verletzen, und das Verhalten wäre von der Helm-Version abhängig.
Mit der neuen Version von Helm sind viele Nuancen hinzugekommen. Die Issues im Helm-Repository sind in verständlicher Sprache beschrieben und helfen, die Details zu verstehen.
Durch das Hinzufügen einer veränderbaren Annotation zum Chart wird es flexibler. Dadurch kann die Anwendung richtig ausgerollt werden, ohne Ausfallzeiten.

Ein Gedanke, der in allen Lebensbereichen funktioniert: Lesen Sie die Anleitung vor der Anwendung und nicht danach. Nur mit vollständigen Informationen lassen sich zuverlässige Systeme aufbauen und die Benutzer glücklich machen.

Weitere Links zum Thema:

Dieser Bericht wurde erstmals auf @Kubernetes Conference von Mail.ru Cloud Solutions. Sehen Sie das Video weitere Vorträge und abonnieren Sie die Ankündigungen von Veranstaltungen auf Telegram Rund um Kubernetes in der Mail.ru Group.

Quelle: habr.com