Un récent cas de débogage met en lumière un problème mémoire subtil mais impactant dans Kubernetes : le cache de pages du noyau Linux peut gonfler l'utilisation mémoire d'un conteneur bien au-delà du heap et de l'off-heap réels de l'application. Dans ce cas, un pod Spring Boot consommait plus de 4 Go de mémoire, alors que le heap JVM plus l'off-heap totalisaient seulement environ 1 Go. L'enquête a révélé que l'active_file (cache de pages) mettait en cache les 3 Go de fichiers journaux stockés sur un répertoire hôte monté (/logs). C'est un comportement connu : lorsqu'un conteneur monte un répertoire hôte, le noyau met en cache les données des fichiers dans le cache de pages, qui compte dans la limite du cgroup mémoire du conteneur. La correction implique soit de limiter le cache de pages via les paramètres du cgroup mémoire, d'utiliser un montage tmpfs pour les journaux, ou de configurer la rotation et la compression des journaux pour réduire la taille des données mises en cache. Ce cas est un rappel précieux pour les équipes DevOps et SRE de surveiller non seulement la mémoire de l'application mais aussi la mise en cache au niveau du noyau lors de l'utilisation de montages de volumes en production.
Un développeur a constaté que l'utilisation mémoire d'un pod Spring Boot (4 Go+) dépassait largement le heap+off-heap (1 Go). Le coupable était le cache de pages du noyau Linux (active_file) qui mettait en cache les fichiers journaux d'un répertoire hôte monté. C'est un problème courant mais souvent négligé dans les environnements K8s.