Qué se registra en un clúster

Un mismo suceso deja huellas distintas según quién lo mire. La API del clúster sabe quién pidió algo y con qué resultado. El kubelet, que corre en cada nodo, sabe qué hizo con ese pedido. La aplicación solo sabe lo que escribió en su salida. Ninguna de las tres ve lo que las otras ven, y por eso una detección empieza por elegir la fuente que contiene la pregunta.

Abre un_pod_que_desaparece. La tabla sigue una eliminación de pod en cuatro fuentes, con la hora de cada fila.

Una fuente apagada es una pregunta sin respuesta posible: ninguna regla puede leer lo que nadie escribió. Antes de diseñar una detección conviene contar con qué se cuenta de verdad. La tabla fuentes_del_cluster trae una columna que dice si cada fuente está activa.

El registro de auditoría ve solicitudes a la API: crear, borrar, leer. No ve qué proceso arrancó dentro de un contenedor ya en marcha ni qué archivo abrió. Para eso hace falta un sensor en el nodo que observe las llamadas al sistema de los procesos. En la tabla hay una fuente de ese tipo.

Una detección que mira «los últimos siete días» sobre una fuente que guarda uno solo está mal diseñada, y nadie se entera hasta el día del incidente. La retención es una propiedad de la fuente, no de la regla. La auditoría de la API es la fuente que más preguntas contesta y conviene saber hasta dónde llega.

Los eventos de Kubernetes cuentan por qué un pod no arrancó o por qué se reinició, pero el clúster no los guarda mucho tiempo. Mira la última fila de un_pod_que_desaparece y la retención de eventos-k8s en la otra tabla. Una analista pregunta a las dos de la tarde por qué se reinició un pod a las diez de la mañana.