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
-
Rufen Sie die Clusterdetails ab.
ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID -
Wenn Ihr Problem Workerknoten umfasst, rufen Sie auch die Details zu den Workerknoten ab.
- 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 ``` -
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.
-
Listen Sie Ihre Worker-Knoten auf, um den Zielknoten und dessen Betriebssystem zu ermitteln.
oc get nodes -o wideNotieren 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. -
Starten Sie eine Debug-Sitzung auf dem Zielknoten.
oc debug node/node_nameUm eine Debug-Sitzung auf dem Zielknoten zu starten, der mit dem Effekt
NoExecutebehaftet 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 -
Legen Sie
/hostals 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 /hostOpenShift 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_DOMAINauf Knoten zuzugreifen. -
Rufen Sie die „
sosreport“ mit der Methode ab, die dem Betriebssystem des Worker-Knotens entspricht.-
RHCOS-Knoten: Verwenden Sie den Befehl „
toolbox“.-
Starten Sie einen Toolbox-Container, der die erforderlichen Binärdateien und Plug-ins enthält, um die
sosreportauszuführen. Der Befehl „toolbox“ wird nur auf RHCOS-Knoten unterstützt.toolboxWenn ein vorhandener Toolbox-Pod bereits läuft, gibt der Toolbox-Befehl
'toolbox-' already exists. Trying to start….aus. Entfernen Sie den laufenden Toolbox-Container mitpodman rm toolbox-und starten Sie einen neuen Toolbox-Container. -
Führen Sie den Befehl
sos reportaus 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=onBeispielbefehl, um Informationen über OVN- Kubernetes Netzwerkkonfigurationen eines Knotens in Ihren Bericht aufzunehmen.
sos report --all-logsDie 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.-
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.
-
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.
-
-
-
Ausgabe der
sosreportin 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.xzOpenShift 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
sosreportArchivs von einem Clusterknoten unter Verwendung vonscpwird nicht empfohlen. Wenn jedoch die API „ OpenShift Container Platform “ nicht verfügbar ist oder das Kubelet auf dem Zielknoten nicht ordnungsgemäß funktioniert, kann dies Auswirkungenocauf den Betrieb haben. In solchen Situationen ist es möglich, einsosreportArchiv von einem Knoten zu kopieren, indem Siescp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>ausführen. -
Laden Sie die Datei in Ihren Support-Fall hoch.
Support-Fall öffnen
-
Wenden Sie sich an den IBM-Support, indem Sie einen Fall eröffnen.
-
Suchen oder wählen Sie für den Problemtyp Red Hat OpenShift on IBM Cloud aus.
-
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.
-
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.