Le suivi des inœuds par Kubelet expose les nœuds Kubernetes à des évictions brutales de pods

Les nœuds d'exécution Kubernetes peuvent épuiser leurs inœuds de fichiers disponibles bien avant de manquer d'espace disque en raison de la façon dont Kubelet gère le nettoyage du stockage. Une analyse technique publiée par la Cloud Native Computing Foundation montre que le ramasse-miettes d'images en arrière-plan de Kubelet surveille exclusivement des seuils en octets, ce qui laisse la croissance des inœuds non gérée jusqu'à ce que les nœuds atteignent les limites strictes d'éviction.

Surveillance asymétrique des ressources dans Kubelet

Kubelet contrôle l'espace disque des images grâce à des configurations basées sur les octets : imageGCHighThresholdPercent (85 % par défaut) et imageGCLowThresholdPercent (80 % par défaut). Lorsque l'utilisation du disque dépasse la limite supérieure, Kubelet supprime silencieusement les images inutilisées. Cependant, ce processus automatisé de ramasse-miettes ne mesure jamais le nombre de fichiers ni la consommation d'inœuds.

Sur les nœuds d'exécution Linux, Kubelet définit des déclencheurs d'éviction stricte lorsque les inœuds disponibles tombent à 5 % sur nodefs ou imagefs. Contrairement à la gestion basée sur les octets, aucun ramasse-miettes passif n'existe pour les inœuds. Lorsqu'un nœud subit une génération rapide de fichiers, Kubelet n'intervient pas avant d'atteindre 95 % d'utilisation des inœuds, moment auquel il commence à évincer les pods. Les configurations par défaut pour les plateformes non Linux omettent complètement les signaux d'éviction stricte fondés sur les inœuds.

Dépendances de conteneurs et multiplication des instantanés

Le principal facteur d'une utilisation élevée des inœuds est la présence d'images de conteneurs hébergeant de vastes collections de petits fichiers, comme les répertoires de dépendances Node.js ou les environnements virtuels de langages. Les builds de conteneurs à étape unique conservent fréquemment les gestionnaires de paquets, les fichiers sources et les dépendances au sein des couches distribuées.

Les pilotes de stockage du runtime de conteneurs, à l'instar du gestionnaire d'instantanés overlayfs de containerd, décompressent chaque couche dans des répertoires distincts. Même si les fichiers sous-jacents sont identiques d'un build à l'autre, les modifications des empreintes de couche empêchent la déduplication des fichiers, entraînant la création de milliers de nouveaux inœuds à chaque déploiement. Les systèmes de fichiers ext4 standard attribuent une limite fixe d'inœuds lors de leur création, ce qui permet à des nombres élevés de fichiers d'épuiser les inœuds alors que la consommation en octets reste faible.

Stratégies d'atténuation et alerte personnalisée

Pour réduire la densité des inœuds, les développeurs peuvent adopter des builds de conteneurs multi-étapes qui séparent les dépendances de compilation des couches d'exécution finales, maintenant ainsi un faible nombre de fichiers dans les artefacts de production. Les administrateurs de grappes peuvent également analyser la distribution des inœuds à travers les chemins de stockage de containerd en utilisant des requêtes par répertoire isolé.

Comme les routines standard de Kubelet n'exécutent pas de nettoyage préventif d'images basé sur l'usage des inœuds, les équipes peuvent établir des règles d'alerte Prometheus personnalisées pour signaler les nœuds dépassant des seuils tels que 80 % de capacité d'inœuds. Une détection précoce permet aux opérateurs de nettoyer manuellement les images inutilisées avec les outils du runtime de conteneurs avant d'atteindre le seuil de 95 % déclenchant l'éviction des pods par Kubelet.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

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