Veröffentlicht am 27-02-2019

Keine Ausfallzeiten mit Kubernetes und Istio

Foto von Jeremy Perkins auf Unsplash

Dies ist ein Auszug aus dem kommenden Ebook "Learn Istio". Sie können ein kostenloses 20-seitiges PDF-Dokument mit unterstützenden YAML-Dateien herunterladen oder das Buch unter https://learnistio.com vorbestellen

Die Idee hinter der Null-Ausfall-Release ist die Veröffentlichung einer neuen Version des Dienstes, ohne dass Benutzer davon betroffen sind. Das heißt, Benutzer wissen nicht einmal, wann eine neue Version des Dienstes veröffentlicht wird. Ein praktisches Beispiel wäre, wenn Sie eine Website betreiben. Wie können Sie eine neue Version veröffentlichen, ohne die Website herunterzufahren? Bei Diensten bedeutet dies, dass Sie fortlaufende Anforderungen an diesen Dienst stellen können, während ein neuer Dienst veröffentlicht wird und die Anrufer diese gefürchtete Antwort nie erhalten.

In diesem Artikel werde ich zwei Methoden erläutern, wie die Bereitstellung ohne Ausfallzeiten durchgeführt wird - eine nur mit Kubernetes und die zweite mit Istio-Service-Mesh.

Verwendung von Kubernetes (Rolling Updates)

Als erste Option für die Bereitstellung von Ausfallzeiten ohne Ausfallzeiten verwenden wir einfach "reine" Kubernetes, ohne dass ein Istio beteiligt ist. Wir werden eine einfache Node.Js-Webanwendung verwenden, die die Meldung "Hello World!" Anzeigt.

Sie können das obige YAML mit kubectl apply -f helloworld.yaml bereitstellen. Dadurch wird ein Kubernetes-Dienst namens helloworld und eine Kubernetes-Bereitstellung mit drei Replikaten und einem Image mit dem Namen learnistio / helloworld erstellt: 1.0.0 - so ziemlich das einfachste YAML, mit dem Sie etwas in Kubernetes ausführen können.

Um auf die Website zuzugreifen, können Sie den Befehl "port-forward" der Kubernetes-CLI verwenden. Dieser Befehl öffnet einen Tunnel zwischen dem Dienst, der im Cluster ausgeführt wird, und Ihrem lokalen Computer:

kubectl portforward service / helloworld 3000 3000

Öffnen Sie http: // localhost: 3000 in einem Browser Ihrer Wahl, und Sie sollten eine hässlich aussehende Seite wie in der folgenden Abbildung erhalten:

Sehr einfach aussehende Hello World App

Nun möchten wir diese Website mit einer neueren Version aktualisieren. Vorausgesetzt, Sie haben ein Image mit dem Namen learnistio / helloworld: 2.0.0 erstellt und erstellt, müssen wir die Bereitstellung mit diesem neuen Image aktualisieren. Darüber hinaus müssen wir die Bereitstellung so aktualisieren, dass sie sich nicht auf alle auswirkt, die versuchen, auf die Website zuzugreifen.

Wie bereits erwähnt, hat Kubernetes das Konzept, eine Bereitstellung ohne Ausfallzeiten mit einer Strategie namens RollingUpdate durchzuführen (diese Einstellung wird für die einzelnen Kubernetes-Implementierungen festgelegt). Dies ist die Standardeinstellung für jede Implementierung. Die zweite Strategie heißt Recreate. Wie der Name vermuten lässt, werden alle vorhandenen Pods gelöscht und die neuen erstellt.

Die standardmäßige Rolling-Update-Strategie aktualisiert die Pods rollend. Zur Steuerung des Prozesses können Sie zwei Einstellungen verwenden: maxUnavailable und maxSurge. Mit der ersten Einstellung können Sie angeben, wie viele Pods (ausgedrückt als Gesamtanzahl von Pods oder Prozentsatz) während der Aktualisierung nicht verfügbar sein können (der Standardwert ist 25%). Wenn Sie also vier Replikate ausführen und das Rolling Upgrade durchführen, wird die alte Bereitstellung auf 75% verkleinert. Gleichzeitig werden neue Pods online gestellt. Mit der Option maxSurge steuern Sie die maximale Anzahl von Pods, die erstellt werden können und über der gewünschten Anzahl von Pods liegen. Wenn wir das vorige Beispiel mit vier Replikaten betrachten und diesen Wert auf 50% setzen, wird die neue Bereitstellung durch den fortlaufenden Aktualisierungsprozess so skaliert, dass die Gesamtzahl der alten und neuen Pods die 150% der gewünschten Werte nicht überschreitet Hülsen (dh sechs Hülsen).

Um die vorhandene Bereitstellung mit der neuen Image-Version zu aktualisieren, verwenden wir den Befehl set in der Kubernetes-CLI. Lassen Sie uns den Befehl ausführen, um das fortlaufende Update durchzuführen:

kubectl set image deploy helloworld web = learnistio / helloworld: 2.0.0 - aufzeichnen

Der obige Befehl setzt das Image für den Container web mit dem Namen learnistio / helloworld: 2.0.0 und zeichnet die Änderung in der Bereitstellungsanmerkung auf (sodass Sie die Änderung ggf. rückgängig machen können).

Führen wir einen weiteren Befehl aus, der den Fortschritt des fortlaufenden Updates anzeigt:

Implementierung des $ kubectl-Rollouts-Status helloworld
Warten auf den Rollout der Bereitstellung „helloworld“: 2 von 3 neuen Repliken wurden aktualisiert…
helloworld wurde erfolgreich ausgerollt

Während dieser ganzen Zeit hätten Sie auf die Website zugreifen können, und Sie erhalten entweder die v1 der Homepage oder die v2. Nach Abschluss des Befehls sollten Sie jedoch nur Antworten von der Version 2 der Homepage erhalten.

Istio verwenden

Sie wundern sich vielleicht, warum ich mit Istio Rollup-Updates machen sollte - die Option Kubernetes ist viel einfacher. Das ist wahr, und Sie sollten Istio wahrscheinlich nicht verwenden, wenn Null-Ausfallzeiten-Releases das einzige sind, für das Sie es verwenden werden. Mit Istio können Sie dasselbe Verhalten erreichen. Sie haben jedoch weitaus mehr Kontrolle darüber, wie und wann der Verkehr zu bestimmten Versionen geleitet wird.

Um Istio für Ausfallzeiten zu verwenden, müssen Sie Folgendes beachten:

Eine Bereitstellung pro Version

Jede Bereitstellung des Service muss versioniert sein. Sie benötigen ein Label mit dem Namen version: v1 (oder ähnliches) sowie einen Namen für die Bereitstellung, sodass klar ist, welche Version sie darstellt (z. B. helloworld-v1). Normalerweise müssen mindestens zwei dieser Labels für jede Bereitstellung festgelegt werden:

Etiketten:
  App: helloworld
  Version: v1

Sie können auch mehrere andere Labels hinzufügen, wenn dies sinnvoll ist. Sie sollten jedoch ein Label haben, das zur Identifizierung Ihrer Komponente und ihrer Version verwendet wird.

Generischer Kubernetes-Dienst

Der Kubernetes-Dienst sollte generisch sein - es ist nicht erforderlich, dass die Version im Selektor vorhanden ist, nur der Name der App / Komponente ist ausreichend

Halten Sie die Bestimmungsregeln auf dem neuesten Stand

Beginnen Sie mit einer Zielregel, die derzeit ausgeführte Versionen enthält, und stellen Sie sicher, dass Sie sie synchron halten. Es ist nicht notwendig, eine Zielregel zu erstellen, die eine Reihe nicht verwendeter oder veralteter Teilmengen enthält.

Definieren Sie eine Fallback-Version

Wenn Sie Übereinstimmungen und Bedingungen verwenden, definieren Sie immer eine "Fallback" -Version des Diensts in Ihrem virtuellen Dienst. Andernfalls landen alle Anforderungen, die nicht den Bedingungen entsprechen, im digitalen Himmel und werden nicht bedient.

In Anbetracht dieser Richtlinien ist hier ein grober Prozess, wie Sie mit Istio eine Version ohne Ausfallzeiten erstellen können. Wir beginnen mit der Bereitstellung von Kubernetes helloworld-v1, einer Zielregel mit einer Teilmenge (v1) und einem virtuellen Dienst, der den gesamten Datenverkehr an die Teilmenge von v1 weiterleitet. Hier ist die Zielregel YAML:

Und hier ist der entsprechende virtuelle Dienst:

Wenn diese Ressourcen bereitgestellt werden, wird der gesamte Datenverkehr glücklich an die Version v1 weitergeleitet. Lass uns die Version 2 starten und ausrollen:

  1. Stellen Sie die geänderte Zielregel bereit, die die neue Teilmenge hinzufügt:

2. Stellen Sie den aktualisierten virtuellen Dienst bereit, wobei 100% des Verkehrs an das v1-Subset weitergeleitet wird.

3. Erstellen / Bereitstellen der Bereitstellung von helloworld-v2 Kubernetes.

4. Aktualisieren Sie den virtuellen Dienst, und stellen Sie ihn erneut bereit, um x% des Datenverkehrs an die Version v1 und y% des Datenverkehrs an das neue v2-Subset weiterzuleiten. Es gibt mehrere Möglichkeiten, dies zu tun - Sie können nach und nach mehr und mehr Datenverkehr auf Version 2 umleiten (z. B. in Schritten von 10%), oder Sie können eine direkte 50/50-Aufteilung zwischen den Versionen durchführen oder sogar 100% der Version weiterleiten Datenverkehr zur neuen v2-Teilmenge. Unabhängig davon, in welche Richtung Sie gehen, erhalten Sie eine Bereitstellung ohne Ausfallzeiten und damit eine 0/100% ige Verkehrsaufteilung.

5. Entfernen Sie das v1-Subset aus dem virtuellen Dienst, und stellen Sie den virtuellen Dienst erneut bereit.

6. Entfernen Sie das v1-Subset aus der Zielregel und stellen Sie es erneut bereit.

7. Löschen Sie die Version 1 von Kubernetes

Wenn Sie zu diesem Teil gelangt sind, fließt der gesamte Datenverkehr nun zum v2-Subset und Sie haben keine v1-Artefakte mehr.

Dies ist ein Auszug aus dem kommenden Ebook "Learn Istio". Sie können ein kostenloses 20-seitiges PDF-Dokument mit unterstützenden YAML-Dateien herunterladen oder das Buch unter https://learnistio.com vorbestellen

Siehe auch

Serverlos werden: Wie wir unsere Kundenwebseiten zu AWS Lambda migriertenIch denke mal, das Timing ist allesWarum schreibe ich Software?Auf der MWC 2019 war ein Xperia 5G-Smartphone zu sehenFake News: Wird der Akku mit einem Mikrowellengerät aufgeladen?Warum große Unternehmen und Marken-USB-Laufwerke nicht gleich glücklich klatschen.