Debugging von OpenShift Data Foundation-Fehlern

Überprüfen Sie die Optionen, um die ODF zu debuggen und die Ursachen für alle Fehler zu ermitteln.

Es wird überprüft, ob der Pod, der Ihre Speicherinstanz anhängt, erfolgreich implementiert wurde

Folgen Sie den Schritten, um alle Fehlermeldungen im Zusammenhang mit der Pod-Bereitstellung zu überprüfen.

Listen Sie die Pods in Ihrem Cluster auf. Ein Pod wurde erfolgreich bereitgestellt, wenn er den Status Running (Aktiv) anzeigt.
```
oc get pods
```
Rufen Sie die Details Ihres Pods ab und überprüfen Sie alle Fehlernachrichten, die im Abschnitt Events Ihrer CLI-Ausgabe angezeigt werden.
```
oc describe pod <pod_name>
```
Rufen Sie die Protokolle für Ihren Pod ab und überprüfen Sie alle Fehlernachrichten.
```
oc logs <pod_name>
```
Lesen Sie die ODF-Fehlerbehebungsdokumentation für Schritte zur Behebung häufiger Fehler.

Ihre App-Pod erneut starten

Einige Probleme können behoben werden, indem Sie Ihre Pods erneut starten und erneut implementieren. Führen Sie die folgenden Schritte aus, um einen bestimmten Pod erneut zu implementieren.

Wenn Ihr Pod Teil einer Bereitstellung ist, löschen Sie den Pod und lassen Sie die Bereitstellung den Pod erneut erstellen. Wenn Ihr Pod nicht Teil einer Bereitstellung ist, löschen Sie den Pod und wenden Sie Ihre Konfigurationsdatei für Pods erneut an.
1. Löschen Sie den Pod.
```
oc delete pod <pod_name>
```
  Beispielausgabe
```
pod "nginx" deleted
```
2. Wenden Sie die Konfigurationsdatei erneut an, um den Pod erneut bereitzustellen.
```
oc apply -f <app.yaml>
```
  Beispielausgabe
```
pod/nginx created
```
Wenn Sie Ihren Pod erneut starten, beheben Sie das Problem nicht, indem Sie Ihre Workerknoten erneut laden.
Überprüfen Sie, ob Sie die neueste Version des IBM Cloud- und IBM Cloud Kubernetes Service-Plug-ins verwenden.
```
ibmcloud update
```
```
ibmcloud plugin repo-plugins
```
```
ibmcloud plugin update
```

Überprüfen Sie, ob der Speichertreiber und die Plug-in-Pods den betriebsbereiten Status Running anzeigen

Führen Sie die entsprechenden Schritte aus, um den Status Ihres Speichertreibers und Ihrer Plug-in-Pods abzurufen und alle Fehlernachrichten zu überprüfen.

Listen Sie die Pods im Projekt kube-system auf.
```
oc get pods -n kube-system
```
Wenn die Speichertreiber- und Plug-in-Pods keinen Aktiv-Status aufweisen, rufen Sie weitere Details des Pods ab, um die Fehlerursache zu finden. Je nach Status Ihres Pods können die folgenden Befehle fehlschlagen.
1. Rufen Sie die Namen der Container ab, die im Treiberpod ausgeführt werden.
```
kubectl describe pod <pod_name> -n kube-system
```
2. Exportieren Sie die Protokolle aus dem Pod für Treiber in eine Datei logs.txt auf Ihrer lokalen Maschine.
```
oc logs <pod_name> -n kube-system > logs.txt
```
3. Überprüfen Sie die Protokolldatei.
```
cat logs.txt
```
Überprüfen Sie die neuesten Protokolle auf irgendwelche Fehlernachrichten. Lesen Sie die ODF-Fehlerbehebungsdokumentation für Schritte zur Behebung häufiger Fehler.

oc CLI-Version wird überprüft und aktualisiert

Wenn Sie eine oc-Version für die CLI (Befehlszeilenschnittstelle) verwenden, die nicht mindestens mit der Major-Minor-Version Ihres Clusters übereinstimmt, können unerwartete Ergebnisse auftreten. Zum Beispiel unterstützt Kubernetes keine oc Client-Versionen, die 2 oder mehr Versionen von der Server-Version abweichen (n +/- 2).

Vergewissern Sie sich, dass die oc-CLI-Version, die Sie auf Ihrem lokalen Rechner ausführen, mit der Kubernetes-Version übereinstimmt, die in Ihrem Cluster installiert ist. Zeigen Sie die oc-CLI-Version an, die in Ihrem Cluster und Ihrem lokalen Rechner installiert ist.

oc version

Beispielausgabe:

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.33", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.33+IKS", GitCommit:"e15454c2216a73b59e9a059fd2def4e6712a7cf0", GitTreeState:"clean", BuildDate:"2019-04-01T10:08:07Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

Die CLI-Versionen stimmen überein, wenn in GitVersion für den Client und den Server dieselbe Version angezeigt wird. Sie können den +IKS-Teil der Version für den Server ignorieren.

Wenn die oc CLI-Versionen auf Ihrem lokalen Rechner und Ihrem Cluster nicht übereinstimmen, aktualisieren Sie entweder Ihren Cluster oder installieren Sie eine andere CLI-Version auf Ihrem lokalen Rechner.

Debuggen Ihrer ODF-Ressourcen

Beschreiben Sie Ihre ODF-Ressourcen und überprüfen Sie die Befehlsausgaben für alle Fehlernachrichten.

Listen Sie den Namen Ihres ODF-Clusters auf.

oc get ocscluster

Beispielausgabe:

NAME             AGE
ocscluster-vpc   71d

Beschreiben Sie den Speichercluster und überprüfen Sie den Abschnitt Events der Ausgabe für alle Fehlernachrichten.
```
oc describe ocscluster <ocscluster-name>
```

Listen Sie die ODF-Pods im Namensbereich kube-system auf und überprüfen Sie, ob sie sich im betriebsbereiten Status Running befinden.

oc get pods -n kube-system

Beispielausgabe

NAME                                                   READY   STATUS    RESTARTS   AGE
ibm-keepalived-watcher-5g2gs                           1/1     Running   0          7d21h
ibm-keepalived-watcher-8l4ld                           1/1     Running   0          7d21h
ibm-keepalived-watcher-mhkh5                           1/1     Running   0          7d21h
ibm-master-proxy-static-10.240.128.10                  2/2     Running   0          71d
ibm-master-proxy-static-10.240.128.11                  2/2     Running   0          71d
ibm-master-proxy-static-10.240.128.12                  2/2     Running   0          71d
ibm-ocs-operator-controller-manager-55667f4d68-md4zb   1/1     Running   8          15d
ibm-vpc-block-csi-controller-0                         4/4     Running   0          48d
ibm-vpc-block-csi-node-6gnwv                           3/3     Running   0          48d
ibm-vpc-block-csi-node-j2h62                           3/3     Running   0          48d
ibm-vpc-block-csi-node-xpwpf                           3/3     Running   0          48d
vpn-5b8694cdb-pll6z

Beschreiben Sie den Pod ibm-ocs-operator-controller-manager und überprüfen Sie den Abschnitt Events in der Ausgabe für alle Fehlernachrichten.
```
oc describe pod <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
```
Überprüfen Sie die Protokolle des ibm-ocs-operator-controller-manager.
```
oc logs <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
```
Beschreiben Sie NooBaa und überprüfen Sie den Abschnitt Events der Ausgabe auf eventuelle Fehlermeldungen.
```
oc describe noobaa -n openshift-storage
```

Beschreiben Sie den Pod ibm-storage-metrics-agent und überprüfen Sie den Abschnitt Events in der Ausgabe für alle Fehlernachrichten.

oc get pods -n kube-system -l name=ibm-storage-metrics-agent

NAME                                                  READY   STATUS    RESTARTS   AGE ibm-storage-metrics-agent-8685869cc6-79qzq

Überprüfen Sie die Protokolle in der ibm-storage-metrics-agent.
```
oc logs ibm-storage-metrics-agent-xxx -n kube-system
```
Beschreiben Sie die ocscluster und überprüfen Sie die Ausgabe auf Fehlernachrichten.
```
oc describe ocscluster <ocscluster-name> -n openshift-storage
```

Erfassen Sie Daten zum Cluster mit dem Befehl oc adm must-gather.

oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:latest --dest-dir=ocs_mustgather

Stellen Sie für klassische Cluster oder Satellite-Cluster, die lokale Datenträger auf dem Workerknoten verwenden, sicher, dass der disk-by-id für die Datenträger, die Sie für die Parameter osd-device-path und mon-device-path verwendet haben, auf den Workerknoten vorhanden ist. Weitere Informationen zum Abrufen dieser Datenträger-IDs finden Sie unter Gerätedetails erfassen
Suchen Sie in der Dokumentation zur Fehlerbehebung nach Schritten zur Behebung gängiger Fehler.