Fehlerbehebung für Workerknoten im Status `Critical` oder `NotReady`

Cluster-Workerknoten wechseln in den Status Critical oder NotReady, wenn sie die Kommunikation mit dem Cluster-Master stoppen. Wenn dies geschieht, werden Ihre Worker-Knoten in der IBM CloudCritical Benutzeroberfläche als markiert oder wenn Sie Befehle ibmcloud oc worker ausführen, und in den Red Hat OpenShiftNotReady Dashboards als markiert und wenn Sie ausführen oc get nodes. Es gibt mehrere Gründe, warum die Kommunikation zwischen Workerknoten und dem Cluster-Master gestoppt wird. Führen Sie die folgenden Schritte aus, um Fehler bei Workerknoten in diesen Status zu beheben.

Überprüfen Sie das Dashboard IBM Cloud für Gesundheit und Status auf Benachrichtigungen oder Wartungsupdates, die für Ihre Worker-Knoten relevant sein könnten. Diese Benachrichtigungen oder Aktualisierungen können Ihnen dabei helfen, die Ursache für die Ausfälle von Workerknoten zu bestimmen.

Allgemeine Ursachen für Ausfälle von Workerknoten überprüfen

Es gibt mehrere Gründe, warum die Kommunikation zwischen Workerknoten und dem Cluster-Master gestoppt wird. Überprüfen Sie, ob die folgenden allgemeinen Probleme die Unterbrechung verursachen.

Der Worker wurde gelöscht, neu geladen, aktualisiert, ersetzt oder neu gestartet.: Workerknoten können vorübergehend den Status Critical oder NotReady aufweisen, wenn sie gelöscht, erneut geladen, aktualisiert oder ersetzt werden. Wenn eine dieser Aktionen auf Ihrem Workerknoten eingeleitet wurde, unabhängig davon, ob sie manuell oder im Rahmen einer Automatisierungskonfiguration wie Cluster-Autoscaler ausgeführt werden, warten Sie, bis die Aktionen abgeschlossen sind. Überprüfen Sie anschließend den Status Ihrer Workerknoten erneut. Wenn Worker im Status Critical oder NotReady verbleiben, laden oder ersetzen Sie die betroffenen Worker.; Wenn ein Workerknoten neu geladen oder ersetzt wurde und anfänglich ordnungsgemäß funktioniert, aber nach einiger Zeit wieder in den Status Critical oder NotReady zurückkehrt, ist es wahrscheinlich, dass eine Workload oder Komponente auf dem Worker das Problem verursacht. Informationen zur Eingrenzung der Problemworkload finden Sie unter Workerknoten debuggen.

Ein Workerknoten wird möglicherweise in den Status Critical oder NotReady versetzt, wenn er erneut gestartet wurde, ohne dass er zuvor gesperrt und bereinigt wurde. Wenn dies der Fall ist, kann das Problem durch Warten auf den Abschluss des Warmstarts nicht behoben werden. Laden Sie den betroffenen Worker erneut oder ersetzen Sie ihn. Wenn das Problem bestehen bleibt, fahren Sie mit den Schritten zur Fehlerbehebung fort.

Der Workerknoten wurde unabsichtlich ausgeschaltet.: Klassische Cluster In der Ressourcenliste derIBM Cloud-Konsolewerden Workerknoten in der klassischen Infrastruktur als Rechenressourcen oder virtuelle Maschinen klassifiziert. Manchmal erkennt ein Benutzer möglicherweise nicht, dass diese Ressourcen als Cluster-Workerknoten funktionieren, und kann die Workerknoten versehentlich herunterfahren. Workerknoten, die ausgeschaltet sind, werden möglicherweise im Status Critical oder NotReady angezeigt. Stellen Sie sicher, dass die betroffenen Workerknoten nicht ausgeschaltet sind.

Schritte zur Fehlerbehebung

Wenn Ihre Workerknoten nach der Behandlung der allgemeinen Ursachen im Status Critical oder NotReady verbleiben, fahren Sie mit den folgenden Schritten zur Fehlerbehebung fort.

Wenn ein Workerknoten, den Sie zuvor neu geladen oder ersetzt haben, beim Ausführen von ibmcloud ks workers den Status deploy_failed oder provision_failed aufweist, führen Sie die Schritte im Abschnitt Alle Workerknoten in einem Cluster sind betroffen aus, auch wenn nicht alle Knoten betroffen sind. Wenn ein anderer Status angegeben wird, finden Sie im Abschnitt Status der Workerknoten Informationen zur Fehlerbehebung für den neuen Worker. Ersetzen oder laden Sie keine zusätzlichen Workerknoten erneut.

Wenn ein oder mehrere Workerknoten betroffen sind

Wenn nur einige, aber nicht alle Workerknoten in Ihrem Cluster den Status Critical oder NotReady aufweisen, führen Sie die folgenden Schritte aus, um die Ursache der Unterbrechung zu ermitteln und das Problem zu beheben. Wenn die betroffenen Workerknoten alle aus derselben Zone, demselben Teilnetz oder VLAN stammen, fahren Sie mit dem nächsten Abschnitt fort.

Rufen Sie die Details des jeweiligen Knotens ab.
```
oc describe node <node-IP-address>
```
Prüfen Sie in der Ausgabe den Abschnitt Bedingungen, um festzustellen, ob auf dem Knoten Speicher-, Platten-oder PID-Probleme auftreten. Diese Informationen können darauf hinweisen, dass der Knoten einen niedrigen Wert für diesen Ressourcentyp aufweist. Diese Situation kann aus einem der folgenden Gründe auftreten:
- Die Erschöpfung des Speichers oder der CPU ist auf einen Mangel an ordnungsgemäßen Anforderungen und Begrenzungen für Ihre Pods zurückzuführen.
- Workerplatten sind voll, manchmal aufgrund umfangreicher Podprotokolle oder Podausgaben auf dem Knoten selbst.
- Langsame Speicherlecks, die im Laufe der Zeit entstehen, was zu Problemen für Worker führen kann, die seit mehr als einem Monat nicht aktualisiert wurden.
- Fehler und Abstürze, die sich auf den Linux-Kernel auswirken.
Wenn Sie die Ursache des Problems anhand der Informationen im Abschnitt Bedingungen bestimmen können, führen Sie die Schritte unter Debugging für Workerknoten durchführen aus, um die Problemworkload einzugrenzen.
Wenn das Problem durch die vorherigen Schritte nicht behoben werden kann, laden Sie die betroffenen Worker nacheinander erneut oder ersetzen Sie sie.

Wenn alle Workerknoten in einer einzelnen Zone, einem Teilnetz oder einem VLAN betroffen sind

Wenn sich alle Arbeitsknoten in einer Zone, einem Subnetz oder einem VLAN in einem Critical- oder NotReady-Zustand befinden, aber alle anderen Arbeitsknoten im Cluster normal funktionieren, liegt möglicherweise ein Problem mit einer Netzwerkkomponente vor. Führen Sie die Schritte in Wenn alle Workerknoten in einem Cluster betroffen sind aus, insbesondere die Schritte in Bezug auf alle Netzkomponenten, die sich auf die Zone, das Teilnetz oder das VLAN auswirken können, wie z. B. Firewall-oder Gateway-Regeln, ACLs oder angepasste Routen, oder Calico-und Kubernetes-Netzrichtlinien.

Wenn Sie Ihre Netzkomponenten überprüft haben und das Problem weiterhin nicht beheben können, erfassen Sie Ihre Workerknotendaten und öffnen Sie ein Support-Ticket.

Wenn alle Workerknoten in einem Cluster betroffen sind

Wenn alle Workerknoten in Ihrem Cluster gleichzeitig Critical oder NotReady anzeigen, liegt möglicherweise ein Problem mit dem Cluster apiserver oder dem Netzpfad zwischen den Workerknoten und dem apiserver vor. Führen Sie die folgenden Schritte zur Fehlerbehebung aus, um die Ursache zu bestimmen und das Problem zu beheben.

Einige Schritte beziehen sich speziell auf einen speziellen Bereich, z. B. Netzbetrieb oder Automatisierung. Ziehen Sie den zuständigen Administrator oder das Team in Ihrem Unternehmen zu Rate, bevor Sie diese Schritte ausführen.

Überprüfen Sie, ob kürzlich Änderungen an Ihrem Cluster, Ihrer Umgebung oder Ihrem Konto vorgenommen wurden, die sich auf Ihre Workerknoten auswirken könnten. Wenn dies der Fall ist, setzen Sie die Änderungen zurück und überprüfen Sie dann den Status des Workerknotens, um festzustellen, ob die Änderungen das Problem verursacht haben.
- Überprüfen Sie bei klassischen Clustern alle Firewalls oder Gateways, z. B. Virtual Router Appliance, Vyatta oder Juniper, die den Datenverkehr für Cluster-Worker verwalten. Suchen Sie nach Änderungen oder Problemen, die möglicherweise den Datenverkehr von Cluster-Workern löschen oder umleiten.
- Prüfen Sie bei VPC-Clustern, ob Änderungen an der Standardsicherheitsgruppe und den ACLs auf der VPC oder den Workerknoten vorgenommen wurden. Wenn Änderungen vorgenommen wurden, stellen Sie sicher, dass Sie den gesamten erforderlichen Datenverkehr von den Cluster-Workerknoten zum Cluster-Master, zur Container-Registry und zu anderen kritischen Services zulassen. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen und Steuern des Datenverkehrs mit ACLs.
- Überprüfen Sie bei VPC-Clustern alle angepassten Routing-Regeln auf Änderungen, die möglicherweise den Datenverkehr vom Cluster blockieren apiserver.
- Überprüfen Sie alle Calico-oder Kubernetes-Netzrichtlinien, die auf den Cluster angewendet werden, und stellen Sie sicher, dass sie den Datenverkehr vom Workerknoten zum Cluster apiservice, zur Container-Registry oder zu anderen kritischen Services nicht blockieren.
Prüfen Sie, ob die Anwendungen, Sicherheits-oder Überwachungskomponenten in Ihrem Cluster den Cluster apiserver mit Anforderungen überlasten, was zu Unterbrechungen für Ihre Workerknoten führen kann.
Wenn Sie kürzlich Komponenten zu Ihrem Cluster hinzugefügt haben, entfernen Sie sie. Wenn Sie Änderungen an vorhandenen Komponenten in Ihrem Cluster vorgenommen haben, setzen Sie die Änderungen zurück. Überprüfen Sie anschließend den Status Ihrer Workerknoten, um festzustellen, ob die neuen Komponenten oder Änderungen das Problem verursacht haben.
Überprüfen Sie alle Cluster-Webhooks auf Änderungen, die apiserver-Anforderungen unterbrechen oder die Fähigkeit eines Workerknotens blockieren können, eine Verbindung zu apiserver herzustellen. Suchen Sie nach Webhooks, die Anfragen ablehnen. Führen Sie den folgenden Befehl aus, um eine Liste der Webhooks zu erhalten, die Anfragen ablehnen.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Überprüfen Sie die Ausgabe für Webhooks mit dem Status " rejected="true".
Entfernen und generieren Sie alle angepassten geheimen Schlüssel für Docker-Pull-Operationen, die bei einer fehlerhaften Konfiguration verhindern können, dass Workerknoten Images aus Docker-Registrys extrahieren.
1. Führen Sie die Befehle oc delete secret -n openshift pull-secret und oc delete secret -n openshift-config pull-secret aus, um die angepassten geheimen Docker-Pull-Schlüssel zu löschen.
```
    oc delete secret -n openshift pull-secret
    ```
    ```sh {: pre}
    oc delete secret -n openshift-config pull-secret
    ```
1. Warten Sie, bis der Cluster die angepassten geheimen Schlüssel für Docker-Pull-Operationen neu generiert hat. Alle fehlerhaft konfigurierten Komponenten sind nicht mehr in den neu generierten geheimen Pull-Schlüsseln enthalten.
```
Überprüfen Sie den Status Ihrer Worker-Knoten. Wenn sie sich im Status Normal befinden, fügen Sie alle gelöschten Komponenten wieder hinzu und erstellen Sie nacheinander alle zurückgesetzten Änderungen erneut, bis Sie ermitteln können, welche Konfiguration oder Komponente die Unterbrechung des Workerknotens verursacht hat.
Wenn das Problem immer noch nicht behoben ist, führen Sie die Schritte zum Erfassen Ihrer Workerknotendaten aus und öffnen Sie ein Support-Ticket.

Wenn Workerknoten zwischen dem Status 'Normal' und dem Status 'Kritisch' wechseln

Wenn Ihre Workerknoten zwischen einem Normal-und Critical-oder NotReady-Status wechseln, überprüfen Sie die folgenden Komponenten auf Probleme oder aktuelle Änderungen, die Ihre Workerknoten unterbrechen könnten.

Überprüfen Sie für klassische Cluster Ihre Firewalls oder Gateways. Wenn eine Bandbreitenbegrenzung oder eine Störung vorliegt, beheben Sie das Problem. Überprüfen Sie anschließend Ihre Workerknoten erneut.
Prüfen Sie, ob die Anwendungen, Sicherheits-oder Überwachungskomponenten in Ihrem Cluster den Cluster apiserver mit Anforderungen überlasten, was zu Unterbrechungen für Ihre Workerknoten führen kann.
Wenn Sie kürzlich Komponenten zu Ihrem Cluster hinzugefügt haben, entfernen Sie sie. Wenn Sie Änderungen an vorhandenen Komponenten in Ihrem Cluster vorgenommen haben, setzen Sie die Änderungen zurück. Überprüfen Sie anschließend den Status Ihrer Workerknoten, um festzustellen, ob die neuen Komponenten oder Änderungen das Problem verursacht haben.
Überprüfen Sie alle Cluster-Webhooks auf Änderungen, die apiserver-Anforderungen unterbrechen oder die Fähigkeit eines Workerknotens blockieren können, eine Verbindung zu apiserver herzustellen. Suchen Sie nach Webhooks, die Anfragen ablehnen. Führen Sie den folgenden Befehl aus, um eine Liste der Webhooks zu erhalten, die Anfragen ablehnen.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Überprüfen Sie die Ausgabe für Webhooks mit dem Status " rejected="true".
Wenn das Problem immer noch nicht behoben ist, führen Sie die Schritte zum Erfassen Ihrer Workerknotendaten aus und öffnen Sie ein Support-Ticket.

Daten für einen Supportfall zusammenstellen

Wenn Sie das Problem mit den Fehlerbehebungsschritten nicht lösen können, stellen Sie Informationen zu Ihren Workerknoten zusammen. Öffnen Sie dann ein Support-Ticket und fügen Sie die erfassten Workerknoteninformationen ein.

Bevor Sie ein Support-Ticket öffnen, lesen Sie die Informationen und führen Sie alle Fehlerbehebungsschritte in Workerknoten debuggen, Workerknotenstatus und Fehlerbehebung für Workerknoten im Zustand Critical oder NotReady aus.

Wenn alle Arbeitsknoten in einem Cluster oder in einer Region, einem Subnetz oder einem VLAN betroffen sind, können Sie ein erstes Support-Ticket eröffnen, ohne Daten zu sammeln. Möglicherweise werden Sie jedoch später aufgefordert, die relevanten Daten zusammenzustellen. Wenn nur einer oder einige Ihrer Workerknoten betroffen sind, müssen Sie die relevanten Daten zusammenstellen, die in Ihr Support-Ticket aufgenommen werden sollen.

Vorbereitende Schritte

Überprüfen Sie die Bedingungen Ihrer Workerknoten und Cluster, bevor Sie Daten zusammenstellen.

Überprüfen Sie die CPU-und Speicherstufe Ihrer Knoten. Wenn ein Knoten mehr als 80% der CPU-oder Speicherbelegung aufweist, sollten Sie in Betracht ziehen, mehr Knoten bereitzustellen oder Ihre Workload zu reduzieren.

oc top node

Beispielausgabe

NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
10.001.1.01     640m         16%    6194Mi          47%       
10.002.2.02     2686m        68%    4024Mi          30%       
10.003.3.03     2088m        53%    10735Mi         81%

Überprüfen Sie alle Cluster-Webhooks auf Änderungen, die apiserver-Anforderungen unterbrechen oder die Fähigkeit eines Workerknotens blockieren können, eine Verbindung zu apiserver herzustellen. Suchen Sie nach Webhooks, die Anfragen ablehnen. Führen Sie den folgenden Befehl aus, um eine Liste der Webhooks zu erhalten, die Anfragen ablehnen.
```
kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds
```
Überprüfen Sie die Ausgabe für Webhooks mit dem Status " rejected="true".

Sammeln von Daten

Führen Sie die Schritte zum Erfassen der relevanten Workerknotendaten aus.

Rufen Sie die Details jedes Knotens ab. Speichern Sie die Ausgabedetails, um sie in Ihr Support-Ticket einzuschließen.
```
oc describe node <node-ip-address>
```
Zeigen Sie an, dass keine hinzugefügten mutierenden oder validierenden Webhooks in Ihrem Cluster verbleiben, indem Sie die Webhook-Details abrufen. Speichern Sie die Befehlsausgabe, um sie in Ihr Support-Ticket aufzunehmen. Beachten Sie, dass die folgenden mutierenden Webhooks verbleiben können und nicht gelöscht werden müssen: alertmanagerconfigs.openshift, managed-storage-validation-webhooks, multus.openshift.io, performance-addon-operator, prometheusrules.openshift.io,snapshot.storage.k8s.io.
```
kubectl get mutatingwebhookconfigurations
```
```
kubectl get validatingwebhookconfigurations
```
Klassische Cluster: Greifen Sie auf die KVM-Konsole für einen der betroffenen Worker zu. Stellen Sie anschließend die relevanten Protokolle und Ausgaben zusammen.
1. Führen Sie die Schritte zum Zugreifen auf die KVM-Konsole aus.
2. Stellen Sie die folgenden Protokolle zusammen und speichern Sie sie. Suchen Sie in den Protokollen nach möglichen Ursachen für den Ausfall des Workerknotens, wie z. B. Mangel an Hauptspeicher oder Plattenspeicherplatz, Wechsel der Platte in den Lesezugriffsmodus und andere Probleme.
  - /var/log/boot.log
  - /var/log/calico/cni/cni.log
  - /var/log/crio.log
  - /var/log/cron
  - /var/log/messages
  - /var/log/secure
3. Führen Sie die folgenden Befehle aus und speichern Sie die Ausgabe, um sie dem Support-Ticket zuzuordnen.
  - ps -aux # Ausführungsprozess für Speicherauszug
  - df -H # Informationen zur Plattenbelegung ausgeben
  - vmstat # Informationen zur Speicherbelegung ausgeben
  - lshw # Speicherauszug für Hardwareinformationen erstellen
  - last -Fxn2 shutdown reboot # Feststellen, ob der letzte Neustart korrekt war oder nicht
  - mount | grep -i "(ro" # um das Problem mit dem Plattenlesezugriff auszuschließen. HINWEIS: tmpfs Sein ro ist in Ordnung
  - touch /this # zum Auslassen des schreibgeschützten Plattenproblems
VPC-Cluster: Erfassen Sie die Ressourcennutzung von Worker Nodes mit dem Befehl kubectl top wie im folgenden Beispiel.
```
kubectl top nodes
```
Die Beispielausgabe zeigt die CPU-Nutzung in Millicores (m) und die Speichernutzung in Megabytes (Mi).
```
NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
k8s-node-1      250m              12%    800Mi                         40%
k8s-node-2      180m               9%     600Mi                         30%
k8s-node-3      250m               22%    700Mi                        50%
```
NAME

Der Name des Knotens.

CPU (Kerne)

Die aktuelle CPU-Auslastung in Millicores (m). 1000m entspricht 1 Kern.

% CPU

Der Prozentsatz der gesamten CPU-Kapazität, der auf dem Knoten verwendet wird.

Speicher (Byte)

Der aktuelle Speicherverbrauch in MiB (Megabyte) oder GiB (Gigabyte).

SPEICHER%

Der Prozentsatz der gesamten Speicherkapazität, der verwendet wird.

Ein Knoten mit hohem CPU% oder MEMORY% (über 80%) könnte überlastet sein und zusätzliche Ressourcen benötigen. Ein Knoten mit niedrigem CPU- oder MEMORY-Anteil (unter 20 %) ist möglicherweise nicht ausgelastet, was auf eine Umverteilung der Arbeitslast hinweist. Wenn ein Knoten eine CPU- oder Speichernutzung von 100 % erreicht, können neue Arbeitslasten möglicherweise nicht eingeplant werden oder es kommt zu Leistungseinbußen.
Erfassen Sie die Ressourcennutzung von Pods mit dem folgenden Befehl.
```
kubectl top pods --all-namespaces
```
Beispielausgabe
```
NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
default            my-app-564bc58dad-hk5gn       120m            256Mi
default             my-db-789d9c6c4f-tn7mv         300m            512Mi
```
NAME

Der Name des Pods.

CPU (Kerne)

Die Gesamt-CPU, die von dem Pod über alle seine Container hinweg verwendet wird.

Speicher (Byte)

Der Gesamtspeicher, den der Pod für alle seine Container verwendet.

Wenn die CPU-Auslastung eines Pods hoch ist, liegt möglicherweise eine CPU-Drosselung vor, die die Leistung beeinträchtigt. Wenn die Speichernutzung eines Pods nahe an seiner Grenze liegt, besteht die Gefahr von OOM-Fehlern (Out of Memory), bei denen Kubernetes Prozesse beendet werden, um Speicher freizugeben. Bei einem Pod mit geringer Ressourcennutzung kann es zu einer Überbelegung von Anfragen kommen, was zu einer Verschwendung von Ressourcen führt.

Überprüfen Sie die Metriken auf Containerebene, indem Sie den Befehl top pod ausführen.

kubectl top pod pod-a --containers -n appns
```sh
{: pre}
Example output
```sh
NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
pod-a            app-container        100m         300Mi
pod-a            db-container           50m          200Mi
```sh
{: screen}

Der Befehl kubectl top zeigt nur die tatsächliche Nutzung an, nicht die angeforderten oder begrenzten Ressourcen. Um die Ausgabe des Befehls top zu vergleichen und zu analysieren, überprüfen Sie die Pod-Spezifikation mit dem folgenden Befehl.
```
kubectl describe pod <pod-name> -n <namespace>
```
Beispielausgabe
```
Containers:
 app-container:
   Requests:
  cpu: 250m
  memory: 512Mi
  Limits:
  cpu: 500m
  memory: 1Gi
```
Wenn die CPU- oder Speichernutzung die Anforderungen übersteigt, kann dies auf eine unzureichende Bereitstellung hinweisen, was zu Leistungsproblemen führt. Wenn die Nutzung nahe an den Grenzwerten liegt, kann der Container gedrosselt oder beendet werden, wenn die Ressourcen knapp werden. Wenn die Nutzung deutlich geringer ist als die Anforderungen, ist der Pod möglicherweise überdimensioniert und verschwendet Ressourcen.

Ermitteln Sie, welche Pods die meiste CPU verbrauchen.

kubectl top pod --all-namespaces | sort -k3 -nr | head -10

Identifizieren Sie Pods, die viel Speicherplatz verbrauchen.

kubectl top pod --all-namespaces | sort -k4 -nr | head -10

Überwachen Sie die Ressourcennutzung des Systemdämons. DaemonSets, wie kube-proxy oder Überwachungsagenten, können unerwartete Ressourcen verbrauchen.
```
kubectl top pod -n kube-system
```sh
{: pre}
```
Wenn bestimmte System-Pods übermäßig viel CPU oder Arbeitsspeicher verbrauchen, sind möglicherweise Abstimmungsanforderungen und -grenzen erforderlich. Um Ressourcenänderungen kontinuierlich zu verfolgen, verwenden Sie den Befehl watch.
```
watch -n 5 kubectl top pod --all-namespaces
```sh
{: pre}
This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.
```
Suchen Sie nach OOMKilled Veranstaltungen. Wenn Kubernetes OOMKilled meldet, hat der Pod seine Speichergrenze überschritten und wurde beendet. Der Status des Pods ändert sich zu crashloopbackoff.
```
kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace
```

Suchen Sie nach OOM Meldungen in den Protokollen.

kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"

Überprüfen Sie den letzten Zustand des Containers auf OOM.

kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"

Sammeln von Arbeiterknoten-Protokollen

Führen Sie die folgenden Schritte aus, um auf den Worker zuzugreifen und Worker-Node-Protokolle zu sammeln.

Sammeln und speichern Sie die folgenden Protokolldateien. Suchen Sie in den Protokollen nach möglichen Ursachen für den Ausfall des Workerknotens, wie z. B. Mangel an Hauptspeicher oder Plattenspeicherplatz, Wechsel der Platte in den Lesezugriffsmodus und andere Probleme.
- /var/log/containerd.log
- /var/log/kern.log
- /var/log/kube-proxy.log
- /var/log/syslog
- /var/log/kubelet.log
Führen Sie die folgenden Befehle aus und speichern Sie die Ausgabe, um sie dem Support-Ticket zuzuordnen.

Container-Statistiken abrufen (erfordert SSH-Zugang zum Knoten).
```
crictl stats
```
Erhalten Sie detaillierte Statistiken für einen bestimmten Container.
```
crictl stats --id <container-id> --output json
```
Führen Sie den Befehl aus, um laufende Prozesse zu löschen.
```
ps -aux
```
Sie erhalten einen dynamischen Echtzeitüberblick über laufende Prozesse und vom Kernel verwaltete Aufgaben sowie über die Ressourcennutzung, einschließlich CPU- und Speichernutzung.
```
top
```
Ermittelt den aktuellen Systemstatus.
```
htop
```
Sie erhalten einen umfassenden Überwachungsbericht mit historischen Daten.
```
atop
```
Erhalten Sie Echtzeitinformationen über Systemprozesse.
```
btop
```
Details zur Netzwerkverbindung abrufen.
```
netstat
```
Abrufen von Informationen zur Festplattennutzung.
```
df -H
```
Führen Sie vmstat aus, um Berichte über Prozesse, Speicher, Paging, Block IO, Traps und CPU-Aktivität zu erhalten. Mit diesem Befehl werden die Informationen in Abständen von 2 Sekunden abgerufen, und zwar 5 Mal.
```
vmstat 2 5
```
Führen Sie iostat aus, um Festplattennutzungsstatistiken zu sammeln, die Durchsatz, Auslastung, Warteschlangenlängen, Transaktionsraten und mehr umfassen.
```
iostat -x 1 5
```
Sammeln Sie Hardware-Informationen.
```
lshw
```
Ermitteln Sie mit dem folgenden Befehl, ob der letzte Neustart ordnungsgemäß war oder nicht.
```
last -Fxn2 shutdown reboot
```
Um das Festplattenproblem auszuschließen, stellen Sie sicher, dass die Festplatte beschreibbar ist.
```
mount | grep -i "(ro"
touch /this
```
Wenn das Problem weiterhin besteht, öffnen Sie ein Support-Ticket und fügen Sie alle in den vorherigen Schritten gespeicherten Ausgaben bei.

Fehlerbehebung für Workerknoten im Status Critical oder NotReady