Kubernetes sano pero las peticiones se atascan: qué mirar

Hay una situación que desespera a cualquier equipo de operaciones: el dashboard de Kubernetes está en verde, los pods corren, los probes de liveness y readiness devuelven éxito y la CPU de los nodos ni se acerca a su límite. Y, aun así, los usuarios abren tickets porque la aplicación va lenta de forma intermitente. ¿Cómo es posible que las comprobaciones básicas pasen mientras el rendimiento se degrada? Es lo que en el sector se conoce como ralentización fantasma, y entenderla es clave para cualquier pyme que ya tenga cargas en contenedores.

Por qué un cluster «sano» no significa que la app funcione

Un probe de liveness sirve para saber si hay que reiniciar un contenedor, incluso uno cuyo proceso está vivo pero bloqueado. Un probe de readiness indica si el contenedor puede recibir tráfico. Los checks personalizados pueden incluir condiciones de la aplicación o de sus dependencias, pero aprobar un probe básico no equivale a que una petición completa cumpla su objetivo de tiempo de respuesta. Son dos cosas distintas y conviene no confundirlas.

Mahesh Ramachandran, responsable de producto de HPE OpsRamp Software, lo explica a The New Stack con un escenario compuesto: usuarios de una aplicación que sirve prompts de IA sobre Kubernetes reportan lentitud esporádica. El equipo revisa cluster, nodos y pods, todo parece correcto y no hay fallos de pod. El problema es precisamente esa intermitencia: sin evidencia histórica, localizar el origen es casi imposible.

«Cuando la degradación ocurre de forma intermitente, señalar la causa sin evidencia histórica se vuelve casi imposible».

La conclusión práctica es sencilla: pasar los probes estrecha la investigación, no la cierra. Una foto de un cluster sano puede no capturar un episodio de lentitud anterior, y la ausencia de fallos en contenedores no demuestra que la aplicación o sus dependencias vayan bien.

Telemetría continua en toda la pila: separar señal de ruido

Para resolver lentitud esporádica hay que ir más allá de las métricas superficiales de Kubernetes y desplegar telemetría continua en varias capas. Una petición de usuario puede depender del código de la aplicación, del runtime de contenedores, de infraestructura virtualizada o bare metal y de APIs de nube pública. Las capas relevantes dependen del despliegue de cada uno.

Según Ramachandran, la recogida continua abarca nodos, pods, controladores de ingress y servicios, capturando logs, eventos y métricas. El paso fundacional es tener un registro continuo: hay que volver al histórico para correlacionar los síntomas que reporta el usuario con la evidencia real. Pero encontrar esa evidencia no suele ser trivial.

«Una anomalía puede no aparecer como un pico obvio en una sola métrica. Puede ser una variación sutil o un comportamiento correlacionado donde dos señales parecen normales por separado, pero su combinación produce latencia».

Esto es importante para una pyme: muchas veces el problema no está en un gráfico que se dispara, sino en la correlación de dos señales que, vistas por separado, parecen correctas.

Cómo investigar un episodio de latencia, paso a paso

1. Partir de la transacción afectada y de la ventana temporal concreta.
2. Comparar tiempos de respuesta y consultas por segundo con la salud y el número de pods.
3. Buscar variaciones en las señales recogidas que coincidan con la ralentización.
4. Tratar la correlación como hipótesis, no como causa probada.
5. Tras aplicar un cambio, comparar las mismas medidas de cara al usuario con el comportamiento anterior.

La cobertura depende de los agentes, integraciones, permisos e instrumentación que configure cada equipo. En el caso de OpsRamp, se recogen trazas compatibles con OpenTelemetry para aplicaciones instrumentadas (ojo: sin instrumentar la app, la monitorización de infraestructura no genera trazas), telemetría de cluster y workloads mediante agentes de Kubernetes, datos de virtualización e HCI a través de integraciones con VMware, Nutanix y HPE Morpheus VM Essentials, y telemetría de servidores físicos vía Redfish con los accesos y pasarelas correspondientes.

Qué significa esto para tu pyme

Si tienes aplicaciones en Kubernetes —o estás migrando—, este artículo deja varias lecciones aplicables sin necesidad de comprar una suite enterprise:

• No te fíes solo del verde. Los probes son un semáforo de disponibilidad, no de rendimiento. Necesitas métricas de experiencia de usuario o de latencia de extremo a extremo.
• Guarda histórico. Sin retención de métricas, logs y eventos, un problema intermitente es indetectable a posteriori. Ajusta la retención según criticidad.
• Instrumenta la aplicación. Si no hay trazas, no hay forma de seguir una petición por sus dependencias. OpenTelemetry es un estándar razonable para empezar.
• Correlaciona capas. El cuello de botella puede estar fuera del cluster: en la base de datos, en una API externa o en el hipervisor.
• Valida los cambios. Una correlación no es una causa. Mide antes y después con la misma vara.

En ForgeNEX vemos muchas pymes que han dado el salto a contenedores sin montar la capa de observabilidad correspondiente. Es un patrón que ya tratamos al hablar de visibilidad y costes de GPUs en Kubernetes, y que aquí se repite: sin telemetría continua y bien correlacionada, cualquier incidencia intermitente se convierte en una caza de brujas. Nuestra recomendación es empezar por lo básico —retención de métricas, trazas de las rutas críticas y alertas basadas en latencia de usuario— antes de plantear herramientas más sofisticadas. La IA puede ayudar a cribar el ruido, pero solo si antes has decidido qué señales guardas y cuánto tiempo las conservas.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.