Un caso reciente de depuración pone de relieve un problema de memoria sutil pero impactante en Kubernetes: la caché de páginas del kernel de Linux puede inflar el uso de memoria del contenedor mucho más allá del heap y off-heap reales de la aplicación. En este caso, un pod de Spring Boot consumía más de 4 GB de memoria, mientras que el heap de la JVM más el off-heap totalizaban solo alrededor de 1 GB. La investigación reveló que el active_file (caché de páginas) estaba almacenando en caché los 3 GB de archivos de registro almacenados en un directorio host montado (/logs). Este es un comportamiento conocido: cuando un contenedor monta un directorio host, el kernel almacena en caché los datos del archivo en la caché de páginas, que cuenta para el límite del cgroup de memoria del contenedor. La solución implica limitar la caché de páginas mediante la configuración del cgroup de memoria, usar un montaje tmpfs para los registros o configurar la rotación y compresión de registros para reducir el tamaño de los datos en caché. Este caso es un recordatorio valioso para los equipos de DevOps y SRE de monitorear no solo la memoria de la aplicación sino también el almacenamiento en caché a nivel de kernel cuando se utilizan montajes de volumen en producción.
Un desarrollador descubrió que el uso de memoria de un pod de Spring Boot (4 GB+) superaba con creces el heap+off-heap (1 GB). El culpable era la caché de páginas del kernel de Linux (active_file) que almacenaba en caché los archivos de registro de un directorio host montado. Este es un problema común pero a menudo pasado por alto en entornos K8s.