Combina todas las opciones: Situación de ejemplo para solucionar problemas

Comprender las herramientas individuales de solución de problemas de Google Kubernetes Engine (GKE) es útil, pero verlas en conjunto para resolver un problema del mundo real puede ayudarte a consolidar tus conocimientos.

Sigue un ejemplo guiado que combina el uso de la consola de Google Cloud , la herramienta de línea de comandos de kubectl, Cloud Logging y Cloud Monitoring para identificar la causa raíz de un error de OutOfMemory (OOMKilled).

Este ejemplo es beneficioso para cualquier persona que desee ver una aplicación práctica de las técnicas de solución de problemas que se describen en esta serie, en particular, los administradores y operadores de plataformas, y los desarrolladores de aplicaciones. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que hacemos referencia en el contenido deGoogle Cloud , consulta Roles de usuario y tareas comunes de GKE.

La situación

Eres el ingeniero de guardia de una app web llamada product-catalog que se ejecuta en GKE.

La investigación comienza cuando recibes una alerta automática de Cloud Monitoring:

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

Esta alerta te indica que existe un problema y que este tiene relación con la carga de trabajo product-catalog.

Confirma el problema en la consola de Google Cloud

Comienzas con una vista general de tus cargas de trabajo para confirmar el problema.

  1. En la consola de Google Cloud , navega a la página Cargas de trabajo y filtra por tu carga de trabajo de product-catalog.
  2. Consulta la columna de estado de Pods. En lugar del 3/3 en buen estado, verás que el valor muestra constantemente un estado no saludable: 2/3. Este valor indica que uno de los Pods de tu app no tiene el estado Ready.
  3. Quieres investigar más, por lo que haces clic en el nombre de la carga de trabajo product-catalog para ir a su página de detalles.
  4. En la página de detalles, verás la sección Pods administrados. Identificas un problema de inmediato: la columna Restarts de tu Pod muestra 14, un número inusualmente alto.

Este recuento alto de reinicios confirma que el problema está causando inestabilidad en la app y sugiere que un contenedor está fallando en sus verificaciones de estado o fallando.

Cómo encontrar el motivo con los comandos de kubectl

Ahora que sabes que tu app se reinicia repetidamente, debes averiguar por qué. El comando kubectl describe es una buena herramienta para esto.

  1. Obtendrás el nombre exacto del Pod inestable:

    kubectl get pods -n prod

    Esta es la salida:

    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. Describe el Pod inestable para obtener el historial detallado de eventos:

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

  3. Revisas el resultado y encuentras pistas en las secciones Last State y 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

    El resultado te brinda dos pistas fundamentales:

    • En primer lugar, la sección Last State muestra que el contenedor se cerró con Reason: OOMKilled, lo que indica que se quedó sin memoria. Esta razón se confirma con el Exit Code: 137, que es el código de salida estándar de Linux para un proceso que se cerró debido a un consumo excesivo de memoria.
    • En segundo lugar, la sección Events muestra un evento Warning: BackOff con el mensaje Back-off restarting failed container. Este mensaje confirma que el contenedor se encuentra en un bucle de errores, que es la causa directa del estado CrashLoopBackOff que viste antes.

Visualiza el comportamiento con métricas

El comando kubectl describe te indicó lo que sucedió, pero Cloud Monitoring puede mostrarte el comportamiento de tu entorno a lo largo del tiempo.

  1. En la consola de Google Cloud , ve al Explorador de métricas.
  2. Selecciona la métrica container/memory/used_bytes.
  3. Filtra el resultado para que se muestre tu clúster, espacio de nombres y nombre de Pod específicos.

El gráfico muestra un patrón distinto: el uso de memoria aumenta de forma constante y, luego, cae abruptamente a cero cuando el contenedor se cierra por falta de memoria y se reinicia. Esta evidencia visual confirma una pérdida de memoria o un límite de memoria insuficiente.

Cómo encontrar la causa raíz en los registros

Ahora sabes que el contenedor se está quedando sin memoria, pero aún no sabes exactamente por qué. Para descubrir la causa raíz, usa el Explorador de registros.

  1. En la consola de Google Cloud , navega al Explorador de registros.

  2. Escribe una consulta para filtrar los registros de tu contenedor específico desde justo antes de la hora de la última falla (que viste en el resultado del comando 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. En los registros, encuentras un patrón repetitivo de mensajes justo antes de cada falla:

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

Estas entradas de registro indican que la app intenta procesar archivos de imágenes grandes cargándolos por completo en la memoria, lo que, finalmente, agota el límite de memoria del contenedor.

Los hallazgos

Si usas las herramientas en conjunto, obtendrás una imagen completa del problema:

  • La alerta de supervisión te notificó que había un problema.
  • La consola de Google Cloud te mostró que el problema afectaba a los usuarios (reinicios).
  • Los comandos kubectl indicaron el motivo exacto de los reinicios (OOMKilled).
  • El Explorador de métricas visualizó el patrón de pérdida de memoria a lo largo del tiempo.
  • El Explorador de registros reveló el comportamiento específico que causa el problema de memoria.

Ya tienes todo listo para implementar una solución. Puedes optimizar el código de la app para controlar archivos grandes de manera más eficiente o, como solución a corto plazo, aumentar el límite de memoria del contenedor (específicamente, el valor de spec.containers.resources.limits.memory) en el manifiesto YAML de la carga de trabajo.

¿Qué sigue?