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 Google Cloud console, de l'outil de ligne de commande kubectl Cloud Logging et Cloud Monitoring ensemble 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 Google Cloud contenu, consultez Rôles utilisateur et tâches courantes de GKE.

Scénario

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

Votre enquête commence lorsque vous recevez une alerte automatisée de Cloud Monitoring :

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

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

Confirmer le problème dans la Google Cloud console

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

  1. Dans la Google Cloud console, accédez à la page Workloads (Charges de travail) et filtrez votre charge de travail product-catalog.
  2. Examinez la colonne d'état Pods. Au lieu de l'état sain 3/3, vous voyez que la valeur affiche un état non sain : 2/3. Cette valeur indique que l'un des pods de votre application n'a pas l'état Ready.
  3. Pour en savoir plus, cliquez sur le nom de la charge de travail product-catalog pour accéder à sa page d'informations.
  4. Sur la page d'informations, affichez la section Managed Pods (Pods gérés). Vous identifiez immédiatement un problème : la colonne Restarts (Redémarrages) 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. Vous 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 (Dernier état) et Events (Événements) :

    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 (Dernier état) 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 (Événements) affiche un événement Warning: BackOff avec le message Back-off restarting failed container (Échec du redémarrage du conteneur). 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 Google Cloud console, accédez à Metrics Explorer (Explorateur de métriques).
  2. Sélectionnez la métrique container/memory/used_bytes.
  3. Filtrez le résultat en fonction de votre cluster, de votre espace de noms et du nom de votre pod.

Le graphique affiche un schéma distinct : l'utilisation de la mémoire augmente de manière constante, puis chute brusquement à zéro lorsque le conteneur est arrêté par OOM et redémarre. Cette preuve visuelle confirme une fuite de mémoire ou une limite de mémoire insuffisante.

Trouver la cause première dans les journaux

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

  1. Dans la Google Cloud console, accédez à Logs Explorer (Explorateur de journaux).

  2. Écrivez une requête pour filtrer les journaux de votre conteneur spécifique juste avant l'heure du dernier plantage (que vous avez vu dans le résultat 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épétitif 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.

Les résultats

En utilisant les outils ensemble, vous obtenez une image complète du problème :

  • L'alerte de surveillance vous a informé qu'il y avait un problème.
  • La Google Cloud console vous a montré que le problème affectait les utilisateurs (redémarrages).
  • Les commandes kubectl ont identifié 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, à titre de solution à court terme, augmenter la limite de mémoire du conteneur (en particulier la valeur spec.containers.resources.limits.memory) dans le fichier manifeste YAML de la charge de travail.

Étape suivante