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>

Überprüfen Sie die File Storage for ClassicFehlerbehebungsdokumentation auf Schritte zur Behebung häufiger Fehler.

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
    ```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 update

ibmcloud plugin repo-plugins

ibmcloud plugin update

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.

```sh {: pre}
    oc logs <pod_name> -n kube-system > logs.txt
    ```
3. Überprüfen Sie die Protokolldatei.

```sh {: pre}
    cat logs.txt
    ```

Überprüfen Sie die neuesten Protokolle auf irgendwelche Fehlernachrichten. Überprüfen Sie die File Storage for ClassicFehlerbehebungsdokumentation auf Schritte zur Behebung häufiger Fehler.

Ü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 WaitForFirstConsumer eingestellt 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
  

Lesen Sie die File Storage for Classic-Dokumentation zur Fehlerbehebung für Schritte zur Behebung allgemeiner File Storage for Classic-PVC-Fehler.

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.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 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 in Ihrem Cluster nicht übereinstimmen, aktualisieren Sie entweder Ihren Cluster oder installieren Sie eine andere CLI-Version auf Ihrem lokalen Rechner.