7.7. Enquêter sur les questions relatives aux nacelles
OpenShift Container Platform exploite le concept Kubernetes de pod, qui est un ou plusieurs conteneurs déployés ensemble sur un hôte. Un pod est la plus petite unité de calcul qui peut être définie, déployée et gérée sur OpenShift Container Platform 4.12.
Une fois qu'un pod est défini, il est affecté à l'exécution sur un nœud jusqu'à ce que ses conteneurs quittent le système ou jusqu'à ce qu'il soit supprimé. En fonction de la politique et du code de sortie, les pods sont soit supprimés après la sortie, soit conservés afin que leurs journaux puissent être consultés.
La première chose à vérifier en cas de problème avec un pod est son état. Si une défaillance explicite du pod s'est produite, observez l'état d'erreur du pod pour identifier les problèmes spécifiques liés à l'image, au conteneur ou au réseau du pod. Concentrez la collecte des données de diagnostic en fonction de l'état d'erreur. Examinez les messages d'événement du module, ainsi que les informations du journal du module et du conteneur. Diagnostiquer les problèmes de manière dynamique en accédant aux pods en cours d'exécution sur la ligne de commande, ou démarrer un pod de débogage avec un accès root basé sur la configuration de déploiement d'un pod problématique.
7.7.1. Comprendre les états d'erreur des pods
Les défaillances du pod renvoient des états d'erreur explicites qui peuvent être observés dans le champ status
de la sortie de oc get pods
. Les états d'erreur du pod couvrent les défaillances liées à l'image, au conteneur et au réseau de conteneurs.
Le tableau suivant fournit une liste des états d'erreur des pods ainsi que leur description.
État d'erreur du pod | Description |
---|---|
| Erreur générique de recherche d'images. |
| La recherche d'images a échoué et est interrompue. |
| Le nom de l'image spécifiée n'est pas valide. |
| L'inspection de l'image n'a pas abouti. |
|
|
| Une erreur HTTP a été rencontrée lors de la récupération d'une image à partir d'un registre. |
| Le conteneur spécifié n'est pas présent ou n'est pas géré par le kubelet, dans le pod déclaré. |
| L'initialisation du conteneur a échoué. |
| Aucun des conteneurs du pod n'a démarré avec succès. |
| Aucun des conteneurs de la nacelle n'a été tué avec succès. |
| Un conteneur s'est arrêté. Le kubelet ne tentera pas de le redémarrer. |
| Un conteneur ou une image a tenté de s'exécuter avec les privilèges de l'utilisateur root. |
| La création du bac à sable n'a pas abouti. |
| La configuration du bac à sable n'a pas été obtenue. |
| Le bac à sable d'un pod ne s'est pas arrêté avec succès. |
| L'initialisation du réseau a échoué. |
| La terminaison du réseau a échoué. |
7.7.2. Examen de l'état des nacelles
Vous pouvez interroger l'état des pods et les états d'erreur. Vous pouvez également interroger la configuration de déploiement associée à un pod et vérifier la disponibilité de l'image de base.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. -
Vous avez installé l'OpenShift CLI (
oc
). -
skopeo
est installé.
Procédure
Passer à un projet :
oc project <nom_du_projet>
Liste des pods en cours d'exécution dans l'espace de noms, ainsi que l'état des pods, les états d'erreur, les redémarrages et l'âge :
$ oc get pods
Déterminez si l'espace de noms est géré par une configuration de déploiement :
$ oc status
Si l'espace de noms est géré par une configuration de déploiement, le résultat comprend le nom de la configuration de déploiement et une référence à l'image de base.
Inspecter l'image de base référencée dans la sortie de la commande précédente :
skopeo inspect docker://<image_reference>
Si la référence de l'image de base n'est pas correcte, mettez à jour la référence dans la configuration du déploiement :
$ oc edit deployment/my-deployment
Lorsque la configuration du déploiement change à la sortie, la configuration sera automatiquement redéployée. Surveillez l'état du pod au fur et à mesure que le déploiement progresse, afin de déterminer si le problème a été résolu :
$ oc get pods -w
Examinez les événements de l'espace de noms pour y trouver des informations de diagnostic relatives aux défaillances des pods :
$ oc get events
7.7.3. Inspection des registres des gousses et des conteneurs
Vous pouvez consulter les journaux des pods et des conteneurs pour y trouver des avertissements et des messages d'erreur liés à des échecs explicites de pods. En fonction de la politique et du code de sortie, les journaux des pods et des conteneurs restent disponibles après l'arrêt des pods.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Your API service is still functional.
-
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Interroger les journaux pour un module spécifique :
oc logs <nom_du_pod>
Interroger les journaux d'un conteneur spécifique au sein d'un pod :
oc logs <nom_du_pod> -c <nom_du_conteneur>
Les journaux récupérés à l'aide des commandes
oc logs
précédentes sont composés de messages envoyés à stdout à l'intérieur des pods ou des conteneurs.Inspecter les grumes contenues dans
/var/log/
à l'intérieur d'une nacelle.Liste des fichiers journaux et des sous-répertoires contenus dans
/var/log
au sein d'un pod :oc exec <nom_du_pod> ls -alh /var/log
Interroger un fichier journal spécifique contenu dans
/var/log
au sein d'un pod :oc exec <nom_du_pod> cat /var/log/<chemin_vers_log>
Liste des fichiers journaux et des sous-répertoires contenus dans
/var/log
à l'intérieur d'un conteneur spécifique :oc exec <nom_du_pod> -c <nom_du_conteneur> ls /var/log
Interroger un fichier journal spécifique contenu dans
/var/log
à l'intérieur d'un conteneur spécifique :oc exec <nom_du_pod> -c <nom_du_conteneur> cat /var/log/<chemin_vers_log>
7.7.4. Accès aux pods en cours d'exécution
Vous pouvez passer en revue les pods en cours d'exécution de manière dynamique en ouvrant un shell à l'intérieur d'un pod ou en obtenant un accès au réseau par le biais d'une redirection de port.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Your API service is still functional.
-
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Entrez dans le projet qui contient le pod auquel vous souhaitez accéder. Cette opération est nécessaire car la commande
oc rsh
n'accepte pas l'option d'espace de noms-n
:oc project <namespace>
Démarrer un shell à distance dans un pod :
$ oc rsh <pod_name> 1
- 1
- Si un module a plusieurs conteneurs,
oc rsh
prend par défaut le premier conteneur, à moins que-c <container_name>
ne soit spécifié.
Lancer un shell à distance dans un conteneur spécifique au sein d'un pod :
oc rsh -c <container_name> pod/<pod_name>
Créer une session de transfert de port vers un port d'un pod :
$ oc port-forward <pod_name> <host_port>:<pod_port> 1
- 1
- Saisissez
Ctrl C
pour annuler la session de transfert de port.
7.7.5. Démarrage des pods de débogage avec accès root
Vous pouvez démarrer un pod de débogage avec un accès root, en fonction du déploiement ou de la configuration du déploiement d'un pod problématique. Les utilisateurs de pods s'exécutent généralement avec des privilèges non root, mais l'exécution de pods de dépannage avec des privilèges root temporaires peut s'avérer utile lors de l'investigation d'un problème.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Your API service is still functional.
-
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Démarrer un pod de débogage avec un accès root, sur la base d'un déploiement.
Obtenir le nom de déploiement d'un projet :
oc get deployment -n <nom_du_projet>
Démarrer un pod de débogage avec les privilèges root, en fonction du déploiement :
$ oc debug deployment/my-deployment --as-root -n <nom_du_projet>
Démarrer un pod de débogage avec un accès root, sur la base d'une configuration de déploiement.
Obtenir le nom de la configuration de déploiement d'un projet :
oc get deploymentconfigs -n <nom_du_projet>
Démarrer un pod de débogage avec les privilèges de root, en fonction de la configuration du déploiement :
$ oc debug deploymentconfig/my-deployment-configuration --as-root -n <nom_du_projet>
Vous pouvez ajouter -- <command>
aux commandes oc debug
précédentes pour exécuter des commandes individuelles dans un module de débogage, au lieu d'exécuter un shell interactif.
7.7.6. Copier des fichiers vers et depuis des pods et des conteneurs
Vous pouvez copier des fichiers vers et à partir d'un module pour tester les changements de configuration ou recueillir des informations de diagnostic.
Conditions préalables
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin
. - Your API service is still functional.
-
Vous avez installé l'OpenShift CLI (
oc
).
Procédure
Copier un fichier dans un pod :
$ oc cp <local_path> <pod_name>:/<path> -c <container_name> 1
- 1
- Le premier conteneur d'un pod est sélectionné si l'option
-c
n'est pas spécifiée.
Copier un fichier à partir d'un pod :
$ oc cp <pod_name>:/<path> -c <container_name><local_path> 1
- 1
- Le premier conteneur d'un pod est sélectionné si l'option
-c
n'est pas spécifiée.
NotePour que
oc cp
fonctionne, le binairetar
doit être disponible dans le conteneur.