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, lo que hace que los datos históricos de los registros sean invaluables.

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 un análisis de la causa raíz de los problemas en todo el clúster, auditar los cambios y comprender las tendencias de comportamiento del sistema. También es fundamental para los desarrolladores de aplicaciones, ya que les permite depurar errores específicos de las aplicaciones, hacer un seguimiento de las rutas de solicitudes y comprender cómo se comporta su código en el entorno de GKE con el 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 y tareas comunes del usuario de GKE.

Comprender 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 otrosGoogle Cloud servicios:

  • Registros de nodos y de tiempo 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.

    Debido a 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 entorno 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 la pregunta “¿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 realizadas al servidor de la API de Kubernetes, lo que es útil para diagnosticar problemas causados por cambios de configuración o acceso no autorizado.

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 kubelet y containerd suelen revelar la causa subyacente, como problemas de red o restricciones 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 anticipado y de inicio de kubelet antes de que los agentes de Logging del nodo estén completamente activos.
  • Si un Pod no se inició 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ó un Deployment crítico y nadie sabe por qué, consulta los registros de auditoría de la 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 consola de Google Cloud , accede a la página Explorador de registros.

    Ve al Explorador de registros

  2. En el panel de consultas, ingresa una consulta. Usa el lenguaje de consulta de Logging para escribir consultas segmentadas. 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 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 tiene problemas.
    • NAMESPACE_NAME: el espacio de nombres en el que se encuentra el Pod. Si no sabes 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 de 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?