Realiza análisis históricos con Cloud Logging

Cuando un Pod falla o un servicio no funciona como se espera en Google Kubernetes Engine (GKE), es fundamental comprender la secuencia de eventos que llevaron al problema. Inspeccionar el estado actual no siempre es suficiente para encontrar la causa raíz, por lo que los datos históricos de registro son muy valiosos.

Usa esta página para aprender a usar Cloud Logging y, así, investigar fallas anteriores (por ejemplo, por qué no se inició un Pod o quién borró una Deployment crítica) consultando y analizando los registros de GKE.

Esta información es importante para los administradores y operadores de la plataforma que necesitan realizar análisis de causa raíz sobre problemas en todo el clúster, auditar cambios y comprender las tendencias de comportamiento del sistema. También es fundamental para los desarrolladores de aplicaciones depurar errores específicos de la aplicación, hacer un seguimiento de las rutas de solicitudes y comprender cómo se comporta su código en el entorno de GKE a lo largo del tiempo. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles de usuario y tareas comunes de GKE.

Comprende los tipos de registros clave para solucionar problemas

Para ayudarte a solucionar problemas, Cloud Logging recopila y agrega automáticamente varios tipos de registros clave de tus clústeres de GKE, apps en contenedores y otros servicios deGoogle Cloud :

  • Registros de nodos y del entorno de ejecución (kubelet, containerd): Son los registros de los servicios de nodos subyacentes. Dado que kubelet administra el ciclo de vida de todos los Pods en el nodo, sus registros son esenciales para solucionar problemas como los inicios de contenedores, los eventos de memoria insuficiente (OOM), las fallas de sondeo y los errores de montaje de volúmenes. Estos registros también son fundamentales para diagnosticar problemas a nivel del nodo, como un nodo que tiene un estado NotReady.

    Dado que containerd administra el ciclo de vida de tus contenedores, incluida la extracción de imágenes, sus registros son fundamentales para solucionar problemas que ocurren antes de que kubelet pueda iniciar el contenedor. Los registros de containerd te ayudan a diagnosticar problemas a nivel del nodo en GKE, ya que documentan las actividades específicas y los posibles errores del tiempo de ejecución del contenedor.

  • Registros de la app (stdout, stderr): Son los flujos de salida y error estándar de tus procesos en contenedores. Estos registros son esenciales para depurar problemas específicos de la app, como fallas, errores o comportamientos inesperados.

  • Registros de auditoría: Estos registros responden las preguntas “¿Quién hizo qué, dónde y cuándo?” para tu clúster. Realizan un seguimiento de las acciones administrativas y las llamadas a la API que se realizan en el servidor de la API de Kubernetes, lo que resulta útil para diagnosticar problemas causados por cambios en la configuración o accesos no autorizados.

Situaciones comunes de solución de problemas

Después de identificar un problema, puedes consultar estos registros para averiguar qué sucedió. Para ayudarte a comenzar, revisar los registros puede ayudarte con los siguientes problemas:

  • Si un nodo tiene el estado NotReady, revisa sus registros. Los registros de kubelet y containerd suelen revelar la causa subyacente, como problemas de red o limitaciones de recursos.
  • Si un nodo nuevo no se aprovisiona ni se une al clúster, revisa los registros del puerto en serie del nodo. Estos registros capturan la actividad de inicio temprano y de kubelet antes de que los agentes de registro del nodo estén completamente activos.
  • Si un Pod no se pudo iniciar en el pasado, revisa los registros de la app para ese Pod y verifica si hubo fallas. Si los registros están vacíos o no se puede programar el Pod, revisa los registros de auditoría para detectar eventos relevantes o los registros de nodos en el nodo de destino para obtener pistas sobre la presión de recursos o los errores de extracción de imágenes.
  • Si se borró una Deployment crítica y nadie sabe por qué, consulta los registros de auditoría de actividad del administrador. Estos registros pueden ayudarte a identificar qué usuario o cuenta de servicio emitió la llamada a la API de eliminación, lo que proporciona un punto de partida claro para tu investigación.

Cómo acceder a los registros

Usa el Explorador de registros para consultar, ver y analizar los registros de GKE en la consola de Google Cloud . El Explorador de registros proporciona potentes opciones de filtrado que te ayudan a aislar el problema.

Para acceder al Explorador de registros y usarlo, completa los siguientes pasos:

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

    Ir al Explorador de registros

  2. En el panel de consultas, ingresa una consulta. Usa el lenguaje de consulta de Logging para escribir consultas específicas. Estos son algunos filtros comunes para comenzar:

    Tipo de filtro Descripción Valor de ejemplo
    resource.type Es el tipo de recurso de Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Es el flujo de registros del recurso. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtra los recursos con un nombre específico.
    Reemplaza RESOURCE_TYPE por el nombre del recurso que deseas consultar. Por ejemplo: namespace o pod.    		 example-namespace-name, example-pod-name
    severity Es el nivel de gravedad del registro. DEFAULT, INFO, WARNING, ERROR, CRITICAL
    jsonPayload.message=~ Es una búsqueda de expresión regular para el texto dentro del mensaje de registro. scale.down.error.failed.to.delete.node.min.size.reached

    Por ejemplo, para solucionar problemas relacionados con un Pod específico, tal vez quieras aislar sus registros de errores. Para ver solo los registros con una gravedad ERROR para ese Pod, usa la siguiente consulta:

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

    Reemplaza lo siguiente:

    • POD_NAME: Es el nombre del Pod que experimenta problemas.
    • NAMESPACE_NAME: Es el espacio de nombres en el que se encuentra el Pod. Si no sabes con certeza cuál es el espacio de nombres, revisa la columna Namespace del resultado del comando kubectl get pods.

    Para obtener más ejemplos, consulta Consultas relacionadas con Kubernetes en la documentación de Google Cloud Observability.

  3. Haz clic en Ejecutar consulta.

  4. Para ver el mensaje de registro completo, incluida la carga útil JSON, los metadatos y la marca de tiempo, haz clic en la entrada de registro.

Para obtener más información sobre los registros de GKE, consulta Acerca de los registros de GKE.

¿Qué sigue?