Introducción a la solución de problemas de GKE

En esta página, se presentan técnicas básicas de solución de problemas para Google Kubernetes Engine (GKE). Esta página está dirigida a los usuarios que no tienen experiencia con Kubernetes y GKE, y que desean aprender prácticas eficaces para solucionar problemas.

En esta página, se proporciona una descripción general de las siguientes herramientas y técnicas para supervisar, diagnosticar y resolver problemas relacionados con GKE:

Comprende los conceptos básicos

Si no conoces Kubernetes ni GKE, es fundamental que comprendas los conceptos básicos, como la arquitectura de clústeres y la relación entre los Pods y los nodos, antes de comenzar a solucionar problemas. Si quieres obtener más información, consulta Comienza a aprender sobre GKE.

También es útil comprender qué partes de GKE eres responsable de mantener y qué partes Trusted Cloud by S3NS es responsable de mantener. Para obtener más información, consulta Responsabilidad compartida de GKE.

Revisa el estado del clúster y la carga de trabajo en la consola de Trusted Cloud

La consola de Trusted Cloud es un buen punto de partida para solucionar problemas, ya que proporciona una vista rápida del estado de tus clústeres y cargas de trabajo. El estado del clúster hace referencia al estado de la infraestructura subyacente de GKE, como los nodos y las redes, mientras que el estado de la carga de trabajo hace referencia al estado y el rendimiento de las apps que se ejecutan en el clúster.

En las siguientes secciones, se describen las páginas de clúster y de cargas de trabajo. Para brindarte una visión completa del estado de tu app, la Trusted Cloud consola también te da acceso a potentes herramientas de registro y supervisión, lo que te permite investigar la causa raíz de los errores pasados y evitar de forma proactiva los futuros. Para obtener más información sobre estas herramientas, consulta las secciones Realiza análisis históricos con Cloud Logging y Realiza un monitoreo proactivo con Cloud Monitoring.

Cómo encontrar problemas de clústeres

La página Clústeres de Kubernetes te proporciona una descripción general del estado de tus clústeres. Para identificar problemas con cualquiera de tus clústeres, comienza en esta página.

Estos son algunos ejemplos de cómo puedes usar esta página para solucionar problemas:

  • Para obtener asesoramiento sobre cómo mejorar el estado de tu clúster, tu estrategia de actualización y la optimización de costos, haz clic en Ver recomendaciones.
  • Para identificar los clústeres en mal estado, revisa la columna Estado. Cualquier clúster que no tenga una marca de verificación verde requiere atención.
  • Para ver los posibles problemas, revisa la columna Notificaciones. Haz clic en cualquier mensaje de notificación para obtener más información.

Investiga un clúster específico

Después de detectar un problema con un clúster, explora la página Detalles del clúster para obtener información detallada que te ayude a solucionar el problema y comprender su configuración.

Para ir a la página Detalles de un clúster, haz lo siguiente:

  1. Ir a la página Clústeres de Kubernetes

    Ir a clústeres de Kubernetes

  2. Revisa la columna Nombre y haz clic en el nombre del clúster que deseas investigar.

Estos son algunos ejemplos de cómo usar la página Detalles del clúster para solucionar problemas relacionados con él:

  • Para las verificaciones de estado generales, prueba las siguientes opciones:

    • Para ver los paneles a nivel del clúster, ve a la pestaña Observabilidad. De forma predeterminada, GKE habilita Cloud Monitoring cuando creas un clúster. Cuando Cloud Monitoring está habilitado, GKE configura automáticamente los paneles en esta página. Estas son algunas de las vistas que pueden resultarte más útiles para solucionar problemas:

      • Descripción general: Consulta un resumen de alto nivel del estado, el uso de recursos y los eventos clave de tu clúster. Este panel te ayuda a evaluar rápidamente el estado general de tu clúster y a identificar posibles problemas.
      • Métricas de tráfico: Consulta las métricas de redes basadas en nodos para obtener estadísticas sobre el tráfico entre tus cargas de trabajo de Kubernetes.
      • Estado de la carga de trabajo: Consulta el estado de las implementaciones, los Pods y los contenedores. Identificar instancias en mal estado o con fallas, y detectar limitaciones de recursos

      • Plano de control: Consulta el estado y el rendimiento del plano de control. Este panel te permite supervisar las métricas clave de los componentes, como kube-apiserver y etcd, identificar cuellos de botella en el rendimiento y detectar fallas en los componentes.

    • Para ver los errores recientes de la app, ve a la pestaña Errores de la app. La información de esta pestaña puede ayudarte a priorizar y resolver errores, ya que muestra la cantidad de ocurrencias, cuándo apareció un error por primera vez y cuándo ocurrió por última vez.

      Para investigar un error más a fondo, haz clic en el mensaje de error para ver un informe detallado, incluidos los vínculos a los registros pertinentes.

  • Si estás solucionando problemas después de una actualización o un cambio recientes, consulta la sección Conceptos básicos del clúster en la pestaña Detalles del clúster. Confirma que la versión que aparece en el campo Versión sea la que esperas. Para investigar más, haz clic en Mostrar historial de actualizaciones en la sección Actualizaciones.

  • Si usas un clúster estándar y tus Pods están atascados en un estado Pending, o sospechas que los nodos están sobrecargados, consulta la pestaña Nodos. La pestaña Nodos no está disponible para los clústeres de Autopilot porque GKE administra los nodos por ti.

    • En la sección Grupos de nodos, verifica que el ajuste de escala automático esté configurado correctamente y que el tipo de máquina sea adecuado para tus cargas de trabajo.
    • En la sección Nodos, busca cualquier nodo con un estado que no sea Ready. El estado NotReady indica un problema con el nodo en sí, como presión de recursos o un problema con kubelet (kubelet es el agente que se ejecuta en cada nodo para administrar contenedores).

Cómo encontrar problemas de cargas de trabajo

Cuando sospeches que hay un problema con una app específica, como una Deployment fallida, ve a la página Cargas de trabajo en la consola de Trusted Cloud . En esta página, se proporciona una vista centralizada de todas las apps que se ejecutan en tus clústeres.

Estos son algunos ejemplos de cómo puedes usar esta página para solucionar problemas:

  • Para identificar las cargas de trabajo en mal estado, revisa la columna Estado. Cualquier carga de trabajo que no tenga una marca de verificación verde requiere atención.
  • Si una app no responde, revisa la columna Pods. Por ejemplo, un estado como 1/3 significa que solo se está ejecutando una de las tres réplicas de la app, lo que indica un problema.

Investiga una carga de trabajo específica

Después de identificar una carga de trabajo problemática en el resumen, explora la página Detalles de la carga de trabajo para comenzar a aislar la causa raíz.

Para ir a la página Detalles de una carga de trabajo, haz lo siguiente:

  1. Ir a la página Cargas de trabajo.

    Ir a Cargas de trabajo

  2. Consulta la columna Nombre y haz clic en el nombre de la carga de trabajo que deseas investigar.

A continuación, se incluyen algunos ejemplos de cómo usar la página Detalles de la carga de trabajo para solucionar problemas relacionados con tus cargas de trabajo:

  • Para verificar la configuración de la carga de trabajo, usa las pestañas Descripción general y Detalles de la carga de trabajo. Puedes usar esta información para verificar eventos, como si se implementó la etiqueta de imagen de contenedor correcta, o para verificar las solicitudes y los límites de recursos de la carga de trabajo.

  • Para encontrar el nombre de un Pod específico con fallas, ve a la sección Managed Pods. Es posible que necesites esta información para los comandos de kubectl. En esta sección, se enumeran todos los Pods controlados por la carga de trabajo, junto con sus estados. Para ver un historial de los cambios recientes en una carga de trabajo, ve a la pestaña Historial de revisión. Si observas problemas de rendimiento después de una implementación nueva, usa esta sección para identificar qué revisión está activa. Luego, puedes comparar la configuración de la revisión actual con las anteriores para identificar el origen del problema. Si esta pestaña no está visible, la carga de trabajo es de un tipo que no usa revisiones o aún no tuvo ninguna actualización.

  • Si parece que falló una Deployment, ve a la pestaña Eventos. Esta página suele ser la fuente de información más valiosa, ya que muestra eventos a nivel de Kubernetes.

  • Para consultar los registros de tu app, haz clic en la pestaña Registros. En esta página, se explica lo que sucede dentro de tu clúster. Aquí puedes buscar mensajes de error y seguimientos de pila que pueden ayudarte a diagnosticar problemas.

  • Para confirmar exactamente lo que se implementó, consulta la pestaña YAML. En esta página, se muestra el manifiesto YAML activo de la carga de trabajo tal como existe en el clúster. Esta información es útil para encontrar cualquier discrepancia en los manifiestos controlados por la fuente. Si estás viendo el manifiesto YAML de un solo Pod, esta pestaña también muestra el estado del Pod, lo que proporciona estadísticas sobre las fallas a nivel del Pod.

Investiga el estado del clúster con la herramienta de línea de comandos de kubectl

Si bien la consola Trusted Cloud te ayuda a comprender si hay un problema, la herramienta de línea de comandoskubectles fundamental para descubrir por qué. Al comunicarse directamente con el plano de control de Kubernetes, la herramienta de línea de comandos de kubectl te permite recopilar la información detallada que necesitas para solucionar problemas en tu entorno de GKE.

En las siguientes secciones, se presentan algunos comandos esenciales que son un punto de partida eficaz para solucionar problemas de GKE.

Antes de comenzar

Antes de comenzar, realiza las siguientes tareas:

  • Instala kubectl.

  • Configura la herramienta de línea de comandos de kubectl para que se comunique con tu clúster:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.
    • LOCATION: Es la ubicación de Compute Engine del plano de control de tu clúster. Proporciona una región para los clústeres regionales o una zona para los clústeres zonales.

  • Revisa tus permisos. Para ver si tienes los permisos necesarios para ejecutar comandos kubectl, usa el comando kubectl auth can-i. Por ejemplo, para ver si tienes permiso para ejecutar kubectl get nodes, ejecuta el comando kubectl auth can-i get nodes.

    Si tienes los permisos necesarios, el comando devolverá yes; de lo contrario, devolverá no.

    Si no tienes permiso para ejecutar un comando kubectl, es posible que veas un mensaje de error similar al siguiente:

    Error from server (Forbidden): pods "POD_NAME" is forbidden: User
"USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
namespace "default"

    Si no tienes los permisos necesarios, pídele al administrador del clúster que te asigne los roles necesarios.

Obtén una descripción general de lo que se está ejecutando

El comando kubectl get te ayuda a ver una vista general de lo que sucede en tu clúster. Usa los siguientes comandos para ver el estado de dos de los componentes del clúster más importantes: los nodos y los Pods:

  1. Para verificar si tus nodos están en buen estado, consulta los detalles de todos los nodos y sus estados:

    kubectl get nodes

    El resultado es similar a este:

    NAME                                        STATUS   ROLES    AGE     VERSION

gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003

    Cualquier estado que no sea Ready requiere una investigación adicional.

  2. Para verificar si tus Pods están en buen estado, consulta los detalles de todos los Pods y sus estados:

    kubectl get pods --all-namespaces

    El resultado es similar a este:

    NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
kube-system netd-6nbsq 3/3     Running     0          4d23h
kube-system netd-g7tpl 3/3     Running     0          4d23h

    Cualquier estado que no sea Running requiere una investigación adicional. A continuación, se indican algunos estados comunes que podrías ver:

    • Running: Un estado de ejecución correcto.
    • Pending: El Pod está esperando a que se programe en un nodo.
    • CrashLoopBackOff: Los contenedores del Pod fallan repetidamente en un bucle porque la app se inicia, sale con un error y, luego, Kubernetes la reinicia.
    • ImagePullBackOff: El Pod no puede extraer la imagen del contenedor.

Los comandos anteriores son solo dos ejemplos de cómo puedes usar el comando kubectl get. También puedes usar el comando para obtener más información sobre muchos tipos de recursos de Kubernetes. Para obtener una lista completa de los recursos que puedes explorar, consulta kubectl get en la documentación de Kubernetes.

Más información sobre recursos específicos

Después de identificar un problema, debes obtener más detalles. Un ejemplo de problema podría ser un Pod que no tiene el estado Running. Para obtener más detalles, usa el comando kubectl describe.

Por ejemplo, para describir un Pod específico, ejecuta el siguiente comando:

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Reemplaza lo siguiente:

  • POD_NAME: Es el nombre del Pod que tiene 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.

El resultado del comando kubectl describe incluye información detallada sobre tu recurso. Estas son algunas de las secciones más útiles que puedes revisar cuando solucionas problemas de un Pod:

  • Status: Es el estado actual del Pod.
  • Conditions: Es el estado general y la preparación del Pod.
  • Restart Count: Indica cuántas veces se reiniciaron los contenedores en el Pod. Las cifras altas pueden ser motivo de preocupación.
  • Events: Es un registro de los eventos importantes que le sucedieron a este Pod, como la programación en un nodo, la extracción de su imagen de contenedor y si se produjo algún error. En la sección Events, a menudo, puedes encontrar las pistas directas sobre por qué falla un Pod.

Al igual que el comando kubectl get, puedes usar el comando kubectl describe para obtener más información sobre varios tipos de recursos. Para obtener una lista completa de los recursos que puedes explorar, consulta kubectl describe en la documentación de Kubernetes.

Realiza análisis históricos con Cloud Logging

Si bien la herramienta de línea de comandos kubectl es muy valiosa para inspeccionar el estado activo de tus objetos de Kubernetes, su vista suele limitarse al momento presente. Para comprender la causa raíz de un problema, a menudo debes investigar qué sucedió con el tiempo. Cuando necesites ese contexto histórico, usa Cloud Logging.

Cloud Logging agrega registros de tus clústeres de GKE, apps en contenedores y otros Trusted Cloud servicios.

Comprende los tipos de registros clave para solucionar problemas

Cloud Logging recopila automáticamente varios tipos de registros de GKE que pueden ayudarte a solucionar problemas:

  • 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 Trusted 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 Trusted 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.

Realiza una supervisión proactiva con Cloud Monitoring

Después de que ocurre un problema, revisar los registros es un paso fundamental para solucionarlo. Sin embargo, un sistema verdaderamente resiliente también requiere un enfoque proactivo para identificar problemas antes de que causen una interrupción.

Para identificar de forma proactiva problemas futuros y hacer un seguimiento de los indicadores clave de rendimiento a lo largo del tiempo, usa Cloud Monitoring. Cloud Monitoring proporciona paneles, métricas y capacidades de alertas. Estas herramientas te ayudan a encontrar tasas de error en aumento, latencia creciente o limitaciones de recursos, lo que te permite actuar antes de que se vean afectados los usuarios.

Revisa las métricas útiles

GKE envía automáticamente un conjunto de métricas a Cloud Monitoring. En las siguientes secciones, se enumeran algunas de las métricas más importantes para la solución de problemas:

Para obtener una lista completa de las métricas de GKE, consulta Métricas del sistema de GKE.

Métricas de rendimiento y estado del contenedor

Comienza con estas métricas cuando sospeches que hay un problema con una app específica. Estas métricas te ayudan a supervisar el estado de tu app, lo que incluye descubrir si un contenedor se reinicia con frecuencia, se queda sin memoria o se limita debido a los límites de la CPU.

Métrica Descripción Importancia de la solución de problemas
kubernetes.io/container/cpu/limit_utilization La parte del límite de CPU que actualmente usa la instancia. Este valor puede ser superior a 1, ya que es posible que se permita que un contenedor exceda su límite de CPU. Identifica la limitación de la CPU. Los valores altos pueden provocar una degradación del rendimiento.
kubernetes.io/container/memory/limit_utilization La parte del límite de la memoria que actualmente usa la instancia. Este valor no puede ser superior a 1. Supervisa el riesgo de errores de memoria insuficiente (OOM).
kubernetes.io/container/memory/used_bytes Es la memoria real que consume el contenedor en bytes. Realiza un seguimiento del consumo de memoria para identificar posibles fugas de memoria o riesgo de errores OOM.
kubernetes.io/container/memory/page_fault_count Cantidad de fallas de página, desglosadas por tipo: principales y secundarias. Indica una presión de memoria significativa. Los errores de página graves significan que se está leyendo memoria del disco (intercambio), incluso si no se alcanzan los límites de memoria.
kubernetes.io/container/restart_count La cantidad de veces que se ha reiniciado el contenedor. Destaca los posibles problemas, como fallas en las apps, errores de configuración o agotamiento de recursos, a través de una cantidad alta o en aumento de reinicios.
kubernetes.io/container/ephemeral_storage/used_bytes Uso de almacenamiento efímero local expresado en bytes. Supervisa el uso del disco temporal para evitar el desalojo de Pods debido al almacenamiento efímero completo.
kubernetes.io/container/cpu/request_utilization La parte de la CPU solicitada que está en uso en la instancia. Este valor puede ser superior a 1, puesto que el uso puede exceder la solicitud. Identifica las solicitudes de CPU con exceso o falta de aprovisionamiento para ayudarte a optimizar la asignación de recursos.
kubernetes.io/container/memory/request_utilization La parte de la memoria solicitada que está en uso en la instancia. Este valor puede ser superior a 1, puesto que el uso puede exceder la solicitud. Identifica las solicitudes de memoria con aprovisionamiento excesivo o insuficiente para mejorar la programación y evitar errores de OOM.

Métricas de rendimiento y estado del nodo

Examina estas métricas cuando necesites diagnosticar problemas con la infraestructura subyacente de GKE. Estas métricas son fundamentales para comprender el estado general y la capacidad de tus nodos, y te ayudan a investigar si un nodo no está en buen estado o está bajo presión, o si tiene suficiente memoria para programar nuevos Pods.

Métrica Descripción Importancia de la solución de problemas
kubernetes.io/node/cpu/allocatable_utilization La parte de la CPU asignable que está en uso en la instancia. Indica si la suma del uso de Pods está sobrecargando los recursos de CPU disponibles del nodo.
kubernetes.io/node/memory/allocatable_utilization La parte de la memoria asignable que está en uso en la instancia. Este valor no puede ser superior a 1, puesto que el uso no puede ser mayor que los bytes de memoria asignable. Sugiere que el nodo no tiene memoria para programar Pods nuevos o para que operen los Pods existentes, en especial cuando los valores son altos.
kubernetes.io/node/status_condition (BETA) Es la condición de un nodo del campo de condición de estado del nodo. Informa las condiciones de salud del nodo, como Ready, MemoryPressure o DiskPressure.
kubernetes.io/node/ephemeral_storage/used_bytes La cantidad de bytes del almacenamiento efímero local que usó el nodo. Ayuda a evitar fallas en el inicio o desalojos de Pods, ya que proporciona advertencias sobre el uso elevado del almacenamiento efímero.
kubernetes.io/node/ephemeral_storage/inodes_free Cantidad de nodos de índice (inodos) libres en el almacenamiento efímero local. Supervisa la cantidad de inodos libres. Quedarse sin inodos puede detener las operaciones incluso si hay espacio disponible en el disco.
kubernetes.io/node/interruption_count (BETA) Las interrupciones son desalojos del sistema de la infraestructura mientras el cliente tiene el control de ella. Esta métrica es el recuento actual de interrupciones por tipo y motivo. Explica por qué un nodo puede desaparecer de forma inesperada debido a desalojos del sistema.

Métricas de rendimiento y estado del pod

Estas métricas te ayudan a solucionar problemas relacionados con la interacción de un Pod con su entorno, como la red y el almacenamiento. Usa estas métricas cuando necesites diagnosticar Pods que tardan en iniciarse, investigar posibles problemas de conectividad de red o administrar el almacenamiento de forma proactiva para evitar errores de escritura por volúmenes llenos.

Métrica Descripción Importancia de la solución de problemas
kubernetes.io/pod/network/received_bytes_count Cantidad acumulada de bytes que recibió el Pod a través de la red. Identifica la actividad de red inusual (alta o baja) que puede indicar problemas de la app o de la red.
kubernetes.io/pod/network/policy_event_count (BETA) Cambio en la cantidad de eventos de política de red que se observan en el plano de datos. Identifica los problemas de conectividad causados por las políticas de red.
kubernetes.io/pod/volume/utilization La parte del volumen que la instancia usa actualmente. Este valor no puede ser mayor que 1, puesto que el uso no puede superar la cantidad de espacio total disponible. Permite la administración proactiva del espacio de volumen, ya que advierte cuando un uso elevado (cercano a 1) podría generar fallas de escritura.
kubernetes.io/pod/latencies/pod_first_ready (BETA) Es la latencia de inicio de extremo a extremo del Pod (desde Pod Created hasta Ready), incluidas las extracciones de imágenes. Diagnostica los Pods que tardan en iniciarse.

Visualiza métricas con el Explorador de métricas

Para visualizar el estado de tu entorno de GKE, crea gráficos basados en métricas con el Explorador de métricas.

Para usar el Explorador de métricas, completa los siguientes pasos:

  1. En la Trusted Cloud consola, ve a la página Explorador de métricas.

    Ir al Explorador de métricas

  2. En el campo Métricas, selecciona o ingresa la métrica que deseas inspeccionar.

  3. Consulta los resultados y observa las tendencias a lo largo del tiempo.

Por ejemplo, para investigar el consumo de memoria de los Pods en un espacio de nombres específico, puedes hacer lo siguiente:

  1. En la lista Seleccionar una métrica, elige la métrica kubernetes.io/container/memory/used_bytes y haz clic en Aplicar.
  2. Haz clic en Agregar filtro y selecciona namespace_name.
  3. En la lista Valor, selecciona el espacio de nombres que deseas investigar.
  4. En el campo Agregación, selecciona Suma > pod_name y haz clic en Aceptar. Este parámetro de configuración muestra una línea de serie temporal separada para cada Pod.
  5. Haz clic en Guardar gráfico.

En el gráfico resultante, se muestra el uso de memoria de cada Pod a lo largo del tiempo, lo que puede ayudarte a identificar visualmente los Pods con un consumo de memoria inusualmente alto o en aumento.

El Explorador de métricas ofrece una gran flexibilidad en la forma de construir las métricas que deseas ver. Para obtener más información sobre las opciones avanzadas del Explorador de métricas, consulta Crea gráficos con el Explorador de métricas en la documentación de Cloud Monitoring.

Crea alertas para la detección proactiva de problemas

Para recibir notificaciones cuando algo sale mal o cuando las métricas superan ciertos umbrales, configura políticas de alertas en Cloud Monitoring.

Por ejemplo, para configurar una política de alertas que te notifique cuando el límite de CPU del contenedor supere el 80% durante cinco minutos, haz lo siguiente:

  1. En la consola de Trusted Cloud , ve a la página Alertas.

    Ve a las alertas

  2. Haz clic en Crear política.

  3. En el cuadro Seleccionar una métrica, filtra por CPU limit utilization y, luego, selecciona la siguiente métrica: kubernetes.io/container/cpu/limit_utilization.

  4. Haz clic en Aplicar.

  5. Deja en blanco el campo Agregar un filtro. Este parámetro de configuración activa una alerta cuando cualquier clúster incumple tu umbral.

  6. En la sección Transforma los datos, haz lo siguiente:

    1. En la lista Ventana progresiva, selecciona 1 minuto. Este parámetro de configuración significa que Trusted Cloud calcula un valor promedio cada minuto.

    2. En la lista Función de ventana progresiva, selecciona media.

      Ambos parámetros de configuración promedian el uso del límite de CPU para cada contenedor cada minuto.

  7. Haz clic en Siguiente.

  8. En la sección Configurar alerta, haz lo siguiente:

    1. En Tipo de condición, selecciona Umbral.
    2. En Activador de alertas, selecciona Cualquier serie temporal es una infracción.
    3. En Posición del umbral, selecciona Umbral superior.
    4. En Valor del umbral, ingresa 0.8. Este valor representa el umbral del 80% que deseas supervisar.
    5. Haz clic en Opciones avanzadas.
    6. En la lista Período de nueva prueba, selecciona 5 min. Este parámetro de configuración significa que la alerta se activa solo si el uso de CPU se mantiene por encima del 80% durante un período continuo de cinco minutos, lo que reduce las falsas alarmas por picos breves.
    7. En el campo Nombre de la condición, asígnale un nombre descriptivo a la condición.
    8. Haz clic en Siguiente.

  9. En la sección Configurar las notificaciones y finalizar la alerta, haz lo siguiente:

    1. En la lista Canales de notificaciones, selecciona el canal en el que deseas recibir la alerta. Si no tienes un canal, haz clic en Administrar canales de notificaciones para crear uno.
    2. En el campo Asigna un nombre a la política de alertas, asígnale un nombre claro y descriptivo.
    3. Deja todos los otros campos con sus valores predeterminados.
    4. Haz clic en Siguiente.

  10. Revisa tu política y, si todo parece correcto, haz clic en Crear política.

Para obtener información sobre las formas adicionales en que puedes crear alertas, consulta Descripción general de las alertas en la documentación de Cloud Monitoring.

Acelera el diagnóstico con Gemini Cloud Assist

A veces, la causa del problema no es obvia de inmediato, incluso cuando usaste las herramientas que se describieron en las secciones anteriores. La investigación de casos complejos puede llevar mucho tiempo y requiere una gran experiencia. En situaciones como esta, Gemini Cloud Assist puede ayudarte. Puede detectar automáticamente patrones ocultos, mostrar anomalías y proporcionar resúmenes para ayudarte a identificar rápidamente una causa probable.

Accede a Gemini Cloud Assist

Para acceder a Gemini Cloud Assist, completa los siguientes pasos:

  1. En la consola de Trusted Cloud , ve a cualquier página.

  2. En la barra de herramientas de la consola de Trusted Cloud , haz clic en spark Abrir o cerrar el chat de Gemini Cloud Assist.

    Se abrirá el panel de Cloud Assist. Puedes hacer clic en las instrucciones de ejemplo si se muestran o ingresar una instrucción en el campo Ingresa una instrucción.

Explora ejemplos de instrucciones

Para ayudarte a comprender cómo Gemini Cloud Assist puede ayudarte, aquí tienes algunos ejemplos de instrucciones:

Tema Situación Ejemplo de instrucción Cómo puede ayudarte Gemini Cloud Assist
Mensaje de error confuso Un Pod tiene el estado CrashLoopBackoff, pero el mensaje de error es difícil de entender. ¿Qué significa este error del Pod de GKE y cuáles son sus causas comunes: panic: runtime error: invalid memory address or nil pointer dereference? Gemini Cloud Assist analiza el mensaje y lo explica en términos claros. También ofrece posibles causas y soluciones.
Problemas de rendimiento Tu equipo observa una latencia alta en una app que se ejecuta en GKE. Mi servicio api-gateway en el clúster de GKE prod experimenta una latencia alta. ¿Qué métricas debo verificar primero? ¿Puedes sugerirme algunas causas comunes relacionadas con GKE para este problema? Gemini Cloud Assist sugiere métricas clave para examinar, explora posibles problemas (por ejemplo, limitaciones de recursos o congestión de la red) y recomienda herramientas y técnicas para una mayor investigación.
Problemas de nodos Un nodo de GKE está atascado con el estado NotReady. Uno de mis nodos de GKE (node-xyz) muestra el estado NotReady. ¿Cuáles son los pasos típicos para solucionar este problema? Gemini Cloud Assist proporciona un plan de investigación paso a paso, explica conceptos como la reparación automática de nodos y sugiere comandos kubectl pertinentes.
Información sobre GKE No tienes certeza sobre una función específica de GKE o cómo implementar una práctica recomendada. ¿Cuáles son las prácticas recomendadas para proteger un clúster de GKE? ¿Hay alguna manera de obtener más información? Gemini Cloud Assist proporciona explicaciones claras de las prácticas recomendadas de GKE. Haz clic en Mostrar contenido relacionado para ver vínculos a la documentación oficial.

Para obtener más información, consulta los siguientes recursos:

Usa las investigaciones de Gemini Cloud Assist

Además del chat interactivo, Gemini Cloud Assist puede realizar análisis más automatizados y detallados a través de las investigaciones de Gemini Cloud Assist. Esta función se integra directamente en flujos de trabajo como el Explorador de registros y es una poderosa herramienta de análisis de causa raíz.

Cuando inicias una investigación a partir de un error o un recurso específico, Gemini Cloud Assist analiza los registros, las configuraciones y las métricas. Utiliza estos datos para generar observaciones e hipótesis clasificadas sobre las posibles causas raíz y, luego, te proporciona los próximos pasos recomendados. También puedes transferir estos resultados a un caso de asistencia para proporcionar contexto valioso que te ayude a resolver el problema más rápido. Trusted Cloud by S3NS

Para obtener más información, consulta Investigaciones de Gemini Cloud Assist en la documentación de Gemini.

Combina todo: Situación de ejemplo para solucionar problemas

En este ejemplo, se muestra cómo puedes usar una combinación de herramientas de GKE para diagnosticar y comprender un problema común del mundo real: un contenedor que falla repetidamente debido a memoria insuficiente.

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 Trusted Cloud

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

  1. En la consola de Trusted 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 fallas, 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 Trusted Cloud , ve al Explorador de métricas.
  2. Selecciona la métrica container/memory/used_bytes.
  3. Filtra el resultado para ver 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 Trusted 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 Trusted 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 está 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?