Débogage des échecs liés à OpenShift Data Foundation

Passez en revue les options permettant de déboguer ODF et d'identifier les causes premières des échecs.

Procédure visant à vérifier si le pod qui monte votre instance de stockage est correctement déployé

Suivez la procédure ci-dessous pour passer en revue les éventuels messages d'erreur liés au déploiement du pod.

Affichez la liste des pods de votre cluster. Un pod est correctement déployé s'il est à l'état En cours d'exécution.
```
oc get pods
```
Obtenez les détails relatifs à votre pod et passez en revue des messages d'erreur éventuels qui s'affichent dans la section Events de la sortie de l'interface CLI.
```
oc describe pod <pod_name>
```
Extrayez les journaux relatifs à votre pod et consultez les messages d'erreur qu'ils contiennent le cas échéant.
```
oc logs <pod_name>
```
Passez en revue la documentation sur le traitement des incidents pour ODF afin de connaître la procédure de résolution des erreurs courantes.

Redémarrage de votre pod d'application

Certains problèmes peuvent être résolus en redémarrant et redéployant les pods. Suivez la procédure ci-dessous pour redéployer un pod spécifique.

Si votre pod fait partie d'un déploiement, supprimez-le et laissez le déploiement le régénérer. Si votre pod ne fait pas partie d'un déploiement, supprimez-le et réappliquez votre fichier de configuration de pod.

Supprimez le pod.

    oc delete pod <pod_name>
    ```
    Exemple de sortie
    ```sh {: screen}
    pod "nginx" deleted
    ```
2. Réappliquez le fichier de configuration pour redéployer le pod.
```sh {: pre}
    oc apply -f <app.yaml>
    ```
    Exemple de sortie
    ```sh {: pre}
    pod/nginx created
    ```

Si le redémarrage de votre pod ne résout pas le problème, rechargez vos noeuds worker.
Vérifiez que vous utilisez la dernière version du plug-in IBM Cloud et IBM Cloud Kubernetes Service.
```
ibmcloud update
```
```
ibmcloud plugin repo-plugins
```
```
ibmcloud plugin update
```

Procédure visant à vérifier que les pods de pilote de stockage et de plug-in sont à l'état En cours d'exécution

Suivez la procédure ci-dessous pour vérifier le statut de votre pilote de stockage et des pods du plug-in, et recherchez les messages d'erreur éventuels.

Répertoriez les pods dans le projet kube-system.
```
oc get pods -n kube-system
```

Si le pilote de stockage et les gousses de plug-in n'affichent pas le statut Exécution, obtenez plus de détails sur le pod pour trouver la cause principale. Selon l'état de votre pod, les commandes suivantes peuvent échouer.

Obtenez les noms des conteneurs qui s'exécutent dans le pod de pilote.

    kubectl describe pod POD_NAME -n kube-system
    ```
2. Exportez les journaux du pod de pilote dans un fichier `logs.txt` sur votre machine locale.

```sh {: pre}
    oc logs <pod_name> -n kube-system > logs.txt
    ```
3. Examinez le fichier journal.

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

Recherchez les messages d'erreur éventuels dans les derniers journaux. Passez en revue la documentation sur le traitement des incidents pour ODF afin de connaître la procédure de résolution des erreurs courantes.

Vérification et mise à jour de la version CLI oc

Si vous utilisez une version d'interface de ligne de commande oc qui ne correspond pas au moins à la version principale.secondaire de votre cluster, vous risquez d'obtenir des résultats inattendus. Par exemple, Kubernetes ne prend pas en charge les versions client oc dont le numéro de version diffère de deux versions ou plus par rapport à la version serveur (n +/- 2).

Vérifiez que la version de l'interface de ligne de commande oc que vous exécutez sur votre machine locale correspond à la version Kubernetes qui est installée dans votre cluster. Affichez la version de l'interface de ligne de commande oc qui est installée dans votre cluster et sur votre machine locale.
```
oc version
```
Exemple de sortie :
```
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"}
```
Les versions de l'interface de ligne de commande correspondent si la même version est visible dans GitVersion pour le client et le serveur. Vous pouvez ignorer la partie +IKS de la version du serveur.
Si les versions de l'interface CLI oc sur votre machine locale et sur votre cluster ne correspondent pas, mettez à jour votre cluster ou installez une autre version de l'interface CLI sur votre machine locale.

Débogage de vos ressources ODF

Décrivez vos ressources ODF et passez en revue les sorties de commande pour tous les messages d'erreur.

Affichez le nom de votre cluster ODF.

oc get ocscluster

Exemple de sortie :

NAME             AGE
ocscluster-vpc   71d

Décrivez le cluster de stockage et consultez les messages d'erreur dans la section Events de la sortie.
```
oc describe ocscluster <ocscluster-name>
```

Répertoriez les pods ODF dans l'espace de noms kube-system et vérifiez qu'ils sont à l'état Running

oc get pods -n kube-system

Exemple de sortie

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

Décrivez le pod ibm-ocs-operator-controller-manager et consultez les messages d'erreur dans la section Events de la sortie.
```
oc describe pod <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system
```

Examinez les journaux d'ibm-ocs-operator-controller-manager.

oc logs <ibm-ocs-operator-controller-manager-a1a1a1a> -n kube-system

Décrivez NooBaa et consultez les messages d'erreur dans la section Events de la sortie.
```
oc describe noobaa -n openshift-storage
```

Décrivez le pod ibm-storage-metrics-agent et consultez les messages d'erreur dans la section Events de la sortie.

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

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

Consultez les journaux à partir de ibm-storage-metrics-agent.
```
oc logs ibm-storage-metrics-agent-xxx -n kube-system
```
Décrivez le fichier ocscluster et examinez la sortie des messages d'erreur.
```
oc describe ocscluster <ocscluster-name> -n openshift-storage
```

Rassembla des données sur le cluster à l'aide de la commande oc adm must-gather.

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

Pour les clusters classiques ou les clusters Satellite qui utilisent des volumes locaux sur le noeud de travail, vérifiez que disk-by-id pour les volumes utilisés pour les paramètres osd-device-path et mon-device-path existe sur les noeuds de travail. Pour plus d'informations sur l'extraction de ces ID de volume, voir Collecte des détails de l'unité
Consultez la documentation d'identification et de résolution des incidents pour résoudre les erreurs courantes.