Antes de empezar

Antes de poder utilizar los servicios de observabilidad para depurar su clúster, asegúrese de que se cumplen los siguientes requisitos.

• Tu clúster está conectado a una instancia de IBM Cloud Monitoring. Para conectar tu clúster, consulta Habilitar métricas para Red Hat OpenShift on IBM Cloud.
• Tu clúster está conectado a una instancia de IBM Cloud Logs. Para conectar tu clúster, consulta Activación del registro.
• Tienes, como mínimo, acceso de Visor a las instancias de los servicios IBM Cloud Monitoring y IBM Cloud Logs de tu cuenta.

Comprueba el uso de recursos de los nodos de trabajo con IBM Cloud Monitoring

Cuando los nodos de trabajo entran en un estado NotReady o Critical, una causa habitual es un uso elevado de la CPU o de la memoria. Utiliza los paneles predefinidos de IBM Cloud Monitoring para identificar rápidamente la sobrecarga de recursos.

1. Abre el panel de control de IBM Cloud Monitoring de tu clúster.

   1. En la consola de IBM Cloud, ve a la página de recursos de clústeres y haz clic en el clúster correspondiente.
   2. En Integraciones, busca la opción Monitorización y haz clic en Iniciar. La interfaz de usuario de IBM Cloud Monitoring se abre en una nueva ventana.

2. Accede al panel de control preconfigurado Kubernetes > Nodes para ver el uso de CPU y memoria por nodo.

   • Busca los nodos en los que el porcentaje de uso de la CPU o de la memoria supere el 80 %. Los nodos que alcancen o superen este umbral corren el riesgo de sobrecargarse y pueden empezar a tener problemas para programar nuevos pods.
   • Busca nodos en los que el uso de la CPU o de la memoria presente un pico repentino o se haya mantenido elevado de forma constante durante la última hora o el último día. Esto puede ayudarte a determinar si el problema es puntual o persistente.

3. Para analizar un nodo concreto, haz clic en el nombre del nodo en el panel de control para filtrar todos los gráficos según ese nodo. Comprueba los siguientes parámetros:

   • Porcentaje de uso de la CPU: un valor sostenido por encima del 90 % indica saturación de la CPU.
   • Porcentaje de uso de memoria: un valor que se mantenga por encima del 85 % aumenta el riesgo de que se produzcan eventos de falta de memoria (OOM).
   • Bytes de entrada y salida de la red: un pico de tráfico inesperado puede indicar una carga de trabajo descontrolada o un ataque a la red.

4. Para comprobar qué pods consumen más recursos en un nodo, acceda al panel de control Kubernetes > Pods y filtre por el nodo afectado. Anota los nombres de los pods que muestren un uso elevado y constante de la CPU o la memoria, ya que es probable que sean los responsables de la inestabilidad del nodo de trabajo.

Comprueba el estado de los pods y el recuento de reinicios con IBM Cloud Monitoring

Los pods que entran en un bucle de fallos o se reinician con frecuencia suelen ser un indicio de problemas a nivel de aplicación, como terminaciones por falta de memoria (OOM) o pruebas de disponibilidad mal configuradas. Utiliza IBM Cloud Monitoring para identificar estos pods sin tener que ejecutar la orden repetidamente oc get pods.

1. En la interfaz de usuario de IBM Cloud Monitoring, acceda al panel de control preconfigurado Kubernetes > Pods.

2. Revisa el panel Reinicios de contenedores. Busca pods que muestren un recuento de reinicios superior a cero en los últimos 15 minutos, o que muestren un aumento rápido a lo largo de un periodo de tiempo más prolongado.

   • Un recuento de reinicios que aumenta repetidamente indica un bucle de fallos. Anota el nombre del pod y el espacio de nombres para utilizarlos en los pasos de análisis de registros que vienen a continuación.
   • Un recuento de reinicios igual a cero, pero con un estado Pendiente o Desconocido, indica un problema de programación o de conectividad del nodo, más que un fallo de la aplicación.

3. Para configurar una alerta para futuros eventos de reinicio de pods, haz clic en el icono Alertas de la interfaz de usuario de IBM Cloud Monitoring y crea una alerta de métrica basada en la métrica kubernetes.pod.restart.count correspondiente. Establece el umbral para que se active cuando el recuento supere los dos reinicios en cinco minutos para cualquier pod. Esto proporciona una alerta temprana antes de que un bucle de fallos llegue a ser perjudicial. Para obtener más información sobre cómo configurar alertas, consulta Configuración de alertas de IBM Cloud® Monitoring.

Analiza los registros de los contenedores con IBM Cloud Logs

Cuando un pod se ha reiniciado o un nodo presenta problemas, es fundamental revisar los registros del contenedor para comprender la causa raíz. IBM Cloud Logs conserva los datos históricos de los registros que no están disponibles a través de una vez oc logs que se ha reiniciado el contenedor.

1. Abra el panel de control de IBM Cloud Logs.

   1. En la consola de IBM Cloud, ve a la página de recursos de clústeres y haz clic en el clúster correspondiente.
   2. En Integraciones, busca la opción Registro y haz clic en Iniciar. La interfaz de usuario de IBM Cloud Logs se abre en una nueva ventana.

2. Establece el intervalo de tiempo para que abarque el periodo en el que se produjo el problema. Si el problema persiste, establece el intervalo en la última hora. Si estás investigando un evento pasado, establece la hora concreta de inicio y fin para acotar los resultados.

3. Busca el pod o el espacio de nombres afectado. Utiliza la barra de búsqueda situada en la parte superior de la interfaz de usuario para filtrar los registros. Por ejemplo, para mostrar los registros de todos los pods del espacio de nombres default, introduce la siguiente consulta:

   kubernetes.namespace_name:"default"
   

   Para limitar los resultados a un pod específico por su nombre, utiliza:

   kubernetes.pod_name:"MY_POD_NAME"
   

4. Revisa las líneas del registro en busca de entradas de nivel de error. Busca cualquiera de los siguientes patrones que indiquen modos de fallo habituales:

   • OOMKilled o out of memory — el contenedor superó su límite de memoria y fue cerrado por el núcleo.
   • CrashLoopBackOff — El contenedor se reinicia repetidamente, a menudo debido a un error de la aplicación al iniciarse.
   • failed to pull image o ImagePullBackOff — el nodo no puede descargar la imagen del contenedor desde el registro.
   • Connection refused o context deadline exceeded — la aplicación no puede acceder a un servicio dependiente o al servidor de la API de Kubernetes.

5. Si encuentra una entrada de registro relacionada con OOM, anote la marca de tiempo y consulte el panel Pods de IBM Cloud Monitoring Kubernetes correspondiente a ese mismo intervalo de tiempo para confirmar que el uso de memoria del pod alcanzó su límite inmediatamente antes del reinicio.

Consulta los eventos de Kubernetes en IBM Cloud Logs

Kubernetes Los eventos recogen actividades importantes del clúster, como fallos en la programación de pods, el estado de los nodos y errores de montaje de volúmenes. IBM Cloud Logs recopila estos eventos automáticamente y te permite buscarlos y filtrarlos históricamente, a diferencia de oc get events, que solo muestra los eventos recientes de la sesión actual.

1. En la interfaz de usuario de IBM Cloud Logs, utilice la siguiente consulta para mostrar todos los eventos de advertencia de Kubernetes en todo el clúster:

   kubernetes.event.type:"Warning"
   

2. Para filtrar eventos en un nodo de trabajo específico, añade el nombre del nodo a la consulta. Sustituye NODE_NAME por el nombre del nodo afectado:

   kubernetes.event.type:"Warning" AND kubernetes.event.involvedObject.name:"NODE_NAME"
   

3. Revisa el campo Motivo en las entradas del registro de eventos. Las siguientes razones son las más relevantes a la hora de depurar problemas en los nodos de trabajo y las cargas de trabajo:

NodeNotReady

El nodo está notificando una condición NotReady. Este evento suele preceder o acompañar a la entrada de un nodo de trabajo en un estado Critical.

OOMKilling

El núcleo terminó un proceso en el nodo debido a que se agotó la memoria.

FailedScheduling

El programador no ha podido ubicar un pod en ningún nodo disponible. El campo de mensaje suele explicar el motivo, como por ejemplo, CPU insuficiente, memoria insuficiente o una discrepancia en el selector de nodos.

BackOff

Un contenedor se encuentra en un bucle de fallos. El evento se genera cada vez que el kubelet se retira antes de reiniciar el contenedor.

FailedMount o FailedAttachVolume

No se ha podido montar ni conectar un volumen persistente a un pod, lo que impide que este se inicie.

1. Para cualquier evento que parezca relevante, anota los valores involvedObject.namespace y involvedObject.name, y utilízalos para establecer una correlación con los datos de registros y métricas que has recopilado en las secciones anteriores.

Próximos pasos

• Si ha detectado un nodo de trabajo con problemas de recursos, considere la posibilidad de recargar o sustituir dicho nodo, o bien ajustar las solicitudes y los límites de recursos de los pods que se ejecutan en ese nodo.
• Si los pods entran en un bucle de fallos debido a terminaciones por falta de memoria (OOM), aumenta los límites de memoria de los contenedores afectados o traslada las cargas de trabajo que consumen mucha memoria a un grupo de trabajadores con nodos más grandes.
• Si los registros indican errores al descargar imágenes, comprueba tus claves secretas de descarga de imágenes y verifica que el nodo de trabajo pueda acceder al registro de contenedores.
• Para los problemas que no se puedan resolver con la información recopilada aquí, consulta Recopilación de datos para un caso de asistencia técnica a fin de recabar la información necesaria para abrir un ticket de asistencia.

Enlaces relacionados

• Supervisión del estado del clúster
• Primeros pasos con IBM Cloud Monitoring
• Primeros pasos con IBM Cloud Logs
• Solución de problemas en nodos de trabajo en estado NotReady o Critical.
• Configuración de alertas de IBM Cloud® Monitoring