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>
  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
  3. 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.

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

    skopeo inspect docker://<image_reference>
  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
  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
  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

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>
  2. 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.

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

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>
  2. 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é.
  3. Lancer un shell à distance dans un conteneur spécifique au sein d'un pod :

    oc rsh -c <container_name> pod/<pod_name>
  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
    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>
    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>
  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>
    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>
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
    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
    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.

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.

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 leBlog 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.

© 2024 Red Hat, Inc.