Etape 1 : Obtenez l'état du noeud worker

Si votre cluster est à l'état Critical, Delete failed ou Warning, ou s'il reste bloqué à l'état Pending, vérifiez l'état de vos noeuds worker.

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

Etape 2 : Vérifiez l'état du noeud worker

Consultez les zones State et Status correspondant à chaque noeud worker dans votre sortie d'interface de ligne de commande.

Pour plus d'informations, voir Etats du noeud worker.

Etape 3 : Affichez les détails relatifs à chaque noeud worker.

Obtenez les détails relatifs à votre noeud worker. Si les détails comprennent un message d'erreur, consultez la liste des messages d'erreur courants concernant les noeuds worker pour savoir comment résoudre le problème.

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

Etape 4 : Vérifiez le fournisseur d'infrastructure du noeud worker

Examinez l'environnement d'infrastructure pour rechercher les autres raisons susceptibles de provoquer des problèmes de noeud worker.

1. Assurez-vous auprès de votre équipe chargée de la mise en réseau qu'aucune opération de maintenance récente, telle que des mises à jour de pare-feu ou de sous-réseau, ne pourrait avoir une incidence sur les connexions de noeud worker.
2. Consultez IBM Cloud pour Red Hat OpenShift on IBM Cloud et le fournisseur d’infrastructure sous-jacent, par exemple Virtual Servers pour les composants classiques liés au VPC, ou Satellite.
3. Si vous accès l'infrastructure sous-jacente, par exemple les serveurs virtuels classiques, examinez les détails des machines correspondantes pour les noeuds worker.

Étape 5 : Rassembler les journaux et autres informations sur les nœuds de travail

Exécution de la commande must-gather

La commande CLI oc adm must-gather recueille les informations de votre cluster pour les problèmes de débogage. Cet outil indispensable recueille les définitions des ressources, les journaux de service, etc. Notez que les journaux d'audit ne sont pas collectés dans le cadre de l'ensemble d'informations par défaut afin de réduire la taille des fichiers.

Lorsque vous exécutez oc adm must-gather, un nouveau pod avec un nom aléatoire est créé dans un nouveau projet sur le cluster. Les données sont collectées sur ce pod et sauvegardées dans un nouveau répertoire commençant par must-gather.local.

Consultez les exemples de commandes suivants.

oc adm must-gather

Exemple de commande pour collecter des données relatives à une ou plusieurs caractéristiques spécifiques, utilisez l'argument --image avec une image spécifique.

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Exemple de commande pour collecter les journaux d'audit.

oc adm must-gather -- /usr/bin/gather_audit_logs

Exemple de commande pour exécuter must-gather dans un espace de noms spécifique.

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

Exemple de commandes pour collecter les journaux à partir d'un moment donné.

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

Exemple de commande pour collecter les journaux du réseau.

oc adm must-gather -- gather_network_logs

Pour plus d'exemples et d'arguments, exécutez la commande suivante

oc adm must-gather -h

Exemple de commande pour créer un fichier compressé à partir du répertoire must-gather.

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

Joignez le fichier compressé à votre dossier d'assistance.

Recueil d'un rapport SOS

sosreport est un outil qui collecte les détails de configuration, les informations système et les données de diagnostic des systèmes Red Hat Enterprise Linux (RHEL) et Red Hat Enterprise Linux CoreOS (RHCOS). Il fournit un moyen normalisé de collecter des informations de diagnostic relatives à un nœud, qui peuvent ensuite être fournies à l'assistance pour le diagnostic des problèmes.

Dans certaines interactions avec le support, celui-ci peut vous demander de collecter une archive sosreport pour un nœud OpenShift Container Platform spécifique. Par exemple, il peut être nécessaire d'examiner les journaux du système ou d'autres données spécifiques au nœud qui ne sont pas incluses dans la sortie de oc adm must-gather.

La méthode de collecte d'un fichier « sosreport » varie en fonction du système d'exploitation du nœud de travail. Les nœuds RHCOS utilisent la commande « toolbox ». Les nœuds RHEL 8 et RHEL 9 ne prennent pas en charge la commande « toolbox »; utilisez plutôt le script « sosreport » de l' Red Hat.

La méthode recommandée pour générer un sosreport pour un nœud de cluster OpenShift Container Platform est d'utiliser un pod de débogage.

Accédez à votre cluster Red Hat OpenShift.

1. Répertoriez vos nœuds de travail afin d'identifier le nœud cible et son système d'exploitation.

   oc get nodes -o wide
   

   Notez le nom du nœud de travail dont vous souhaitez collecter l' sosreport. La colonne « OS-IMAGE » indique si le nœud exécute RHCOS ou RHEL.

2. Lancez une session de débogage sur le nœud cible.

   oc debug node/node_name
   

   Pour entrer dans une session de débogage sur le nœud cible entaché de l'effet NoExecute, ajoutez une tolérance à un espace de noms temporaire et démarrez le pod de débogage dans l'espace de noms temporaire.

   oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'
   

   oc debug node/my-cluster-node
   

3. Définir /host comme répertoire racine dans l'interpréteur de commandes de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans le répertoire « /host » au sein du pod. En définissant le répertoire racine sur /host, vous pouvez exécuter les binaires présents dans les chemins d'accès aux exécutables de l'hôte.

   chroot /host
   

   OpenShift Container Platform Les nœuds de cluster exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les modifications apportées au cluster. Il n'est pas recommandé d'accéder aux nœuds de la grappe en utilisant SSH. Cependant, si l'API OpenShift Container Platform n'est pas disponible ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc peuvent être affectées. Dans ce cas, il est possible d'accéder aux nœuds en utilisant ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN.

4. Récupérez l' sosreport e en utilisant la méthode adaptée au système d'exploitation du nœud de travail.

   • Nœuds RHCOS: utilisez la commande « toolbox ».

     1. Démarrer un conteneur de boîte à outils, qui comprend les binaires et les modules d'extension nécessaires à l'exécution du site sosreport. La commande « toolbox » n'est prise en charge que sur les nœuds RHCOS.

        toolbox
        

        Si un module de boîte à outils est déjà en cours d'exécution, la commande Toolbox affiche 'toolbox-' already exists. Trying to start….. Elle supprime le module de boîte à outils en cours d'exécution avec podman rm toolbox- et démarre un nouveau module de boîte à outils.

     2. Exécutez la commande sos report et suivez les invites pour collecter les données de dépannage.

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on
        

        Exemple de commande pour inclure dans votre rapport des informations sur les configurations de réseau OVN- Kubernetes d'un nœud.

        sos report --all-logs
        

        La sortie « sosreport » indique l'emplacement de l'archive et sa somme de contrôle. L'exemple de résultat suivant fait référence à l'identifiant de cas de soutien 01234567. Le chemin d'accès au fichier se trouve en dehors de l'environnement « chroot », car le conteneur de la boîte à outils monte le répertoire racine de l'hôte à l'adresse /host.

        Your sosreport has been generated and saved in:
        /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
        The checksum is: 382ffc167510fd71b4f12a4f40b97a4e
        

   • Nœuds RHEL 8 et RHEL 9: la commande « toolbox » n'est pas prise en charge sur les nœuds RHEL. Utilisez plutôt le script de collecte de rapports SOS « Red Hat ».

     1. Téléchargez et exécutez le script « sosreport » de l' Red Hat en suivant les instructions fournies dans l'article de la base de connaissances disponible à l'adresse Red Hat.

     2. Suivez les instructions du script pour collecter les données de dépannage. Notez l'emplacement du fichier d'archive généré à partir de la sortie du script.

5. Affiche le site sosreport dans un fichier.

   Le conteneur de débogage monte le répertoire racine de l'hôte à l'adresse /host. Lorsque vous spécifiez les fichiers cibles à concaténer, indiquez le chemin d'accès absolu à partir du répertoire racine du conteneur de débogage, en incluant « /host ».

   oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
   

   OpenShift Container Platform Les nœuds de cluster exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les modifications apportées au cluster. Le transfert d'une archive sosreport à partir d'un nœud de cluster en utilisant scp n'est pas recommandé. Cependant, si l'API OpenShift Container Platform n'est pas disponible ou si le kubelet ne fonctionne pas correctement sur le nœud cible, oc les opérations peuvent être affectées. Dans de telles situations, il est possible de copier une archive sosreport à partir d'un nœud en exécutant scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path>.

6. Téléchargez le fichier dans votre dossier d'assistance.