Truc marrant : aujourd'hui je me retrouve avec une erreur "too many open files" sur un de nos clusters Kubernetes, lors de la consultation des logs et j'avoue que je galère à identifier la cause. J'essaie d'identifier quel process pourrait taper la limite de fichiers ouverts, sans grand succès.
Comments
(certains diraient que c'est la preuve que Kube n'est pas adapté au baremetal, mais j'ai envie de creuser le sujet).
Dis autrement, pouvoir avoir ~15 pods par vCPU (thread).
C'est pas non plus un gros problème, on pourrait changer de hardware aussi. Mais cette limite "arbitraire" me gonfle.
Mais j'imagine bien qu'on va rencontrer d'autres petits couacs du genre.
(double allocation IP au cas où + marge de fonctionnement, et zou, on se retrouve avec une limite arbitraire).
Donc quand tu changes le max-pods, faut changer l'adressage réseau aussi.
C'est plutôt la perte multi-noeud qui m'inquiète.
Je me dis que c'est vraiment naze en fait, et je ré-essaie sur ChatGPT. Copier/coller du prompt, et... réponse tout aussi inutile.
OK bah retour sur Google hein !
Je me dis «n'importe quoi», je continue ma recherche, je tombe sur une issue Github sur Kairos, qui explique que… ça vient de fs.inotify.
Bref, pardon Qwant, tu avais raison, je t'écouterai un peu plus désormais !
Chez vous aussi, Qwant est devenu plus pertinent (pratique ?) avec cette IA qui fait des résumés des réponses ? 😇
https://bsky.app/profile/bool.fr/post/3lhtwa6ipqk2z
C'est pour Incus mais ça vaut pour Kube also
La limite par défaut étant à 512, et avec 150 pods ça ne suffisait pas.
(mais je n'ai guère creusé plus loin pour le moment)
Après on a des clusters vraiment surdimenssionés donc le problème se pose pas tous les jours.