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

Il est utile de comprendre les outils de dépannage individuels pour Google Kubernetes Engine (GKE), mais les voir utilisés ensemble pour résoudre un problème concret peut vous aider à consolider vos connaissances.

Suivez un exemple guidé qui combine l'utilisation de la console Google Cloud , de l'outil de ligne de commande kubectl, de Cloud Logging et de Cloud Monitoring pour identifier la cause première d'une erreur OutOfMemory (OOMKilled).

Cet exemple est utile pour tous ceux qui souhaitent voir une application pratique des techniques de dépannage décrites dans cette série, en particulier les administrateurs et opérateurs de plate-forme, ainsi que les développeurs d'applications. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

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

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

  1. Dans la console Google 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 l'état sain 3/3, la valeur indique un état non opérationnel : 2/3. 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 pouvez consulter 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 de l'é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 Google 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 le cluster, l'espace de noms et le 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 Google 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 Google 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 schéma 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