🥇 Die Funktionsweise von Helm und seine Fallstricke

Konzept des Typhon-Frachttransporters, Anton Swanepoel

Mein Name ist Dmitrij Sugrobov, ich bin Entwickler bei „Leroy Merlin“. In diesem Artikel erläutere ich, warum Helm nötig ist, wie er die Arbeit mit Kubernetes erleichtert, was sich in der dritten Version geändert hat und wie man mit seiner Hilfe Anwendungen im Produktionsumfeld ohne Ausfallzeit aktualisieren kann.

Dies ist eine Zusammenfassung basierend auf einem Vortrag auf einer Konferenz @Kubernetes Konferenz by Mail.ru Cloud Lösungen — wenn Sie nicht lesen möchten, schauen Sie sich das Video an.

Warum wir Kubernetes in der Produktion verwenden

„Leroy Merlin“ ist ein führendes Unternehmen im DIY-Einzelhandel in Russland und Europa. In unserer Firma gibt es mehr als einhundert Entwickler, 33.000 interne Mitarbeiter und eine riesige Anzahl von Menschen, die unsere Baumärkte und unsere Website besuchen. Um alle glücklich zu machen, haben wir uns entschieden, uns an gängige Standards der Branche zu halten. Wir entwickeln neue Anwendungen unter Verwendung einer Microservices-Architektur; zur Isolierung von Umgebungen und für die korrekte Bereitstellung nutzen wir Container; und für die Orchestrierung verwenden wir Kubernetes. Die Kosten für den Einsatz von Orchestratoren sinken rasant: Die Anzahl der Ingenieure, die mit der Technologie vertraut sind, steigt, und es entstehen Anbieter, die Kubernetes als Service anbieten.

Alles, was Kubernetes tut, kann natürlich auch auf andere Weise erledigt werden, zum Beispiel indem man mit Skripten einen Jenkins und docker-compose aufsetzt. Aber warum das Leben komplizierter machen, wenn es eine fertige und zuverlässige Lösung gibt? Daher haben wir uns für Kubernetes entschieden und nutzen es nun seit einem Jahr in der Produktion. Momentan betreiben wir vierundzwanzig Kubernetes-Cluster, der älteste hat über ein Jahr auf dem Buckel und umfasst etwa zweihundert Pods.

Das Fluch der vielen 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 diese in den Cluster. Für die nächste Anwendung wiederholen wir diesen YAML-Satz, und mit der dritten – nochmals einen und so weiter. Multiplizieren wir die Anzahl der Dokumente mit der Anzahl der Umgebungen, haben wir bereits Hunderte von Dateien, ganz zu schweigen von dynamischen Umgebungen.

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

Copy YAML – YAML-Datei kopieren.
Paste YAML – einfügen.
Fix Indents – Einrückungen reparieren.
Repeat – erneut wiederholen.

Das ist ein funktionierender Ansatz, aber man muss die YAML-Dateien oft mehrfach kopieren. Um diesen Zyklus zu ändern, wurde Helm entwickelt.

Was ist Helm?

Zunächst einmal ist Helm – von KISS ist in Shell geschrieben und umfasst etwa 500 Zeilen Code. Alle Pakete werden aus Quelltexten erstellt. Die Abhängigkeiten werden berücksichtigt und zusätzliche Patches können angewendet werden., der bei der Suche und Installation der benötigten Programme hilft. 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 ist Helm — ein Template-Manager, der hilft, Dateien zu parametrisieren. Zurück zu den YAML-Dateien in Kubernetes. Es ist einfacher, dieselbe YAML-Datei zu schreiben und einige Platzhalter hinzuzufügen, die Helm mit Werten ausfüllt. Anstatt einer großen Anzahl von YAML-Dateien gibt es also eine Sammlung von Templates, in die zur passenden Zeit die benötigten Werte eingesetzt werden.

Drittens ist Helm — der Meister des Deployments. Damit können Anwendungen installiert, zurückgerollt und aktualisiert werden. Lass uns anschauen, wie das gemacht wird.

Wie man Helm zur Bereitstellung eigener Anwendungen nutzt

Wir installieren den Helm-Client auf dem Computer, indem wir der offiziellen Anleitung folgen. Anleitung. Anschließend erstellen wir eine Sammlung von YAML-Dateien. Anstatt spezifische Werte anzugeben, lassen wir Platzhalter, die Helm später mit Informationen füllen wird. Diese Sammlung von Dateien wird als Helm Chart bezeichnet. Es gibt drei Möglichkeiten, sie an den Helm-Konsolen-Client zu übermitteln:

ein Verzeichnis mit Templates angeben;
in einer .tar-Archive packen und darauf verweisen;
Legen Sie die Vorlage in ein entferntes Repository und fügen Sie den Link zum Repository im Helm-Client hinzu.

Außerdem wird eine Datei mit Werten benötigt – values.yaml. Die Daten daraus werden in die Vorlage eingesetzt. Lassen Sie uns auch diese erstellen.

In der zweiten Version von Helm gibt es eine zusätzliche Serveranwendung – Tiller. Diese läuft außerhalb von Kubernetes und wartet auf Anfragen vom Helm-Client, um beim Aufruf die erforderlichen Werte in die Vorlage einzusetzen und an Kubernetes zu senden.

Helm 3 ist einfacher strukturiert: Anstatt die Vorlagen auf dem Server zu verarbeiten, wird die gesamte Information jetzt direkt auf der Seite des Helm-Clients verarbeitet und direkt an die Kubernetes-API gesendet. Diese Vereinfachung erhöht die Sicherheit des Clusters und erleichtert den Rollout-Prozess.

So funktioniert das alles

Wir starten den Befehl helm install. Wir geben den Namen der Anwendungsbereitstellung an und den Pfad zur values.yaml. Am Ende geben wir das Repository an, das das Chart enthält, sowie den Namen des Charts. In diesem 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 erneuten Ausführung muss install verwendet werden. upgradeUm es einfacher zu machen, kann der Befehl upgrade mit dem zusätzlichen Schlüssel --install. Bei der ersten Ausführung sendet Helm den Befehl zur Installation des Releases und wird es fortan aktualisieren.

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

Herausforderungen beim Deployen neuer Versionen von Anwendungen mit Helm

An dieser Stelle des Erzählens spiele ich mit dem Publikum in „Wer wird Millionär?“ und wir klären, wie wir Helm dazu bringen, die Version der Anwendung zu aktualisieren. Video ansehen.

Als ich die Funktionsweise von Helm studierte, war ich über das seltsame Verhalten erstaunt, als ich versuchte, die Versionen laufender Anwendungen zu aktualisieren. Ich hatte den Anwendungscode aktualisiert, ein neues Image im Docker-Registry hochgeladen, den Befehl zum Deployen gesendet – und es passierte nichts. Nachfolgend einige weniger erfolgreiche Methoden zur Aktualisierung von Anwendungen. Wenn man jede von ihnen genauer betrachtet, versteht man die inneren Funktionsweisen des Tools und die Gründe für dieses nicht offensichtliche Verhalten.

Methode 1. Keine Informationen seit dem letzten Start ändern

Wie es heißt eine offizielle Website Helm: 'Kubernetes-Charts können groß und komplex sein, deshalb bemüht sich Helm darum, nichts unnötig zu ändern.' Daher, wenn man die neueste Version des Anwendung-Images im Docker-Registry aktualisiert und den Befehl ausführt helm upgrade, dann passiert nichts. Helm wird denken, dass sich nichts geändert hat, und es ist nicht notwendig, Kubernetes den Befehl zur Aktualisierung der Anwendung zu senden.

Der Tag latest wird hier und in der Folge nur als Beispiel angezeigt. Wenn dieser Tag angegeben ist, wird Kubernetes jedes Mal das Image aus dem Docker-Registry herunterladen, unabhängig von der imagePullPolicy. Die Verwendung von latest in der Produktion ist unerwünscht und kann Nebenwirkungen verursachen.

Methode 2. LABEL im Image aktualisieren

Wie im selben Dokumentation., "Helm wird die Anwendung nur aktualisieren, wenn sie sich seit dem letzten Release geändert hat." Eine logische Option dafür wäre es, das LABEL im Docker-Image zu aktualisieren. Allerdings sieht Helm nicht in die Anwendungs-Images und hat keine Kenntnis über Änderungen daran. Daher wird Helm bei der Aktualisierung der Labels im Image nichts davon erfahren, und der Befehl zur Aktualisierung der Anwendung wird nicht an Kubernetes gesendet.

Methode 3. Den Schlüssel --force

Schauen wir in die Handbücher und suchen nach dem passenden Schlüssel. Am sinnvollsten scheint der Schlüssel --force. Trotz des vielsagenden Namens verhält sich das Ganze anders als erwartet. Anstelle eines erzwungenen Anwendungsupdates ist es tatsächlich dafür gedacht, eine fehlgeschlagene Veröffentlichung wiederherzustellen. Wenn dieser Schlüssel nicht verwendet wird, müssen die Kommandos nacheinander ausgeführt werden. helm delete && helm install --replace. Stattdessen wird empfohlen, den Schlüssel --force, der das sequentielle Ausführen dieser Kommandos automatisiert, zu verwenden. Weitere Informationen finden Sie in diesem Pull-Request.. Um Helm tatsächlich zu sagen, dass die Version der Anwendung aktualisiert werden soll, geeignet sich dieser Schlüssel leider nicht.

Methode 4. Labels direkt in Kubernetes ändern.

Die Aktualisierung von Labels direkt im Cluster mit dem Befehl kubectl edit ist eine schlechte Idee. Diese Aktion führt zu Inkonsistenzen zwischen der laufenden Anwendung und dem, was ursprünglich deployt wurde. Das Verhalten von Helm beim Deployment ist in diesem Fall anders als in der vorherigen Version: Helm 2 wird nichts tun, während Helm 3 eine neue Version der Anwendung deployt. Um den Grund zu verstehen, muss man wissen, wie Helm funktioniert.

Wie Helm funktioniert

Um festzustellen, ob sich die Anwendung seit der letzten Veröffentlichung geändert hat, kann Helm Folgendes verwenden:

laufenden Anwendung in Kubernetes;
neuen values.yaml und dem aktuellen Chart;
internen Helm-Informationen zu den Releases.

Für die Neugierigen: Wo speichert Helm die internen Informationen zu den Releases?Führen Sie den Befehl aus helm history, um alle Informationen zu den Versionen, die mit Helm installiert wurden, zu erhalten.

Es gibt auch detaillierte Informationen zu den übermittelten Templates 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), im ConfigMap, das mit dem Tag „OWNER=TILLER“ versehen ist:

Mit dem Erscheinen der dritten Helm-Version sind die Informationen in Secrets umgezogen, und zwar in denselben Namespace, in dem die Anwendung läuft. Dadurch wurde es möglich, mehrere Anwendungen gleichzeitig in verschiedenen Namespaces mit demselben Release-Namen zu starten. In der zweiten Version war dies ein großes Kopfzerbrechen, da Namespaces isoliert sind, aber dennoch Einfluss aufeinander nehmen können.

Die zweite Helm-Version, wenn sie versucht zu verstehen, ob ein Update erforderlich ist, verwendet nur zwei Informationsquellen: das, was ihr gerade bereitgestellt wurde, und die internen Informationen zu den Releases, die im ConfigMap liegen.

Die dritte Version von Helm verwendet eine Strategie des Three-Way-Merge: Zusätzlich zu den vorhandenen Informationen wird auch die Anwendung berücksichtigt, die aktuell in Kubernetes läuft.

Aus diesem Grund wird die alte Version von Helm nichts unternehmen, da sie die Informationen über die Anwendung im Cluster nicht berücksichtigt. Helm 3 hingegen wird die Änderungen erfassen und die neue Anwendung bereitstellen.

Methode 5. Verwenden des Schlüssels —recreate-pods

Mit dem Schlüssel --recreate-pods kann das erreicht werden, was ursprünglich mit dem Schlüssel --forcegeplant war. Die Container werden neu gestartet und, gemäß der Richtlinie imagePullPolicy: Always für das Tag latest (siehe Anmerkung oben), wird Kubernetes die neue Version des Images herunterladen und starten. Dies geschieht jedoch nicht optimal: Unabhängig vom StrategyType des Deployments werden abrupt alle alten Instanzen der Anwendung abgeschaltet und neue gestartet. Während des Neustarts wird das System nicht funktionieren, und die Benutzer werden betroffen sein.

Ein ähnliches Problem bestand auch in Kubernetes über einen längeren Zeitraum. Und nun, vier Jahre nach der Entdeckung Problem, wurde das Problem behoben, und seit Version 1.15 von Kubernetes gibt es die Möglichkeit, Pods rolling-neu zu starten.

Helm schaltet einfach alle Anwendungen aus und startet daneben neue Container. Das sollte in der Produktion nicht gemacht werden, um keine Ausfallzeiten der Anwendung zu verursachen. Das ist nur für Entwicklungszwecke notwendig und sollte ausschließlich in Staging-Umgebungen durchgeführt werden.

Wie aktualisiere ich die Version einer Anwendung mit Helm?

Wir werden die Werte ändern, die an Helm übergeben werden. In der Regel sind das die Werte, die anstelle des Image-Tags eingesetzt werden. Bei 'latest', das häufig in nicht-produktiven Umgebungen verwendet wird, ist die zu ändernde Information die Annotation, die für Kubernetes selbst nutzlos ist, aber für Helm als Signal zur Notwendigkeit der Aktualisierung der Anwendung dient. Optionen zur Ausfüllung des Wertes der Annotation:

Zufälliger Wert mit der Standardfunktion — {{ randAlphaNum 6 }}.
Es gibt einen Haken: Nach jedem Deployment mit einem Chart, das eine solche Variable enthält, wird der Wert der Annotation einzigartig sein, und Helm wird annehmen, dass Änderungen vorliegen. Das heißt, wir werden die Anwendung immer neu starten, auch wenn wir ihre Version nicht geändert haben. Das ist nicht kritisch, da es keine Ausfallzeiten geben wird, aber dennoch unangenehm.
Aktuelles Datum und Uhrzeit — {{ .Release.Date }}.
Die Option ähnelt einem zufälligen Wert mit einer ständig einzigartigen Variable.
Der richtigere Weg ist, Prüfziffern. Dies ist der SHA des Images oder der SHA des letzten Commits im Git – {{ .Values.sha }}.
Sie müssen berechnet und an den Helm-Client auf der aufrufenden Seite gesendet werden, beispielsweise in Jenkins. Wenn sich die Anwendung ändert, ändert sich auch die Prüfziffer. Daher wird Helm die Anwendung nur dann aktualisieren, wenn es notwendig ist.

Fassen wir unsere Versuche zusammen.

Helm führt Änderungen auf die am wenigsten invasive Weise durch, weshalb jede Änderung auf der Ebene des Anwendungs-Images im Docker-Registry nicht zu einem Update führt: Nach der Ausführung des Befehls passiert nichts.
Der Schlüssel --force wird verwendet, um problematische Releases wiederherzustellen und steht nicht im Zusammenhang mit einem erzwungenen Update.
Der Schlüssel --recreate-pods wird die Anwendungen gezwungen aktualisieren, aber auf vandalistische Weise: Alle Container werden abrupt abgeschaltet. Dies wird den Benutzern schaden; so sollte man das in der Produktion nicht machen.
Änderungen direkt am Kubernetes-Cluster durchzuführen mit dem Befehl kubectl edit sollte man nicht: wir würden die Konsistenz verletzen, und das Verhalten würde je nach Helm-Version variieren.
Mit der neuen Version von Helm sind viele Nuancen aufgetreten. Die Probleme im Helm-Repository sind klar beschrieben und helfen, die Details zu verstehen.
Das Hinzufügen einer veränderbaren Annotation zum Chart macht es flexibler. Dadurch kann die Anwendung korrekt ausgerollt werden, ohne Ausfallzeiten.

Ein Gedanke, der in allen Lebensbereichen gilt: Lesen Sie die Anleitung vor der Anwendung, nicht danach. Nur mit vollständigen Informationen können zuverlässige Systeme aufgebaut und die Nutzer glücklich gemacht werden.

Weitere Links zum Thema:

Dieser Vortrag wurde erstmals gehalten auf @Kubernetes Konferenz von Mail.ru Cloud Solutions. Sehen Sie sich an Video anderer Vorträge an und abonnieren Sie die Veranstaltungshinweise auf Telegram. Rund um Kubernetes in der Mail.ru Group.

Quelle: habr.com