Débogage des échecs Portworx

Passez en revue les options permettant de déboguer Portworx 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>
```
Consultez la documentation liée au traitement des incidents de Portworx pour connaître la procédure à suivre afin de corriger les 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
```

Vérification visant à s'assurer que les pods de pilote de stockage Portworx et de plug-in sont à l'état En cours d'exécution (Running).

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 | grep `portworx\|stork`

Exemple de sortie :

portworx-594rw                          1/1       Running     0          20h
portworx-rn6wk                          1/1       Running     0          20h
portworx-rx9vf                          1/1       Running     0          20h
stork-6b99cf5579-5q6x4                  1/1       Running     0          20h
stork-6b99cf5579-slqlr                  1/1       Running     0          20h
stork-6b99cf5579-vz9j4                  1/1       Running     0          20h
stork-scheduler-7dd8799cc-bl75b         1/1       Running     0          20h
stork-scheduler-7dd8799cc-j4rc9         1/1       Running     0          20h
stork-scheduler-7dd8799cc-knjwt         1/1       Running     0          20h

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 le statut de votre pod, il se peut que vous ne soit pas en mesure d'exécuter toutes les commandes suivantes.
1. 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. Consultez la documentation liée au traitement des incidents de Portworx pour connaître la procédure à suivre afin de corriger les 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 d' oc qui présentent un écart 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 d' oc s 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.

Mise à jour des chartes Helm

Recherchez la dernière version de la charte Helm.
Répertoriez les chartes Helm installées dans votre cluster et comparez la version que vous avez installée avec la version la plus récente.
```
helm list --all-namespaces
```
Si une version plus récente est disponible, installez la nouvelle version. Pour obtenir des instructions, voir Mise à jour de Portworx dans votre cluster.