Introduction au dépannage de GKE

Cette page vous présente les techniques de dépannage de base pour Google Kubernetes Engine (GKE). Cette page s'adresse aux utilisateurs qui débutent avec Kubernetes et GKE, et qui souhaitent apprendre des pratiques de dépannage efficaces.

Cette page présente les outils et techniques suivants pour surveiller, diagnostiquer et résoudre les problèmes liés à GKE :

Comprendre les concepts de base

Si vous débutez avec Kubernetes et GKE, il est essentiel de comprendre les concepts de base, comme l'architecture des clusters et la relation entre les pods et les nœuds, avant de commencer à résoudre les problèmes. Pour en savoir plus, consultez Commencer à découvrir GKE.

Il est également utile de comprendre les parties de GKE que vous êtes responsable de maintenir et celles dont Trusted Cloud by S3NS est responsable. Pour en savoir plus, consultez Responsabilité partagée de GKE.

Vérifier l'état des clusters et des charges de travail dans la console Trusted Cloud

La console Trusted Cloud est un bon point de départ pour résoudre les problèmes, car elle offre un aperçu rapide de l'état de vos clusters et de vos charges de travail. L'état du cluster fait référence à l'état de l'infrastructure GKE sous-jacente, comme les nœuds et le réseau, tandis que l'état de la charge de travail fait référence à l'état et aux performances de vos applications exécutées sur le cluster.

Les sections suivantes décrivent les pages "Cluster" et "Charge de travail". Pour vous donner une vue d'ensemble de l'état de votre application, la console Trusted Cloud vous donne également accès à de puissants outils de journalisation et de surveillance. Vous pouvez ainsi identifier la cause première des échecs passés et prévenir ceux à venir. Pour en savoir plus sur ces outils, consultez les sections Effectuer des analyses historiques avec Cloud Logging et Effectuer une surveillance proactive avec Cloud Monitoring.

Identifier les problèmes de cluster

La page Clusters Kubernetes vous offre une vue d'ensemble de l'état de vos clusters. Pour identifier les problèmes liés à vos clusters, commencez par consulter cette page.

Voici quelques exemples d'utilisation de cette page pour résoudre des problèmes :

  • Pour obtenir des conseils sur l'amélioration de l'état de votre cluster, de votre stratégie de mise à niveau et de l'optimisation des coûts, cliquez sur Afficher les recommandations.
  • Pour identifier les clusters non opérationnels, consultez la colonne État. Tout cluster qui ne comporte pas de coche verte requiert votre attention.
  • Pour identifier les problèmes potentiels, consultez la colonne Notifications. Cliquez sur un message de notification pour en savoir plus.

Examiner un cluster spécifique

Une fois que vous avez identifié un problème avec un cluster, explorez la page Détails du cluster pour obtenir des informations détaillées qui vous aideront à résoudre le problème et à comprendre la configuration du cluster.

Pour accéder à la page Détails d'un cluster, procédez comme suit :

  1. Accédez à la page des clusters Kubernetes.

    Accéder à la page "Clusters Kubernetes"

  2. Examinez la colonne Nom, puis cliquez sur le nom du cluster que vous souhaitez examiner.

Voici quelques exemples d'utilisation de la page Détails du cluster pour résoudre les problèmes liés à votre cluster :

  • Pour les vérifications d'état générales, essayez les options suivantes :

    • Pour afficher les tableaux de bord au niveau du cluster, accédez à l'onglet Observabilité. Par défaut, GKE active Cloud Monitoring lorsque vous créez un cluster. Lorsque Cloud Monitoring est activé, GKE configure automatiquement les tableaux de bord sur cette page. Voici quelques-unes des vues qui pourraient vous être les plus utiles pour résoudre les problèmes :

      • Présentation : affichez un récapitulatif général de l'état, de l'utilisation des ressources et des événements clés de votre cluster. Ce tableau de bord vous aide à évaluer rapidement l'état général de votre cluster et à identifier les problèmes potentiels.
      • Métriques de trafic : affichez les métriques de mise en réseau basées sur les nœuds pour obtenir des insights sur le trafic entre vos charges de travail Kubernetes.
      • État de la charge de travail : affichez l'état des déploiements, des pods et des conteneurs. Identifier les instances défaillantes ou non opérationnelles et détecter les contraintes de ressources.

      • Plan de contrôle : affichez l'état et les performances du plan de contrôle. Ce tableau de bord vous permet de surveiller les métriques clés des composants tels que kube-apiserver et etcd, d'identifier les goulots d'étranglement des performances et de détecter les défaillances des composants.

    • Pour afficher les erreurs récentes de l'application, accédez à l'onglet Erreurs de l'application. Les informations de cet onglet peuvent vous aider à hiérarchiser et à résoudre les erreurs. Elles indiquent le nombre d'occurrences, la date de la première apparition d'une erreur et la date de sa dernière occurrence.

      Pour examiner une erreur plus en détail, cliquez sur le message d'erreur afin d'afficher un rapport d'erreurs détaillé, y compris des liens vers les journaux concernés.

  • Si vous rencontrez des problèmes après une mise à niveau ou une modification récente, consultez la section Principes de base des clusters dans l'onglet Détails du cluster. Vérifiez que la version indiquée dans le champ Version est celle que vous attendez. Pour en savoir plus, cliquez sur Afficher l'historique des mises à niveau dans la section Mises à niveau.

  • Si vous utilisez un cluster standard et que vos pods sont bloqués à l'état Pending, ou si vous pensez que les nœuds sont surchargés, consultez l'onglet Nœuds. L'onglet Nœuds n'est pas disponible pour les clusters Autopilot, car GKE gère les nœuds à votre place.

    • Dans la section Pools de nœuds, vérifiez que l'autoscaling est correctement configuré et que le type de machine est adapté à vos charges de travail.
    • Dans la section Nœuds, recherchez les nœuds dont l'état n'est pas Ready. Un état NotReady indique un problème lié au nœud lui-même, tel qu'une pression sur les ressources ou un problème avec le kubelet (l'agent qui s'exécute sur chaque nœud pour gérer les conteneurs).

Identifier les problèmes liés aux charges de travail

Lorsque vous pensez qu'un problème est lié à une application spécifique, comme un déploiement ayant échoué, accédez à la page Charges de travail dans la console Trusted Cloud . Cette page fournit une vue centralisée de toutes les applications qui s'exécutent dans vos clusters.

Voici quelques exemples d'utilisation de cette page pour résoudre des problèmes :

  • Pour identifier les charges de travail non opérationnelles, consultez la colonne État. Toute charge de travail qui ne comporte pas de coche verte requiert votre attention.
  • Si une application ne répond pas, consultez la colonne Pods. Par exemple, un état tel que 1/3 signifie qu'une seule des trois répliques d'application est en cours d'exécution, ce qui indique un problème.

Examiner une charge de travail spécifique

Une fois que vous avez identifié une charge de travail problématique dans l'aperçu, explorez la page Détails de la charge de travail pour commencer à isoler la cause première.

Pour accéder à la page Détails d'une charge de travail, procédez comme suit :

  1. Accédez à la page "Charges de travail".

    Accéder à la page Charges de travail

  2. Consultez la colonne Nom et cliquez sur le nom de la charge de travail que vous souhaitez examiner.

Voici quelques exemples d'utilisation de la page Détails de la charge de travail pour résoudre les problèmes liés à vos charges de travail :

  • Pour vérifier la configuration de la charge de travail, utilisez les onglets Présentation et Détails de la charge de travail. Vous pouvez utiliser ces informations pour vérifier des événements tels que le déploiement du tag d'image de conteneur approprié ou les limites et demandes de ressources de la charge de travail.

  • Pour trouver le nom d'un pod spécifique qui plante, accédez à la section Pods gérés. Vous aurez peut-être besoin de ces informations pour les commandes kubectl. Cette section liste tous les pods contrôlés par la charge de travail, ainsi que leur état. Pour afficher l'historique des modifications récentes apportées à une charge de travail, accédez à l'onglet Historique des révisions. Si vous constatez des problèmes de performances après un nouveau déploiement, utilisez cette section pour identifier la révision active. Vous pouvez ensuite comparer les configurations de la révision actuelle avec les précédentes pour identifier la source du problème. Si cet onglet n'est pas visible, cela signifie que la charge de travail est d'un type qui n'utilise pas de révisions ou qu'elle n'a pas encore été mise à jour.

  • Si un déploiement semble avoir échoué, accédez à l'onglet Événements. Cette page est souvent la source d'informations la plus utile, car elle affiche les événements au niveau de Kubernetes.

  • Pour consulter les journaux de votre application, cliquez sur l'onglet Journaux. Cette page vous aide à comprendre ce qui se passe dans votre cluster. Recherchez ici les messages d'erreur et les traces de pile qui peuvent vous aider à diagnostiquer les problèmes.

  • Pour confirmer exactement ce qui a été déployé, consultez l'onglet YAML. Cette page affiche le fichier manifeste YAML actif de la charge de travail telle qu'elle existe sur le cluster. Ces informations sont utiles pour identifier les éventuelles incohérences dans vos fichiers manifestes contrôlés par source. Si vous consultez le fichier manifeste YAML d'un seul pod, cet onglet affiche également l'état du pod, ce qui fournit des informations sur les échecs au niveau du pod.

Examiner l'état du cluster avec l'outil de ligne de commande kubectl

Bien que la console Trusted Cloud vous aide à comprendre si un problème existe, l'outil en ligne de commande kubectl est essentiel pour en découvrir la cause. En communiquant directement avec le plan de contrôle Kubernetes, l'outil de ligne de commande kubectl vous permet de recueillir les informations détaillées dont vous avez besoin pour résoudre les problèmes liés à votre environnement GKE.

Les sections suivantes vous présentent quelques commandes essentielles qui constituent un excellent point de départ pour le dépannage de GKE.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Installez kubectl.

  • Configurez l'outil de ligne de commande kubectl pour communiquer avec votre cluster :

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster
    • LOCATION : emplacement Compute Engine du plan de contrôle de votre cluster. Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.

  • Vérifiez vos autorisations. Pour vérifier si vous disposez des autorisations requises pour exécuter les commandes kubectl, utilisez la commande kubectl auth can-i. Par exemple, pour vérifier si vous êtes autorisé à exécuter kubectl get nodes, exécutez la commande kubectl auth can-i get nodes.

    Si vous disposez des autorisations requises, la commande renvoie yes. Sinon, elle renvoie no.

    Si vous n'êtes pas autorisé à exécuter une commande kubectl, un message d'erreur semblable à celui-ci peut s'afficher :

    Error from server (Forbidden): pods "POD_NAME" is forbidden: User
"USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
namespace "default"

    Si vous ne disposez pas des autorisations requises, demandez à l'administrateur de votre cluster de vous attribuer les rôles nécessaires.

Obtenir une vue d'ensemble de ce qui est en cours d'exécution

La commande kubectl get vous permet d'obtenir une vue d'ensemble de ce qui se passe dans votre cluster. Utilisez les commandes suivantes pour afficher l'état de deux des composants de cluster les plus importants, les nœuds et les pods :

  1. Pour vérifier si vos nœuds sont opérationnels, affichez les détails de tous les nœuds et de leurs états :

    kubectl get nodes

    Le résultat ressemble à ce qui suit :

    NAME                                        STATUS   ROLES    AGE     VERSION

gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003

    Tout état autre que Ready nécessite une enquête supplémentaire.

  2. Pour vérifier si vos pods sont opérationnels, affichez les détails de tous les pods et de leurs états :

    kubectl get pods --all-namespaces

    Le résultat ressemble à ce qui suit :

    NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
kube-system netd-6nbsq 3/3     Running     0          4d23h
kube-system netd-g7tpl 3/3     Running     0          4d23h

    Tout état autre que Running nécessite une enquête supplémentaire. Voici quelques états courants que vous pouvez rencontrer :

    • Running : état d'exécution sain.
    • Pending : le pod est en attente de planification sur un nœud.
    • CrashLoopBackOff : les conteneurs du pod plantent en boucle à plusieurs reprises, car l'application démarre, quitte avec une erreur, puis est redémarrée par Kubernetes.
    • ImagePullBackOff : le pod ne peut pas extraire l'image de conteneur.

Les commandes précédentes ne sont que deux exemples d'utilisation de la commande kubectl get. Vous pouvez également utiliser cette commande pour en savoir plus sur de nombreux types de ressources Kubernetes. Pour obtenir la liste complète des ressources que vous pouvez explorer, consultez kubectl get dans la documentation Kubernetes.

En savoir plus sur des ressources spécifiques

Une fois que vous avez identifié un problème, vous devez obtenir plus d'informations. Par exemple, un problème peut être un pod dont l'état n'est pas Running. Pour obtenir plus de détails, utilisez la commande kubectl describe.

Par exemple, pour décrire un pod spécifique, exécutez la commande suivante :

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Remplacez les éléments suivants :

  • POD_NAME : nom du pod qui rencontre des problèmes.
  • NAMESPACE_NAME : espace de noms dans lequel se trouve le pod. Si vous n'êtes pas sûr de l'espace de noms, consultez la colonne Namespace dans le résultat de la commande kubectl get pods.

Le résultat de la commande kubectl describe inclut des informations détaillées sur votre ressource. Voici quelques-unes des sections les plus utiles à consulter lorsque vous résolvez un problème lié à un Nest :

  • Status : état actuel du pod.
  • Conditions : état de santé et disponibilité globale du pod.
  • Restart Count : nombre de fois où les conteneurs du pod ont redémarré. Un nombre élevé peut être préoccupant.
  • Events : journal des événements importants qui se sont produits pour ce pod, comme sa programmation sur un nœud, l'extraction de son image de conteneur et les éventuelles erreurs survenues. La section Events contient souvent des indices directs sur la raison de l'échec d'un pod.

Comme la commande kubectl get, vous pouvez utiliser la commande kubectl describe pour en savoir plus sur plusieurs types de ressources. Pour obtenir la liste complète des ressources que vous pouvez explorer, consultez kubectl describe dans la documentation Kubernetes.

Effectuer des analyses historiques avec Cloud Logging

Bien que l'outil de ligne de commande kubectl soit indispensable pour inspecter l'état actuel de vos objets Kubernetes, sa vue est souvent limitée au moment présent. Pour comprendre la cause racine d'un problème, vous devez souvent examiner ce qui s'est passé au fil du temps. Lorsque vous avez besoin de ce contexte historique, utilisez Cloud Logging.

Cloud Logging agrège les journaux de vos clusters GKE, de vos applications conteneurisées et d'autres services Trusted Cloud .

Comprendre les principaux types de journaux pour le dépannage

Cloud Logging collecte automatiquement plusieurs types de journaux GKE qui peuvent vous aider à résoudre les problèmes :

  • Journaux de nœud et d'exécution (kubelet, containerd) : journaux des services de nœud sous-jacents. Étant donné que kubelet gère le cycle de vie de tous les pods sur le nœud, ses journaux sont essentiels pour résoudre les problèmes tels que les démarrages de conteneurs, les événements de mémoire insuffisante (OOM), les échecs de vérification et les erreurs de montage de volume. Ces journaux sont également essentiels pour diagnostiquer les problèmes au niveau des nœuds, par exemple un nœud dont l'état est NotReady.

    Comme containerd gère le cycle de vie de vos conteneurs, y compris l'extraction d'images, ses journaux sont essentiels pour résoudre les problèmes qui surviennent avant que le kubelet puisse démarrer le conteneur. Les journaux containerd vous aident à diagnostiquer les problèmes au niveau des nœuds dans GKE, car ils documentent les activités spécifiques et les erreurs potentielles de l'environnement d'exécution du conteneur.

  • Journaux d'application (stdout, stderr) : flux de sortie et d'erreur standards de vos processus conteneurisés. Ces journaux sont essentiels pour déboguer les problèmes spécifiques à l'application, tels que les plantages, les erreurs ou les comportements inattendus.

  • Journaux d'audit : ces journaux répondent à la question "Qui a fait quoi, où et quand ?" pour votre cluster. Ils permettent de suivre les actions d'administration et les appels d'API effectués sur le serveur d'API Kubernetes, ce qui est utile pour diagnostiquer les problèmes causés par des modifications de configuration ou un accès non autorisé.

Scénarios de dépannage courants

Une fois que vous avez identifié un problème, vous pouvez interroger ces journaux pour savoir ce qui s'est passé. Pour vous aider à vous lancer, l'examen des journaux peut vous aider à résoudre les problèmes suivants :

  • Si un nœud est à l'état NotReady, consultez ses journaux. Les journaux kubelet et containerd révèlent souvent la cause sous-jacente, comme des problèmes de réseau ou des contraintes de ressources.
  • Si un nouveau nœud ne parvient pas à être provisionné ni à rejoindre le cluster, consultez les journaux du port série du nœud. Ces journaux enregistrent l'activité de démarrage anticipé et de démarrage de kubelet avant que les agents de journalisation du nœud ne soient entièrement actifs.
  • Si un pod n'a pas démarré dans le passé, examinez les journaux d'application de ce pod pour vérifier s'il y a eu des plantages. Si les journaux sont vides ou si le pod ne peut pas être planifié, consultez les journaux d'audit pour trouver les événements pertinents ou les journaux de nœud sur le nœud cible pour obtenir des indices sur la pression des ressources ou les erreurs d'extraction d'image.
  • Si un déploiement critique a été supprimé sans que personne ne sache pourquoi, interrogez les journaux d'audit Activité d'administration. Ces journaux peuvent vous aider à identifier le compte d'utilisateur ou de service qui a émis l'appel d'API de suppression, ce qui constitue un point de départ clair pour votre enquête.

Accéder aux journaux

Utilisez l'explorateur de journaux pour interroger, afficher et analyser les journaux GKE dans la console Trusted Cloud . L'explorateur de journaux fournit de puissantes options de filtrage qui vous aident à isoler votre problème.

Pour accéder à l'explorateur de journaux et l'utiliser, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le volet Requête, saisissez une requête. Utilisez le langage de requête Logging pour rédiger des requêtes ciblées. Voici quelques filtres courants pour vous aider à démarrer :

    Type de filtre Description Exemple de valeur
    resource.type Type de ressource Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Flux de journaux de la ressource. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtrez les ressources portant un nom spécifique.
     Remplacez RESOURCE_TYPE par le nom de la ressource que vous souhaitez interroger. Par exemple, namespace ou pod.    		 example-namespace-name, example-pod-name
    severity Niveau de gravité du journal. DEFAULT, INFO, WARNING, ERROR et CRITICAL
    jsonPayload.message=~ Recherche par expression régulière d'un texte dans le message de journal. scale.down.error.failed.to.delete.node.min.size.reached

    Par exemple, pour résoudre les problèmes liés à un pod spécifique, vous pouvez isoler ses journaux d'erreurs. Pour n'afficher que les journaux dont la gravité est définie sur ERROR pour ce pod, utilisez la requête suivante :

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Remplacez les éléments suivants :

    • POD_NAME : nom du pod qui rencontre des problèmes.
    • NAMESPACE_NAME : espace de noms dans lequel se trouve le pod. Si vous n'êtes pas sûr de l'espace de noms, consultez la colonne Namespace dans le résultat de la commande kubectl get pods.

    Pour obtenir d'autres exemples, consultez Requêtes liées à Kubernetes dans la documentation Google Cloud Observability.

  3. Cliquez sur Exécuter la requête.

  4. Pour afficher le message de journal complet, y compris la charge utile JSON, les métadonnées et le code temporel, cliquez sur l'entrée de journal.

Pour en savoir plus sur les journaux GKE, consultez À propos des journaux GKE.

Effectuer une surveillance proactive avec Cloud Monitoring

Après un problème, l'examen des journaux est une étape essentielle du dépannage. Toutefois, un système véritablement résilient nécessite également une approche proactive pour identifier les problèmes avant qu'ils ne provoquent une panne.

Pour identifier de manière proactive les futurs problèmes et suivre les indicateurs clés de performances au fil du temps, utilisez Cloud Monitoring. Cloud Monitoring fournit des tableaux de bord, des métriques et des fonctionnalités d'alerte. Ces outils vous aident à identifier les taux d'erreur en hausse, l'augmentation de la latence ou les contraintes de ressources, ce qui vous permet d'agir avant que les utilisateurs ne soient affectés.

Examiner les métriques utiles

GKE envoie automatiquement un ensemble de métriques à Cloud Monitoring. Les sections suivantes listent certaines des métriques les plus importantes pour le dépannage :

Pour obtenir la liste complète des métriques GKE, consultez Métriques système GKE.

Métriques de performances et d'état des conteneurs

Commencez par ces métriques lorsque vous suspectez un problème avec une application spécifique. Elles vous aident à surveiller l'état de votre application, y compris à déterminer si un conteneur redémarre fréquemment, manque de mémoire ou est limité par les limites de processeur.

Métrique Description Importance du dépannage
kubernetes.io/container/cpu/limit_utilization Fraction de la limite de processeur actuellement utilisée sur l'instance. Cette valeur peut être supérieure à 1, car un conteneur peut être autorisé à dépasser sa limite de processeur. Identifie la limitation du processeur. Des valeurs élevées peuvent entraîner une dégradation des performances.
kubernetes.io/container/memory/limit_utilization Fraction de la limite de mémoire actuellement utilisée sur l'instance. Cette valeur ne peut pas être supérieure à 1. Surveille le risque d'erreurs de mémoire insuffisante (OOM).
kubernetes.io/container/memory/used_bytes Mémoire réelle consommée par le conteneur en octets. Suit la consommation de mémoire pour identifier les fuites de mémoire potentielles ou le risque d'erreurs OOM.
kubernetes.io/container/memory/page_fault_count Nombre de défauts de page, ventilés par types : majeurs et mineurs. Indique une forte sollicitation de la mémoire. Les défauts de page majeurs signifient que la mémoire est lue à partir du disque (permutation), même si les limites de mémoire ne sont pas atteintes.
kubernetes.io/container/restart_count Nombre de redémarrages du conteneur. Met en évidence les problèmes potentiels tels que les plantages d'applications, les erreurs de configuration ou l'épuisement des ressources en raison d'un nombre élevé ou croissant de redémarrages.
kubernetes.io/container/ephemeral_storage/used_bytes Utilisation du stockage éphémère local, en octets. Surveille l'utilisation du disque temporaire pour éviter l'éviction des pods en raison d'un stockage éphémère complet.
kubernetes.io/container/cpu/request_utilization Fraction des ressources processeur demandées en cours d'utilisation sur l'instance. Cette valeur peut être supérieure à 1, car l'utilisation peut dépasser la demande. Identifie les demandes de processeur surprovisionnées ou sous-provisionnées pour vous aider à optimiser l'allocation des ressources.
kubernetes.io/container/memory/request_utilization Fraction des ressources mémoire demandées en cours d'utilisation sur l'instance. Cette valeur peut être supérieure à 1, car l'utilisation peut dépasser la demande. Identifie les demandes de mémoire surprovisionnées ou sous-provisionnées pour améliorer la planification et éviter les erreurs OOM.

Métriques de performances et d'état des nœuds

Examinez ces métriques lorsque vous devez diagnostiquer des problèmes liés à l'infrastructure GKE sous-jacente. Ces métriques sont essentielles pour comprendre l'état et la capacité globale de vos nœuds. Elles vous aident à déterminer si un nœud est défaillant ou sous pression, ou s'il dispose de suffisamment de mémoire pour planifier de nouveaux pods.

Métrique Description Importance du dépannage
kubernetes.io/node/cpu/allocatable_utilization Fraction du processeur allouable actuellement en cours d'utilisation sur l'instance. Indique si la somme de l'utilisation des pods met à rude épreuve les ressources de processeur disponibles du nœud.
kubernetes.io/node/memory/allocatable_utilization Fraction de la mémoire allouable actuellement utilisée sur l'instance. Cette valeur ne peut pas être supérieure à 1, car l'utilisation ne peut pas dépasser la quantité de mémoire allouable en octets. Suggère que le nœud manque de mémoire pour planifier de nouveaux pods ou pour que les pods existants fonctionnent, en particulier lorsque les valeurs sont élevées.
kubernetes.io/node/status_condition (BÊTA) Condition d'un nœud à partir du champ de condition de l'état du nœud. Indique l'état de santé des nœuds, par exemple Ready, MemoryPressure ou DiskPressure.
kubernetes.io/node/ephemeral_storage/used_bytes Nombre d'octets de stockage éphémère local utilisés par le nœud. Aide à éviter les échecs de démarrage ou les expulsions de pods en fournissant des avertissements sur l'utilisation élevée du stockage éphémère.
kubernetes.io/node/ephemeral_storage/inodes_free Nombre d'inodes libres sur le stockage éphémère local. Surveille le nombre d'inodes libres. Un manque de nœuds d'index peut interrompre les opérations, même si de l'espace disque est disponible.
kubernetes.io/node/interruption_count (BÊTA) Les interruptions sont des évictions système de l'infrastructure, alors que le client en a le contrôle. Cette métrique correspond au nombre actuel d'interruptions par type et par motif. Explique pourquoi un nœud peut disparaître de manière inattendue en raison d'évictions système.

Métriques de performances et d'état des pods

Ces métriques vous aident à résoudre les problèmes liés à l'interaction d'un pod avec son environnement, comme la mise en réseau et le stockage. Utilisez ces métriques lorsque vous devez diagnostiquer des pods qui démarrent lentement, examiner des problèmes potentiels de connectivité réseau ou gérer de manière proactive le stockage pour éviter les échecs d'écriture dus à des volumes pleins.

Métrique Description Importance du dépannage
kubernetes.io/pod/network/received_bytes_count Nombre cumulé d'octets reçus par le pod sur le réseau. Identifie les activités réseau inhabituelles (élevées ou faibles) qui peuvent indiquer des problèmes d'application ou de réseau.
kubernetes.io/pod/network/policy_event_count (BÊTA) Variation du nombre d'événements liés aux règles de réseau observés dans le plan de données. Identifie les problèmes de connectivité causés par les règles réseau.
kubernetes.io/pod/volume/utilization Fraction du volume en cours d'utilisation par l'instance. Cette valeur ne peut pas être supérieure à 1, car l'utilisation ne peut pas dépasser l'espace total disponible pour le volume. Permet de gérer de manière proactive l'espace de volume en envoyant un avertissement lorsque l'utilisation élevée (proche de 1) peut entraîner des échecs d'écriture.
kubernetes.io/pod/latencies/pod_first_ready (BÊTA) Latence de démarrage de bout en bout du pod (de la création du pod à son état prêt), y compris les extractions d'images. Diagnostique les pods qui mettent du temps à démarrer.

Visualiser les métriques avec l'explorateur de métriques

Pour visualiser l'état de votre environnement GKE, créez des graphiques basés sur des métriques avec l'explorateur de métriques.

Pour utiliser l'explorateur de métriques, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à la page Explorateur de métriques.

    Accéder à l'explorateur de métriques

  2. Dans le champ Métriques, sélectionnez ou saisissez la métrique que vous souhaitez examiner.

  3. Affichez les résultats et observez les tendances au fil du temps.

Par exemple, pour examiner la consommation de mémoire des pods dans un espace de noms spécifique, vous pouvez procéder comme suit :

  1. Dans la liste Sélectionner une métrique, sélectionnez la métrique kubernetes.io/container/memory/used_bytes, puis cliquez sur Appliquer.
  2. Cliquez sur Ajouter un filtre, puis sélectionnez namespace_name.
  3. Dans la liste Valeur, sélectionnez l'espace de noms que vous souhaitez examiner.
  4. Dans le champ Agrégation, sélectionnez Somme > pod_name, puis cliquez sur OK. Ce paramètre affiche une ligne de série temporelle distincte pour chaque pod.
  5. Cliquez sur Enregistrer le graphique.

Le graphique obtenu vous montre l'utilisation de la mémoire pour chaque pod au fil du temps, ce qui peut vous aider à identifier visuellement les pods dont la consommation de mémoire est inhabituellement élevée ou en pic.

L'explorateur de métriques offre une grande flexibilité pour construire les métriques que vous souhaitez afficher. Pour en savoir plus sur les options avancées de l'explorateur de métriques, consultez Créer des graphiques avec l'explorateur de métriques dans la documentation Cloud Monitoring.

Créer des alertes pour détecter les problèmes de manière proactive

Pour recevoir des notifications en cas de problème ou lorsque des métriques dépassent certains seuils, configurez des règles d'alerte dans Cloud Monitoring.

Par exemple, pour configurer une règle d'alerte qui vous avertit lorsque la limite d'utilisation du processeur du conteneur dépasse 80 % pendant cinq minutes, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à la page Alertes.

    Accéder à la page "Alertes"

  2. Cliquez sur Créer une règle.

  3. Dans la zone Sélectionner une métrique, filtrez sur CPU limit utilization, puis sélectionnez la métrique suivante : kubernetes.io/container/cpu/limit_utilization.

  4. Cliquez sur Appliquer.

  5. Laissez le champ Ajouter un filtre vide. Ce paramètre déclenche une alerte lorsqu'un cluster dépasse votre seuil.

  6. Dans la section Transformer les données, procédez comme suit :

    1. Dans la liste Fenêtre glissante, sélectionnez 1 minute. Ce paramètre signifie que Trusted Cloud calcule une valeur moyenne chaque minute.

    2. Dans la liste Fonction de fenêtrage glissante, sélectionnez moyenne.

      Ces deux paramètres calculent la moyenne de l'utilisation de la limite de processeur pour chaque conteneur toutes les minutes.

  7. Cliquez sur Suivant.

  8. Dans la section Configurer l'alerte, procédez comme suit :

    1. Pour Type de condition, sélectionnez Seuil.
    2. Pour Déclencheur d'alerte, sélectionnez À chaque infraction de série temporelle.
    3. Pour Position du seuil, sélectionnez Au-dessus du seuil.
    4. Dans le champ Valeur du seuil, saisissez 0.8. Cette valeur représente le seuil de 80 % que vous souhaitez surveiller.
    5. Cliquez sur Options avancées.
    6. Dans la liste Période de nouveau test, sélectionnez 5 min. Ce paramètre signifie que l'alerte ne se déclenche que si l'utilisation du processeur reste supérieure à 80 % pendant une période continue de cinq minutes, ce qui réduit les fausses alertes dues à de brefs pics.
    7. Dans le champ Nom de la condition, attribuez un nom descriptif à la condition.
    8. Cliquez sur Suivant.

  9. Dans la section Configurer les notifications et finaliser l'alerte, procédez comme suit :

    1. Dans la liste Canaux de notification, sélectionnez le canal sur lequel vous souhaitez recevoir l'alerte. Si vous n'avez pas de canal, cliquez sur Gérer les canaux de notification pour en créer un.
    2. Dans le champ Nom de la règle d'alerte, attribuez à la règle un nom clair et descriptif.
    3. Conservez les valeurs par défaut dans les autres champs.
    4. Cliquez sur Suivant.

  10. Vérifiez votre règle. Si tout semble correct, cliquez sur Créer une règle.

Pour découvrir d'autres façons de créer des alertes, consultez Présentation des alertes dans la documentation Cloud Monitoring.

Accélérer le diagnostic avec Gemini Cloud Assist

Parfois, la cause de votre problème n'est pas immédiatement évidente, même lorsque vous avez utilisé les outils décrits dans les sections précédentes. L'examen des cas complexes peut prendre du temps et nécessite une expertise approfondie. Dans ce type de scénario, Gemini Cloud Assist peut vous aider. Elle peut détecter automatiquement les schémas cachés, identifier les anomalies et fournir des résumés pour vous aider à identifier rapidement une cause probable.

Accéder à Gemini Cloud Assist

Pour accéder à Gemini Cloud Assist, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à n'importe quelle page.

  2. Dans la barre d'outils de la console Trusted Cloud , cliquez sur spark Ouvrir ou fermer le chat Gemini Cloud Assist.

    Le panneau Cloud Assist s'ouvre. Vous pouvez cliquer sur des exemples de requêtes s'ils s'affichent, ou saisir une requête dans le champ Saisissez une requête.

Découvrir des exemples de requêtes

Pour vous aider à comprendre comment Gemini Cloud Assist peut vous aider, voici quelques exemples de requêtes :

Thème Scénario Exemple de requête Comment Gemini Cloud Assist peut vous aider
Message d'erreur ambigu Un pod présente l'état CrashLoopBackoff, mais le message d'erreur est difficile à comprendre. Que signifie cette erreur de pod GKE et quelles en sont les causes courantes : panic: runtime error: invalid memory address or nil pointer dereference ? Gemini Cloud Assist analyse le message et l'explique clairement. Il propose également des causes et des solutions potentielles.
Problèmes de performances Votre équipe constate une latence élevée pour une application qui s'exécute dans GKE. Mon service api-gateway dans le cluster GKE prod présente une latence élevée. Quelles métriques dois-je vérifier en premier ? Pouvez-vous me suggérer des causes courantes liées à GKE ? Gemini Cloud Assist suggère des métriques clés à examiner, explore les problèmes potentiels (par exemple, les contraintes de ressources ou la congestion du réseau) et recommande des outils et des techniques pour une analyse plus approfondie.
Problèmes de nœuds Un nœud GKE est bloqué avec l'état NotReady. L'un de mes nœuds GKE (node-xyz) affiche l'état NotReady. Quelles sont les étapes de dépannage habituelles ? Gemini Cloud Assist fournit un plan d'investigation détaillé, explique des concepts tels que la réparation automatique des nœuds et suggère des commandes kubectl pertinentes.
Comprendre GKE Vous n'êtes pas sûr d'une fonctionnalité GKE spécifique ou de la façon d'implémenter une bonne pratique. Quelles sont les bonnes pratiques pour sécuriser un cluster GKE ? Puis-je en savoir plus ? Gemini Cloud Assist fournit des explications claires sur les bonnes pratiques GKE. Cliquez sur Afficher le contenu associé pour afficher des liens vers la documentation officielle.

Pour en savoir plus, consultez les ressources suivantes :

Utiliser les investigations Gemini Cloud Assist

En plus du chat interactif, Gemini Cloud Assist peut effectuer des analyses plus approfondies et automatisées grâce à Gemini Cloud Assist Investigations. Cette fonctionnalité est intégrée directement aux workflows tels que l'explorateur de journaux. Il s'agit d'un outil puissant d'analyse des causes premières.

Lorsque vous lancez une investigation à partir d'une erreur ou d'une ressource spécifique, Gemini Cloud Assist analyse les journaux, les configurations et les métriques. Il utilise ces données pour générer des observations et des hypothèses classées sur les causes racines probables, puis vous fournit les prochaines étapes recommandées. Vous pouvez également transférer ces résultats vers une demande d'assistance Trusted Cloud by S3NS pour fournir un contexte utile qui peut vous aider à résoudre votre problème plus rapidement.

Pour en savoir plus, consultez Investigations Gemini Cloud Assist dans la documentation Gemini.

Synthèse : exemple de scénario de dépannage

Cet exemple montre comment utiliser une combinaison d'outils GKE pour diagnostiquer et comprendre un problème courant en conditions réelles : un conteneur qui plante à plusieurs reprises en raison d'une mémoire insuffisante.

Le scénario

Vous êtes l'ingénieur d'astreinte pour une application Web nommée product-catalog qui s'exécute dans GKE.

Votre enquête commence lorsque vous recevez une alerte automatique de Cloud Monitoring :

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

Cette alerte vous informe qu'un problème existe et qu'il est lié à la charge de travail product-catalog.

Confirmer le problème dans la console Trusted Cloud

Vous commencez par une vue d'ensemble de vos charges de travail pour confirmer le problème.

  1. Dans la console Trusted Cloud , accédez à la page Charges de travail et filtrez sur votre charge de travail product-catalog.
  2. Vous consultez la colonne d'état Pods. Au lieu de la valeur 3/3, qui indique un état opérationnel, vous voyez la valeur 2/3, qui indique un état non opérationnel. Cette valeur indique que l'un des pods de votre application n'a pas l'état Ready.
  3. Vous souhaitez en savoir plus. Vous cliquez donc sur le nom de la charge de travail product-catalog pour accéder à sa page d'informations.
  4. Sur la page des détails, vous verrez la section Pods gérés. Vous identifiez immédiatement un problème : la colonne Restarts de votre pod affiche 14, un nombre inhabituellement élevé.

Ce nombre élevé de redémarrages confirme que le problème est à l'origine de l'instabilité de l'application et suggère qu'un conteneur échoue à ses vérifications d'état ou plante.

Trouver la raison avec les commandes kubectl

Maintenant que vous savez que votre application redémarre à plusieurs reprises, vous devez en trouver la raison. La commande kubectl describe est un bon outil pour cela.

  1. Vous obtenez le nom exact du pod instable :

    kubectl get pods -n prod

    Le résultat est le suivant :

    NAME                             READY  STATUS            RESTARTS  AGE
product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m

  2. Décrivez le pod instable pour obtenir l'historique détaillé des événements :

    kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod

  3. Vous examinez le résultat et trouvez des indices dans les sections Last State et Events :

    Containers:
  product-catalog-api:
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 23 Jun 2025 10:50:15 -0700
      Finished:     Mon, 23 Jun 2025 10:54:58 -0700
    Ready:          False
    Restart Count:  14
...
Events:
  Type     Reason     Age                           From                Message
  ----     ------     ----                          ----                -------
  Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
  Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
  Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
  Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
  Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container

    Le résultat vous donne deux indices essentiels :

    • Tout d'abord, la section Last State indique que le conteneur a été arrêté avec Reason: OOMKilled, ce qui signifie qu'il a manqué de mémoire. Cette raison est confirmée par le Exit Code: 137, qui est le code de sortie Linux standard pour un processus qui a été arrêté en raison d'une consommation excessive de mémoire.
    • Ensuite, la section Events affiche un événement Warning: BackOff avec le message Back-off restarting failed container. Ce message confirme que le conteneur est dans une boucle d'échec, qui est la cause directe de l'état CrashLoopBackOff que vous avez vu précédemment.

Visualiser le comportement avec des métriques

La commande kubectl describe vous a indiqué ce qui s'est passé, mais Cloud Monitoring peut vous montrer le comportement de votre environnement au fil du temps.

  1. Dans la console Trusted Cloud , accédez à l'explorateur de métriques.
  2. Vous sélectionnez la métrique container/memory/used_bytes.
  3. Vous filtrez la sortie pour n'afficher que votre cluster, votre espace de noms et votre nom de pod spécifiques.

Le graphique montre un schéma distinct : l'utilisation de la mémoire augmente régulièrement, puis chute brusquement à zéro lorsque le conteneur est arrêté en raison d'une erreur de mémoire insuffisante et redémarre. Cette preuve visuelle confirme une fuite de mémoire ou une limite de mémoire insuffisante.

Identifier la cause dans les journaux

Vous savez maintenant que le conteneur manque de mémoire, mais vous ne savez toujours pas exactement pourquoi. Pour identifier la cause première, utilisez l'explorateur de journaux.

  1. Dans la console Trusted Cloud , accédez à l'explorateur de journaux.

  2. Vous écrivez une requête pour filtrer les journaux de votre conteneur spécifique à partir de juste avant l'heure du dernier plantage (que vous avez vu dans la sortie de la commande kubectl describe) :

    resource.type="k8s_container"
resource.labels.cluster_name="example-cluster"
resource.labels.namespace_name="prod"
resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
timestamp >= "2025-06-23T17:50:00Z"
timestamp < "2025-06-23T17:55:00Z"

  3. Dans les journaux, vous trouverez un schéma de messages récurrent juste avant chaque plantage :

    {
  "message": "Processing large image file product-image-large.jpg",
  "severity": "INFO"
},
{
  "message": "WARN: Memory cache size now at 248MB, nearing limit.",
  "severity": "WARNING"
}

Ces entrées de journal indiquent que l'application tente de traiter des fichiers image volumineux en les chargeant entièrement en mémoire, ce qui finit par épuiser la limite de mémoire du conteneur.

Résultats

En utilisant ces outils ensemble, vous obtenez une vue d'ensemble du problème :

  • L'alerte de surveillance vous a informé qu'un problème était survenu.
  • La console Trusted Cloud vous a montré que le problème affectait les utilisateurs (redémarrages).
  • Les commandes kubectl ont permis d'identifier la raison exacte des redémarrages (OOMKilled).
  • L'explorateur de métriques a visualisé le modèle de fuite de mémoire au fil du temps.
  • L'explorateur de journaux a révélé le comportement spécifique à l'origine du problème de mémoire.

Vous êtes maintenant prêt à implémenter une solution. Vous pouvez optimiser le code de l'application pour gérer les fichiers volumineux plus efficacement ou, comme solution à court terme, augmenter la limite de mémoire du conteneur (plus précisément la valeur spec.containers.resources.limits.memory) dans le fichier manifeste YAML de la charge de travail.

Étapes suivantes