🥇Kubernetes-Cluster-Update ohne Ausfallzeiten

Der Aktualisierungsprozess für Ihr Kubernetes-Cluster

Im Laufe der Nutzung eines Kubernetes-Clusters entsteht die Notwendigkeit, die aktiven Nodes zu aktualisieren. Dies kann Aktualisierungen von Paketen, das Update des Kernels oder die Bereitstellung neuer Images von virtuellen Maschinen umfassen. In der Kubernetes-Terminologie wird dies als "Freiwillige Störung".

Dieser Post ist Teil eines Zyklus von 4 Beiträgen:

Dieser Beitrag.
Richtiges Beenden von Pods in einem Kubernetes-Cluster
Verzögertes Beenden eines Pods beim Löschen
Wie man Ausfallzeiten im Kubernetes-Cluster mit Hilfe von PodDisruptionBudgets vermeidet

(Hinweis: Die Übersetzungen der anderen Artikel des Zyklus sind in Kürze verfügbar)

In diesem Artikel werden wir alle Werkzeuge beschreiben, die Kubernetes zur Verfügung stellt, um eine null Ausfallzeit für die in Ihrem Cluster laufenden Nodes zu erreichen.

Definition des Problems

Zunächst werden wir einen naiven Ansatz verfolgen, um Probleme zu identifizieren und potenzielle Risiken dieses Ansatzes zu bewerten sowie Wissen zu sammeln, um jede der Herausforderungen, die uns während des gesamten Zyklus begegnen, zu lösen. Das Ergebnis wird eine Konfiguration sein, die Lifecycle-Hooks, Readiness-Probes und Pod-Disruption-Budgets verwendet, um eine nullprozentige Ausfallzeit zu erreichen.

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

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

Wir möchten die Kernel-Version der beiden Arbeitsknoten in unserem Cluster aktualisieren. Wie gehen wir vor? Eine einfache Lösung wäre, neue Knoten mit aktualisierter Konfiguration zu starten und dann die alten Knoten gleichzeitig mit dem Start der neuen Knoten auszuschalten. Obwohl das funktionieren wird, gibt es einige Probleme mit diesem Ansatz:

Wenn Sie die alten Knoten abschalten, werden auch die darauf laufenden Pods beendet. Was, wenn die Pods für ein korrektes Abschalten bereinigt werden müssen? Das von Ihnen verwendete Virtualisierungssystem wartet möglicherweise nicht auf das Ende des Bereinigungsvorgangs.
Was passiert, wenn Sie alle Knoten gleichzeitig abschalten? Sie werden eine erhebliche Ausfallzeit haben, während die Pods auf die neuen Knoten umziehen.

Wir benötigen einen Weg zur korrekten Migration von Pods von den alten Knoten und müssen dabei sicherstellen, dass keiner unserer Arbeitsprozesse aktiv ist, während wir Änderungen an den Knoten vornehmen. Oder wenn wir einen vollständigen Clusterwechsel durchführen, wie im Beispiel (d. h. wir ersetzen die VM-Images), möchten wir laufende Anwendungen von den alten Knoten auf die neuen überführen. In beiden Fällen wollen wir die Planung neuer Pods auf den alten Knoten verhindern und dann alle aktiven Pods von ihnen abziehen. Zu diesem Zweck können wir den Befehl verwenden, kubectl drain.

Alle Pods von Knoten umverteilen

Der Drain-Befehl ermöglicht es, alle Pods von einem Knoten umzuverteilen. Während des Drain-Vorgangs wird der Knoten als unschedulable (Flag) markiert. NoSchedule). Das verhindert das Erscheinen neuer Pods. Anschließend beginnt der Drain, die Pods von der Node zu entfernen, und beendet die Container, die derzeit auf der Node ausgeführt werden, indem er ein Signal sendet. TERM an die Container im Pod.

Obwohl kubectl drain zielt darauf ab, die Pods erfolgreich zu evakuieren, jedoch gibt es noch zwei Faktoren, die zu einem Fehler beim Ausführen des Drain führen können:

Ihre Anwendung muss in der Lage sein, sich korrekt zu beenden, wenn ein TERM Signal empfangen wird. Wenn Pods evakuiert werden, sendet Kubernetes ein Signal TERM an die Container und wartet eine bestimmte Zeit auf deren Stopp, bevor sie, wenn sie nicht gestoppt sind, gewaltsam beendet werden. In jedem Fall, wenn Ihr Container das Signal nicht korrekt verarbeitet, können Sie die Pods möglicherweise nicht richtig herunterfahren, wenn sie gerade in Betrieb sind (z.B. bei einer Datenbanktransaktion).
Sie verlieren alle Pods, die Ihre Anwendung enthalten. Sie könnte während des Starts neuer Container auf neuen Nodes vorübergehend nicht verfügbar sein oder, wenn Ihre Pods ohne Controller bereitgestellt werden, eventuell überhaupt nicht neu gestartet werden.

Vermeidung von Ausfallzeiten

Um die Ausfallzeiten durch freiwillige Störungen, wie beispielsweise durch den Drain-Befehl für einen Knoten, zu minimieren, bietet Kubernetes folgende Möglichkeiten zur Fehlerbehandlung an:

In den anderen Phasen des Zyklus werden wir diese Kubernetes-Funktionen nutzen, um die Auswirkungen der Pod-Verlagerung zu mildern. Um den Überblick über die zentrale Idee zu erleichtern, 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. Darüber hinaus beschreibt die Konfiguration die Ressource Service, die verwendet werden kann, um auf die Pods von nginx im Cluster zuzugreifen.

Während des gesamten Zyklus werden wir diese Konfiguration iterativ erweitern, sodass sie am Ende alle von Kubernetes bereitgestellten Funktionen zur Reduzierung der Ausfallzeiten umfasst.

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