Upgrade-Prozess für Ihren Kubernetes-Cluster
Bei der Verwendung eines Kubernetes-Clusters besteht irgendwann die Notwendigkeit, laufende Knoten zu aktualisieren. Dies kann Paketaktualisierungen, Kernel-Updates oder die Bereitstellung neuer Images virtueller Maschinen umfassen. In der Kubernetes-Terminologie nennt man das .
Dieser Beitrag ist Teil einer 4-Beitrags-Serie:
- Dieser Beitrag.
- Korrektes Herunterfahren von Pods in einem Kubernetes-Cluster
- Verzögerte Beendigung eines Pods, wenn er gelöscht wird
- So vermeiden Sie Ausfallzeiten von Kubernetes-Clustern mithilfe von PodDisruptionBudgets
(ca. Übersetzungen der übrigen Artikel der Reihe sind in naher Zukunft zu erwarten)
In diesem Artikel beschreiben wir alle Tools, die Kubernetes bereitstellt, um Ausfallzeiten für die in Ihrem Cluster ausgeführten Knoten zu vermeiden.
Problem Definition
Wir werden zunächst einen naiven Ansatz verfolgen, Probleme identifizieren und die potenziellen Risiken dieses Ansatzes bewerten und Wissen aufbauen, um jedes der Probleme zu lösen, auf die wir im Laufe des Zyklus stoßen. Das Ergebnis ist eine Konfiguration, die Lebenszyklus-Hooks, Bereitschaftsprüfungen und Pod-Unterbrechungsbudgets verwendet, um unser Null-Ausfallzeit-Ziel zu erreichen.
Nehmen wir zu Beginn unserer Reise ein konkretes Beispiel. Nehmen wir an, wir haben einen Kubernetes-Cluster aus zwei Knoten, in dem eine Anwendung läuft und zwei Pods dahinter liegen Service:
Beginnen wir mit zwei Pods, wobei Nginx und Service auf unseren beiden Kubernetes-Clusterknoten ausgeführt werden.
Wir möchten die Kernel-Version von zwei Worker-Knoten in unserem Cluster aktualisieren. Wie machen wir das? Eine einfache Lösung wäre, neue Knoten mit der aktualisierten Konfiguration zu starten und dann die alten Knoten herunterzufahren, während die neuen gestartet werden. Obwohl dies funktionieren wird, wird es bei diesem Ansatz einige Probleme geben:
- Wenn Sie alte Knoten ausschalten, werden auch die darauf laufenden Pods ausgeschaltet. Was passiert, wenn die Pods für ein ordnungsgemäßes Herunterfahren freigegeben werden müssen? Das von Ihnen verwendete Virtualisierungssystem wartet möglicherweise nicht auf den Abschluss des Bereinigungsvorgangs.
- Was passiert, wenn Sie alle Knoten gleichzeitig ausschalten? Während die Pods auf neue Knoten verschoben werden, kommt es zu angemessenen Ausfallzeiten.
Wir benötigen eine Möglichkeit, Pods ordnungsgemäß von alten Knoten zu migrieren und gleichzeitig sicherzustellen, dass keiner unserer Arbeitsprozesse ausgeführt wird, während wir Änderungen am Knoten vornehmen. Oder wenn wir wie im Beispiel einen vollständigen Austausch des Clusters durchführen (also VM-Images ersetzen), möchten wir laufende Anwendungen von alten Knoten auf neue übertragen. In beiden Fällen möchten wir verhindern, dass neue Pods auf alten Knoten geplant werden, und dann alle laufenden Pods von ihnen entfernen. Um diese Ziele zu erreichen, können wir den Befehl verwenden kubectl drain.
Neuverteilung aller Pods von einem Knoten
Mit der Drain-Operation können Sie alle Pods von einem Knoten aus neu verteilen. Während der Drain-Ausführung wird der Knoten als nicht planbar markiert (Flag NoSchedule). Dadurch wird verhindert, dass neue Pods darauf erscheinen. Dann beginnt Drain, Pods vom Knoten zu entfernen, fährt die Container herunter, die derzeit auf dem Knoten ausgeführt werden, und sendet ein Signal TERM Behälter in einer Kapsel.
obwohl kubectl drain Während das Entleeren von Pods gute Arbeit leistet, gibt es zwei weitere Faktoren, die dazu führen können, dass der Entleerungsvorgang fehlschlägt:
- Ihre Bewerbung muss nach der Einreichung ordnungsgemäß beendet werden können
TERMSignal. Wenn Pods geräumt werden, sendet Kubernetes ein SignalTERMContainer und wartet darauf, dass sie für eine bestimmte Zeitspanne angehalten werden. Wenn sie danach nicht angehalten werden, werden sie zwangsweise beendet. Wenn Ihr Container das Signal nicht richtig wahrnimmt, kann es in jedem Fall immer noch dazu kommen, dass Pods falsch gelöscht werden, wenn sie gerade ausgeführt werden (z. B. wenn eine Datenbanktransaktion läuft). - Sie verlieren alle Pods, die Ihre Anwendung enthalten. Es ist möglicherweise nicht verfügbar, wenn neue Container auf neuen Knoten gestartet werden, oder wenn Ihre Pods ohne Controller bereitgestellt werden, werden sie möglicherweise überhaupt nicht neu gestartet.
Ausfallzeiten vermeiden
Um Ausfallzeiten aufgrund freiwilliger Unterbrechungen, beispielsweise durch einen Drain-Vorgang auf einem Knoten, zu minimieren, bietet Kubernetes die folgenden Optionen zur Fehlerbehandlung:
Im Rest der Serie werden wir diese Kubernetes-Funktionen verwenden, um die Auswirkungen der Pod-Migration abzumildern. Um es einfacher zu machen, der Hauptidee zu folgen, verwenden wir unser obiges Beispiel mit der folgenden Ressourcenkonfiguration:
---
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: 80Diese Konfiguration ist ein Minimalbeispiel Deployment, das Nginx-Pods im Cluster verwaltet. Darüber hinaus beschreibt die Konfiguration die Ressource Service, mit dem auf Nginx-Pods in einem Cluster zugegriffen werden kann.
Im Laufe des Zyklus werden wir diese Konfiguration iterativ erweitern, sodass sie schließlich alle Funktionen umfasst, die Kubernetes zur Reduzierung von Ausfallzeiten bietet.
Eine vollständig implementierte und getestete Version der Kubernetes-Cluster-Updates für null Ausfallzeiten auf AWS und darüber hinaus finden Sie unter .
Lesen Sie auch andere Artikel in unserem Blog:
Source: habr.com