**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.
# Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur
Der Knotenstatus bezieht sich auf den Betriebsstatus und die Fähigkeit eines Kubernetes-Knotens, Workloads effektiv auszuführen. Ein fehlerfreier Knoten hält die erwartete Netzwerkkonnektivität aufrecht, verfügt über ausreichende Rechen- und Speicherressourcen und kann Workloads ohne Unterbrechung erfolgreich ausführen.
Um bei der Aufrechterhaltung fehlerfreier Knoten in EKS-Clustern zu helfen, bietet EKS den *Knotenüberwachungsagenten* und die *automatische Knotenreparatur*. Diese Funktionen werden bei EKS Auto Mode Compute automatisch aktiviert. Sie können die automatische Knotenreparatur auch mit von EKS verwalteten Knotengruppen und Karpenter verwenden und den EKS-Knotenüberwachungsagenten mit allen EKS-Compute-Typen außer Fargate verwenden. AWS Der EKS-Knotenüberwachungsagent und die automatische Knotenreparatur sind am effektivsten, wenn sie zusammen verwendet werden. Sie können jedoch auch einzeln in EKS-Clustern verwendet werden.
**Wichtig**
Der *Knoten-Überwachungsagente* und die *Knotenreparatur* sind nur in Linux verfügbar. Diese Features sind unter Windows nicht verfügbar.
## Knotenüberwachungsagent
Der EKS-Knotenüberwachungsagent liest Knotenprotokolle, um Gesundheitsprobleme zu erkennen. Er analysiert Protokolle, um Fehler zu erkennen, und zeigt Statusinformationen über den Gesundheitszustand der Knoten an. Für jede Kategorie erkannter Probleme wendet der Agent eine für die Worker-Knoten spezifische Methode `NodeCondition` an. Ausführliche Informationen zu den vom EKS-Knotenüberwachungsagenten festgestellten Problemen mit dem Knotenstatus finden Sie unter[Erkennen Sie Probleme mit dem Knotenüberwachungsagenten von EKS](node-health-nma.md).
EKS Auto Mode Compute beinhaltet den Node Monitoring Agent. Für andere EKS-Berechnungstypen können Sie den Node Monitoring Agent als EKS-Add-on hinzufügen oder ihn mit Kubernetes-Tools wie Helm verwalten. Weitere Informationen finden Sie unter [Konfigurieren Sie den Node Monitoring Agent](node-health-nma.md#node-monitoring-agent-configure).
Mit dem EKS-Node-Monitoring-Agenten werden die folgenden Kategorien von Problemen mit dem Knotenstatus als Knotenbedingungen angezeigt. Beachten Sie, `Ready``DiskPressure`, und `MemoryPressure` sind Standardbedingungen für Kubernetes-Knoten, die auch ohne den EKS-Knotenüberwachungsagenten angezeigt werden.
| Zustand des Knotens | Description |
| --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady gibt an, ob die beschleunigte Hardware (GPU, Neuron) auf dem Knoten ordnungsgemäß funktioniert. |
| ContainerRuntimeReady | ContainerRuntimeReady gibt an, ob die Container-Laufzeit (containerd usw.) korrekt funktioniert und Container ausführen kann. |
| DiskPressure | DiskPressure ist eine Standardbedingung für Kubernetes, die darauf hinweist, dass der Knoten unter Druck steht (geringer Festplattenspeicher oder hoher I/O). |
| KernelReady | KernelReady gibt an, ob der Kernel ohne kritische Fehler, Panik oder Ressourcenerschöpfung ordnungsgemäß funktioniert. |
| MemoryPressure | MemoryPressure ist eine Standardbedingung für Kubernetes, die darauf hinweist, dass der Knoten unter Speicherdruck steht (zu wenig verfügbarer Speicher). |
| NetworkingReady | NetworkingReady gibt an, ob der Netzwerkstapel des Knotens ordnungsgemäß funktioniert (Schnittstellen, Routing, Konnektivität). |
| StorageReady | StorageReady gibt an, ob das Speichersubsystem des Knotens ordnungsgemäß funktioniert (Festplatten, Dateisysteme, I/O). |
| Bereit | Bereit ist die Standardbedingung für Kubernetes, die angibt, dass der Knoten fehlerfrei und bereit ist, Pods anzunehmen. |
## Automatische Knotenreparatur
Die automatische Knotenreparatur von EKS überwacht kontinuierlich den Zustand der Knoten, reagiert auf erkannte Probleme und ersetzt Knoten oder startet sie neu, wenn möglich. Dies verbessert die Zuverlässigkeit des Clusters bei minimalem manuellem Eingriff und trägt dazu bei, die Ausfallzeiten von Anwendungen zu reduzieren.
Die automatische EKS-Knotenreparatur reagiert von selbst auf die `Ready` Bedingungen im Kubelet, auf alle manuell gelöschten Knotenobjekte und auf von EKS verwaltete Knotengruppeninstanzen, die dem Cluster nicht beitreten können. Wenn die automatische EKS-Knotenreparatur aktiviert ist und der Node Monitoring Agent installiert ist, reagiert die automatische Knotenreparatur von EKS auf zusätzliche Knotenbedingungen:`AcceleratedHardwareReady`,`ContainerRuntimeReady`, `KernelReady``NetworkingReady`, und. `StorageReady`
Die automatische EKS-Knotenreparatur reagiert nicht auf standardmäßige Kubernetes `DiskPressure` - `MemoryPressure` oder `PIDPressure` Knotenbedingungen. Diese Bedingungen deuten häufig eher auf Probleme mit dem Anwendungsverhalten, der Workload-Konfiguration oder Ressourcenbeschränkungen als auf Ausfälle auf Knotenebene hin, was es schwierig macht, eine geeignete Standardreparaturaktion zu ermitteln. [In diesen Szenarien unterliegen Workloads dem Verhalten von Kubernetes-Knotenüberlastung.](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction)
Weitere Informationen zur automatischen Knotenreparatur von EKS finden Sie unter. [Automatisches Reparieren von Knoten in EKS-Clustern](node-repair.md)
**Topics**
# Erkennen Sie Probleme mit dem Knotenüberwachungsagenten von EKS
In diesem Thema werden die vom EKS-Node-Monitoring-Agenten erkannten Knotenzustandsprobleme beschrieben, wie diese Probleme als Knotenbedingungen oder -ereignisse zum Vorschein kommen und wie der Node Monitoring Agent konfiguriert wird.
Der EKS-Knotenüberwachungsagent kann mit oder ohne automatische EKS-Knotenreparatur verwendet werden. Weitere Informationen zur automatischen EKS-Knotenreparatur finden Sie unter[Automatisches Reparieren von Knoten in EKS-Clustern](node-repair.md).
Der Quellcode für den EKS-Node-Monitoring-Agenten ist am GitHub im [eks-node-monitoring-agentaws/-Repository](https://github.com/aws/eks-node-monitoring-agent) veröffentlicht.
## 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](learn-status-conditions.md#status-node-conditions).
+ Ereignis – Ein vorübergehendes Problem oder eine suboptimale Knotenkonfiguration. Es erfolgt keine automatische Reparatur. Weitere Informationen finden Sie unter [Knotenereignisse](learn-status-conditions.md#status-node-events).
## AcceleratedHardware Probleme mit dem Zustand des Knotens
Der Überwachungszustand ist `AcceleratedHardwareReady` für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“. Die Ereignisse und Bedingungen in der folgenden Tabelle beziehen sich auf Probleme mit dem Zustand von Knoten im Zusammenhang mit NVIDIA und Neuron.
| Name | Schweregrad | Description | Aktion reparieren |
| --- | --- | --- | --- |
| DCGMDiagnosticFehlschlag | Bedingung | Ein Testfall aus der Test-Suite für die aktive DCGM-Diagnose ist fehlgeschlagen. | Keine |
| DCGMError | Bedingung | Die Verbindung zum DCGM-Hostprozess wurde unterbrochen oder konnte nicht hergestellt werden. | Keine |
| DCGMFieldFehler [Code] | Veranstaltung | DCGM hat anhand einer Feld-ID eine Verschlechterung der GPU festgestellt. | Keine |
| DCGMHealthCode [Kode] | Veranstaltung | Ein DCGM-Gesundheitscheck schlug ohne schwerwiegenden Fehler fehl. | Keine |
| DCGMHealthKode [Kodierung] | Bedingung | Ein DCGM-Gesundheitscheck ist auf fatale Weise fehlgeschlagen. | Keine |
| Neuron DMAError | Bedingung | Bei einer DMA-Engine ist ein nicht behebbarer Fehler aufgetreten. | Ersetzen |
| Neuronenfehler HBMUncorrectable | Bedingung | Bei einem HBM ist ein nicht korrigierbarer Fehler aufgetreten und es wurden falsche Ergebnisse ausgegeben. | Ersetzen |
| Neuronenfehler NCUncorrectable | Bedingung | Ein nicht korrigierbarer Neuron Core-Speicherfehler wurde erkannt. | Ersetzen |
| Neuronenfehler SRAMUncorrectable | Bedingung | Ein On-Chip-SRAM hat einen Paritätsfehler festgestellt und unkorrekte Ergebnisse erzeugt. | Ersetzen |
| NvidiaDeviceCountMismatch | Veranstaltung | Die Anzahl der durch NVML GPUs sichtbaren Geräte stimmt nicht mit der Anzahl der NVIDIA-Geräte im Dateisystem überein. | Keine |
| NvidiaDoubleBitError | Bedingung | Der GPU-Treiber hat einen doppelten Bit-Fehler erzeugt. | Ersetzen |
| Nvidia NCCLError | Veranstaltung | In der NVIDIA-Bibliothek für kollektive Kommunikation (`libnccl`) ist ein Sicherheitsfehler aufgetreten. | Keine |
| Nvidia-Fehler NVLink | Bedingung | NVLink Fehler wurden vom GPU-Treiber gemeldet. | Ersetzen |
| PCIeNvidia-Fehler | Veranstaltung | PCIe Wiederholungen wurden ausgelöst, um Übertragungsfehler zu beheben. | Keine |
| 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. | Keine |
| NvidiaPowerError | Veranstaltung | Der Stromverbrauch von hat die zulässigen GPUs Grenzwerte überschritten. | Keine |
| NvidiaThermalError | Veranstaltung | Thermischer Status hat die GPUs zulässigen Grenzwerte überschritten. | Keine |
| NVIDIAxID [Code] -Fehler | Bedingung | Ein kritischer GPU-Fehler ist aufgetreten. | Ersetzen oder neu starten |
| NvidiaXID[Code]Warning | Veranstaltung | Ein unkritischer GPU-Fehler ist aufgetreten. | Keine |
## NVIDIA XID-Fehlercodes
Der Node Monitoring Agent erkennt NVIDIA XID-Fehler anhand von GPU-Kernelprotokollen. XID-Fehler lassen sich in zwei Kategorien einteilen:
+ **Bekannte XID-Codes** — Kritische Fehler, die eine Knotenbedingung (`AcceleratedHardwareReady=False`) festlegen und bei Aktivierung eine auto Reparatur auslösen. Das Format des Ursachencodes lautet`NvidiaXID[Code]Error`. Die bekannten XID-Codes, die der EKS-Knotenüberwachungsagent erkennt, stellen möglicherweise nicht die vollständige Liste der NVIDIA-XID-Codes dar, für die Reparaturmaßnahmen erforderlich sind.
+ **Unbekannte XID-Codes** — Nur als Kubernetes-Ereignisse protokolliert. Diese lösen keine Autoreparatur aus. Das Format des Ursachencodes ist`NvidiaXID[Code]Warning`. Um unbekannte XID-Fehler zu untersuchen, überprüfen Sie Ihre Kernelprotokolle mit`dmesg | grep -i nvrm`.
Weitere Informationen zu XID-Fehlern finden Sie unter [XID-Fehler](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) in der *Dokumentation zur Bereitstellung und Verwaltung von NVIDIA-GPUs*. Weitere Informationen zu den einzelnen XID-Meldungen finden Sie unter [XID-Meldungen verstehen](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) in der *Dokumentation zur Bereitstellung und Verwaltung von NVIDIA-GPUs*.
In der folgenden Tabelle sind die bekannten XID-Codes, ihre Bedeutung und die Standardaktion zur Knotenreparatur, falls diese aktiviert ist, aufgeführt.
| XID-Code | Description | Aktion reparieren |
| --- | --- | --- |
| 13 | Grafik-Engine-Ausnahme — Ein GPU-Grafik-Engine-Fehler ist aufgetreten, der in der Regel durch Software- oder Treiberfehler verursacht wird. | Starten Sie neu |
| 31 | Fehler bei der GPU-Speicherseite — Eine Anwendung hat versucht, auf GPU-Speicher zuzugreifen, der weder zugeordnet noch zugänglich ist. | Starten Sie neu |
| 48 | Double-Bit-ECC-Fehler — Im GPU-Speicher ist ein nicht behebbarer Doppelbitfehler aufgetreten, der auf eine mögliche Hardwareverschlechterung hindeutet. | Starten Sie neu |
| 63 | Ereignis zur Neuzuweisung des GPU-Speichers — Der GPU-Treiber hat aufgrund festgestellter Fehler einen Teil des GPU-Speichers neu zugeordnet. Dies ist oft wiederherstellbar. | Starten Sie neu |
| 64 | Fehler bei der Neuzuweisung des GPU-Speichers — Die GPU konnte defekten Speicher nicht neu zuordnen, was auf Hardwareprobleme hindeutet. | Starten Sie neu |
| 74 | NVLink Fehler — Bei der NVLink Hochgeschwindigkeitsverbindung zwischen GPUs ist ein Fehler aufgetreten. | Ersetzen |
| 79 | GPU ist vom Bus gefallen — Auf die GPU kann nicht mehr zugegriffen werden PCIe, was in der Regel auf einen Hardware- oder Stromausfall hindeutet. | Ersetzen |
| 94 | Fehler im eingeschlossenen Speicher — Es ist ein Speicherfehler aufgetreten, der jedoch eingedämmt wurde und sich nicht auf andere Anwendungen auswirkte. | Starten Sie neu |
| 95 | Fehler bei fehlendem Speicher — Es ist ein Speicherfehler aufgetreten, der sich möglicherweise auf andere Anwendungen oder den Systemspeicher ausgewirkt hat. | Starten Sie neu |
| 119 | GSP RPC Timeout — Bei der Kommunikation mit dem GPU-Systemprozessor wurde das Zeitlimit überschritten, möglicherweise aufgrund von Firmware-Problemen. | Ersetzen |
| 120 | GSP-Fehler — Im GPU-Systemprozessor ist ein Fehler aufgetreten. | Ersetzen |
| 121 | C2C-Fehler — Bei der chip-to-chip Verbindung (die bei Multi-Die verwendet wird) ist ein Fehler aufgetreten. GPUs | Ersetzen |
| 140 | Nicht wiederhergestellter ECC-Fehler — Ein ECC-Fehler ist der Beschränkung entgangen und hat möglicherweise Daten beschädigt. | Ersetzen |
Führen Sie den folgenden Befehl aus, um die aktuellen Knotenbedingungen in Bezug auf den GPU-Zustand anzuzeigen.
```
kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason'
```
Führen Sie einen der folgenden Befehle aus, um XID-bezogene Ereignisse auf Ihrem Cluster anzuzeigen.
```
kubectl get events | grep -i "NvidiaXID"
```
## 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 | Aktion reparieren |
| --- | --- | --- | --- |
| ContainerRuntimeFailed | Veranstaltung | Die Container-Laufzeit konnte keinen Container erstellen. Dies hängt wahrscheinlich mit einem der gemeldeten Probleme zusammen, wenn es wiederholt auftritt. | Keine |
| DeprecatedContainerdConfiguration | Veranstaltung | Ein Container-Image, das die veraltete Image-Manifest-Version 2, Schema 1 verwendet, wurde kürzlich auf den Knoten übertragen. `containerd` | Keine |
| KubeletFailed | Veranstaltung | Der kubelet ist in einen fehlerhaften Zustand übergegangen. | Keine |
| 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. | Keine |
| 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. | Ersetzen |
| 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. | Keine |
| [Name] RepeatedRestart | Veranstaltung | Eine Systemd-Einheit wird häufig neu gestartet. | Keine |
| ServiceFailedToStart | Veranstaltung | Eine systemd-Einheit konnte nicht gestartet werden | Keine |
## Integritätsprobleme des Kernelknotens
Der Überwachungszustand ist `KernelReady` für Probleme in der folgenden Tabelle mit dem Schweregrad „Zustand“.
| Name | Schweregrad | Description | Aktion reparieren |
| --- | --- | --- | --- |
| 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. | Keine |
| AppCrash | Veranstaltung | Eine Anwendung auf dem Knoten ist abgestürzt. | Keine |
| 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. | Keine |
| 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 | Keine |
| 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. | Keine |
| 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. | Keine |
| ForkFailedOutOfPIDs | 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. | Ersetzen |
| 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. | Keine |
| LargeEnvironment | Veranstaltung | Die Anzahl der Umgebungsvariablen für diesen Prozess ist größer als erwartet, was möglicherweise auf viele Dienste zurückzuführen ist, deren Wert auf true `enableServiceLinks` gesetzt ist, was zu Leistungsproblemen führen kann. | Keine |
| 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. | Keine |
| SoftLockup | Veranstaltung | Die CPU ist für eine bestimmte Zeit blockiert. | Keine |
## 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 | Aktion reparieren |
| --- | --- | --- | --- |
| BandwidthInExceeded | Veranstaltung | Pakete wurden in die Warteschlange gestellt oder verworfen, da die eingehende Gesamtbandbreite das Maximum für die Instance überschritten hat. | Keine |
| BandwidthOutExceeded | Veranstaltung | Pakete wurden in die Warteschlange gestellt oder verworfen, da die ausgehende Gesamtbandbreite das Maximum für die Instance überschritten hat. | Keine |
| 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. | Keine |
| EFAErrorMetrik | Veranstaltung | Die EFA-Treiberkennzahlen zeigen, dass es eine Schnittstelle mit Leistungseinbußen gibt. | Keine |
| IPAMDInconsistentStatus | Veranstaltung | Der Status des IPAMD-Checkpoints auf der Festplatte spiegelt nicht die Laufzeit IPs in der Container-Laufzeit wider. | Keine |
| IPAMDNoIPs | Veranstaltung | IPAMD hat keine IP-Adressen mehr. | Keine |
| IPAMDNotBereit | Bedingung | IPAMD kann keine Verbindung zum API-Server herstellen. | Ersetzen |
| IPAMDNotLäuft | Bedingung | Es wurde festgestellt, dass der Amazon VPC CNI-Prozess nicht läuft. | Ersetzen |
| IPAMDRepeatedlyStarten Sie neu | Veranstaltung | Es sind mehrere Neustarts des IPAMD-Services aufgetreten. | Keine |
| InterfaceNotRunning | Bedingung | Diese Schnittstelle scheint nicht zu funktionieren oder es liegen Netzwerkprobleme vor. | Ersetzen |
| InterfaceNotUp | Bedingung | Diese Schnittstelle scheint derzeit nicht verfügbar zu sein oder es liegen Netzwerkprobleme vor. | Ersetzen |
| KubeProxyNotReady | Veranstaltung | Kube-proxy konnte die Ressourcen nicht überwachen oder auflisten. | Keine |
| LinkLocalExceeded | Veranstaltung | Pakete wurden verworfen, da die PPS des Datenverkehrs zu lokalen Proxy- Services das Maximum der Netzwerkschnittstelle überschritten hat. | Keine |
| MACAddressPolicyMisconfigured | Veranstaltung | Die Verbindungskonfiguration systemd-networkd hat den falschen Wert. `MACAddressPolicy` | Keine |
| MissingDefaultRoutes | Veranstaltung | Es fehlen Standard- Weiterleitungsregeln. | Keine |
| Fehlt IPRoutes | Veranstaltung | Es fehlen Routen für Pod IPs. | Keine |
| Es fehlt IPRules | Veranstaltung | Es fehlen Regeln für Pod IPs. | Keine |
| 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. | Ersetzen |
| NetworkSysctl | Veranstaltung | Die `sysctl` Netzwerkeinstellungen dieses Knotens sind möglicherweise falsch. | Keine |
| PPSExceeded | Veranstaltung | Pakete wurden in die Warteschlange gestellt oder verworfen, da die bidirektionale PPS das Maximum für die Instance überschritten hat. | Keine |
| 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. | Keine |
| UnexpectedRejectRule | Veranstaltung | Im wurde eine unerwartete `REJECT` `DROP` Oder-Regel gefunden`iptables`, die möglicherweise den erwarteten Datenverkehr blockiert. | Keine |
## 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 | Aktion reparieren |
| --- | --- | --- | --- |
| EBSInstanceIOPSExceeded | Veranstaltung | Die maximale Anzahl an IOPS für die Instanz wurde überschritten. | Keine |
| EBSInstanceThroughputExceeded | Veranstaltung | Der maximale Durchsatz für die Instanz wurde überschritten. | Keine |
| EBSVolumeIOPSExceeded | Veranstaltung | Die maximale Anzahl an IOPS für ein bestimmtes EBS-Volume wurde überschritten. | Keine |
| EBSVolumeThroughputExceeded | Veranstaltung | Der maximale Durchsatz für ein bestimmtes Amazon EBS-Volume wurde überschritten. | Keine |
| 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` | Keine |
| 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. | Keine |
| 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. | Keine |
| 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. | Keine |
## Konfigurieren Sie den Node Monitoring Agent
Der EKS-Knotenüberwachungsagent wird als bereitgestellt DaemonSet. Wenn Sie ihn als EKS-Add-On bereitstellen, können Sie die Installation mit den folgenden Konfigurationswerten anpassen. Standardkonfigurationen finden Sie in der [Helm-Tabelle](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) des EKS-Knotenüberwachungs-Agenten.
| Konfigurationsoption | Description |
| --- | --- |
| `monitoringAgent.resources.requests.cpu` | CPU-Ressourcenanforderung für den Monitoring-Agenten. |
| `monitoringAgent.resources.requests.memory` | Speicherressourcenanforderung für den Monitoring-Agenten. |
| `monitoringAgent.resources.limits.cpu` | CPU-Ressourcenlimit für den Monitoring-Agenten. |
| `monitoringAgent.resources.limits.memory` | Speicherressourcenlimit für den Monitoring-Agenten. |
| `monitoringAgent.tolerations` | Toleranzen bei der Planung des Monitoring-Agenten auf fehlerhaften Knoten. |
| `monitoringAgent.additionalArgs` | Zusätzliche Befehlszeilenargumente, die an den Monitoring-Agenten übergeben werden sollen. |
**Anmerkung**
Sie können `verbosity` wie `monitoringAgent.additionalArgs` bei der EKS-Add-Ons oder der Helm-Installation konfigurieren`hostname-override`. Derzeit können Sie die Einstellungen `probe-address` (`8002`) oder `metrics-address` (`8003`) des Node Monitoring Agents nicht über zusätzliche Argumente mit EKS-Add-Ons oder der Helm-Installation anpassen.
Der Node Monitoring Agent umfasst eine NVIDIA DCGM (Data Center GPU Manager) -Serverkomponente (`nv-hostengine`) zur Überwachung von NVIDIA. GPUs Diese Komponente wird nur auf Knoten ausgeführt, bei denen es sich um NVIDIA-GPU-Instanztypen handelt, wie `nodeAffinity` im [Helm-Diagramm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) des Agenten dargestellt. Sie können eine bestehende NVIDIA DCGM-Installation nicht mit dem EKS-Node-Monitoring-Agenten verwenden. Bitte geben Sie Feedback zum [GitHub EKS-Roadmap-Problem \$12763](https://github.com/aws/containers-roadmap/issues/2763), wenn Sie diese Funktionalität benötigen.
Wenn Sie den EKS-Node-Monitoring-Agenten als EKS-Add-On bereitstellen, können Sie die NVIDIA DCGM-Installation mit den folgenden Konfigurationswerten anpassen.
| Konfigurationsoption | Description |
| --- | --- |
| `dcgmAgent.resources.requests.cpu` | CPU-Ressourcenanforderung für den DCGM-Agenten. |
| `dcgmAgent.resources.requests.memory` | Speicherressourcenanforderung für den DCGM-Agenten. |
| `dcgmAgent.resources.limits.cpu` | CPU-Ressourcenlimit für den DCGM-Agenten. |
| `dcgmAgent.resources.limits.memory` | Speicherressourcenlimit für den DCGM-Agenten. |
| `dcgmAgent.tolerations` | Toleranzen bei der Planung des DCGM-Agenten auf fehlerhaften Knoten. |
Sie können die folgenden AWS CLI-Befehle verwenden, um nützliche Informationen zu den Versionen und dem Schema für das EKS-Add-On für den EKS-Knotenüberwachungsagenten zu erhalten.
Holen Sie sich die neueste Agent-Add-On-Version für Ihre Kubernetes-Version. Ersetzen Sie sie `1.35` durch Ihre Kubernetes-Version.
```
aws eks describe-addon-versions \
--addon-name eks-node-monitoring-agent \
--kubernetes-version 1.35 \
--query='addons[].addonVersions[].addonVersion'
```
Holen Sie sich das Agent-Add-On-Schema, das in EKS-Add-ons unterstützt wird. `v1.5.1-eksbuild.1`Ersetzen Sie es durch Ihre Agentenversion.
```
aws eks describe-addon-configuration \
--addon-name eks-node-monitoring-agent \
--addon-version v1.5.1-eksbuild.1
```
# Automatisches Reparieren von Knoten in EKS-Clustern
In diesem Thema wird das Verhalten der automatischen EKS-Knotenreparatur und die Konfiguration gemäß Ihren Anforderungen beschrieben. Die automatische EKS-Knotenreparatur ist im automatischen EKS-Modus standardmäßig aktiviert und kann mit von EKS verwalteten Knotengruppen und Karpenter verwendet werden.
Die standardmäßigen automatischen EKS-Knotenreparaturaktionen sind in der folgenden Tabelle zusammengefasst und gelten für das Verhalten im automatischen EKS-Modus, bei EKS-verwalteten Knotengruppen und bei Karpenter. Bei Verwendung von EKS Auto Mode oder Karpenter werden alle `AcceleratedHardwareReady` Reparaturaktionen `Reboot` als Reparaturaktion unterstützt`Replace`, und nur von EKS verwaltete Knotengruppen werden unterstützt.
Eine ausführliche Liste der vom EKS-Knotenüberwachungsagenten erkannten Knotenzustandsprobleme und der entsprechenden Reparaturaktionen für Knoten finden Sie unter. [Erkennen Sie Probleme mit dem Knotenüberwachungsagenten von EKS](node-health-nma.md)
| Zustand des Knotens | Description | Danach reparieren | Aktion (en) reparieren |
| --- | --- | --- | --- |
| AcceleratedHardwareReady | AcceleratedHardwareReady gibt an, ob die beschleunigte Hardware (GPU, Neuron) auf dem Knoten ordnungsgemäß funktioniert. | 10m | Ersetzen oder neu starten |
| ContainerRuntimeReady | ContainerRuntimeReady gibt an, ob die Container-Laufzeit (containerd usw.) korrekt funktioniert und Container ausführen kann. | 30m | Ersetzen |
| DiskPressure | DiskPressure ist eine Standardbedingung für Kubernetes, die darauf hinweist, dass der Knoten unter Druck steht (geringer Festplattenspeicher oder hoher I/O). | – | Keine |
| KernelReady | KernelReady gibt an, ob der Kernel ohne kritische Fehler, Panik oder Ressourcenerschöpfung ordnungsgemäß funktioniert. | 30m | Ersetzen |
| MemoryPressure | MemoryPressure ist eine Standardbedingung für Kubernetes, die darauf hinweist, dass der Knoten unter Speicherdruck steht (zu wenig verfügbarer Speicher). | – | Keine |
| NetworkingReady | NetworkingReady gibt an, ob der Netzwerkstapel des Knotens ordnungsgemäß funktioniert (Schnittstellen, Routing, Konnektivität). | 30m | Ersetzen |
| StorageReady | StorageReady gibt an, ob das Speichersubsystem des Knotens ordnungsgemäß funktioniert (Festplatten, Dateisysteme, I/O). | 30m | Ersetzen |
| Bereit | Bereit ist die Standardbedingung für Kubernetes, die angibt, dass der Knoten fehlerfrei und bereit ist, Pods anzunehmen. | 30m | Ersetzen |
Die automatischen EKS-Node-Reparaturaktionen sind in den folgenden Szenarien standardmäßig deaktiviert. In Bearbeitung befindliche Knotenreparaturaktionen werden in jedem Szenario fortgesetzt. Informationen [Konfigurieren Sie die automatische Knotenreparatur](#configure-node-repair) zum Überschreiben dieser Standardeinstellungen finden Sie unter.
**Von EKS verwaltete Knotengruppen**
+ Die Knotengruppe hat mehr als fünf Knoten und mehr als 20% der Knoten in der Knotengruppe sind fehlerhaft.
+ Eine Zonenverschiebung für Ihren Cluster wird durch den Application Recovery Controller (ARC) ausgelöst.
**EKS-Automatikmodus und Karpenter**
+ Mehr als 20% der Knoten in der NodePool sind fehlerhaft.
+ Im eigenständigen NodeClaims Modus sind 20% der Knoten im Cluster fehlerhaft.
## Konfigurieren Sie die automatische Knotenreparatur
Die automatische Knotenreparatur kann nicht konfiguriert werden, wenn der EKS-Automatikmodus verwendet wird, und sie ist immer mit den gleichen Standardeinstellungen wie Karpenter aktiviert.
### Karpenter
Um die automatische Knotenreparatur mit Karpenter zu verwenden, aktivieren Sie das Feature Gate. `NodeRepair=true` Sie können die Feature-Gates über die `--feature-gates` CLI-Option oder die `FEATURE_GATES` Umgebungsvariable in der Karpenter-Bereitstellung aktivieren. Weitere Informationen finden Sie in der [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair)-Dokumentation.
### Verwaltete Knotengruppen
Sie können die automatische Knotenreparatur aktivieren, wenn Sie neue von EKS verwaltete Knotengruppen erstellen oder indem Sie bestehende von EKS verwaltete Knotengruppen aktualisieren.
+ **Amazon EKS-Konsole** — Wählen Sie das Kontrollkästchen **auto Knotenreparatur aktivieren** für die verwaltete Knotengruppe aus. Weitere Informationen finden Sie unter [Eine verwaltete Knotengruppe für Ihren Cluster erstellen](create-managed-node-group.md).
+ ** AWS CLI** — `--node-repair-config enabled=true` Zum [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html)Befehl [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)oder hinzufügen.
+ **eksctl** [— Konfiguration`managedNodeGroups.nodeRepairConfig.enabled: true`, siehe das Beispiel in eksctl. GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml)
Wenn Sie von EKS verwaltete Knotengruppen verwenden, können Sie das Verhalten bei der auto Reparatur von Knoten mit den folgenden Einstellungen steuern.
Um zu steuern, wann die auto Knotenreparatur nicht mehr aktiv wird, legen Sie einen Schwellenwert fest, der auf der Anzahl der fehlerhaften Knoten in der Knotengruppe basiert. Legen Sie entweder die absolute Anzahl oder den Prozentsatz fest, aber nicht beide.
| Einstellung | Description |
| --- | --- |
| `maxUnhealthyNodeThresholdCount` | Die absolute Anzahl fehlerhafter Knoten, bei deren Überschreitung die auto Knotenreparatur beendet wird. Verwenden Sie diese Option, um den Umfang der Reparaturen einzuschränken. |
| `maxUnhealthyNodeThresholdPercentage` | Der Prozentsatz fehlerhafter Knoten, bei dessen Überschreitung die auto Knotenreparatur beendet wird (0-100). |
Um zu kontrollieren, wie viele Knoten gleichzeitig repariert werden, können Sie die Reparaturparallelität konfigurieren. Legen Sie wie beim Schwellenwert für fehlerhafte Knoten entweder die absolute Anzahl oder den Prozentsatz fest, aber nicht beides.
| Einstellung | Description |
| --- | --- |
| `maxParallelNodesRepairedCount` | Die maximale Anzahl von Knoten, die gleichzeitig repariert werden sollen. |
| `maxParallelNodesRepairedPercentage` | Der maximale Prozentsatz fehlerhafter Knoten, die gleichzeitig repariert werden müssen (0-100). |
Mit `nodeRepairConfigOverrides` können Sie das Reparaturverhalten an bestimmte Bedingungen anpassen. Verwenden Sie diese Option, wenn Sie unterschiedliche Reparaturaktionen oder Wartezeiten für verschiedene Problemtypen benötigen.
Für jede Überschreibung sind alle der folgenden Felder erforderlich:
| Feld | Description |
| --- | --- |
| `nodeMonitoringCondition` | Der vom Node-Monitoring-Agent gemeldete Knotenbedingungstyp. Zum Beispiel:`AcceleratedHardwareReady`,`NetworkingReady`,`StorageReady`,`KernelReady`. |
| `nodeUnhealthyReason` | Der spezifische Ursachencode für den ungesunden Zustand. Zum Beispiel: `NvidiaXID31Error`, `IPAMDNotRunning`. |
| `minRepairWaitTimeMins` | Die Mindestdauer in Minuten, für die der Zustand bestehen muss, bevor der Knoten repariert werden kann. Verwenden Sie diese Option, um zu vermeiden, dass Knoten aufgrund vorübergehender Probleme repariert werden. |
| `repairAction` | Die Aktion, die ergriffen werden muss, wenn die Bedingungen erfüllt sind. Gültige Werte: `Replace` (Knoten beenden und ersetzen), `Reboot` (Knoten neu starten) oder `NoAction` (keine Reparaturaktionen). |
Das folgende AWS CLI-Beispiel erstellt eine Knotengruppe mit benutzerdefinierten Reparatureinstellungen.
```
aws eks create-nodegroup \
--cluster-name my-cluster \
--nodegroup-name my-nodegroup \
--node-role arn:aws:iam::111122223333:role/NodeRole \
--subnets subnet-0123456789abcdef0 \
--node-repair-config '{
"enabled": true,
"maxUnhealthyNodeThresholdPercentage": 10,
"maxParallelNodesRepairedCount": 3,
"nodeRepairConfigOverrides": [
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID64Error",
"minRepairWaitTimeMins": 5,
"repairAction": "Replace"
},
{
"nodeMonitoringCondition": "AcceleratedHardwareReady",
"nodeUnhealthyReason": "NvidiaXID31Error",
"minRepairWaitTimeMins": 15,
"repairAction": "NoAction"
}
]
}'
```
Diese Konfiguration macht Folgendes:
+ Aktiviert die auto Knotenreparatur
+ Stoppt Reparaturaktionen, wenn mehr als 10% der Knoten fehlerhaft sind
+ Repariert bis zu 3 Knoten gleichzeitig
+ Überschreibt XID 64-Fehler (Fehler bei der Neuzuweisung des GPU-Speichers), um den Knoten nach 5 Minuten zu ersetzen. Die Standardeinstellung ist ein Neustart nach 10 Minuten.
+ Überschreibt XID 31-Fehler (GPU-Speicherseitenfehler), sodass keine Maßnahmen ergriffen werden. Die Standardeinstellung ist ein Neustart nach 10 Minuten.
# Integritätsstatus Ihrer Knoten anzeigen
In diesem Thema werden die Tools und Methoden beschrieben, die zur Überwachung des Zustands von Knoten in Amazon-EKS-Clustern verfügbar sind. Die Informationen umfassen Knotenbedingungen, Ereignisse und Erkennungsfälle, die Sie bei der Identifizierung und Diagnose von Problemen auf Knotenebene unterstützen. Verwenden Sie die hier beschriebenen Befehle und Muster, um die Ressourcen für den Knotenstatus zu überprüfen, Statusbedingungen zu interpretieren und Knotenereignisse für die Fehlerbehebung im Betrieb zu analysieren.
Mit Kubernetes-Befehlen können Sie einige Informationen zum Knotenzustand für alle Knoten abrufen. Wenn Sie den Knoten-Überwachungsagent über den Amazon EKS Auto Mode oder das verwaltete Amazon-EKS-Add-On verwenden, erhalten Sie eine größere Auswahl an Knotensignalen, die Ihnen bei der Fehlerbehebung helfen. Beschreibungen der vom Knoten-Überwachungsagent erkannten Integritätsprobleme werden auch im Dashboard zur Beobachtbarkeit angezeigt. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenüberwachungsagenten von EKS](node-health-nma.md).
## Knotenzustände
Knotenzustände stellen terminale Probleme dar, die Abhilfemaßnahmen wie den Austausch oder Neustart einer Instance erfordern.
**So rufen Sie die Zustände für alle Knoten ab:**
```
kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status'
```
**So erhalten Sie detaillierte Bedingungen für einen bestimmten Knoten**
```
kubectl describe node node-name
```
**Beispiel für die Ausgabe des Zustands eines fehlerfreien Knotens:**
```
- lastHeartbeatTime: "2024-11-21T19:07:40Z"
lastTransitionTime: "2024-11-08T03:57:40Z"
message: Monitoring for the Networking system is active
reason: NetworkingIsReady
status: "True"
type: NetworkingReady
```
**Beispiel für den Zustand eines fehlerhaften Knotens mit einem Netzwerkproblem:**
```
- lastHeartbeatTime: "2024-11-21T19:12:29Z"
lastTransitionTime: "2024-11-08T17:04:17Z"
message: IPAM-D has failed to connect to API Server which could be an issue with
IPTable rules or any other network configuration.
reason: IPAMDNotReady
status: "False"
type: NetworkingReady
```
## Knotenereignisse
Knotenereignisse weisen auf vorübergehende Probleme oder nicht optimale Konfigurationen hin.
**So rufen Sie alle vom Knoten-Überwachungsagenten gemeldeten Ereignisse ab**
Wenn der Knoten-Überwachungsagent verfügbar ist, können Sie den folgenden Befehl ausführen.
```
kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent
```
Beispielausgabe:
```
LAST SEEN TYPE REASON OBJECT MESSAGE
4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s
```
**So erhalten Sie Ereignisse für alle Knoten**
```
kubectl get events --field-selector involvedObject.kind=Node
```
**So rufen Sie Ereignisse für einen bestimmten Knoten ab**
```
kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name
```
**So beobachten Sie Ereignisse in Echtzeit**
```
kubectl get events -w --field-selector involvedObject.kind=Node
```
**Beispiel für eine Ereignisausgabe:**
```
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure
5m Normal NodeReady Node/node-1 Node became ready
```
## Gängige Befehle zur Fehlerbehebung
```
# Get comprehensive node status
kubectl get node node-name -o yaml
# Watch node status changes
kubectl get nodes -w
# Get node metrics
kubectl top node
```
# Abrufen von Knotenprotokollen für einen verwalteten Knoten mithilfe von kubectl und S3
Erfahren Sie, wie Sie Knotenprotokolle für einen von Amazon EKS verwalteten Knoten abrufen können, auf dem der Knoten-Überwachungsagent installiert ist.
## Voraussetzungen
Stellen Sie sicher, dass Sie über Folgendes verfügen:
+ Ein vorhandener Amazon-EKS-Cluster mit dem Knoten-Überwachungsagent. Weitere Informationen finden Sie unter [Erkennen Sie Probleme mit dem Knotenstatus und aktivieren Sie die automatische Knotenreparatur](node-health.md).
+ Das Befehlszeilentool `kubectl`, das für die Kommunikation mit Ihrem Cluster installiert und konfiguriert wurde.
+ Die AWS CLI wurde installiert und hat sich mit ausreichenden Berechtigungen angemeldet, um S3-Buckets und -Objekte zu erstellen.
+ Eine aktuelle Installation von Python 3
+ Das AWS SDK für Python 3, Boto 3, ist installiert.
## Schritt 1: S3-Bucket-Ziel erstellen (optional)
Falls Sie noch nicht über einen S3-Bucket zum Speichern der Protokolle verfügen, erstellen Sie einen. Verwenden Sie den folgenden AWS CLI-Befehl. Der Bucket verwendet standardmäßig die `private`-Zugriffskontroll-Liste. *bucket-name*Ersetzen Sie es durch den von Ihnen ausgewählten eindeutigen Bucket-Namen.
```
aws s3api create-bucket --bucket
```
## Schritt 2: Vorab signierte S3-URL für HTTP Put erstellen
Amazon EKS gibt die Knotenprotokolle zurück, indem es eine HTTP-PUT-Operation an eine von Ihnen angegebene URL durchführt. In diesem Tutorial erstellen wir eine vorab signierte S3-HTTP-PUT-URL.
Die Protokolle werden als gzip tarball mit der `.tar.gz`-Erweiterung zurückgegeben.
**Anmerkung**
Sie müssen die AWS API oder ein SDK verwenden, um die vorsignierte S3-Upload-URL für EKS zum Hochladen der Protokolldatei zu erstellen. Sie können mit der AWS CLI keine vorsignierte S3-Upload-URL erstellen.
1. Bestimmen Sie, wo im Bucket Sie die Protokolle speichern möchten. Sie können beispielsweise *2024-11-12/logs1.tar.gz* als Schlüssel verwenden.
1. Speichern Sie den folgenden Python-Code in der Datei *presign-upload.py*. Ersetzen Sie ** und **. Der Schlüssel sollte mit `.tar.gz` enden.
```
import boto3; print(boto3.client('s3').generate_presigned_url(
ClientMethod='put_object',
Params={'Bucket': '', 'Key': ''},
ExpiresIn=1000
))
```
1. Skript ausführen mit
```
python presign-upload.py
```
1. Beachten Sie die URL-Ausgabe. Verwenden Sie diesen Wert im nächsten Schritt als *http-put-destination*.
Weitere Informationen finden Sie unter [Generieren einer vorsignierten URL zum Hochladen einer Datei](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) in der Dokumentation zum AWS Boto3-SDK für Python.
## Schritt 3: Ressource erstellen NodeDiagnostic
Identifizieren Sie den Namen des Knotens, von dem Sie Protokolle erfassen möchten.
Erstellen Sie ein `NodeDiagnostic`-Manifest, das den Namen des Knotens als Namen der Ressource verwendet und eine HTTP-PUT-URL-Zieladresse angibt.
```
apiVersion: eks.amazonaws.com/v1alpha1
kind: NodeDiagnostic
metadata:
name:
spec:
logCapture:
destination: http-put-destination
```
Wenden Sie die Manifestdatei auf Ihren Cluster an.
```
kubectl apply -f nodediagnostic.yaml
```
Sie können den Status der Sammlung überprüfen, indem Sie die `NodeDiagnostic`-Ressource beschreiben:
+ Ein Status von `Success` oder `SuccessWithErrors` zeigt an, dass die Aufgabe abgeschlossen und die Protokolle an das angegebene Ziel hochgeladen wurden (`SuccessWithErrors` zeigt an, dass möglicherweise einige Protokolle fehlen).
+ Wenn der Status „Fehler“ lautet, stellen Sie sicher, dass die Upload-URL korrekt formatiert und nicht abgelaufen ist.
```
kubectl describe nodediagnostics.eks.amazonaws.com/
```
## Schritt 4: Protokolle aus S3 herunterladen
Warten Sie etwa eine Minute, bevor Sie versuchen, die Protokolle herunterzuladen. Verwenden Sie anschließend die S3-CLI, um die Protokolle herunterzuladen.
```
# Once NodeDiagnostic shows Success status, download the logs
aws s3 cp s3:///key ./.tar.gz
```
## Schritt 5: NodeDiagnostic Ressource bereinigen
+ `NodeDiagnostic`-Ressourcen werden nicht automatisch gelöscht. Sie sollten diese selbst bereinigen, nachdem Sie Ihre Protokoll-Artefakte erhalten haben
```
# Delete the NodeDiagnostic resource
kubectl delete nodediagnostics.eks.amazonaws.com/
```
## NodeDiagnostic `node`Ziel
Ab `v1.6.0` der Version des Node Monitoring Agents gibt es eine Option, mit der Sie das Ziel für die Protokollerfassung festlegen können`node`. Die Verwendung dieses Ziels führt zur Erfassung und temporären Speicherung von Protokollen auf dem Knoten für eine spätere Erfassung. Zusätzlich zu dieser Funktionalität befindet sich im GitHub Repository des Node Monitoring Agents ein `kubectl` Plugin, das Sie für eine einfache Interaktion und Protokollerfassung installieren können. Weitere Informationen finden Sie in der [Dokumentation zum `kubectl ekslogs` Plugin](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md).
## Beispielverwendung
```
# Collect NodeDiagnostic logs from a single node
kubectl ekslogs
# Collect NodeDiagnostic logs from multiple nodes
kubectl ekslogs
# Collect NodeDiagnostic logs from all nodes with a specific label
kubectl ekslogs -l =
```