El seguimiento de inodos en Kubelet expone los nodos de Kubernetes a expulsiones repentinas de pods

Los nodos de trabajo de Kubernetes pueden agotar los inodos de archivos disponibles mucho antes de quedarse sin espacio en disco debido a la forma en que Kubelet gestiona la limpieza del almacenamiento. Un análisis técnico publicado por la Cloud Native Computing Foundation demuestra que la recolección de basura de imágenes en segundo plano de Kubelet supervisa exclusivamente los umbrales de bytes, lo que deja el crecimiento de inodos sin gestionar hasta que los nodos alcanzan los límites estrictos de expulsión.

Monitoreo asimétrico de recursos en Kubelet

Kubelet controla el espacio en disco de las imágenes mediante configuraciones basadas en bytes: imageGCHighThresholdPercent (85 % por defecto) e imageGCLowThresholdPercent (80 % por defecto). Cuando la utilización del disco supera el límite superior, Kubelet elimina discretamente las imágenes no utilizadas. Sin embargo, este proceso automatizado de recolección de basura nunca mide el recuento de archivos ni el consumo de inodos.

En los nodos de trabajo de Linux, Kubelet define activadores de expulsión estricta cuando los inodos disponibles caen al 5 % en nodefs o imagefs. A diferencia de la gestión basada en bytes, no existe una recolección de basura pasiva para los inodos. Cuando un nodo experimenta una rápida generación de archivos, Kubelet no interviene hasta alcanzar el 95 % de utilización de inodos, momento en el que comienza a expulsar pods. Las configuraciones por defecto para plataformas que no son Linux omiten por completo las señales de expulsión estricta por inodos.

Dependencias de contenedores y multiplicación de instantáneas

El factor principal del elevado uso de inodos son las imágenes de contenedores que contienen grandes colecciones de archivos pequeños, como los directorios de dependencias de Node.js o los entornos virtuales de lenguajes de programación. Las compilaciones de contenedores de una sola etapa suelen conservar gestores de paquetes, archivos fuente y dependencias dentro de las capas de distribución.

Los controladores de almacenamiento de los entornos de ejecución de contenedores, como el gestor de instantáneas overlayfs de containerd, descompresionan cada capa en directorios independientes. Incluso cuando los archivos subyacentes son idénticos entre compilaciones, los cambios en los resúmenes digest de las capas impiden la deduplicación de archivos, lo que genera miles de inodos nuevos por cada despliegue de compilación. Los sistemas de archivos ext4 estándar asignan límites fijos de inodos al crearse, lo que permite que una gran cantidad de archivos agote los inodos mientras la utilización de bytes en disco se mantiene baja.

Estrategias de mitigación y alertas personalizadas

Para reducir la densidad de inodos, los desarrolladores pueden adoptar compilaciones de contenedores multietapa que separan las dependencias de compilación de las capas finales de ejecución, lo que mantiene bajo el recuento de archivos en los artefactos de producción. Los administradores de clústeres también pueden rastrear la distribución de inodos a través de las rutas de almacenamiento de containerd mediante consultas de directorios aislados por archivos.

Dado que las rutinas estándar de Kubelet no ejecutan una limpieza preventiva de imágenes basada en el uso de inodos, los equipos pueden establecer reglas de alerta personalizadas en Prometheus para señalar los nodos que superen umbrales como el 80 % de capacidad de inodos. La detección temprana permite a los operadores depurar manualmente las imágenes no utilizadas mediante utilidades del entorno de ejecución de contenedores antes de alcanzar el umbral de expulsión de pods del 95 % de Kubelet.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: Kubelet watches inodes. Just not until it’s an emergency.