Las capas de un clúster y lo que registra cada una

Un clúster de Kubernetes se puede mirar en capas. El plano de control recibe cada petición a su API (listar pods, leer un secreto, abrir un shell) y puede dejar una auditoría de esas peticiones. El nodo es la máquina donde de verdad corren los contenedores, y un sensor allí puede ver procesos, archivos y conexiones. La aplicación escribe lo que sus programadores decidieron escribir. La red deja flujos. Y antes de todo eso, la canalización y el registro de imágenes dejan rastro de qué se construyó y qué se publicó.

Lo importante es que cada capa ve lo suyo. La API sabe quién pidió algo, pero no ve lo que pasa después dentro del contenedor. El sensor del nodo ve el proceso, pero no sabe con qué identidad se pidió.

Abre la consola. Ejecuta SELECT * FROM capas y lee las columnas registra y no_ve.

Cada fuente guarda sus registros un tiempo distinto, y eso decide qué preguntas se pueden contestar cuando llega una alerta tarde. Un evento de ejecución que ya se purgó no se puede recuperar mirando la auditoría: son testigos distintos.

Ejecuta SELECT * FROM capas WHERE retencion_dias < 10.

Si la auditoría de la API conserva sus registros durante un número de días y el sensor del nodo durante menos, hay una parte de la ventana de la auditoría de la que se sabe quién pidió cosas pero ya no se puede ver qué ocurrió por dentro. Esa parte se calcula restando.

Ejecuta SELECT * FROM capas WHERE id IN ('C1', 'C2') y lee la columna de retención de cada una.

El silencio de una capa tiene tres explicaciones posibles: no pasó nada, pasó y la capa no lo ve, o pasó y la capa no estaba mirando (sensor sin desplegar en ese nodo, evento fuera de la ventana de retención, colección rota). Por eso un informe de SOC dice siempre qué capas se miraron y qué ventana cubrían.