Obtenir de l'aide et une assistance pour votre cluster

Découvrez les options d'assistance, les ressources de dépannage et les moyens d'obtenir de l'aide concernant votre cluster.

Avant d'ouvrir un cas de support, collectez des informations pertinentes sur votre environnement de cluster.

Vous cherchez l'outil de diagnostic et de débogage? Ce module complémentaire n'est plus pris en charge. IBM Cloud Monitoring est recommandé pour surveiller et diagnostiquer les problèmes de votre cluster. D'autres liens de dépannage peuvent s'avérer utiles, notamment Troubleshooting worker nodes in Critical or NotReady state(dépannage des nœuds de travail en état critique ou ) et Troubleshooting apps in IBM Cloud Kubernetes Service.

Obtenez les détails de votre cluster

  1. Obtenez les détails de votre cluster.

    ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
    
  2. Si votre problème implique des noeuds worker, obtenez les détails du noeud worker.

    1. Répertoriez tous les noeuds worker du cluster et notez l'ID de ceux dont l'état ou le statut est défectueux.
        ibmcloud oc worker ls -c CLUSTER_NAME_OR_ID
        ```
    2. Obtenez les détails relatifs au noeud worker défectueux.
    
    ```sh {: pre}
        ibmcloud oc worker get -w WORKER_ID -c CLUSTER_NAME_OR_ID
        ```
    
  3. Pour les problèmes liés aux ressources de votre cluster, telles que les pods ou les services, connectez-vous au cluster et utilisez l'API Kubernetes pour obtenir plus d'informations sur ces ressources.

Recueillir les journaux d'erreurs et d'autres informations

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 la commande « 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 du 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 de la commande « 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 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 du cluster. Le transfert d'une archive sosreport à partir d'un nœud de cluster à l'aide de 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.

Ouvrir un dossier de support

  1. Contactez le support d' IBM en ouvrant un dossier.

  2. Dans le champ Type de problème, recherchez ou sélectionnez Red Hat OpenShift on IBM Cloud.

  3. Concernant les Détails du cas, fournissez un titre descriptif et incluez les détails que vous avez précédemment collectés. Dans la zone Ressources, vous pouvez également sélectionner le cluster auquel se rapporte la question.

  4. Soyez aussi précis que possible et incluez des diagrammes d'architecture ou des éléments supplémentaires que vous pensez pouvoir aider le support IBM à résoudre le problème.