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.

Tableau 7.3. États d'erreur du pod
État d'erreur du podDescription

ErrImagePull

Erreur générique de recherche d'images.

ErrImagePullBackOff

La recherche d'images a échoué et est interrompue.

ErrInvalidImageName

Le nom de l'image spécifiée n'est pas valide.

ErrImageInspect

L'inspection de l'image n'a pas abouti.

ErrImageNeverPull

PullPolicy est défini sur NeverPullImage et que l'image cible n'est pas présente localement sur l'hôte.

ErrRegistryUnavailable

Une erreur HTTP a été rencontrée lors de la récupération d'une image à partir d'un registre.

ErrContainerNotFound

Le conteneur spécifié n'est pas présent ou n'est pas géré par le kubelet, dans le pod déclaré.

ErrRunInitContainer

L'initialisation du conteneur a échoué.

ErrRunContainer

Aucun des conteneurs du pod n'a démarré avec succès.

ErrKillContainer

Aucun des conteneurs de la nacelle n'a été tué avec succès.

ErrCrashLoopBackOff

Un conteneur s'est arrêté. Le kubelet ne tentera pas de le redémarrer.

ErrVerifyNonRoot

Un conteneur ou une image a tenté de s'exécuter avec les privilèges de l'utilisateur root.

ErrCreatePodSandbox

La création du bac à sable n'a pas abouti.

ErrConfigPodSandbox

La configuration du bac à sable n'a pas été obtenue.

ErrKillPodSandbox

Le bac à sable d'un pod ne s'est pas arrêté avec succès.

ErrSetupNetwork

L'initialisation du réseau a échoué.

ErrTeardownNetwork

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

  1. Passer à un projet :

    oc project <nom_du_projet>
    Copy to Clipboard
  2. 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
    Copy to Clipboard
  3. Déterminez si l'espace de noms est géré par une configuration de déploiement :

    $ oc status
    Copy to Clipboard

    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.

  4. Inspecter l'image de base référencée dans la sortie de la commande précédente :

    skopeo inspect docker://<image_reference>
    Copy to Clipboard
  5. 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
    Copy to Clipboard
  6. 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
    Copy to Clipboard
  7. 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
    Copy to Clipboard

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

  1. Interroger les journaux pour un module spécifique :

    oc logs <nom_du_pod>
    Copy to Clipboard
  2. Interroger les journaux d'un conteneur spécifique au sein d'un pod :

    oc logs <nom_du_pod> -c <nom_du_conteneur>
    Copy to Clipboard

    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.

  3. Inspecter les grumes contenues dans /var/log/ à l'intérieur d'une nacelle.

    1. 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
      Copy to Clipboard
    2. 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>
      Copy to Clipboard
    3. 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
      Copy to Clipboard
    4. 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>
      Copy to Clipboard

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

  1. 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>
    Copy to Clipboard
  2. Démarrer un shell à distance dans un pod :

    $ oc rsh <pod_name>  
    1
    Copy to Clipboard
    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é.
  3. Lancer un shell à distance dans un conteneur spécifique au sein d'un pod :

    oc rsh -c <container_name> pod/<pod_name>
    Copy to Clipboard
  4. Créer une session de transfert de port vers un port d'un pod :

    $ oc port-forward <pod_name> <host_port>:<pod_port>  
    1
    Copy to Clipboard
    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

  1. Démarrer un pod de débogage avec un accès root, sur la base d'un déploiement.

    1. Obtenir le nom de déploiement d'un projet :

      oc get deployment -n <nom_du_projet>
      Copy to Clipboard
    2. 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>
      Copy to Clipboard
  2. Démarrer un pod de débogage avec un accès root, sur la base d'une configuration de déploiement.

    1. Obtenir le nom de la configuration de déploiement d'un projet :

      oc get deploymentconfigs -n <nom_du_projet>
      Copy to Clipboard
    2. 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>
      Copy to Clipboard
Note

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

  1. Copier un fichier dans un pod :

    $ oc cp <local_path> <pod_name>:/<path> -c <container_name>  
    1
    Copy to Clipboard
    1
    Le premier conteneur d'un pod est sélectionné si l'option -c n'est pas spécifiée.
  2. Copier un fichier à partir d'un pod :

    $ oc cp <pod_name>:/<path>  -c <container_name><local_path>  
    1
    Copy to Clipboard
    1
    Le premier conteneur d'un pod est sélectionné si l'option -c n'est pas spécifiée.
    Note

    Pour que oc cp fonctionne, le binaire tar doit être disponible dans le conteneur.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat