Kubernetes-Health Check
Eine Einführung in Health Check mit Kubernetes für WinCC OA
Übersicht
Ein Health Check fragt den Status der laufenden Manager ab. Ein Health Check-Befehl wird während des Starts eines Containers verwendet. Der Health Check wird in regelmäßigen Abständen auf der Grundlage der von Ihnen in den Probeneinstellungen festgelegten Konfiguration durchgeführt. Die Häufigkeit, der Zeitpunkt und das Verhalten dieser Prüfungen hängen von Parametern wie periodSeconds, initialDelaySeconds und anderen ab.
HEALTHCHECK --interval=5s --timeout=5s --start-period=10s --retries=20 CMD "${BIN_DIR}
WCCILpmon" -config ${OAPROJ}config/config -status || exit 1
Sie finden ein Beispiel für einen Health Check für WinCC OA, die in Docker ausgeführt wird. Die Dateien befinden sich in wincc_oa_path/data/containerization/examples/kubernetes/healthProbes.
Fehlerhafte Container
Um einen fehlerhaften Container in Kubernetes wieder funktionsfähig zu machen, müssen die Probleme diagnostiziert und behoben werden, die dazu führen, dass der Health Check fehlschlägt. Manchmal reicht ein einfacher Neustart des Containers oder Pods aus, um das Problem zu beheben. In Kubernetes werden Neustarts automatisch verwaltet, wenn ein Container den Health Check nicht besteht.
Kubernetes bietet drei Haupttypen von Health Check-Mechanismen, die als "Probes" bezeichnet werden. Diese Probes stellen sicher, dass die Container in einem Pod wie erwartet laufen und bereit sind, ihren Dienst zu verrichten.
Liveness-Probe
Liveness-Probes bestimmen, wann ein Container neu gestartet werden muss. Liveness-Probes können zum Beispiel einen Deadlock abfangen, wenn eine Anwendung zwar läuft, aber nicht vorankommt.
Readiness-Probe
Readiness-Probes ermitteln, wann ein Container bereit ist, Datenverkehr anzunehmen. Dies ist nützlich, wenn man darauf wartet, dass eine Anwendung zeitaufwändige Anfangsaufgaben durchführt, wie z. B. das Herstellen von Netzwerkverbindungen, das Laden von Dateien und das Aktivieren von Caches.
Startup-Probe
Eine Startup-Probe prüft, ob die Anwendung innerhalb eines Containers gestartet ist. Dies kann dazu verwendet werden, um Liveness-Checks bei langsam startenden Containern durchzuführen, um zu verhindern, dass sie vom Kubernetes beendet werden, bevor sie gestartet sind und laufen.
Die Behebung des "ungesunden" Zustands eines Containers in Kubernetes hängt von der Art des Problems und dem spezifischen Grund für das Versagen ab. Die Diagnose der Grundursache ist entscheidend für die Anwendung der richtigen Lösung. Für mehr Information, siehe https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/.
Mit welcher Zeit ist zu rechnen?
Die Zeit zur Behebung eines Health Check-Problems in einem Container ist nicht festgelegt und hängt von der Art des Problems ab. Manchmal reicht ein einfacher Neustart des Containers oder Pods aus, um das Problem zu beheben. In solchen Fällen ist die benötigte Zeit in der Regel die Zeit, die Kubernetes benötigt, um den alten Container oder Pod zu beenden und einen Neuen zu starten, was in der Regel nur wenige Sekunden bis einige Minuten dauert.
Wie funktioniert der Health Check mit WinCC OA?
Um Kubernetes in die Lage zu versetzen, den Health Check-Status von WinCC OA-Komponenten/Containern zu überwachen, können Sie das mitgelieferte Skript verwenden:
liveness.sh
Kubernetes führt liveness.sh direkt innerhalb des Containers aus, um eine "Liveness"-Prüfung durchzuführen.
WCCILpmon -config $OAPROJ/config/config -command MGRLIST:STATI -log +stdout
Bitte stellen Sie sicher, dass die Umgebungsvariablen $OAINST und $OAPROJ_NAME in Ihren Containern gesetzt sind, oder passen Sie das Skript Ihren speziellen Bedürfnissen an. Die folgende Logik wird verwendet, um den Health Check-Status des WinCC OA zur Laufzeit zu bewerten:

Standby- und Startup-Tests können deaktiviert werden (oder entsprechend Ihren eigenen Anforderungen implementiert werden). Die Startup-Tests sind nicht erforderlich, da keine inkonsistenten Startzeiten der WinCC OA-Laufzeit erwartet werden. Nachfolgend finden Sie ein Konfigurationsbeispiel:

- Warten auf initialDelaySeconds
- Bereitschaftsprüfung durchführen und timeoutSeconds auf ein Timeout warten
-
Wenn die Anzahl der fortgesetzten Erfolge größer als successThreshold ist, wird ein "Erfolg" zurückgeben
Oder
Wenn die Anzahl der fortgesetzten Fehlschläge größer ist als failureThreshold, wird ein Fehler zurückgegeben
andernfalls wird periodSeconds gewartet und eine neue Bereitschaftsprüfung gestartet.