Mein Name ist Dmitry Sugrobov, ich bin Entwickler bei Leroy Merlin. In diesem Artikel erzähle ich Ihnen, warum Helm benötigt wird, wie er die Arbeit mit Kubernetes vereinfacht, was sich in der dritten Version geändert hat und wie Sie damit Anwendungen in der Produktion ohne Ausfallzeiten aktualisieren können.
Dies ist eine Zusammenfassung, die auf einer Rede auf einer Konferenz basiert by — Wenn Sie nicht lesen möchten, schauen Sie sich das Video an.
Warum wir Kubernetes in der Produktion verwenden
Leroy Merlin ist führend auf dem DIY-Einzelhandelsmarkt in Russland und Europa. Unser Unternehmen hat mehr als hundert Entwickler, 33 interne Mitarbeiter und eine große Anzahl von Menschen, die Verbrauchermärkte und die Website besuchen. Um sie alle glücklich zu machen, haben wir uns entschieden, branchenübliche Ansätze zu verfolgen. Entwickeln Sie neue Anwendungen mithilfe einer Microservice-Architektur. Verwenden Sie Behälter, um Umgebungen zu isolieren und eine ordnungsgemäße Lieferung sicherzustellen. und verwenden Sie Kubernetes für die Orchestrierung. Die Kosten für den Einsatz von Orchestratoren werden immer günstiger: Die Zahl der mit der Technologie vertrauten Ingenieure auf dem Markt wächst und es tauchen immer mehr Anbieter auf, die Kubernetes als Service anbieten.
Alles, was Kubernetes macht, kann natürlich auch auf andere Weise erledigt werden, zum Beispiel durch die Abdeckung einiger Jenkins und Docker-Compose mit Skripten, aber warum sollte man das Leben verkomplizieren, wenn es eine fertige und zuverlässige Lösung gibt? Deshalb sind wir zu Kubernetes gekommen und nutzen es seit einem Jahr in der Produktion. Wir haben derzeit vierundzwanzig Kubernetes-Cluster, von denen der älteste mehr als ein Jahr alt ist, mit etwa zweihundert Pods.
Der Fluch großer YAML-Dateien in Kubernetes
Um einen Microservice 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 Pfostenpaket, für die dritte schreiben wir ein weiteres und so weiter. Wenn wir die Anzahl der Dokumente mit der Anzahl der Umgebungen multiplizieren, erhalten wir bereits Hunderte von Dateien, wobei dynamische Umgebungen noch nicht berücksichtigt sind.
Adam Reese, Hauptbetreuer von Helm, stellte das Konzept vor: „", das so aussieht:
- YAML kopieren – Kopieren Sie eine YAML-Datei.
- YAML einfügen – einfügen.
- Einzüge korrigieren – Einzüge korrigieren.
- Wiederholen – noch einmal wiederholen.
Die Option funktioniert, allerdings müssen Sie die YAML-Dateien viele Male kopieren. Um diesen Zyklus zu ändern, wurde Helm erfunden.
Was ist Helm
Erstens, Helm - Paket-Manager, das Ihnen hilft, die benötigten Programme zu finden und zu installieren. Um beispielsweise MongoDB zu installieren, müssen Sie nicht auf die offizielle Website gehen und Binärdateien herunterladen, sondern führen Sie einfach den Befehl aus helm install stable/mongodb.
Zweitens, Helm - Template-Engine, hilft bei der Parametrisierung von Dateien. Kehren wir zur Situation mit YAML-Dateien in Kubernetes zurück. Es ist einfacher, dieselbe YAML-Datei zu schreiben und ihr einige Platzhalter hinzuzufügen, in die Helm die Werte einsetzt. Das heißt, anstelle eines großen Satzes von Gerüsten wird es einen Satz Vorlagen geben, in die die erforderlichen Werte zum richtigen Zeitpunkt eingefügt werden.
Drittens, Helm - Bereitstellungsmaster. Damit können Sie Anwendungen installieren, Rollbacks durchführen und aktualisieren. Lassen Sie uns herausfinden, wie das geht.
So verwenden Sie Helm, um Ihre eigenen Anwendungen bereitzustellen
Lassen Sie uns den Helm-Client gemäß den offiziellen Anweisungen auf Ihrem Computer installieren . Als Nächstes erstellen wir eine Reihe von YAML-Dateien. Anstatt konkrete Werte anzugeben, werden wir Platzhalter belassen, die Helm künftig mit Informationen füllen wird. Eine Reihe solcher Dateien wird als Helm-Chart bezeichnet. Es kann auf drei Arten an den Helm-Konsolen-Client gesendet werden:
- geben Sie einen Ordner mit Vorlagen an;
- Packen Sie das Archiv in eine .tar-Datei und zeigen Sie darauf.
- Legen Sie die Vorlage in einem Remote-Repository ab und fügen Sie im Helm-Client einen Link zum Repository hinzu.
Sie benötigen außerdem eine Datei mit Werten – Values.yaml. Die Daten von dort werden in die Vorlage eingefügt. Lass es uns auch schaffen.
Die zweite Version von Helm verfügt über eine zusätzliche Serveranwendung – Tiller. Es hängt außerhalb von Kubernetes und wartet auf Anfragen vom Helm-Client. Wenn es aufgerufen wird, ersetzt es die erforderlichen Werte in die Vorlage und sendet sie an Kubernetes.
Helm 3 ist einfacher: Anstatt Vorlagen auf dem Server zu verarbeiten, werden Informationen jetzt vollständig auf der Helm-Client-Seite verarbeitet und direkt an die Kubernetes-API gesendet. Diese Vereinfachung verbessert die Clustersicherheit und erleichtert das Rollout-Schema.
Wie funktioniert das Ganze?
Führen Sie den Befehl aus helm install. Geben wir den Namen der Anwendungsversion und den Pfad zu „values.yaml“ an. Am Ende geben wir das Repository an, in dem sich das Diagramm befindet, und den Namen des Diagramms. Im Beispiel sind dies „lmru“ bzw. „bestchart“.
helm install --name bestapp --values values.yaml lmru/bestchart
Der Befehl kann nur einmal ausgeführt werden, stattdessen wird er erneut ausgeführt install verwenden müssen upgrade. Der Einfachheit halber können Sie anstelle von zwei Befehlen den Befehl ausführen upgrade mit Zusatzschlüssel --install. Bei der ersten Ausführung sendet Helm einen Befehl zur Installation der Version und aktualisiert sie in Zukunft.
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Fallstricke bei der Bereitstellung neuer Versionen einer Anwendung mit Helm
An diesem Punkt der Geschichte spiele ich mit dem Publikum „Wer wird Millionär“ und wir überlegen, wie wir Helm dazu bringen können, die Version der App zu aktualisieren. .
Als ich lernte, wie Helm funktioniert, war ich von einem seltsamen Verhalten überrascht, als ich versuchte, Versionen laufender Anwendungen zu aktualisieren. Ich habe den Anwendungscode aktualisiert, ein neues Image in die Docker-Registrierung hochgeladen, den Bereitstellungsbefehl gesendet – und nichts ist passiert. Im Folgenden finden Sie einige nicht ganz erfolgreiche Möglichkeiten zum Aktualisieren von Anwendungen. Indem Sie die einzelnen Elemente genauer studieren, beginnen Sie, die interne Struktur des Instruments und die Gründe für dieses nicht offensichtliche Verhalten zu verstehen.
Methode 1. Ändern Sie die Informationen seit dem letzten Start nicht
Wie das Sprichwort sagt Helm: „Kubernetes-Diagramme können groß und komplex sein, daher versucht Helm, nichts zu sehr anzutasten.“ Wenn Sie daher die neueste Version des Anwendungsimages in der Docker-Registrierung aktualisieren und den Befehl ausführen helm upgrade, dann passiert nichts. Helm geht davon aus, dass sich nichts geändert hat und dass kein Befehl an Kubernetes gesendet werden muss, um die Anwendung zu aktualisieren.
Hier und im Folgenden wird der neueste Tag lediglich als Beispiel angezeigt. Wenn Sie dieses Tag angeben, lädt Kubernetes das Image jedes Mal aus der Docker-Registrierung herunter, unabhängig vom Parameter imagePullPolicy. Die Verwendung neuester Produkte ist unerwünscht und verursacht Nebenwirkungen.
Methode 2. LABEL im Bild aktualisieren
Wie im selben geschrieben „Helm aktualisiert eine Anwendung nur, wenn sie sich seit der letzten Veröffentlichung geändert hat.“ Eine logische Option hierfür scheint die Aktualisierung des LABEL im Docker-Image selbst zu sein. Helm schaut sich die Anwendungsbilder jedoch nicht an und hat keine Ahnung, dass sich daran Änderungen ergeben. Dementsprechend erfährt Helm bei der Aktualisierung von Beschriftungen im Image nichts davon und der Befehl zur Anwendungsaktualisierung wird nicht an Kubernetes gesendet.
Methode 3: Verwenden Sie einen Schlüssel --force
Schauen wir uns die Handbücher an und suchen nach dem erforderlichen Schlüssel. Der Schlüssel macht am meisten Sinn --force. Trotz des offensichtlichen Namens ist das Verhalten anders als erwartet. Anstatt ein Anwendungsupdate zu erzwingen, besteht der eigentliche Zweck darin, eine Version wiederherzustellen, die sich im Status „FEHLGESCHLAGEN“ befindet. Wenn Sie diese Taste nicht verwenden, müssen Sie die Befehle nacheinander ausführen helm delete && helm install --replace. Es wird empfohlen, stattdessen den Schlüssel zu verwenden --force, das die sequentielle Ausführung dieser Befehle automatisiert. Weitere Informationen finden Sie hier . Um Helm anzuweisen, die Anwendungsversion zu aktualisieren, funktioniert dieser Schlüssel leider nicht.
Methode 4. Labels direkt in Kubernetes ändern
Aktualisieren Sie das Label direkt im Cluster mit dem Befehl kubectl edit - schlechte Idee. Diese Aktion führt zu einer Inkonsistenz der Informationen zwischen der laufenden Anwendung und der, die ursprünglich zur Bereitstellung gesendet wurde. Das Verhalten von Helm während der Bereitstellung unterscheidet sich in diesem Fall von seiner Version: Helm 2 führt keine Aktionen aus und Helm 3 stellt die neue Version der Anwendung bereit. Um zu verstehen, warum, müssen Sie verstehen, wie Helm funktioniert.
Wie funktioniert Helm?
Um festzustellen, ob sich eine Anwendung seit ihrer letzten Veröffentlichung geändert hat, kann Helm Folgendes verwenden:
- Ausführen einer Anwendung in Kubernetes;
- neue Werte.yaml und aktuelles Diagramm;
- Helms interne Release-Informationen.
Für die Neugierigeren: Wo speichert Helm interne Informationen über Veröffentlichungen?Durch Ausführen des Befehls helm historyerhalten wir alle Informationen zu den mit Helm installierten Versionen.
Außerdem gibt es detaillierte Informationen zu den gesendeten Vorlagen und Werten. Wir können es anfordern:
In der zweiten Version von Helm befinden sich diese Informationen im selben Namespace, in dem Tiller ausgeführt wird (standardmäßig kube-system), in der ConfigMap, gekennzeichnet mit der Bezeichnung „OWNER=TILLER“:
Als die dritte Version von Helm erschien, wurden die Informationen in Secrets und in denselben Namespace verschoben, in dem die Anwendung ausgeführt wurde. Dadurch wurde es möglich, mehrere Anwendungen gleichzeitig in verschiedenen Namespaces mit demselben Release-Namen auszuführen. In der zweiten Version war es ein ernstes Problem, wenn Namespaces isoliert sind, sich aber gegenseitig beeinflussen können.
Wenn der zweite Helm versucht zu verstehen, ob ein Update erforderlich ist, verwendet er nur zwei Informationsquellen: was ihm jetzt zur Verfügung gestellt wird, und interne Informationen zu Releases, die in der ConfigMap liegen.
Der dritte Helm verwendet eine Drei-Wege-Merge-Strategie: Zusätzlich zu diesen Informationen berücksichtigt er auch die Anwendung, die gerade in Kubernetes ausgeführt wird.
Aus diesem Grund wird die alte Version von Helm nichts unternehmen, da sie die Anwendungsinformationen im Cluster nicht berücksichtigt, aber Helm 3 empfängt die Änderungen und sendet die neue Anwendung zur Bereitstellung.
Methode 5. Verwenden Sie den Schalter --recreate-pods
Mit einem Schlüssel --recreate-pods Sie können mit dem Schlüssel das erreichen, was Sie ursprünglich geplant hatten --force. Die Container werden neu gestartet und gemäß der imagePullPolicy: Always-Richtlinie für das neueste Tag (mehr dazu in der Fußnote oben) lädt Kubernetes eine neue Version des Images herunter und startet sie. Dies wird nicht auf die beste Weise geschehen: Ohne Berücksichtigung des Strategietyps der Bereitstellung werden alle alten Anwendungsinstanzen abrupt ausgeschaltet und neue gestartet. Während des Neustarts funktioniert das System nicht, die Benutzer werden darunter leiden.
Auch bei Kubernetes selbst bestand seit längerem ein ähnliches Problem. Und jetzt, 4 Jahre nach der Eröffnung , das Problem wurde behoben und ab Version 1.15 von Kubernetes gibt es die Möglichkeit, Pods rollierend neu zu starten.
Helm schaltet einfach alle Anwendungen aus und startet neue Container in der Nähe. Dies ist in der Produktion nicht möglich, um keine Ausfallzeiten der Anwendung zu verursachen. Dies wird nur für Entwicklungszwecke benötigt und kann nur in Bühnenumgebungen durchgeführt werden.
Wie aktualisiere ich die Anwendungsversion mit Helm?
Wir werden die an Helm gesendeten Werte ändern. Typischerweise handelt es sich hierbei um Werte, die anstelle des Bild-Tags eingesetzt werden. Im Fall von Latest, das häufig in unproduktiven Umgebungen verwendet wird, handelt es sich bei den veränderbaren Informationen um eine Annotation, die für Kubernetes selbst nutzlos ist und für Helm als Signal für die Notwendigkeit einer Aktualisierung der Anwendung dient. Optionen zum Ausfüllen des Anmerkungswerts:
- Zufälliger Wert mit der Standardfunktion -
{{ randAlphaNum 6 }}.
Es gibt eine Einschränkung: Nach jeder Bereitstellung unter Verwendung eines Diagramms mit einer solchen Variablen ist der Annotationswert eindeutig und Helm geht davon aus, dass es Änderungen gibt. Es stellt sich heraus, dass wir die Anwendung immer neu starten, auch wenn wir ihre Version nicht geändert haben. Dies ist nicht kritisch, da es keine Ausfallzeiten gibt, ist aber dennoch unangenehm. - Aktuelles einfügen Datum (und Uhrzeit -
{{ .Release.Date }}.
Eine Variante ähnelt einem Zufallswert mit einer dauerhaft eindeutigen Variablen. - Ein korrekterer Weg ist die Verwendung Prüfsummen. Dies ist der SHA des Bildes oder der SHA des letzten Commits im Git -
{{ .Values.sha }}.
Sie müssen gezählt und an den Helm-Client auf der aufrufenden Seite gesendet werden, beispielsweise in Jenkins. Wenn sich die Anwendung geändert hat, ändert sich auch die Prüfsumme. Daher aktualisiert Helm die Anwendung nur bei Bedarf.
Fassen wir unsere Versuche zusammen
- Helm nimmt Änderungen auf die am wenigsten invasive Weise vor, sodass jede Änderung auf der Anwendungs-Image-Ebene in der Docker-Registrierung nicht zu einer Aktualisierung führt: Nach der Ausführung des Befehls geschieht nichts.
- Schlüssel
--forceWird zum Wiederherstellen problematischer Versionen verwendet und ist nicht mit erzwungenen Updates verbunden. - Schlüssel
--recreate-podsaktualisiert Anwendungen zwangsweise, tut dies jedoch auf vandalistische Weise: Alle Container werden abrupt ausgeschaltet. Die Benutzer werden darunter leiden; Sie sollten dies in der Produktion nicht tun. - Nehmen Sie mit dem Befehl direkt Änderungen am Kubernetes-Cluster vor
kubectl editTun Sie es nicht: Wir brechen die Konsistenz und das Verhalten wird je nach Helm-Version unterschiedlich sein. - Mit der Veröffentlichung der neuen Helm-Version sind viele Nuancen aufgetaucht. Probleme im Helm-Repository werden in klarer Sprache beschrieben und helfen Ihnen, die Details zu verstehen.
- Durch das Hinzufügen einer bearbeitbaren Anmerkung zu einem Diagramm wird es flexibler. Dadurch können Sie die Anwendung korrekt und ohne Ausfallzeiten ausrollen.
Ein „Weltfrieden“-Gedanke, der in allen Lebensbereichen funktioniert: Lesen Sie die Gebrauchsanweisung vor der Anwendung, nicht danach. Nur mit vollständigen Informationen ist es möglich, zuverlässige Systeme aufzubauen und Benutzer zufrieden zu stellen.
Weitere verwandte Links:
Dieser Bericht wurde erstmals vorgestellt bei von Mail.ru Cloud Solutions. Suchen andere Aufführungen und abonnieren Sie Veranstaltungsankündigungen auf Telegram .
Source: habr.com