Hilf mit, diese Seite zu verbessern
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.
Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.
Der Zustand eines Knotens bezieht sich auf den Betriebsstatus und die Fähigkeit eines Knotens, Workloads effektiv auszuführen. Ein fehlerfreier Knoten behält die erwartete Konnektivität bei, verfügt über ausreichende Ressourcen und kann Pods ohne Unterbrechung erfolgreich ausführen. Informationen zum Abrufen von Details zu Ihren Knoten finden Sie unter Sehen Sie sich den Gesundheitsstatus Ihrer Knoten an undRufen Sie mit kubectl und S3 Knotenprotokolle für einen verwalteten Knoten ab.
Um die Aufrechterhaltung fehlerfreier Knoten zu unterstützen, bietet Amazon EKS den Node Monitoring Agent und die auto Knotenreparatur.
Agent zur Knotenüberwachung
Der Node Monitoring Agent liest automatisch Knotenprotokolle, um bestimmte Gesundheitsprobleme zu erkennen. Er analysiert Knotenprotokolle, um Fehler zu erkennen, und zeigt verschiedene Statusinformationen zu Worker-Knoten an. Für jede Kategorie von erkannten Problemen, z. B. Speicher- und Netzwerkprobleme, wird auf die Worker-Knoten ein eigener NodeCondition
Fehler angewendet. Beschreibungen der erkannten Gesundheitsprobleme werden im Observability-Dashboard zur Verfügung gestellt. Weitere Informationen finden Sie unter Probleme mit dem Zustand des Knotens.
Der Node Monitoring Agent ist als Funktion für alle Amazon EKS Auto Mode-Cluster enthalten. Für andere Clustertypen können Sie den Monitoring-Agenten als Amazon EKS-Add-on hinzufügen. Weitere Informationen finden Sie unter Ein Amazon EKS-Add-on erstellen.
auto Knotenreparatur
Die auto Reparatur von Knoten ist eine zusätzliche Funktion, die kontinuierlich den Zustand von Knoten überwacht, automatisch auf erkannte Probleme reagiert und Knoten nach Möglichkeit ersetzt. Dadurch wird die Gesamtverfügbarkeit des Clusters bei minimalem manuellem Eingriff verbessert. Wenn eine Zustandsprüfung fehlschlägt, wird der Knoten automatisch gesperrt, sodass keine neuen Pods auf dem Knoten geplant werden.
Die auto Knotenreparatur allein kann auf den Ready
Zustand der Knotenobjekte kubelet
und aller manuell gelöschten Knotenobjekte reagieren. In Kombination mit dem Node Monitoring Agent kann Node Auto Repair auf mehr Bedingungen reagieren, die sonst nicht erkannt würden. Zu diesen zusätzlichen Bedingungen gehören KernelReady
NetworkingReady
, undStorageReady
.
Diese automatische Knotenwiederherstellung behebt automatisch sporadisch auftretende Knotenprobleme wie Fehler beim Beitritt zum Cluster, nicht reagierende Kubelets und vermehrte Beschleunigerfehler (Gerätefehler). Die verbesserte Zuverlässigkeit trägt dazu bei, Ausfallzeiten von Anwendungen zu reduzieren und den Clusterbetrieb zu verbessern. Die auto Knotenreparatur kann bestimmte gemeldete Probleme wie DiskPressure
MemoryPressure
, und nicht behandelnPIDPressure
. Amazon EKS wartet 10 Minuten, bevor es auf die Bedingungen reagiert AcceleratedHardwareReady
NodeConditions
, und 30 Minuten, wenn es sich um alle anderen Bedingungen handelt.
In zwei Szenarien deaktivieren verwaltete Knotengruppen aus Sicherheitsgründen außerdem automatisch die Reparatur von Knoten. Alle Reparaturvorgänge, die zuvor ausgeführt wurden, werden in beiden Situationen fortgesetzt.
-
Wenn durch den Application Recovery Controller (ARC) eine Zonenverschiebung für Ihren Cluster ausgelöst wurde, werden alle nachfolgenden Reparaturvorgänge angehalten.
-
Wenn Ihre Knotengruppe mehr als fünf Knoten umfasst und sich mehr als 20% der Knoten in Ihrer Knotengruppe in einem fehlerhaften Zustand befinden, werden die Reparaturvorgänge angehalten.
Sie können die auto Knotenreparatur aktivieren, wenn Sie eine verwaltete Knotengruppe erstellen oder bearbeiten.
-
Wenn Sie die Amazon EKS-Konsole verwenden, aktivieren Sie das Kontrollkästchen auto Reparatur von Knoten aktivieren für die verwaltete Knotengruppe. Weitere Informationen finden Sie unter Erstellen Sie eine verwaltete Knotengruppe für Ihren Cluster.
-
Wenn Sie die AWS CLI verwenden, fügen Sie
--node-repair-config enabled=true
demeks update-nodegroup-config
Befehleks create nodegroup
or den hinzu. -
Ein Beispiel
eksctl
ClusterConfig
, das eine verwaltete Knotengruppe mit auto Knotenreparatur verwendet, finden Sie unter 44-node-repair.yamlon. GitHub
Probleme mit dem Zustand des Knotens
In den folgenden Tabellen werden Probleme mit dem Knotenstatus beschrieben, die vom Node Monitoring Agent erkannt werden können. Es gibt zwei Arten von Problemen:
-
Zustand — Ein Terminalproblem, das eine Behebungsmaßnahme wie den Austausch einer Instanz oder einen Neustart rechtfertigt. Wenn die auto Reparatur aktiviert ist, führt Amazon EKS eine Reparaturaktion durch, entweder als Knotenersatz oder als Neustart. Weitere Informationen finden Sie unter Bedingungen der Knoten.
-
Ereignis — Ein vorübergehendes Problem oder eine suboptimale Knotenkonfiguration. Es werden keine Autoreparaturmaßnahmen durchgeführt. Weitere Informationen finden Sie unter Knotenereignisse.
Probleme mit dem Zustand des Kernelknotens
Name | Schweregrad | Beschreibung |
---|---|---|
ForkFailedOutOfPID |
Bedingung |
Ein Fork- oder Exec-Aufruf ist fehlgeschlagen, weil das System keinen Prozess IDs - oder Speicherzugriff mehr hatte. Dies kann durch Zombie-Prozesse oder physische Speichererschöpfung verursacht werden. |
AppBlocked |
Ereignis |
Die Aufgabe wurde über einen längeren Zeitraum von der Planung blockiert, 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 PIDs , die gemäß der aktuellen kernel.pid_max-Einstellung verfügbar sind. Danach können keine Prozesse mehr gestartet werden. |
ApproachingMaxOpenFiles |
Ereignis |
Die Anzahl der geöffneten Dateien nähert sich angesichts der aktuellen Kernel-Einstellungen der maximalen Anzahl möglicher geöffneter Dateien. Danach schlägt das Öffnen neuer Dateien fehl. |
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 |
Prozesse, die nicht vollständig zurückgewonnen werden können, häufen sich in großer Zahl, was auf Anwendungsprobleme hindeutet und dazu führen kann, dass die Prozessgrenzen des Systems erreicht werden. |
KernelBug |
Ereignis |
Ein Kernelfehler wurde vom Linux-Kernel selbst entdeckt und gemeldet. Dieser Fehler 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, was möglicherweise darauf zurückzuführen ist, dass viele Dienste auf true enableServiceLinks gesetzt sind, was zu Leistungsproblemen führen kann. |
RapidCron |
Ereignis |
Ein Cron-Job wird auf diesem Knoten schneller als alle fünf Minuten ausgeführt, was sich negativ auf die Leistung auswirken kann, wenn der Job erhebliche Ressourcen verbraucht. |
SoftLockup |
Ereignis |
Die CPU ist für eine bestimmte Zeit ins Stocken geraten. |
Probleme mit dem Zustand des Netzwerkknotens
Name | Schweregrad | Beschreibung |
---|---|---|
InterfaceNotRunning |
Bedingung |
Diese Schnittstelle scheint nicht zu laufen oder es liegen Netzwerkprobleme vor. |
InterfaceNotUp |
Bedingung |
Diese Schnittstelle scheint nicht zu funktionieren oder es liegen Netzwerkprobleme vor. |
IPAMDNotBereit |
Bedingung |
IPAMD kann keine Verbindung zum API-Server herstellen. |
IPAMDNotWird ausgeführt |
Bedingung |
Es wurde nicht festgestellt, dass der |
MissingLoopbackInterface |
Bedingung |
Die Loopback-Schnittstelle fehlt in dieser Instanz, was je nach lokaler Konnektivität zum Ausfall von Diensten führt. |
BandwidthInExceeded |
Ereignis |
Pakete wurden in die Warteschlange gestellt oder verworfen, weil die Gesamtbandbreite für eingehende Nachrichten das Maximum für die Instanz überschritten hat. |
BandwidthOutExceeded |
Ereignis |
Pakete wurden in die Warteschlange gestellt oder verworfen, weil die Gesamtbandbreite für ausgehende Nachrichten das Maximum für die Instance überschritten hat. |
ConntrackExceeded |
Ereignis |
Die Verbindungsverfolgung hat das Maximum für die Instanz überschritten und es konnten keine neuen Verbindungen hergestellt werden, was zu Paketverlusten führen kann. |
IPAMDNoIPs |
Ereignis |
IPAM-D hat keine IP-Adressen mehr. |
IPAMDRepeatedlyStarten Sie neu |
Ereignis |
Der IPAMD-Dienst wurde mehrfach neu gestartet. |
KubeProxyNotReady |
Ereignis |
Der Kube-Proxy konnte keine Ressourcen überwachen oder auflisten. |
LinkLocalExceeded |
Ereignis |
Pakete wurden verworfen, weil der PPS-Wert des Datenverkehrs zu lokalen Proxydiensten den Grenzwert für die Netzwerkschnittstelle überschritten hat. |
MissingDefaultRoutes |
Ereignis |
Es fehlen Standardroutenregeln. |
FehltIPRules, fehlt IPRoutes |
Ereignis |
In der Routentabelle fehlen Routenregeln für IPs den folgenden Pod. |
NetworkSysctl |
Ereignis |
Die Netzwerk-Sysctl-Einstellungen dieses Knotens sind möglicherweise falsch. |
PortConflict |
Ereignis |
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 verhindern. |
PPSExceeded |
Ereignis |
Pakete wurden in die Warteschlange gestellt oder verworfen, weil das bidirektionale PPS das Maximum für die Instanz überschritten hat. |
UnexpectedRejectRule |
Ereignis |
In den iptables wurde eine unerwartete |
Probleme mit der Gesundheit von Neuronenknoten
Name | Schweregrad | Beschreibung |
---|---|---|
Neuron DMAError |
Bedingung |
Bei einer DMA-Engine ist ein nicht behebbarer Fehler aufgetreten. |
HBMUncorrectableNeuronenfehler |
Bedingung |
Ein HBM ist auf einen nicht behebbaren Fehler gestoßen und hat zu falschen Ergebnissen geführt. |
NCUncorrectableNeuronenfehler |
Bedingung |
Es wurde ein nicht behebbarer Speicherfehler in Neuron Core festgestellt. |
SRAMUncorrectableNeuron-Fehler |
Bedingung |
Bei einem SRAM auf dem Chip ist ein Paritätsfehler aufgetreten, der zu falschen Ergebnissen geführt hat. |
Probleme mit dem Zustand von NVIDIA-Knoten
Wenn die auto 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
Name | Schweregrad | Beschreibung | Aktion reparieren |
---|---|---|---|
NvidiaDoubleBitError |
Bedingung |
Der GPU-Treiber hat einen Double-Bit-Fehler verursacht. |
Ersetzen |
NVLinkNvidia-Fehler |
Bedingung |
NVLink Fehler wurden vom GPU-Treiber gemeldet. |
Ersetzen |
XID13Nvidia-Fehler |
Bedingung |
Es gibt eine Ausnahme für die Grafik-Engine. |
Neustart |
XID31Nvidia-Fehler |
Bedingung |
Es bestehen vermutete Hardwareprobleme. |
Neustart |
XID48Nvidia-Fehler |
Bedingung |
Double-Bit-ECC-Fehler werden vom Treiber gemeldet. |
Neustart |
Nvidia-Fehler XID63 |
Bedingung |
Es wurde eine Seite zurückgezogen oder die Zeile neu zugewiesen. |
Neustart |
Nvidia-Fehler XID64 |
Bedingung |
Beim Versuch, eine Seite zurückzuziehen oder eine Node-Neuzuordnung durchzuführen, sind Fehler aufgetreten. |
Neustart |
Nvidia-Fehler XID74 |
Bedingung |
Es besteht ein Problem mit einer Verbindung von der GPU zu einer anderen GPU oder einer anderen NVSwitch GPU NVLink. Dies kann auf einen Hardwarefehler mit der Verbindung selbst oder auf ein Problem mit dem Gerät am entfernten Ende der Verbindung hinweisen. |
Ersetzen |
XID79Nvidia-Fehler |
Bedingung |
Der GPU-Treiber hat versucht, über seine PCI-Express-Verbindung auf die GPU zuzugreifen, und hat festgestellt, dass auf die GPU nicht zugegriffen werden kann. |
Ersetzen |
XID94Nvidia-Fehler |
Bedingung |
Es gibt ECC-Speicherfehler. |
Neustart |
Nvidia-Fehler XID95 |
Bedingung |
Es gibt ECC-Speicherfehler. |
Neustart |
Nvidia-Fehler XID119 |
Bedingung |
Das GSP hat bei der Reaktion auf RPC-Anfragen von anderen Bits im Treiber eine Zeitüberschreitung erlitten. |
Ersetzen |
XID12Nvidia 0 Fehler |
Bedingung |
Das GSP hat rechtzeitig geantwortet, aber mit einem Fehler. |
Ersetzen |
Nvidia-Fehler XID121 |
Bedingung |
C2C ist eine Chip-Verbindung. Es ermöglicht die gemeinsame Nutzung von Speicher zwischen CPUs Beschleunigern und mehr. |
Ersetzen |
Nvidia 0 Fehler XID14 |
Bedingung |
Der GPU-Treiber hat möglicherweise nicht behebbare Fehler im GPU-Speicher festgestellt, sodass der GPU-Treiber nicht mehr in der Lage ist, Seiten für dynamisches Seitenofflining oder Zeilenneuzuweisung zu markieren. |
Ersetzen |
NvidiaPageRetirement |
Ereignis |
Der GPU-Treiber hat eine Speicherseite als veraltet markiert. Dies kann der Fall sein, wenn ein einzelner Doppelbitfehler oder zwei Einzelbitfehler an derselben Adresse auftreten. |
Keine |
nvidiaxID [Code] Warnung |
Ereignis |
Jedes Auftreten XIDs anderer als der in dieser Liste definierten Ereignisse führt zu diesem Ereignis. |
Keine |
DCGMError |
Bedingung |
Die Verbindung zum Data Center GPU Manager (DCGM) -Hostprozess wurde unterbrochen oder konnte nicht hergestellt werden. |
Keine |
DCGMDiagnosticFehler |
Bedingung |
Beim Ausführen der aktiven DCGM-Diagnose ist ein Problem aufgetreten. |
Keine |
DCGMDiagnosticEin Fehler |
Bedingung |
Ein Testfall aus der DCGM Active Diagnostics Test Suite ist fehlgeschlagen. |
Keine |
Probleme mit dem Zustand des Laufzeitknotens
Name | Schweregrad | Beschreibung |
---|---|---|
PodStuckTerminating |
Bedingung |
Ein Pod steckt oder war hängen geblieben und hat zu lange gekündigt. Dies kann durch CRI-Fehler verursacht werden, die das Fortschreiten des Pod-Status verhindern. |
%sRepeatedRestart |
Ereignis |
Startet alle Systemd-Dienste auf dem Knoten neu (formatiert unter Verwendung des Unit-Namens in Titelbuchstaben). |
ContainerRuntimeFailed |
Ereignis |
Die Container-Laufzeit konnte keinen Container erstellen, was wahrscheinlich auf gemeldete Probleme zurückzuführen ist, wenn sie wiederholt auftreten. |
KubeletFailed |
Ereignis |
Das Kubelet ist in einen ausgefallenen Zustand übergegangen. |
LivenessProbeFailures |
Ereignis |
Es wurde ein Fehler bei der Verfügbarkeitsprüfung festgestellt, der möglicherweise auf Probleme mit dem Anwendungscode oder unzureichende Timeout-Werte hindeutet, falls er wiederholt auftritt. |
ReadinessProbeFailures |
Ereignis |
Es wurde ein Fehler bei der Bereitschaftsprüfung festgestellt, der möglicherweise auf Probleme mit dem Anwendungscode oder unzureichende Timeoutwerte hindeutet, falls er wiederholt auftritt. |
ServiceFailedToStart |
Ereignis |
Eine Systemd-Einheit konnte nicht gestartet werden. |
Probleme mit dem Zustand des Speicherknotens
Name | Schweregrad | Beschreibung |
---|---|---|
XFSSmallAverageClusterSize |
Bedingung |
Die durchschnittliche XFS-Clustergröße ist klein, was auf eine übermäßige Fragmentierung des freien Speicherplatzes hindeutet, die trotz verfügbarer Inodes oder freiem Speicherplatz die Erstellung von Dateien verhindern kann. |
EtcHostsMountFailed |
Ereignis |
Das Mounten des generierten Kubelets ist |
IODelays |
Ereignis |
In einem Prozess wurde eine Eingabe- oder Ausgabeverzögerung festgestellt, was möglicherweise auf eine unzureichende Bereitstellung von Eingabe und Ausgabe hindeutet, falls diese zu hoch ist. |
KubeletDiskUsageSlow |
Ereignis |
Kubelet meldet eine langsame Festplattennutzung beim Versuch, auf das Dateisystem zuzugreifen, was möglicherweise auf unzureichende Festplatteneingabe- und -ausgabeprobleme oder auf Dateisystemprobleme hindeutet. |