Einer der Vorteile von Kubernetes ist die Unterstützung von deklarativer Konfigurationsverwaltung. Die Dienste, die Sie in den Konfigurationsdateien definieren, werden um jeden Preis erhalten.
Das bedeutet, dass Kubernetes bei einem Ausfall die Dienste, die vor dem Ausfall ausgeführt wurden, automatisch neu startet.
Sehen wir uns diese Resilienz in der Praxis an, indem wir den storefrontend-Pod löschen und dann überprüfen, ob Kubernetes ihn neu gestartet hat.
Führen Sie zunächst im TERMINAL im Codespace den Befehl kubectl get pods aus, und notieren Sie sich den Namen, einschließlich der zufälligen Zeichenfolge, des storefrontend Pods. Hier ist eine Beispielausgabe:
@user-name /workspaces/eShopLite % kubectl get pods
NAME READY STATUS RESTARTS AGE
productsbackend-7445bdb5c9-pnpk6 1/1 Running 0 31m
storefrontend-5b6cc765c4-hjpx4 1/1 Running 0 63m
Löschen Sie jetzt den storefrontend-Pod mit dem Befehl kubectl delete. Sie müssen den vollständigen Namen des Pods angeben, einschließlich der zufälligen Zeichenfolge.
kubectl delete pod storefrontend-5b6cc765c4-hjpx4
Sie erhalten sofort eine Meldung mit dem Hinweis, dass der Pod gelöscht wurde.
Da Kubernetes den Systemstatus wie in den Konfigurationsdateien deklariert aufrecht erhält, startet es sofort eine weitere Podinstanz. Sie können dies überprüfen, indem Sie kubectl get pods ausführen.
@user-name /workspaces/eShopLite % kubectl get pods
NAME READY STATUS RESTARTS AGE
productsbackend-7445bdb5c9-pnpk6 1/1 Running 0 31m
storefrontend-5b6cc765c4-vwmv8 1/1 Running 0 7s
Die zufällige Zeichenfolge hat sich nach dem storefrontend-Namen geändert, was darauf hindeutet, dass der Pod eine neue Instanz ist. Auch der AGE-Wert ist deutlich weniger.
In dieser Übung haben Sie gelernt, wie Kubernetes den deklarierten Systemstatus automatisch aufrecht erhält, selbst bei einem Ausfall.