Hilfe und Support für Ihren Cluster

Hier finden Sie Support-Optionen, Ressourcen zur Fehlerbehebung und Möglichkeiten, Hilfe für Ihren Cluster zu erhalten.

Stellen Sie vor dem Öffnen eines Supportfalls die entsprechenden relevanten Informationen zu Ihrer Clusterumgebung zusammen.

Suchen Sie das Diagnose- und Debugging-Tool? Dieses Add-on wird nicht mehr unterstützt. IBM Cloud Monitoring wird für die Überwachung und Diagnose von Problemen in Ihrem Cluster empfohlen. Weitere Links zur Fehlerbehebung, die relevant sein könnten, sind Fehlerbehebung für Worker Nodes im Zustand Kritisch oder NotReady und Fehlerbehebung für Anwendungen in IBM Cloud Kubernetes Service.

Erhalten Sie Ihre Cluster-Details

  1. Rufen Sie die Clusterdetails ab.

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
    
  2. Wenn Ihr Problem Workerknoten umfasst, rufen Sie auch die Details zu den Workerknoten ab.

    1. Listen Sie alle Workerknoten im Cluster auf und notieren Sie sich die ID all jener Workerknoten, deren Zustand (State) oder Status nicht einwandfrei ist.
        ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
        ```
    2. Rufen Sie die Details zu den Workerknoten ab, deren Zustand bzw. Status nicht einwandfrei ist.
    
    ```sh {: pre}
        ibmcloud oc worker get -w WORKER_ID -c CLUSTER_NAME_OR_ID
        ```
    
  3. Bei Problemen mit Ressourcen in Ihrem Cluster, wie beispielsweise Pods oder Services, melden Sie sich beim Cluster an und verwenden Sie die Kubernetes-API, um weitere Informationen zu den betreffenden Ressourcen zu erhalten.

Sammeln von Fehlerprotokollen und anderen Informationen

Ausführen des Befehls must-gather

Der CLI-Befehl oc adm must-gather sammelt die Informationen aus Ihrem Cluster für die Fehlersuche bei Problemen. 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 Erstellen 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 ermitteln.

    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 aus 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.

Support-Fall öffnen

  1. Wenden Sie sich an den IBM-Support, indem Sie einen Fall eröffnen.

  2. Suchen oder wählen Sie für den Problemtyp Red Hat OpenShift on IBM Cloud aus.

  3. Geben Sie für die Falldetails einen aussagekräftigen Titel an und fügen Sie die Details hinzu, die Sie zuvor zusammengestellt haben. Über Ressourcen können Sie auch den Cluster auswählen, auf den sich das Problem bezieht.

  4. Seien Sie so konkret wie möglich und schließen Sie und Architekturdiagramme oder ergänzende Materialien ein, von denen Sie denken, dass Sie IBM Support bei der Fehlerbehebung unterstützen könnten.