Schritt 1: Status des Workerknotens abrufen

Wenn Ihr Cluster den Status Critical, Delete failed oder Warning aufweist oder sich seit längerer Zeit im Status Pending befindet, überprüfen Sie den Status Ihrer Workerknoten.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

Schritt 2: Status des Workerknotens überprüfen

Überprüfen Sie die Felder State (Zustand) und Status für jeden Workerknoten in Ihrer CLI-Ausgabe.

Weitere Informationen finden Sie unter Status des Workerknotens.

Schritt 3: Details für jeden Workerknoten abrufen

Rufen Sie die Details für den Workerknoten ab. Wenn die Details eine Fehlernachricht enthalten, überprüfen Sie die Liste der gängigen Fehlernachrichten für Workerknoten und lernen Sie, diese Probleme zu beheben.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

Schritt 4: Infrastrukturprovider für Workerknoten überprüfen

Überprüfen Sie die Infrastrukturumgebung, um zu sehen, ob es noch andere Gründe für Probleme mit dem Workerknoten gibt.

1. Halten Sie Rücksprache mit Ihrem Netzteam, um sicherzustellen, dass keine kürzlich erfolgten Wartungsmaßnahmen wie Firewall- oder Teilnetzaktualisierungen die Verbindungen des Workerknotens beeinträchtigen.
2. Lesen Sie die IBM Cloud für Red Hat OpenShift on IBM Cloud und den zugrunde liegenden Infrastrukturanbieter, z. B. Virtual Servers für klassische, VPC-bezogene Komponenten oder Satellite.
3. Wenn Sie Zugriff auf die zugrunde liegende Infrastruktur haben, z. B. auf klassische virtuelle Server, überprüfen Sie die Details der entsprechenden Maschinen für die Workerknoten.

Schritt 5: Sammeln Sie die Protokolle und andere Details über Ihre Arbeitsknoten

Ausführen des Befehls must-gather

Der CLI-Befehl oc adm must-gather sammelt die Informationen aus Ihrem Cluster für die Fehlersuche. Dieses Tool sammelt Ressourcendefinitionen, Dienstprotokolle und vieles mehr. Beachten Sie, dass Audit-Protokolle nicht als Teil der Standardinformationen gesammelt werden, um die Größe der Dateien zu reduzieren.

Wenn Sie oc adm must-gather ausführen, wird ein neuer Pod mit einem zufälligen Namen in einem neuen Projekt auf dem Cluster erstellt. Die Daten werden auf diesem Pod gesammelt und in einem neuen Verzeichnis gespeichert, das mit must-gather.local beginnt.

Sehen Sie sich die folgenden Beispielbefehle an.

oc adm must-gather

Beispielbefehl, um Daten zu einem oder mehreren bestimmten Merkmalen zu sammeln, verwenden Sie das Argument --image mit einem bestimmten Bild.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Beispielbefehl zum Sammeln von Audit-Protokollen.

oc adm must-gather -- /usr/bin/gather_audit_logs

Beispielbefehl zur Ausführung von must-gather in einem bestimmten Namensraum.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Beispielbefehle zum Sammeln von Protokollen zu einem bestimmten Zeitpunkt.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

Beispielbefehl zum Sammeln von Netzwerkprotokollen.

oc adm must-gather -- gather_network_logs

Für weitere Beispiele und Argumente führen Sie den folgenden Befehl aus

oc adm must-gather -h

Beispielbefehl zum Erstellen einer komprimierten Datei aus dem Verzeichnis must-gather.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

Hängen Sie die komprimierte Datei an Ihren Supportfall an.

Erstellung eines SOS-Berichts

sosreport ist ein Tool, das Konfigurationsdetails, Systeminformationen und Diagnosedaten von Red Hat Enterprise Linux (RHEL) und Red Hat Enterprise Linux CoreOS (RHCOS) Systemen sammelt. Es bietet eine standardisierte Möglichkeit, Diagnoseinformationen zu einem Knoten zu sammeln, die dann dem Support zur Problemdiagnose zur Verfügung gestellt werden können.

In einigen Fällen kann der Support Sie bitten, ein sosreport Archiv für einen bestimmten OpenShift Container Platform Knoten zu sammeln. So kann es beispielsweise erforderlich sein, Systemprotokolle oder andere knotenspezifische Daten zu prüfen, die nicht in der Ausgabe von oc adm must-gather enthalten sind.

Die Vorgehensweise zum Abrufen eines „ sosreport “ hängt vom Betriebssystem des Worker-Knotens ab. RHCOS-Knoten verwenden den Befehl „ toolbox “. RHEL 8- und RHEL 9-Knoten unterstützen „ toolbox “ nicht; verwenden Sie stattdessen das Skript „ Red Hat “ (sosreport).

Es wird empfohlen, eine sosreport für einen OpenShift Container Platform Clusterknoten über einen Debug-Pod zu erstellen.

Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

1. Listen Sie Ihre Worker-Knoten auf, um den Zielknoten und dessen Betriebssystem zu identifizieren.

   oc get nodes -o wide
   

   Notieren Sie sich den Namen des Worker-Knotens, von dem Sie die „ sosreport “ abrufen möchten. Die Spalte „OS-IMAGE“ gibt an, ob auf dem Knoten RHCOS oder RHEL ausgeführt wird.

2. Starten Sie eine Debug-Sitzung auf dem Zielknoten.

   oc debug node/node_name
   

   Um eine Debug-Sitzung auf dem Zielknoten zu starten, der mit dem Effekt NoExecute behaftet ist, fügen Sie eine Duldung zu einem temporären Namensraum hinzu und starten den Debug-Pod im temporären Namensraum.

   oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'
   

   oc debug node/my-cluster-node
   

3. Legen Sie /host als Stammverzeichnis innerhalb der Debug-Shell fest. Der Debug-Pod bindet das Root-Dateisystem des Hosts unter „ /host “ innerhalb des Pods ein. Indem Sie das Stammverzeichnis auf „ /host “ ändern, können Sie Binärdateien ausführen, die in den Ausführungswegen des Hosts enthalten sind.

   chroot /host
   

   OpenShift Container Platform Clusterknoten, auf denen Red Hat Enterprise Linux CoreOS (RHCOS) läuft, sind unveränderlich und benötigen Operatoren, um Clusteränderungen anzuwenden. Der Zugriff auf Clusterknoten über SSH wird nicht empfohlen. Wenn jedoch die API „ OpenShift Container Platform “ nicht verfügbar ist oder das Kubelet auf dem Zielknoten nicht ordnungsgemäß funktioniert, kann dies Auswirkungen auf die OC-Operationen haben. In solchen Situationen ist es möglich, stattdessen über ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN auf Knoten zuzugreifen.

4. Rufen Sie die „ sosreport “ mit der Methode ab, die dem Betriebssystem des Worker-Knotens entspricht.

   • RHCOS-Knoten: Verwenden Sie den Befehl „ toolbox “.

     1. Starten Sie einen Toolbox-Container, der die erforderlichen Binärdateien und Plug-ins enthält, um die sosreport auszuführen. Der Befehl „ toolbox “ wird nur auf RHCOS-Knoten unterstützt.

        toolbox
        

        Wenn ein vorhandener Toolbox-Pod bereits läuft, gibt der Toolbox-Befehl 'toolbox-' already exists. Trying to start…. aus. Entfernen Sie den laufenden Toolbox-Container mit podman rm toolbox- und starten Sie einen neuen Toolbox-Container.

     2. Führen Sie den Befehl sos report aus und folgen Sie den Aufforderungen, um Daten zur Fehlerbehebung zu sammeln.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on
        

        Beispielbefehl, um Informationen über OVN- Kubernetes Netzwerkkonfigurationen eines Knotens in Ihren Bericht aufzunehmen.

        sos report --all-logs
        

        Die Ausgabe von „ sosreport “ enthält den Speicherort des Archivs und die Prüfsumme. Die folgenden Beispielnachrichten beziehen sich auf die Fall-ID 01234567. Der Dateipfad liegt außerhalb der Umgebung „ chroot “, da der Toolbox-Container das Stammverzeichnis des Hosts unter „ /host “ einbindet.

        Your sosreport has been generated and saved in:
        /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
        The checksum is: 382ffc167510fd71b4f12a4f40b97a4e
        

   • RHEL 8- und RHEL 9-Knoten: Der Befehl „ toolbox “ wird auf RHEL-Knoten nicht unterstützt. Verwenden Sie stattdessen das Skript „sosreport collection“ unter Red Hat.

     1. Laden Sie das Skript „ Red Hat “ herunter und führen Sie es aus, indem Sie die Anweisungen im Knowledge-Base-Artikel unter Red Hat befolgen.

     2. Befolgen Sie die Anweisungen im Skript, um die Daten zur Fehlerbehebung zu erfassen. Notieren Sie sich den Speicherort der vom Skript erstellten Archivdatei anhand der Skriptausgabe.

5. Ausgabe der sosreport in eine Datei.

   Der Debug-Container bindet das Stammverzeichnis des Hosts unter „ /host “ ein. Geben Sie bei der Angabe der Zieldateien für die Verkettung den absoluten Pfad ausgehend vom Stammverzeichnis des Debug-Containers an, einschließlich „ /host “.

   oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
   

   OpenShift Container Platform Clusterknoten, auf denen Red Hat Enterprise Linux CoreOS (RHCOS) läuft, sind unveränderlich und benötigen Operatoren, um Clusteränderungen anzuwenden. Die Übertragung eines sosreport Archivs von einem Clusterknoten unter Verwendung von scp wird nicht empfohlen. Wenn jedoch die API „ OpenShift Container Platform “ nicht verfügbar ist oder das Kubelet auf dem Zielknoten nicht ordnungsgemäß funktioniert, kann dies Auswirkungen oc auf den Betrieb haben. In solchen Situationen ist es möglich, ein sosreport Archiv von einem Knoten zu kopieren, indem Sie scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> ausführen.

6. Laden Sie die Datei in Ihren Support-Fall hoch.