Irgendwie stellten sie in den Kommentaren die Frage, wie sich die Teilnahme am Slurm vom Lesen von Handbüchern zu Kubernetes unterscheidet. Ich bat Pavel Selivanov, Sprecher von Slurm-2 und MegaSlurm, ein kleines Beispiel dafür zu geben, was er über Slurm erzählen wird. Ich gebe ihm das Wort.
Ich verwalte den Kubernetes-Cluster. Vor kurzem musste ich die Version von k8s aktualisieren und einschließlich aller Computer im Cluster neu starten. Ich begann den Prozess um 12:00 Uhr und am Ende des Arbeitstages war alles fertig. Und zum ersten Mal verfolgte ich immer noch das Update und zum zweiten Mal ging ich für 1,5 Stunden zum Mittagessen (fairerweise schnappte ich mir einen Laptop). Der Cluster selbst wurde ohne meine Teilnahme und unsichtbar für die Kunden aktualisiert, die Entwicklung bemerkte nichts, die Bereitstellung wurde fortgesetzt, der Service funktionierte wie gewohnt.
Wie es aussah.
Mögliche Probleme
Beim Neustart von Computern gibt es zwei schlechte Szenarien.
- Der Entwickler hat die Anwendung / redis in einer Instanz gestartet. Unabhängig davon, wie sorgfältig Sie das Auto außer Betrieb nehmen, kommt es zu Ausfallzeiten.
- Es gibt zwei Replikate der Anwendung und eines wird bereitgestellt. Sie ging aus, es gab nur eine Replik, und dann kommt der Administrator und löscht die letzte Replik. Bis das Replikat nach der Bereitstellung hochgefahren ist, treten erneut Ausfallzeiten auf.
Ich könnte den Neustart mit der Entwicklung koordinieren, sie sagen, die Bereitstellung stoppen, die Instanzen überprüfen, ich werde die Maschinen neu starten, aber ich mag die DevOps-Idee, dass die menschliche Kommunikation minimiert werden sollte. Es ist besser, die Automatisierung einmal einzurichten, als Ihre Aktionen jedes Mal zu koordinieren.
Aufgabenbedingungen
Ich benutze Amazon mit seiner Bequemlichkeit und Stabilität. Alles ist automatisiert, Sie können virtuelle Maschinen erstellen und löschen, deren Verfügbarkeit überprüfen usw.
Der Kubernetes-Cluster wird über das Dienstprogramm kops bereitgestellt, verwaltet und aktualisiert, das ich sehr liebe.
Beim Aktualisieren von Kops wird automatisch ein Knoten (Kubectl Drain Node) entleert, gewartet, bis alles von diesem Knoten evakuiert wurde, es entfernt, ein neuer Knoten in Amazon mit der richtigen Version der Kubernetes-Komponenten erstellt, an den Cluster angehängt und überprüft, ob der Knoten gut in den Cluster eingetreten ist. und so mit allen Knoten in einem Kreis, bis die gewünschte Version von Kubernetes überall ist.
Lösung
In CI verwende ich kube-lint, um alle Manifeste zu überprüfen, die in Kubernetes gestartet werden. Helmvorlage wirft alles, was es starten wird, ich setze einen Linter zum Entladen, der alles nach den vorgegebenen Regeln auswertet.
Eine der Regeln besagt beispielsweise, dass für jede Anwendung im Kubernetes-Cluster die Anzahl der Replikate mindestens 2 betragen muss.
Wenn es überhaupt keine Replikate gibt (standardmäßig 1), gibt es 0 oder 1 davon. Kube-lint verbietet die Bereitstellung im Cluster, um zukünftige Probleme zu vermeiden.
Angenommen, die Bereitstellung durch Design ist so konzipiert, dass nur eine Replik vorhanden ist. In diesem Fall gibt es ein Budget für Pod-Unterbrechungen, in dem max_unavailable und min_available für eine Anwendung festgelegt sind, die in Kubernetes ausgeführt wird. Wenn Sie immer mindestens 1 Replikat haben möchten, setzen Sie min_available = 1.
Es gab 2 Replikate, eine Bereitstellung wurde gestartet, 1 Replikat ist gestorben, 1 ist geblieben. Auf dem Computer, auf dem sich das Replikat befindet, startet der Administrator den Kubectl-Drain-Knoten. Theoretisch sollte Kubernetes damit beginnen, dieses Live-Replikat zu entfernen und auf einen anderen Knoten zu transportieren. Aber das Budget für Pod-Störungen funktioniert. Kubernetes sagt zum Administrator: Entschuldigung, das Replikat lebt hier. Wenn wir es löschen, verletzen wir das Budget für Pod-Störungen. Der Smart Drain-Knoten hängt vor Ablauf des Timeouts und versucht, den Knoten zu verschieben. Wenn die Bereitstellung abgeschlossen ist und beide Replikate verfügbar sind, wird das Replikat auf diesem Knoten angezeigt.
Bei MegaSlerme zeige ich ein vollständiges Regelwerk, nach dem ich in einem Café Kaffee trinken kann, während der Kubernetes-Cluster mit einem Neustart aller Knoten aktualisiert wird.
Meine Themen zu Slurm :
- Einführung in Kubernetes, Schlüsselkomponenten
- Cluster-Gerät, Hauptkomponenten, Fehlertoleranz, k8s-Netzwerk
- Erweiterte Kubernetes-Abstraktionen
- Protokollierung und Überwachung
Meine Themen zu MegaSlerme :
- Innerhalb des Failoverclusterprozesses
- Cluster-Autorisierung über einen externen Anbieter
- Sichere und hochverfügbare Anwendungen im Cluster
- Implementieren anderer Bereitstellungsstrategien als RollingUpdate
- Fehlerbehebung bei Kubernetes