🥇Kubernetes-Cluster-Update ohne Ausfallzeiten

Der Aktualisierungsprozess für Ihr Kubernetes-Cluster

Es gibt Momente, in denen beim Einsatz eines Kubernetes-Clusters die Notwendigkeit entsteht, die aktiven Knoten zu aktualisieren. Dies kann Updates von Paketen, das Aktualisieren des Kernels oder die Bereitstellung neuer Images von virtuellen Maschinen umfassen. In der Terminologie von Kubernetes wird dies als "Freiwillige Störung".

Dieser Beitrag ist Teil einer Reihe von 4 Beiträgen:

Dieser Beitrag.
Ordnungsgemäßes Herunterfahren von Pods in einem Kubernetes-Cluster
Abgegebene Störungen von Pods beim Löschen
Wie man Ausfallzeiten in einem Kubernetes-Cluster mit PodDisruptionBudgets vermeidet

(Anm. Üb. Die Übersetzungen der anderen Artikel der Reihe erwarten Sie in Kürze.)

In diesem Artikel werden wir alle Werkzeuge beschreiben, die Kubernetes bietet, um eine Ausfallzeit von null für die in Ihrem Cluster aktiven Knoten zu erreichen.

Problemdefinition

Zunächst werden wir einen naiven Ansatz verwenden, um Probleme zu identifizieren und die potenziellen Risiken dieses Ansatzes zu bewerten und Wissen für die Lösung jedes Problems zu sammeln, mit dem wir im Verlauf der gesamten Reihe konfrontiert werden. Als Ergebnis erhalten wir eine Konfiguration, die Lifecycle-Hooks, Readiness-Probes und Pod Disruption Budgets zur Erreichung unserer null Ausfallzeit verwendet.

Um unseren Weg zu beginnen, nehmen wir ein konkretes Beispiel. Angenommen, wir haben ein Kubernetes-Cluster mit zwei Knoten, in dem eine Anwendung mit zwei Pods läuft, die hinter Service:

Wir beginnen mit zwei Pods mit Nginx und einem Service, die auf unseren beiden Knoten des Kubernetes-Clusters laufen.

Wir möchten die Kernelversion der beiden Arbeitsknoten in unserem Cluster aktualisieren. Wie gehen wir dabei vor? Eine einfache Lösung wäre, neue Knoten mit aktualisierter Konfiguration zu laden und dann die alten Knoten auszuschalten, während die neuen starten. Obwohl das funktionieren würde, gibt es einige Probleme mit diesem Ansatz:

Wenn Sie die alten Knoten ausschalten, werden auch die auf ihnen laufenden Pods heruntergefahren. Was ist, wenn die Pods für ein ordnungsgemäßes Abschalten bereinigt werden müssen? Das Virtualisierungssystem, das Sie verwenden, wartet möglicherweise nicht auf den Abschluss des Bereinigungsprozesses.
Was, wenn Sie alle Knoten gleichzeitig ausschalten? Sie werden beträchtliche Ausfallzeiten haben, während die Pods auf die neuen Knoten umziehen.

Wir benötigen eine Möglichkeit, Pods korrekt von alten Knoten zu migrieren, und müssen dabei sicherstellen, dass keiner unserer Arbeitsabläufe läuft, während wir Änderungen an dem Knoten vornehmen. Oder wenn wir den Cluster vollständig ersetzen, wie im Beispiel (d.h. wir ersetzen die VM-Images), möchten wir die aktiven Anwendungen von den alten Knoten auf die neuen übertragen. In beiden Fällen wollen wir verhindern, dass neue Pods auf den alten Knoten geplant werden, und dann alle laufenden Pods von diesen abziehen. Um diese Ziele zu erreichen, können wir den Befehl kubectl drain.

Das Umverteilen aller Pods von einem Knoten

Der Befehl drain ermöglicht es, alle Pods von einem Knoten umzuleiten. Während des drain-Vorgangs wird der Knoten als unschedulable (Flag NoSchedule) markiert. Dies verhindert, dass neue Pods auf ihm erscheinen. Danach beginnt der drain, die Pods vom Knoten abzuziehen, und beendet die Container, die derzeit auf dem Knoten laufen, indem er ein Signal sendet TERM an die Container im Pod.

Obwohl kubectl drain Der drain wird gut mit dem Abziehen von Pods fertig, es gibt jedoch zwei weitere Faktoren, die bei der Ausführung des drain-Vorgangs zu einem Fehler führen können:

Ihre Anwendung muss ordnungsgemäß beendet werden können, wenn TERM das Signal empfangen wird. Wenn Pods abgezogen werden, sendet Kubernetes ein Signal TERM an die Container und wartet eine festgelegte Zeit auf deren Stop, nach der, wenn sie nicht gestoppt wurden, diese gewaltsam beendet werden. In jedem Fall, wenn Ihr Container das Signal nicht korrekt empfängt, können Sie die Pods möglicherweise falsch herunterfahren, wenn sie gerade in Betrieb sind (zum Beispiel wird eine Transaktion in der DB ausgeführt).
Sie verlieren alle Pods, die Ihre Anwendung enthalten. Diese könnte zum Zeitpunkt des Starts neuer Container auf den neuen Knoten nicht verfügbar sein, oder, wenn Ihre Pods ohne Controller bereitgestellt werden, können sie überhaupt nicht neu gestartet werden.

Ausfallzeiten vermeiden

Um die Ausfallzeiten durch freiwillige Störungen, wie durch den drain-Befehl für einen Knoten, zu minimieren, bietet Kubernetes die folgenden Optionen zur Fehlerbehandlung an:

In den anderen Phasen des Zyklus werden wir die Funktionen von Kubernetes verwenden, um die Auswirkungen der Migration von Pods zu mildern. Um die zentrale Idee leichter nachzuvollziehen, verwenden wir unser obiges Beispiel mit der folgenden Ressourcen-Konfiguration:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Diese Konfiguration ist ein minimales Beispiel Deployment, das die Pods von nginx im Cluster verwaltet. Zudem beschreibt die Konfiguration eine Ressource Service, die zum Zugriff auf die Pods von nginx im Cluster verwendet werden kann.

Im Verlauf des gesamten Zyklus werden wir diese Konfiguration schrittweise erweitern, sodass sie am Ende alle Funktionen enthält, die Kubernetes zur Reduzierung von Ausfallzeiten bietet.

Um eine voll implementierte und getestete Version von Kubernetes-Cluster-Updates für null Ausfallzeiten auf AWS und anderen Ressourcen zu erhalten, besuchen Sie Gruntwork.io.