Kubelet e o Desafio dos Inodes: Quando a Coleta de Lixo Não é Suficiente

A recente descoberta, oriunda de um processo de Reverse-engineering detalhado, aponta uma lacuna crítica na estratégia do Kubelet para gerenciamento de imagens em nós do Kubernetes. Enquanto a coleta de lixo de imagens do Kubelet prioriza o espaço em disco (bytes), os inodes, que representam a quantidade de arquivos, são monitorados apenas em um limiar de emergência de 5% livres. Isso significa que, em cenários com muitos arquivos pequenos, como camadas descompactadas de dependências de front-end (exemplo real do incidente envolvendo @mui/icons-material), os inodes podem se esgotar muito antes que o espaço em disco atinja um nível crítico, levando à interrupção de serviços através da remoção de pods.

O problema é agravado pela forma como o containerd e seu overlayfs snapshotter lidam com camadas de imagem. Mesmo com deduplicação de camadas comprimidas, cada camada descompactada é armazenada em seu próprio diretório, o que pode resultar em múltiplas cópias de estruturas com muitos arquivos, como node_modules. O Kubelet, por padrão, não tem um gatilho antecipado para inodes, fazendo com que a primeira intervenção seja a evacuação de pods, uma ação altamente disruptiva. A investigação revela que o Dockerfile original, sendo de estágio único, contribuiu para o problema ao incluir dependências de desenvolvimento na imagem final, que são ricas em arquivos pequenos.

A cobertura do CEVIU News já apontava para os riscos de imagens Docker inchadas. Em 25 de maio de 2026, a matéria “Sua Imagem Docker Tem 1.2GB? Veja Como Reduzi-la Para Menos de 80MB” destacava a importância de técnicas como builds multiestágio para otimizar o tamanho de imagens de Node.js, inclusive mencionando a remoção de dependências desnecessárias. Naquela ocasião, o foco era na eficiência geral e no consumo de espaço. Agora, percebe-se que essa mesma prática, a construção multiestágio, é uma defesa essencial contra um problema específico e perigoso: o esgotamento de inodes que passa despercebido pelo Kubelet, mostrando a evolução da compreensão sobre os benefícios indiretos dessas otimizações. Em 14 de maio de 2026, a notícia “Quando 36 mil Arquivos Minúsculos Quebram Seu Pipeline Spark” também já indicava como a proliferação de arquivos pequenos pode gerar gargalos inesperados em sistemas distribuídos, reforçando um padrão de vulnerabilidade que agora se manifesta no Kubernetes.

Entender a diferença entre como o Kubelet gerencia o espaço em disco e os inodes é crucial para a resiliência de plataformas Kubernetes. A automação focada apenas em bytes pode dar uma falsa sensação de segurança, deixando o cluster vulnerável a panes inesperadas. Implementar builds multiestágio não é apenas uma boa prática para otimização de imagens, mas uma estratégia vital para evitar a exaustão de inodes. Além disso, a adição de alertas de monitoramento proativos, como as métricas de Prometheus para uso de inodes (ex: acima de 80%), é fundamental para identificar e remediar o problema antes que o Kubelet precise tomar medidas drásticas, como a remoção de pods.