Warum ändert sich der Blockspeicher in einen schreibgeschützten Speicher?

Fehlerbehebung bei Blockspeichervolumes, die schreibgeschützt werden.

Virtuelle private Cloud Klassische Infrastruktur

Sie bemerken möglicherweise die folgenden Symptome:

• Wenn Sie den Befehl oc get pods -o wide ausführen, können Sie erkennen, dass mehrere Pods auf demselben Workerknoten im Status ContainerCreating oder CrashLoopBackOff blockiert sind. Alle diese Pods verwenden dieselbe Blockspeicherinstanz.
• Wenn Sie den Befehl oc describe pod ausführen, sehen Sie den folgenden Fehler im Abschnitt Events (Ereignisse): MountVolume.SetUp failed for volume ... read-only.

Wenn ein Netzfehler auftritt, während ein Pod auf einen Datenträger schreibt, schützt die IBM Cloud-Infrastruktur die Daten auf dem Datenträger gegen Beschädigung, indem der Datenträger in den Lesezugriffsmodus versetzt wird. Pods, die diesen Datenträger verwenden, können nicht weiter auf den Datenträger schreiben und schlagen fehl.

Überprüfen Sie die Plug-in-Version, erstellen Sie Ihre App neu und starten Sie Ihren Worker-Knoten sicher neu.

1. Prüfen Sie die Version des IBM Cloud Block Storage-Plug-ins, das in Ihrem Cluster installiert ist.

   helm list --all-namespaces
   

2. Überprüfen Sie, ob Sie die neueste Version des IBM Cloud Block Storage-Plug-ins verwenden. Ist dies nicht der Fall, aktualisieren Sie Ihr Plug-in.
3. Wenn Sie eine Kubernetes-Bereitstellung für Ihren Pod verwendet haben, starten Sie den fehlgeschlagenen Pod erneut, indem Sie den Pod entfernen und Kubernetes den Pod erneut erstellen lassen. Wenn Sie keine Bereitstellung verwendet haben, rufen Sie die YAML-Datei ab, die zum Erstellen Ihres Pods verwendet wurde, indem Sie oc get pod <pod_name> -o yaml >pod.yaml ausführen. Löschen Sie anschließend den Pod und erstellen Sie ihn neu.

   oc delete pod <pod_name>
   

4. Prüfen Sie, ob die erneute Erstellung Ihres Pods das Problem behoben hat. Falls nicht, laden Sie den Workerknoten neu.
   1. Ermitteln Sie den Workerknoten, auf dem Ihr Pod ausgeführt wird, und notieren Sie die private IP-Adresse, die Ihrem Workerknoten zugeordnet ist.

       oc describe pod <pod_name> | grep Node
       ```
       Beispielausgabe:
       ```sh {: screen}
       Node:               10.75.XX.XXX/10.75.XX.XXX
       Node-Selectors:  <none>
       ```
   2. Rufen Sie die **ID** Ihres Workerknotens ab, indem Sie die private IP-Adresse aus dem vorherigen Schritt verwenden.
   ```sh {: pre}
       ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID
       ```
   3. [Laden Sie den Workerknoten sicher erneut](/docs/openshift?topic=openshift-kubernetes-service-cli#worker-reload-cli).