Debugging für Block Storage for Classic-Fehler
Überprüfen Sie die Optionen zur Fehlersuche in Block Storage for Classic und finden Sie die Grundursachen von Fehlern.
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>
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.
- Löschen Sie den Pod.
oc delete pod <pod_name> ``` Beispielausgabe ```sh {: screen} pod "nginx" deleted ``` 2. Wenden Sie die Konfigurationsdatei erneut an, um den Pod erneut bereitzustellen. ```sh {: pre} oc apply -f <app.yaml> ``` Beispielausgabe ```sh {: pre} pod/nginx created ``` -
Wenn durch den Neustart des Pods das Problem nicht behoben wird, laden Sie Ihre Workerknoten erneut.
-
Überprüfen Sie, ob Sie die neueste Version des IBM Cloud- und IBM Cloud Kubernetes Service-Plug-ins verwenden.
ibmcloud updateibmcloud plugin repo-pluginsibmcloud 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-systemauf.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.
- 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. ```sh {: pre} oc logs <pod_name> -n kube-system > logs.txt ``` 3. Überprüfen Sie die Protokolldatei. ```sh {: pre} cat logs.txt ``` -
Wenn die Speichertreiber- und Plug-in-Pods keinen Aktiv-Status aufweisen, rufen Sie weitere Details des Pods ab, um die Fehlerursache zu finden. Abhängig vom Status Ihres Pods können Sie möglicherweise nicht alle folgenden Befehle ausführen.
- Rufen Sie die Namen der Container ab, die im Treiberpod ausgeführt werden.
kubectl get pod ibm-vpc-block-csi-controller-0 -n kube-system -o jsonpath="{.spec['containers','initContainers'][*].name}" | tr -s '[[:space:]]' '\n' ``` **Beispielausgabe für Block Storage for VPC** ```sh {: screen} csi-provisioner csi-attacher liveness-probe iks-vpc-block-driver ``` 2. Exportieren Sie die Containerprotokolle vom Treiber-Pod in eine `logs.txt`-Datei auf Ihrem lokalen Gerät. ```sh {: pre} oc logs <pod_name> -n kube-system -c <container_name> > logs.txt ``` -
Überprüfen Sie die neuesten Protokolle auf irgendwelche Fehlernachrichten. Überprüfen Sie die Block Storage for ClassicFehlerbehebungsdokumentation auf Schritte zur Behebung häufiger Fehler.
Es wird überprüft, ob Ihr PVC erfolgreich bereitgestellt wurde.
Folgen Sie den Schritten, um den Status Ihres PVC und alle Fehlernachrichten zu überprüfen.
-
Überprüfen Sie den Status Ihres PVC. Ein PVC wurde erfolgreich bereitgestellt, wenn er den Status Bound (Gebunden) anzeigt.
oc get pvc-
Wenn das PVC den Status gebundenanzeigt, wird das PVC erfolgreich bereitgestellt.
Beispielausgabe
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE silver-pvc Bound pvc-4b881a6b-ada8-4a44-b568-fe909107d756 24Gi RWX ibmc-file-silver 7m29s -
Wenn der Status des PVC den Wartezustand Pending anzeigt, beschreiben Sie den PVC und überprüfen Sie den Abschnitt Ereignisse der Ausgabe für alle Warnungen oder Fehlernachrichten. Beachten Sie, dass PVCs, die auf Speicherklassen verweisen, deren Datenträger-Bindungsmodus auf
WaitForFirstConsumereingestellt ist, so lange im Wartezustand Pending bleiben, bis ein App-Pod bereitgestellt wird, der den PVC verwendet.oc describe pvc <pvc_name>Beispielausgabe
Name: local-pvc Namespace: default StorageClass: sat-local-file-gold Status: Pending Volume: Labels: <none> Annotations: <none> Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: VolumeMode: Filesystem Mounted By: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 60s (x42 over 11m) persistentvolume-controller storageclass.storage.k8s.io "sat-local-file-gold" not found
-
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. Beispiel: Kubernetes unterstützt keine oc Client-Versionen, die zwei 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 dieoc-CLI-Version an, die in Ihrem Cluster und Ihrem lokalen Rechner installiert ist.oc versionBeispielausgabe:
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.35", 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.35+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
GitVersionfü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
ocCLI-Versionen auf Ihrem lokalen Rechner und in Ihrem Cluster nicht übereinstimmen, aktualisieren Sie entweder Ihren Cluster oder installieren Sie eine andere CLI-Version auf Ihrem lokalen Rechner.
Block Storage for Classic-Treiber überprüfen und aktualisieren
-
Für Block Storage for VPC müssen Sie überprüfen, ob Sie über die neueste Version des Block Storage for VPC-Cluster-Add-ons verfügen.
-
Für Block Storage for Classic auf klassischen Clustern müssen Sie sich vergewissern, dass Sie die neueste Helm-Diagrammversion für das Plug-in installiert haben.
- Aktualisieren Sie Ihre Helm-Chart-Repositorys.
helm repo update ``` 2. Listen Sie die Helm-Charts im Repository auf. ```sh {: pre} helm search repo iks-charts | grep block-storage-plugin ``` Beispielausgabe ```sh {: screen} iks-charts-stage/ibmcloud-block-storage-plugin 1.5.0 A Helm chart for installing ibmcloud block storage plugin iks-charts/ibmcloud-block-storage-plugin 1.5.0 A Helm chart for installing ibmcloud block storage plugin ``` 3. Listen Sie die installierten Helm-Charts in Ihrem Cluster auf und vergleichen Sie die Version, die Sie installiert haben, mit der Version, die verfügbar ist. ```sh {: pre} helm list --all-namespaces ``` 4. Wenn eine neuere Version verfügbar ist, installieren Sie diese Version. Anweisungen hierzu finden Sie unter [Aktualisieren des IBM Cloud-Blockspeicher-Plug-ins](/docs/openshift?topic=openshift-vpc-block#vpc-addon-update).