Analizar todos los datos en conjunto: ejemplo de solución de problemas

Conocer las herramientas de solución de problemas de Google Kubernetes Engine (GKE) es útil, pero ver cómo se usan juntas para resolver un problema real puede ayudarte a consolidar tus conocimientos.

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

Este ejemplo es útil para cualquier persona que quiera ver una aplicación práctica de las técnicas de solución de problemas descritas en esta serie, especialmente para administradores y operadores de plataformas, así como para desarrolladores de aplicaciones. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas de usuario habituales de GKE.

Situación

Eres el ingeniero de guardia de una aplicación 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 informa de que hay un problema e indica que está relacionado con la carga de trabajo de product-catalog.

Confirmar el problema en la consola Google Cloud

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

  1. En la Google Cloud consola, ve a la página Cargas de trabajo y filtra por tu carga de trabajo product-catalog.
  2. Consulta la columna de estado Pods. En lugar de 3/3, verá que el valor muestra un estado no correcto: 2/3. Este valor indica que uno de los pods de tu aplicación no tiene el estado Ready.
  3. Quieres investigar más a fondo, así que haces clic en el nombre de la carga de trabajo product-catalogpara ir a su página de detalles.
  4. En la página de detalles, verás la sección Pods gestionados. Identificas un problema de inmediato: la columna Restarts de tu pódcast muestra 14, un número inusualmente alto.

Este elevado número de reinicios confirma que el problema está provocando inestabilidad en la aplicación y sugiere que un contenedor no está superando las comprobaciones de estado o que está fallando.

Buscar el motivo con los comandos de kubectl

Ahora que sabes que tu aplicación se reinicia repetidamente, debes averiguar por qué. El comando kubectl describe es una buena herramienta para ello.

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

    kubectl get pods -n prod

    El resultado es el siguiente:

    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 de eventos detallado:

    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 da dos pistas cruciales:

    • En primer lugar, la sección Last State muestra que el contenedor se ha terminado con Reason: OOMKilled, lo que indica que se ha quedado sin memoria. Esta razón se confirma con Exit Code: 137, que es el código de salida estándar de Linux para un proceso que se ha cancelado 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 está en un bucle de errores, que es la causa directa del estado CrashLoopBackOff que has visto antes.

Visualizar el comportamiento con métricas

El comando kubectl describe te ha informado de lo que ha ocurrido, pero Cloud Monitoring puede mostrarte el comportamiento de tu entorno a lo largo del tiempo.

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

El gráfico muestra un patrón claro: el uso de memoria aumenta de forma constante y, a continuación, cae bruscamente a cero cuando el contenedor se cierra por falta de memoria y se reinicia. Esta prueba visual confirma que hay una fuga de memoria o que el límite de memoria es insuficiente.

Buscar 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 principal, usa el Explorador de registros.

  1. En la Google Cloud consola, ve a Explorador de registros.

  2. Escribe una consulta para filtrar los registros de tu contenedor específico justo antes de la hora del último fallo (que has visto 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, encontrarás un patrón repetitivo de mensajes justo antes de cada fallo:

    {
  "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 aplicación está intentando procesar archivos de imagen grandes cargándolos por completo en la memoria, lo que acaba agotando el límite de memoria del contenedor.

Resultados

Si usas las herramientas juntas, tendrás una visión completa del problema:

  • La alerta de monitorización te ha avisado de que había un problema.
  • La Google Cloud consola te ha mostrado que el problema afectaba a los usuarios (reinicios).
  • Los comandos kubectl han determinado el motivo exacto de los reinicios (OOMKilled).
  • El explorador de métricas visualizó el patrón de fuga de memoria a lo largo del tiempo.
  • Explorador de registros reveló el comportamiento específico que provocaba el problema de memoria.

Ya puedes implementar una solución. Puedes optimizar el código de la aplicación para gestionar archivos grandes de forma más eficiente o, como solución a corto plazo, aumentar el límite de memoria del contenedor (concretamente, el valor spec.containers.resources.limits.memory) en el manifiesto YAML de la carga de trabajo.

Siguientes pasos