Aktivieren der automatischen Knotenreparatur und Untersuchen von Problemen mit dem Zustand des Knotens - Amazon EKS
KnotenüberwachungsagentAutomatische KnotenreparaturProbleme mit dem Zustand des Knotens

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Aktivieren der automatischen Knotenreparatur 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 Knotenreparatur

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-Fehlern (Gerätefehler). 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.

AcceleratedHardware Probleme mit dem Zustand des Knotens

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

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.

Name Schweregrad Description

DCGMDiagnosticFehlschlag

Bedingung

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

DCGMError

Bedingung

Die Verbindung zum DCGM-Hostprozess wurde unterbrochen oder konnte nicht hergestellt werden.

DCGMFieldFehler [Code]

Veranstaltung

DCGM hat anhand einer Feld-ID eine Verschlechterung der GPU festgestellt.

DCGMHealthCode [Kode]

Veranstaltung

Ein DCGM-Gesundheitscheck schlug ohne schwerwiegenden Fehler fehl.

DCGMHealthKode [Kodierung]

Bedingung

Ein DCGM-Gesundheitscheck ist auf fatale Weise fehlgeschlagen.

Neuron DMAError

Bedingung

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

Neuronenfehler HBMUncorrectable

Bedingung

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

Neuronenfehler NCUncorrectable

Bedingung

Ein nicht korrigierbarer Neuron Core-Speicherfehler wurde erkannt.

Neuronenfehler SRAMUncorrectable

Bedingung

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

NvidiaDeviceCountMismatch

Veranstaltung

Die Anzahl der durch NVML GPUs sichtbaren Geräte stimmt nicht mit der Anzahl der NVIDIA-Geräte im Dateisystem überein.

NvidiaDoubleBitError

Bedingung

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

Nvidia NCCLError

Veranstaltung

In der NVIDIA-Bibliothek für kollektive Kommunikation (libnccl) ist ein Sicherheitsfehler aufgetreten.

Nvidia-Fehler NVLink

Bedingung

NVLink Fehler wurden vom GPU-Treiber gemeldet.

PCIeNvidia-Fehler

Veranstaltung

PCIe Wiederholungen wurden ausgelöst, um Übertragungsfehler zu beheben.

NvidiaPageRetirement

Veranstaltung

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.

NvidiaPowerError

Veranstaltung

Der Stromverbrauch von hat die zulässigen GPUs Grenzwerte überschritten.

NvidiaThermalError

Veranstaltung

Thermischer Status hat die GPUs zulässigen Grenzwerte überschritten.

NVIDIAxID [Code] -Fehler

Bedingung

Ein kritischer GPU-Fehler ist aufgetreten.

NvidiaXID[Code]Warning

Veranstaltung

Ein unkritischer GPU-Fehler ist aufgetreten.

ContainerRuntime Probleme mit dem Zustand des Knotens

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

Name Schweregrad Description

ContainerRuntimeFailed

Veranstaltung

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

DeprecatedContainerdConfiguration

Veranstaltung

Ein Container-Image, das die veraltete Image-Manifest-Version 2, Schema 1 verwendet, wurde kürzlich auf den Knoten übertragen. containerd

KubeletFailed

Veranstaltung

Der kubelet ist in einen fehlerhaften Zustand übergegangen.

LivenessProbeFailures

Veranstaltung

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.

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.

ReadinessProbeFailures

Veranstaltung

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.

[Name] RepeatedRestart

Veranstaltung

Eine Systemd-Einheit wird häufig neu gestartet.

ServiceFailedToStart

Veranstaltung

Eine systemd-Einheit konnte nicht gestartet werden

Integritätsprobleme des Kernelknotens

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

Name Schweregrad Description

AppBlocked

Veranstaltung

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

Veranstaltung

Eine Anwendung auf dem Knoten ist abgestürzt.

ApproachingKernelPidMax

Veranstaltung

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

ApproachingMaxOpenFiles

Veranstaltung

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

Veranstaltung

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

Veranstaltung

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.

ForkFailedOutOfPIDs

Bedingung

Ein Fork- oder Exec-Aufruf ist fehlgeschlagen, weil das System keinen Prozess IDs - oder Speicherzugriff mehr hatte. Dies kann auf Zombie-Prozesse oder physische Speichererschöpfung zurückzuführen sein.

KernelBug

Veranstaltung

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

Veranstaltung

Die Anzahl der Umgebungsvariablen für diesen Prozess ist größer als erwartet, was möglicherweise darauf zurückzuführen ist, dass viele Dienste auf true enableServiceLinks gesetzt sind, was zu Leistungsproblemen führen kann.

RapidCron

Veranstaltung

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

Veranstaltung

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 Description

BandwidthInExceeded

Veranstaltung

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

BandwidthOutExceeded

Veranstaltung

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

ConntrackExceeded

Veranstaltung

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

IPAMDInconsistentStatus

Veranstaltung

Der Status des IPAMD-Checkpoints auf der Festplatte entspricht nicht der Laufzeit IPs in der Container-Laufzeit.

IPAMDNoIPs

Veranstaltung

IPAMD hat keine IP-Adressen mehr.

IPAMDNotBereit

Bedingung

IPAMD kann keine Verbindung zum API-Server herstellen.

IPAMDNotLäuft

Bedingung

Es wurde festgestellt, dass der Amazon VPC CNI-Prozess nicht läuft.

IPAMDRepeatedlyStarten Sie neu

Veranstaltung

Es sind mehrere Neustarts des IPAMD-Services aufgetreten.

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.

KubeProxyNotReady

Veranstaltung

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

LinkLocalExceeded

Veranstaltung

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

MACAddressPolicyMisconfigured

Veranstaltung

Die Verbindungskonfiguration systemd-networkd hat den falschen Wert. MACAddressPolicy

MissingDefaultRoutes

Veranstaltung

Es fehlen Standard- Weiterleitungsregeln.

Fehlt IPRoutes

Veranstaltung

Es fehlen Routen für Pod IPs.

Es fehlt IPRules

Veranstaltung

Es fehlen Regeln für Pod IPs.

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.

NetworkSysctl

Veranstaltung

Die sysctl Netzwerkeinstellungen dieses Knotens sind möglicherweise falsch.

PPSExceeded

Veranstaltung

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

PortConflict

Veranstaltung

Wenn ein Pod HostPort verwendet, kann er iptables Regeln schreiben, die die bereits gebundenen Ports des Hosts außer Kraft setzen und so möglicherweise den API-Serverzugriff kubelet verhindern.

UnexpectedRejectRule

Veranstaltung

Im wurde eine unerwartete REJECT DROP Oder-Regel gefundeniptables, die möglicherweise den erwarteten Datenverkehr blockiert.

Probleme mit der Integrität von Speicherknoten

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

Name Schweregrad Description

EBSInstanceIOPSExceeded

Veranstaltung

Die maximale Anzahl an IOPS für die Instanz wurde überschritten.

EBSInstanceThroughputExceeded

Veranstaltung

Der maximale Durchsatz für die Instanz wurde überschritten.

EBSVolumeIOPSExceeded

Veranstaltung

Die maximale Anzahl an IOPS für ein bestimmtes EBS-Volume wurde überschritten.

EBSVolumeThroughputExceeded

Veranstaltung

Der maximale Durchsatz für ein bestimmtes Amazon EBS-Volume wurde überschritten.

EtcHostsMountFailed

Veranstaltung

Das Mounten des generierten Kubelets ist /etc/hosts fehlgeschlagen, da die Benutzerdaten während des Betriebs erneut bereitgestellt wurden. /var/lib/kubelet/pods kubelet-container

IODelays

Veranstaltung

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

Veranstaltung

Der meldet kubelet eine langsame Festplattennutzung beim Versuch, auf das Dateisystem zuzugreifen. Dies deutet möglicherweise auf eine unzureichende Eingabe- und Ausgabekapazität der Festplatte oder auf Probleme mit dem Dateisystem hin.

XFSSmallAverageClusterSize

Veranstaltung

Die durchschnittliche XFS-Clustergröße ist klein, was auf eine übermäßige Fragmentierung des freien Speicherplatzes hindeutet. Dies kann die Erstellung von Dateien trotz verfügbarer Inodes oder freiem Speicherplatz verhindern.