Aktivieren der automatischen Knoten-Reparatur und untersuchen von Problemen mit dem Zustand des Knotens - Amazon EKS
KnotenüberwachungsagentAutomatische Knoten-ReparaturProbleme mit dem Zustand des Knotens

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Aktivieren der automatischen Knoten-Reparatur und untersuchen von Problemen mit dem Zustand des Knotens

Der Knotenzustand bezieht sich auf den Betriebsstatus und die Fähigkeit eines Knotens, Workloads effektiv auszuführen. Ein fehlerfreier Knoten verfügt über die erwartete Konnektivität, ausreichende Ressourcen und kann Pods ohne Unterbrechungen erfolgreich ausführen. Informationen zum Abrufen von Details zu Ihren Knoten finden Sie unter Integritätsstatus Ihrer Knoten anzeigen und Abrufen von Knotenprotokollen für einen verwalteten Knoten mithilfe von kubectl und S3.

Um die Aufrechterhaltung eines einwandfreien Zustands der Knoten zu unterstützen, bietet Amazon EKS den Knoten-Überwachungsagenten und die automatische Knotenreparatur an.

Wichtig

Der Knoten-Überwachungsagente und die Knotenreparatur sind nur in Linux verfügbar. Diese Features sind unter Windows nicht verfügbar.

Knotenüberwachungsagent

Der Knoten-Überwachungsagent liest automatisch Knotenprotokolle, um Zustandsprobleme zu erkennen. Er analysiert Knotenprotokolle, um Fehler zu erkennen und verschiedene Statusinformationen über Worker-Knoten anzuzeigen. Für jede Kategorie der erkannten Probleme, wie beispielsweise Speicher- und Netzwerkprobleme, wird eine dedizierte NodeCondition auf die Worker-Knoten angewendet. Beschreibungen der erkannten Statusprobleme werden im Beobachtbarkeits-Dashboard zur Verfügung gestellt. Weitere Informationen finden Sie unter Probleme mit dem Zustand des Knotens.

Der Knoten-Überwachungsagent ist als Funktion für alle Cluster von Amazon EKS Auto Mode enthalten. Für andere Cluster-Typen können Sie den Überwachungsagenten als Amazon-EKS-Add-On hinzufügen. Weitere Informationen finden Sie unter Erstellung eines Amazon-EKS-Add-Ons.

Automatische Knoten-Reparatur

Die automatische Knotenreparatur ist ein zusätzliches Feature, das den Zustand der Knoten kontinuierlich überwacht, automatisch auf erkannte Probleme reagiert und Knoten nach Möglichkeit ersetzt. Dies unterstützt die Gesamtverfügbarkeit des Clusters mit minimalen manuellen Eingriffen. Wenn eine Zustandsprüfung fehlschlägt, wird der Knoten automatisch gesperrt, sodass keine neuen Pods auf dem Knoten geplant werden.

Die automatische Knotenreparatur kann von sich aus auf den Ready-Zustand des kubelet und aller manuell gelöschten Knotenobjekte reagieren. In Kombination mit dem Knoten-Überwachungsagenten kann die automatische Knotenreparatur auf mehr Zustände reagieren, die anderenfalls nicht erkannt würden. Zu diesen zusätzlichen Zuständen gehören KernelReady, NetworkingReady und StorageReady.

Diese automatische Knotenwiederherstellung behebt automatisch intermittierende Knotenprobleme wie Fehler beim Beitritt zum Cluster, nicht reagierende kubelets und eine zunehmende Zahl von Accelerator- (Geräte-) Fehlern. Die erhöhte Zuverlässigkeit trägt dazu bei, Ausfallzeiten von Anwendungen zu reduzieren und den Cluster-Betrieb zu verbessern. Die automatische Knotenreparatur kann bestimmte gemeldete Probleme wie DiskPressure, MemoryPressure und PIDPressure nicht verarbeiten. Amazon EKS wartet 10 Minuten, bevor es auf AcceleratedHardwareReady NodeConditions reagiert, und 30 Minuten bei allen anderen Bedingungen.

Verwaltete Knotengruppen deaktivieren Knotenreparaturen aus Sicherheitsgründen in zwei Szenarien automatisch. Alle bereits laufenden Reparaturarbeiten werden in beiden Fällen fortgesetzt.

  • Wenn eine Zonenverschiebung für Ihren Cluster über den Application Recovery Controller (ARC) ausgelöst wurde, werden alle nachfolgenden Reparaturvorgänge angehalten.

  • Wenn Ihre Knotengruppe mehr als fünf Knoten umfasst und mehr als 20 % der Knoten in Ihrer Knotengruppe sich in einem fehlerhaften Zustand befinden, werden die Reparaturvorgänge angehalten.

Sie können die automatische Knotenreparatur beim Erstellen oder Bearbeiten einer verwalteten Knotengruppe aktivieren.

Amazon EKS bietet eine differenziertere Kontrolle über das Verhalten der automatischen Knotenreparatur durch Folgendes:

  • maxUnhealthyNodeThresholdCount und maxUnhealthyNodeThresholdPercentage

    • In diesen Feldern können Sie eine Anzahl oder einen Prozentsatz als Schwellenwert für fehlerhafte Knoten festlegen, ab dem die automatische Knotenreparatur beendet wird. Dadurch erhalten Sie mehr Kontrolle über den „Explosionsradius“ der automatischen Knotenreparatur.

    • Sie können entweder die absolute Anzahl oder den Prozentsatz festlegen, jedoch nicht beides.

  • maxParallelNodesRepairedCount und maxParallelNodesRepairedPercentage

    • In diesen Feldern können Sie die maximale Anzahl von Knoten angeben, die gleichzeitig oder parallel repariert werden können, ausgedrückt als Anzahl oder Prozentsatz aller fehlerhaften Knoten. Dadurch erhalten Sie eine differenzierte Kontrolle über das Tempo des Knotenaustauschs.

    • Ähnlich wie beim Schwellenwert für fehlerhafte Knoten können Sie entweder die absolute Anzahl oder den Prozentsatz festlegen, jedoch nicht beides.

  • nodeRepairConfigOverrides

    • Es handelt sich hierbei um eine komplexe Struktur, die es Ihnen ermöglicht, differenzierte Überschreibungen für bestimmte Reparaturmaßnahmen festzulegen. Diese Überschreibungen steuern die Reparaturmaßnahme und die Reparaturverzögerungszeit, bevor ein Knoten als reparaturbedürftig eingestuft wird.

    • Die spezifischen Felder in dieser Struktur sind:

      • nodeMonitoringCondition: Der vom Knoten-Überwachungsagent gemeldete fehlerhafte Zustand.

      • nodeUnhealthyReason: Der Grund, warum der Knoten-Überwachungsagent den Knoten als fehlerhaft identifiziert hat.

      • minRepairWaitTimeMins: Die Mindestzeit (in Minuten), die der Reparaturzustand und der Grund für den fehlerhaften Zustand bestehen müssen, bevor der Knoten für eine Reparatur in Frage kommt.

      • repairAction: Die Maßnahme, die das Reparatursystem ergreifen soll, wenn die oben genannten Bedingungen erfüllt sind.

    • Wenn Sie dieses Feld verwenden, müssen Sie alle Felder in der Struktur angeben. Sie können auch eine Liste dieser Überschreibungen bereitstellen.

    • nodeMonitoringCondition und nodeUnhealthyReason sind manuelle Texteingaben, die Sie festlegen, um anzugeben, dass Sie vom Standardverhalten des Systems abweichen möchten.

    • Mit den Feldern minRepairWaitTimeMins und repairAction können Sie Abweichungen vom Standardverhalten des Systems angeben.

Probleme mit dem Zustand des Knotens

In den folgenden Tabellen werden Knotenintegritätsprobleme beschrieben, die vom Knoten-Überwachungsagenten erkannt werden können. Es gibt zwei Arten von Problemen:

  • Zustand – Ein schwerwiegendes Problem, das eine Behebungsmaßnahme wie den Austausch einer Instance oder einen Neustart erfordert. Wenn die automatische Reparatur aktiviert ist, führt Amazon EKS eine Reparaturmaßnahme durch, entweder einen Knotenaustausch oder einen Neustart. Weitere Informationen finden Sie unter Knotenzustände.

  • Ereignis – Ein vorübergehendes Problem oder eine suboptimale Knotenkonfiguration. Es erfolgt keine automatische Reparatur. Weitere Informationen finden Sie unter Knotenereignisse.

Integritätsprobleme des Kernelknotens

Der Überwachungszustand ist KernelReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung

ForkFailedOutOfPID

Bedingung

Ein Fork- oder Exec-Aufruf ist fehlgeschlagen, da dem System Prozess-IDs oder Speicherplatz fehlen. Dies kann durch Zombie-Prozesse oder einen Mangel an physischem Speicher verursacht werden.

AppBlocked

Ereignis

Die Aufgabe wurde für einen längeren Zeitraum aus der Planung ausgeschlossen, was in der Regel darauf zurückzuführen ist, dass sie bei der Eingabe oder Ausgabe blockiert wurde.

AppCrash

Ereignis

Eine Anwendung auf dem Knoten ist abgestürzt.

ApproachingKernelPidMax

Ereignis

Die Anzahl der Prozesse nähert sich der maximalen Anzahl von PIDs, die gemäß der aktuellen Einstellung von kernel.pid_max verfügbar sind. Danach können keine weiteren Prozesse mehr gestartet werden.

ApproachingMaxOpenFiles

Ereignis

Die Anzahl der geöffneten Dateien nähert sich der maximalen Anzahl möglicher geöffneter Dateien gemäß den aktuellen Kernel-Einstellungen. Danach wird das Öffnen neuer Dateien fehlschlagen

ConntrackExceededKernel

Ereignis

Die Verbindungsverfolgung hat das Maximum für den Kernel überschritten, und es konnten keine neuen Verbindungen hergestellt werden, was zu Paketverlusten führen kann.

ExcessiveZombieProcesses

Ereignis

Es sammeln sich zahlreiche Prozesse, die nicht vollständig wiederhergestellt werden können. Dies weist auf Anwendungsprobleme hin und kann dazu führen, dass die Grenzen der Systemprozesse erreicht werden.

KernelBug

Ereignis

Ein Kernel-Fehler wurde vom Linux-Kernel selbst erkannt und gemeldet. Dieser kann jedoch manchmal durch Knoten mit hoher CPU- oder Speicherauslastung verursacht werden, was zu einer verzögerten Ereignisverarbeitung führt.

LargeEnvironment

Ereignis

Die Anzahl der Umgebungsvariablen für diesen Prozess ist größer als erwartet. Dies kann möglicherweise durch viele Services verursacht werden, bei denen „enableServiceLinks“ auf „true“ gesetzt ist, was zu Leistungsproblemen führen kann.

RapidCron

Ereignis

Ein Cron-Auftrag wird auf diesem Knoten schneller als alle fünf Minuten ausgeführt. Dies kann die Leistung beeinträchtigen, wenn der Auftrag erhebliche Ressourcen verbraucht.

SoftLockup

Ereignis

Die CPU ist für eine bestimmte Zeit blockiert.

Probleme mit der Integrität von Netzwerkknoten

Der Überwachungszustand ist NetworkingReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung

InterfaceNotRunning

Bedingung

Diese Schnittstelle scheint nicht zu funktionieren oder es liegen Netzwerkprobleme vor.

InterfaceNotUp

Bedingung

Diese Schnittstelle scheint derzeit nicht verfügbar zu sein oder es liegen Netzwerkprobleme vor.

IPAMDNotReady

Bedingung

IPAMD kann keine Verbindung zum API-Server herstellen.

IPAMDNotRunning

Bedingung

Der aws-k8s-agent-Prozess wurde nicht ausgeführt.

MissingLoopbackInterface

Bedingung

Die Loopback-Schnittstelle fehlt in dieser Instance, was zu einem Ausfall von Services führt, die von der lokalen Konnektivität abhängig sind.

BandwidthInExceeded

Ereignis

Pakete wurden in die Warteschlange gestellt oder verworfen, da die eingehende Gesamtbandbreite das Maximum für die Instance überschritten hat.

BandwidthOutExceeded

Ereignis

Pakete wurden in die Warteschlange gestellt oder verworfen, da die ausgehende Gesamtbandbreite das Maximum für die Instance überschritten hat.

ConntrackExceeded

Ereignis

Die Verbindungsverfolgung hat das Maximum für die Instance überschritten und es konnten keine neuen Verbindungen hergestellt werden, was zu Paketverlusten führen kann.

IPAMDNoIPs

Ereignis

IPAM-D hat keine IP-Adressen mehr.

IPAMDRepeatedlyRestart

Ereignis

Es sind mehrere Neustarts des IPAMD-Services aufgetreten.

KubeProxyNotReady

Ereignis

Kube-proxy konnte die Ressourcen nicht überwachen oder auflisten.

LinkLocalExceeded

Ereignis

Pakete wurden verworfen, da die PPS des Datenverkehrs zu lokalen Proxy- Services das Maximum der Netzwerkschnittstelle überschritten hat.

MissingDefaultRoutes

Ereignis

Es fehlen Standard- Weiterleitungsregeln.

MissingIPRules, MissingIPRoutes

Ereignis

In der Routing-Tabelle fehlen Weiterleitungsregeln für die folgenden Pod-IPs.

NetworkSysctl

Ereignis

Die sysctl-Einstellungen des Netzwerks dieses Knotens sind möglicherweise nicht korrekt.

PortConflict

Ereignis

Wenn ein Pod hostPort verwendet, kann er iptables-Regeln schreiben, welche die bereits gebundenen Ports des Hosts überschreiben und möglicherweise den Zugriff des API-Servers auf kubelet verhindern.

PPSExceeded

Ereignis

Pakete wurden in die Warteschlange gestellt oder verworfen, da die bidirektionale PPS das Maximum für die Instance überschritten hat.

UnexpectedRejectRule

Ereignis

In den iptables wurde eine unerwartete REJECT- oder DROP-Regel gefunden, die möglicherweise den erwarteten Datenverkehr blockiert.

Integritätsprobleme der Neuron-Knoten

Der Überwachungszustand ist AcceleratedHardwareReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung

NeuronDMAError

Bedingung

Bei einer DMA-Engine ist ein nicht behebbarer Fehler aufgetreten.

NeuronHBMUncorrectableError

Bedingung

Bei einem HBM ist ein nicht korrigierbarer Fehler aufgetreten und es wurden falsche Ergebnisse ausgegeben.

NeuronNCUncorrectableError

Bedingung

Ein nicht korrigierbarer Neuron Core-Speicherfehler wurde erkannt.

NeuronSRAMUncorrectableError

Bedingung

Ein On-Chip-SRAM hat einen Paritätsfehler festgestellt und unkorrekte Ergebnisse erzeugt.

Probleme mit der Integrität von NVIDIA-Knoten

Wenn die automatische Reparatur aktiviert ist, beginnen die aufgeführten Reparaturaktionen 10 Minuten, nachdem das Problem erkannt wurde. Weitere Informationen zu XID-Fehlern finden Sie unter XID-Fehler in der Dokumentation zur Bereitstellung und Verwaltung von NVIDIA-GPUs. Weitere Informationen zu den einzelnen XID-Meldungen finden Sie unter XID-Meldungen verstehen in der Dokumentation zur Bereitstellung und Verwaltung von NVIDIA-GPUs.

Der Überwachungszustand ist AcceleratedHardwareReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung Reparaturmaßnahme

NvidiaDoubleBitError

Bedingung

Der GPU-Treiber hat einen doppelten Bit-Fehler erzeugt.

Ersetzen

NvidiaNVLinkError

Bedingung

Der GPU-Treiber hat NVLink-Fehler gemeldet.

Ersetzen

NvidiaXID13Error

Bedingung

Es liegt eine Grafik-Engine-Ausnahme vor.

Neustart

NvidiaXID31Error

Bedingung

Es liegen vermutlich Hardware-Probleme vor.

Neustart

NvidiaXID48Error

Bedingung

Der Treiber meldet Doppelbit-ECC-Fehler.

Neustart

NvidiaXID63Error

Bedingung

Es liegt eine Seitenlöschung oder Zeilenneuzuordnung vor.

Neustart

NvidiaXID64Error

Bedingung

Beim Versuch, eine Seite zu löschen oder eine Knoten-Neuzuordnung durchzuführen, treten Fehler auf.

Neustart

NvidiaXID74Error

Bedingung

Es liegt ein Problem mit einer Verbindung von der GPU zu einer anderen GPU oder einem NVSwitch über NVLink vor. Dies kann auf einen Hardware-Fehler der Verbindung selbst oder auf ein Problem mit dem Gerät am anderen Ende der Verbindung hindeuten.

Ersetzen

NvidiaXID79Error

Bedingung

Der GPU-Treiber hat versucht, über seine PCI Express-Verbindung auf die GPU zuzugreifen, und festgestellt, dass die GPU nicht erreichbar ist.

Ersetzen

NvidiaXID94Error

Bedingung

Es liegen ECC-Speicherfehler vor.

Neustart

NvidiaXID95Error

Bedingung

Es liegen ECC-Speicherfehler vor.

Neustart

NvidiaXID119Error

Bedingung

Das GSP hat bei der Beantwortung von RPC-Anfragen von anderen Bits im Treiber eine Zeitüberschreitung verursacht.

Ersetzen

NvidiaXID120Error

Bedingung

Das GSP hat rechtzeitig geantwortet, jedoch mit einem Fehler.

Ersetzen

NvidiaXID121Error

Bedingung

C2C bezeichnet eine Chip-Verbindung. Sie ermöglicht die gemeinsame Nutzung von Speicher zwischen CPUs, Beschleunigern und weiteren Komponenten.

Ersetzen

NvidiaXID140Error

Bedingung

Der GPU-Treiber hat möglicherweise nicht korrigierbare Fehler im GPU-Speicher festgestellt, die dazu führen, dass der GPU-Treiber die Seiten nicht mehr für die dynamische Seitenoffline-Funktion oder die Zeilen-Neuzuordnung markieren kann.

Ersetzen

NvidiaPageRetirement

Ereignis

Der GPU-Treiber hat eine Speicherseite zur Außerbetriebnahme markiert. Dies kann auftreten, wenn ein einzelner Doppel-Bit-Fehler oder zwei Einzel-Bit-Fehler an derselben Adresse auftreten.

Keine

NvidiaXID[Code]Warning

Ereignis

Jedes Auftreten von XIDs, die nicht in dieser Liste definiert sind, führt zu diesem Ereignis.

Keine

DCGMError

Bedingung

Die Verbindung zum Host-Prozess des Data Center GPU Manager (DCGM) wurde unterbrochen oder konnte nicht hergestellt werden.

Keine

DCGMDiagnosticError

Bedingung

Bei der Ausführung der aktiven Diagnose des DCGM ist ein Problem aufgetreten.

Keine

DCGMDiagnosticFailure

Bedingung

Ein Testfall aus der Test-Suite für die aktive DCGM-Diagnose ist fehlgeschlagen.

Keine

Probleme mit der Integrität von Laufzeitknoten

Der Überwachungszustand ist ContainerRuntimeReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung

PodStuckTerminating

Bedingung

Ein Pod ist oder war über einen längeren Zeitraum hinweg blockiert. Dies kann auf CRI-Fehler zurückzuführen sein, die den Fortschritt des Pod-Status verhindern.

%sRepeatedRestart

Ereignis

Neustarts aller systemd- Services auf dem Knoten (formatiert unter Verwendung des großgeschriebenen Einheitennamens).

ContainerRuntimeFailed

Ereignis

Die Container-Laufzeit konnte keinen Container erstellen. Dies hängt wahrscheinlich mit einem der gemeldeten Probleme zusammen, wenn es wiederholt auftritt.

KubeletFailed

Ereignis

Der kubelet ist in einen fehlerhaften Zustand übergegangen.

LivenessProbeFailures

Ereignis

Es wurde ein Fehler bei der Aktivitätsprüfung erkannt, der bei wiederholtem Auftreten möglicherweise auf Probleme mit dem Anwendungscode oder unzureichende Timeout-Werte hinweist.

ReadinessProbeFailures

Ereignis

Es wurde ein Fehler bei der Bereitschaftsprüfung erkannt, der bei wiederholtem Auftreten möglicherweise auf Probleme mit dem Anwendungscode oder unzureichende Timeout-Werte hinweist.

ServiceFailedToStart

Ereignis

Eine systemd-Einheit konnte nicht gestartet werden

Probleme mit der Integrität von Speicherknoten

Der Überwachungszustand ist StorageReady für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.

Name Schweregrad Beschreibung

XFSSmallAverageClusterSize

Bedingung

Die durchschnittliche Cluster-Größe von XFS ist gering, was auf eine übermäßige Fragmentierung des freien Speicherplatzes hindeutet. Dadurch kann die Dateierstellung trotz verfügbarer Inodes oder freien Speicherplatzes verhindert werden.

EtcHostsMountFailed

Ereignis

Die Einbindung des vom Kubelet generierten /etc/hosts ist fehlgeschlagen, da userdata während des Betriebs des Kubelet-Containers /var/lib/kubelet/pods erneut eingebunden hat.

IODelays

Ereignis

In einem Prozess wurde eine Eingabe- oder Ausgabeverzögerung festgestellt, die bei übermäßiger Dauer auf eine unzureichende Eingabe-Ausgabe-Bereitstellung hindeuten könnte.

KubeletDiskUsageSlow

Ereignis

Kubelet meldet beim Versuch, auf das Dateisystem zuzugreifen, eine langsame Festplattennutzung, was möglicherweise auf unzureichende Festplatteneingabe/-ausgabe oder Probleme mit dem Dateisystem hinweist.