Debug degli errori di OpenShift Data Foundation

Esaminare le opzioni per eseguire il debug di ODF e individuare le cause principali di eventuali errori.

Verifica che il pod che monta l'istanza di archiviazione sia stato distribuito correttamente

Attieniti alla procedura per esaminare eventuali messaggi di errore correlati alla distribuzione del pod.

  1. Elenca i pod nel tuo cluster. Un pod è stato distribuito correttamente se lo stato del pod è Running.

    oc get pods
    
  2. Verifica i dettagli del tuo pod ed esamina eventuali messaggi di errore visualizzati nella sezione "Eventi " dell'output della CLI.

    oc describe pod <pod_name>
    
  3. Richiama i log per il tuo pod e riesamina eventuali messaggi di errore.

    oc logs <pod_name>
    
  4. Consultare la documentazione per la risoluzione dei problemi ODF per la procedura di risoluzione degli errori comuni.

Riavvio del tuo pod dell'applicazione

Alcuni problemi possono essere risolti riavviando e ridistribuendo i tuoi pod. Attieniti alla procedura per ridistribuire un pod specifico.

  1. Se il tuo pod fa parte di una distribuzione, elimina il pod e lascia che la distribuzione lo ricrei. Se il pod non fa parte di una distribuzione, elimina il pod e applica nuovamente il suo file di configurazione.

    1. Elimina il pod.
        oc delete pod <pod_name>
        ```
        Output di esempio
        ```sh {: screen}
        pod "nginx" deleted
        ```
    2. Riapplica il file di configurazione per ridistribuire il pod.
    ```sh {: pre}
        oc apply -f <app.yaml>
        ```
        Output di esempio
        ```sh {: pre}
        pod/nginx created
        ```
    
  2. Se il riavvio del pod non risolve il problema, ricarica i nodi di lavoro.

  3. Accertati di utilizzare la versione più recente di IBM Cloud e del plug-in IBM Cloud Kubernetes Service.

    ibmcloud update
    
    ibmcloud plugin repo-plugins
    
    ibmcloud plugin update
    

Verificare che il driver di archiviazione e i pod plug-in presentino lo stato “In esecuzione

Attieniti alla procedura per controllare lo stato del tuo driver di archiviazione e dei pod del plug-in ed esaminare eventuali messaggi di errore.

  1. Elenca i pod nel progetto kube-system.

    oc get pods -n kube-system
    
  2. Se il driver di archiviazione e i pod plug-in non mostrano lo stato " In esecuzione ", ottenere ulteriori dettagli sul pod per individuare la causa principale. A seconda dello stato del tuo pod, i seguenti comandi potrebbero avere esito negativo.

    1. Ottieni i nomi dei contenitori che vengono eseguiti nel pod del driver.
        kubectl describe pod POD_NAME -n kube-system
        ```
    2. Esporta i log dal pod del driver in un file `logs.txt` sulla tua macchina locale.
    
    ```sh {: pre}
        oc logs <pod_name> -n kube-system > logs.txt
        ```
    3. Riesamina il file di log.
    
    ```sh {: pre}
        cat logs.txt
        ```
    
    
  3. Controllare i log più recenti per eventuali messaggi di errore. Consultare la documentazione per la risoluzione dei problemi ODF per la procedura di risoluzione degli errori comuni.

Controllo e aggiornamento della versione della CLI oc

Se si utilizza una versione della CLI di oc che non corrisponde almeno alla versione major.minor del proprio cluster, si potrebbero verificare risultati imprevisti. Ad esempio, Kubernetes non supporta le versioni client di oc che presentano una differenza di 2 o più versioni rispetto alla versione server (n ± 2).

  1. Verifica che la versione della CLI di oc in esecuzione sul tuo computer locale corrisponda alla versione di Kubernetes installata nel tuo cluster. Visualizza la versione della CLI di oc installata nel tuo cluster e sul tuo computer locale.

    oc version
    

    Output di esempio:

    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"}
    

    Le versioni delle CLI corrispondono se la versione visualizzata per il client e per il server in GitVersion è la stessa. Puoi ignorare la parte +IKS della versione del server.

  2. Se le versioni della CLI di oc sul tuo computer locale e sul tuo cluster non corrispondono, aggiorna il cluster oppure installa una versione diversa della CLI sul tuo computer locale.

Debug delle risorse ODF

Descrivere le risorse ODF ed esaminare gli output del comando per eventuali messaggi di errore.

  1. Elencare il nome del cluster ODF.

    oc get ocscluster
    

    Output di esempio:

    NAME             AGE
    ocscluster-vpc   71d
    
  2. Descrivere il cluster di archiviazione ed esaminare la sezione Events dell'output per eventuali messaggi di errore.

    oc describe ocscluster <ocscluster-name>
    
  3. Elencare i pod ODF nello spazio dei nomi kube-system e verificare che siano Running.

    oc get pods -n kube-system
    

    Output di esempio

    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
    
  4. Descrivi il pod ibm-ocs-operator-controller-manager e rivedi la sezione Events nell'output per eventuali messaggi di errore.

    oc describe pod <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
    
  5. Esaminare i log di ibm-ocs-operator-controller-manager.

    oc logs <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
    
  6. Descrivere NooBaa ed esaminare la sezione Events dell'output per eventuali messaggi di errore.

    oc describe noobaa -n openshift-storage
    
  7. Descrivi il pod ibm-storage-metrics-agent e rivedi la sezione Events nell'output per eventuali messaggi di errore.

    oc get pods -n kube-system -l name=ibm-storage-metrics-agent
    
    NAME                                                  READY   STATUS    RESTARTS   AGE ibm-storage-metrics-agent-8685869cc6-79qzq   
    
  8. Esaminare i log da ibm-storage-metrics-agent.

    oc logs ibm-storage-metrics-agent-xxx -n kube-system
    
  9. Descrivere ocscluster ed esaminare l'output per i messaggi di errore.

    oc describe ocscluster <ocscluster-name> -n openshift-storage
    
  10. Raccogliere i dati sul cluster utilizzando il comando oc adm must-gather.

    oc adm must-gather --image=registry.redhat.io/ocs4/ocs-must-gather-rhel8:latest --dest-dir=ocs_mustgather
    
  11. Per i cluster classici o i cluster Satellite che utilizzano volumi locali sul nodo di lavoro, assicurati che il disk-by-id per i volumi che hai utilizzato per i parametri osd-device-path e mon-device-path esista sui nodi di lavoro. Per ulteriori informazioni su come recuperare questi ID volume, vedi Raccolta dei dettagli del dispositivo

  12. Consultare la documentazione per la risoluzione dei problemi per la procedura per risolvere gli errori comuni.