Utilisation de IBM Cloud Monitoring et IBM Cloud Logs pour déboguer votre cluster

Virtual Private Cloud Classic infrastructure

Utilisez les tableaux de bord et les requêtes intégrés dans IBM Cloud Monitoring et IBM Cloud Logs pour analyser et diagnostiquer les problèmes de cluster sans avoir besoin d'un oc accès direct à chaque nœud ou pod.

De nombreux guides de dépannage figurant dans cette documentation vous invitent à exécuter des commandes oc afin de collecter des données manuellement. Si votre cluster est connecté à IBM Cloud Monitoring ou IBM Cloud Logs, vous trouverez souvent les mêmes informations — ainsi que des éléments de contexte historiques supplémentaires — directement dans les tableaux de bord de ces services. Cette approche est particulièrement utile lorsqu'un nœud de travail est inaccessible ou lorsque vous souhaitez consulter les événements qui se sont produits par le passé.

Avant de commencer

Avant de pouvoir utiliser les services d’observabilité pour déboguer votre cluster, assurez-vous que les conditions suivantes sont remplies.

Vérifiez l'utilisation des ressources des nœuds de travail avec IBM Cloud Monitoring

Lorsque les nœuds de travail passent à l'état NotReady ou Critical, une utilisation élevée du processeur ou de la mémoire en est souvent la cause. Utilisez les tableaux de bord prédéfinis d' IBM Cloud Monitoring pour identifier rapidement les contraintes sur les ressources.

  1. Ouvrez le tableau de bord IBM Cloud Monitoring de votre cluster.

    1. Dans la console d' IBM Cloud, accédez à la page des ressources de votre cluster et cliquez sur le cluster concerné.
    2. Dans la section Intégrations, recherchez l'option Surveillance et cliquez sur Lancer. L'interface utilisateur d' IBM Cloud Monitoring s'ouvre dans une nouvelle fenêtre.

  2. Accédez au tableau de bord prédéfini Kubernetes > Nodes pour consulter l’utilisation du processeur et de la mémoire par nœud.

    • Recherchez les nœuds dont le pourcentage d'utilisation du processeur (CPU %) ou de la mémoire ( Memory %) dépasse 80 %. Les nœuds atteignant ou dépassant ce seuil risquent d’être surchargés et peuvent ne plus être en mesure de planifier de nouveaux pods.
    • Recherchez les nœuds dont l'utilisation du processeur ou de la mémoire présente un pic soudain ou est restée élevée de manière constante au cours de la dernière heure ou de la dernière journée. Cela peut vous aider à déterminer si le problème est temporaire ou persistant.

  3. Pour examiner un nœud spécifique, cliquez sur le nom du nœud dans le tableau de bord afin de filtrer tous les graphiques en fonction de ce nœud. Vérifiez les indicateurs suivants :

    • Pourcentage d'utilisation du processeur — une valeur supérieure à 90 % de manière prolongée indique une saturation du processeur.
    • Pourcentage d'utilisation de la mémoire: une valeur constamment supérieure à 85 % augmente le risque d'événements de manque de mémoire (OOM).
    • Trafic réseau entrant/sortant — un pic de trafic inattendu peut indiquer une charge de travail hors de contrôle ou une attaque réseau.

  4. Pour vérifier quels pods consomment le plus de ressources sur un nœud, accédez au tableau de bord Kubernetes > Pods et filtrez par nœud concerné. Notez les noms des pods qui présentent une utilisation systématiquement élevée du processeur ou de la mémoire, car ceux-ci sont susceptibles d'être à l'origine de l'instabilité du nœud de travail.

Vérifiez l'état des pods et le nombre de redémarrages avec l' IBM Cloud Monitoring

Les pods qui entrent dans une boucle de plantage ou redémarrent fréquemment sont souvent le signe de problèmes au niveau de l'application, tels que des arrêts dus à un manque de mémoire (OOM) ou des tests de disponibilité mal configurés. Utilisez la commande IBM Cloud Monitoring pour identifier ces pods sans avoir à l'exécuter à plusieurs oc get pods reprises.

  1. Dans l'interface utilisateur d' IBM Cloud Monitoring, accédez au tableau de bord prédéfini Kubernetes > Pods.

  2. Consultez le panneau Redémarrages des conteneurs. Recherchez les pods dont le nombre de redémarrages au cours des 15 dernières minutes est supérieur à zéro, ou qui affichent une augmentation rapide sur une période plus longue.

    • Un compteur de redémarrages qui augmente de manière répétée indique une boucle de plantage. Notez le nom du pod et l'espace de noms afin de les utiliser lors des étapes d'analyse des journaux qui suivent.
    • Un compteur de redémarrages à zéro, mais un statut En attente ou Inconnu, indique un problème de planification ou de connectivité des nœuds plutôt qu'une défaillance de l'application.

  3. Pour configurer une alerte concernant les futurs redémarrages de pods, cliquez sur l'icône Alertes dans l'interface utilisateur d' IBM Cloud Monitoring, puis créez une alerte de métrique sur cette métrique kubernetes.pod.restart.count. Définissez le seuil de déclenchement lorsque le nombre de redémarrages dépasse deux en l'espace de cinq minutes pour n'importe quel pod. Cela permet de donner l'alerte avant qu'une boucle de plantage ne devienne perturbatrice. Pour plus d’informations sur la configuration des alertes, consultez la section Configuration des alertes d’ IBM Cloud® Monitoring.

Analyser les journaux des conteneurs avec l' IBM Cloud Logs

Lorsqu'un pod a redémarré ou qu'un nœud rencontre des problèmes, il est essentiel de consulter les journaux des conteneurs pour en comprendre la cause première. IBM Cloud Logs conserve l'historique des données de journaux qui ne sont plus disponibles via après oc logs le redémarrage d'un conteneur.

  1. Ouvrir le tableau de bord IBM Cloud Logs.

    1. Dans la console d' IBM Cloud, accédez à la page des ressources de votre cluster et cliquez sur le cluster concerné.
    2. Dans la section Intégrations, repérez l'option Logging et cliquez sur Lancer. L'interface utilisateur d' IBM Cloud Logs s'ouvre dans une nouvelle fenêtre.

  2. Définissez la plage horaire correspondant à la période pendant laquelle le problème s’est produit. Si le problème persiste, définissez la plage sur la dernière heure. Si vous effectuez une recherche sur un événement passé, définissez les heures de début et de fin précises pour affiner les résultats.

  3. Recherchez le pod ou l'espace de noms concerné. Utilisez la barre de recherche située en haut de l'interface utilisateur pour filtrer les journaux. Par exemple, pour afficher les journaux de tous les pods de l'espace de noms default, saisissez la requête suivante :

    kubernetes.namespace_name:"default"

    Pour affiner les résultats et ne conserver qu'un pod spécifique en indiquant son nom, utilisez :

    kubernetes.pod_name:"MY_POD_NAME"

  4. Passez en revue les lignes du journal pour les entrées de niveau erreur. Recherchez l'un des schémas suivants, qui indiquent des modes de défaillance courants :

    • OOMKilled ou out of memory — le conteneur a dépassé sa limite de mémoire et a été arrêté par le noyau.
    • CrashLoopBackOff — Le conteneur redémarre sans cesse, souvent en raison d'une erreur d'application au démarrage.
    • failed to pull image ou ImagePullBackOff — le nœud ne parvient pas à récupérer l'image du conteneur depuis le registre.
    • Connection refused ou context deadline exceeded — l'application ne parvient pas à accéder à un service dépendant ou au serveur API d' Kubernetes.

  5. Si vous repérez une entrée de journal liée à un problème de mémoire insuffisante (OOM), notez l'horodatage et consultez le tableau de bord Pods de IBM Cloud Monitoring Kubernetes pour la même plage horaire afin de confirmer que l'utilisation de la mémoire du pod a atteint sa limite juste avant le redémarrage.

Consultez le calendrier des événements de l' Kubernetes s sur IBM Cloud Logs

Kubernetes Les événements enregistrent les activités importantes du cluster, telles que les échecs de planification des pods, l'état des nœuds et les erreurs de montage de volumes. IBM Cloud Logs ingère automatiquement ces événements et vous permet de les rechercher et de les filtrer dans l'historique — contrairement à oc get events, qui n'affiche que les événements récents de la session en cours.

  1. Dans l'interface utilisateur d' IBM Cloud Logs, utilisez la requête suivante pour afficher tous les événements d'avertissement Kubernetes sur l'ensemble du cluster :
    kubernetes.event.type:"Warning"
  2. Pour filtrer les événements vers un nœud de travail spécifique, ajoutez le nom du nœud à la requête. Remplacez NODE_NAME par le nom du nœud concerné :
    kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
  3. Vérifiez le champ Raison dans les entrées du journal des événements. Les raisons suivantes sont les plus pertinentes pour le débogage des problèmes liés aux nœuds de travail et aux charges de travail :
NodeNotReady
Le nœud signale un problème NotReady. Cet événement précède ou accompagne souvent le passage d'un nœud de travail dans un état Critical.
OOMKilling
Le noyau a interrompu un processus sur le nœud en raison d'un épuisement de la mémoire.
FailedScheduling
Le planificateur n'a pas pu placer de pod sur aucun nœud disponible. Le champ Message explique généralement la raison de l'erreur, par exemple une capacité insuffisante du processeur ou de la mémoire, ou encore une incompatibilité du sélecteur de nœud.
BackOff
Un conteneur est pris dans une boucle de plantage. L'événement est généré chaque fois que le système kubelet attend un certain temps avant de redémarrer le conteneur.
FailedMount ou FailedAttachVolume
Un volume persistant n'a pas pu être monté ou associé à un pod, ce qui empêche le démarrage de ce dernier.
  1. Pour tout événement qui semble pertinent, notez les valeurs involvedObject.namespace et involvedObject.name, puis utilisez-les pour établir des corrélations avec les données de journaux et de métriques que vous avez recueillies dans les sections précédentes.

Etapes suivantes

  • Si vous avez identifié un nœud de travail soumis à une pression sur les ressources, envisagez de le recharger ou de le remplacer, ou encore d'ajuster les demandes et les limites de ressources des pods s'exécutant sur ce nœud.
  • Si des pods entrent dans une boucle de plantage due à des interruptions OOM, augmentez les limites de mémoire des conteneurs concernés ou déplacez les charges de travail gourmandes en mémoire vers un pool de travailleurs doté de nœuds plus puissants.
  • Si les journaux indiquent des échecs de récupération d'images, vérifiez vos secrets de récupération d'images et assurez-vous que le nœud de travail peut accéder au registre de conteneurs.
  • Pour les problèmes qui ne peuvent être résolus à l'aide des informations rassemblées ici, consultez la section Collecte des données pour une demande d'assistance afin de rassembler les informations nécessaires à l'ouverture d'un ticket d'assistance.