Kubernetes et ses Ressources : Confessions d'un Kubelet au bord de la crise de nerfs

Introduction : Le grand malentendu cosmique des millicores

Ah, Kubernetes. Notre sauveur, notre plateforme rutilante, notre promesse d'un monde où les déploiements se font en musique et où les conteneurs gambadent joyeusement dans des prés de Nodes verdoyants. Et puis... il y a la gestion des ressources. Les fameux requests et limits. C'est là que le rêve DevOps rencontre la dure réalité, un peu comme quand on commande un plat magnifique sur Instagram et qu'on reçoit une bouillie triste dans une barquette en alu.

Avouons-le, expliquer les requests et limits à un nouveau venu, c'est comme essayer d'expliquer la règle du hors-jeu avec des marionnettes : ça semble simple en théorie, mais ça finit toujours en chaos et en pleurs.

Chapitre 1 : Les Requests - La liste au Père Noël (ou au kube-scheduler)

Imaginez votre conteneur comme un enfant un peu capricieux avant son anniversaire. Le request, c'est sa liste de souhaits :

• "Je VEUX au moins 100 millicores de CPU pour pouvoir... euh... afficher 'Hello World' de manière très optimisée."
• "Et il me FAUT absolument 128Mi de RAM, sinon mes variables vont se sentir à l'étroit et faire une dépression."

Le kube-scheduler, ce grand organisateur bienveillant mais un peu débordé (pensez à un animateur de colo avec 300 gamins hyperactifs), regarde cette liste. Il parcourt ses Nodes disponibles, en marmonnant : "Voyons voir... Tatie Node-01 a encore de la place à côté du conteneur Nginx qui ronfle... Oui, ça devrait passer. Allez hop, casé !"

Voix tremblante d'un Kubelet Anonyme (Kubelet-7b3f sur Node-Stresstest-04) :
"L'autre jour, le Scheduler m'a refilé un Pod qui demandait '10m' de CPU. Dix ! 
Pour une application qui, je le jure, essayait de calculer Pi jusqu'à la dernière décimale. 
Je l'ai vu venir gros comme une maison que ça allait mal finir. 
Mais bon, le request était satisfait, alors j'ai dû le prendre..."

Le request, c'est la promesse minimum garantie. C'est le siège réservé dans le train Kube. Si le Node ne peut même pas garantir ce minimum vital, votre Pod restera sur le quai, regardant les autres partir vers la gloire (ou vers une boucle infinie, on sait jamais).

Le drame des requests mal calibrées :

• Trop basses : Votre Pod se retrouve sur un Node déjà bondé, partageant son CPU avec un voisin bruyant qui compile le noyau Linux en boucle. Résultat : votre application rame comme un galérien sous Prozac.
• Trop hautes : Votre Pod devient une diva insupportable. "QUOI ? Pas de Node avec 8 coeurs dédiés juste pour mon script batch qui tourne 5 minutes par jour ? Scandaleux ! Je refuse de démarrer." Et il boude en état Pending pendant des heures.

Chapitre 2 : Les Limits - La Laisse Électronique (et parfois mortelle)

Ah, les limits. Si le request était la liste au Père Noël, le limit c'est le budget réel que Papa Maman Kubelet vous accorde. C'est la dure réalité après les rêves de grandeur.

• "Ok, tu as demandé 100m de CPU, mais écoute coco, tu n'auras JAMAIS PLUS que 500m. Si tu dépasses, on va commencer à te ralentir TRES fort." (C'est le CPU Throttling, l'équivalent de devoir courir un 100m dans de la mélasse).

Confession d'un Kubelet Blasé (Kubelet-c4f8 sur Node-Production-Critical-66) :
"Regarder un Pod taper son limit CPU et commencer à se faire throttler... 
C'est mon petit plaisir coupable.
Ça rame, ça supplie, ça envoie des signaux de détresse dans les logs... 
et moi je suis là, imperturbable : 'Désolé mon grand, la limite, c'est la limite. 
Fallait pas être si gourmand.'"

• "Et pour la RAM, tu voulais 128Mi ? Adorable. Mais si tu oses toucher à 1 Mi de plus que tes 256Mi de limit, pouf, tu disparais." (Ça, mes amis, c'est le célèbre et redouté OOMKiller, l'ange exterminateur de Kubernetes, aussi subtil qu'un coup de bazooka pour écraser une mouche).

Témoignage Anonyme d'un Kubelet Traumatisé (Kubelet-9a1d sur Node-Dev-Chaos-01) :
"'Limit Exceeded: 256Mi'. Ah, cette ligne dans mes logs... c'est le son de l'inévitable.
J'ai même pas le temps de dire 'OOM...' que l'autre psychopathe (l'OOMKiller, ndlr) 
est déjà passé et a tout nettoyé. 
Parfois, la nuit, j'entends encore les cris des processus terminés..."

Le Kubelet, maintenant transformé en videur de boîte de nuit fatigué, surveille tout le monde. Dès qu'un conteneur devient trop gourmand en CPU, il lui tire l'oreille numériquement (throttling). Si un autre se goinfre de RAM comme s'il n'y avait pas de lendemain, le Kubelet appelle son pote OOMKiller, qui arrive avec sa faux et... Terminé bonsoir. Votre Pod est OOMKilled, laissant derrière lui un message cryptique dans les logs et une équipe d'astreinte en sueur à 3h du matin.

Chapitre 3 : Les Classes de QoS - Le Club VIP, la Classe Éco et... les autres

Pour ajouter un peu de piment (comme s'il en manquait), Kubernetes classe vos Pods en fonction de comment vous avez défini (ou pas) ces requests et limits. C'est une sorte de hiérarchie sociale pour conteneurs :

1. Guaranteed (Le VIP) : Vous avez défini des requests ET des limits, et (attention, subtilité) ils sont égaux pour le CPU et la RAM. Ce Pod est un membre du Gotha. Il a une place réservée et un traitement de faveur. L'OOMKiller ira voir ailleurs en premier. C'est le Pod qui sirote du champagne dans le carré VIP du Node.
2. Burstable (La Classe Éco Confort) : Vous avez défini des requests, mais les limits sont plus hauts (ou absents pour une ressource mais pas l'autre). Ce Pod a sa place assise (request), mais il peut essayer de s'étaler un peu plus si personne ne regarde (limit > request). Attention, il est moins protégé que le VIP. Si ça chauffe, il risque de se faire throttler ou même OOMKiller avant les Guaranteed. C'est le passager qui espère secrètement que le siège à côté reste vide.
3. BestEffort (Le Stagiaire / Le Squatteur) : Vous n'avez défini AUCUN request ni limit. Ce Pod vit dangereusement. Il n'a aucune garantie, il prend ce qui reste. C'est le premier à se faire éjecter sans ménagement si les ressources viennent à manquer. L'OOMKiller le regarde avec un sourire carnassier dès son démarrage. C'est celui qui essaie de rentrer gratos à la soirée et qui se fait sortir par la sécurité à la première occasion.

Soupir d'un Kubelet Fataliste (Kubelet-f8g2 sur Node-Shared-08) :
"Quand je vois arriver un Pod BestEffort, je ne m'attache pas. Vraiment.
C'est comme accueillir un poisson rouge dans un aquarium de piranhas.
On sait tous comment ça va finir. 
Je prépare déjà le message 'Evicted'..."

Chapitre 4 : Le Grand Bazar - Pourquoi on se plante tous (avec amour)

Personne n'est parfait. Voici le florilège des erreurs classiques qui transforment nos clusters en joyeux chaos :

• Le " YOLO Driven Development " : Ne mettre aucun request ni limit. Vos Pods sont en mode BestEffort, le Node devient une jungle où seule la loi du plus fort (ou du plus rapide à consommer la RAM) s'applique. Les OOMKills pleuvent comme à Gravelotte.
• Le " Copier-Coller Sans Réfléchir " : Prendre les requests/limits d'un exemple sur Stack Overflow pour votre application Java ultra-gourmande. Spoiler : ça finit mal.
• Le " Optimiste Pathologique " : Mettre des requests ridicules ("Mon appli utilise à peine 10m de CPU !") et des limits stratosphériques ("Mais au cas où, donnons-lui 4 coeurs !"). Résultat : vos Nodes sont pleins à craquer (basé sur les requests faibles), mais en réalité, ils sont constamment au bord de l'implosion car tout le monde dépasse allègrement. C'est l'overbooking aérien appliqué aux serveurs.
• Le " Pessimiste Anxieux " : Mettre requests = limits partout, très haut "pour être sûr". Félicitations, vos Pods sont Guaranteed, mais vous utilisez 3 Nodes là où un seul aurait suffi. Votre DSI vous regarde avec des yeux qui lancent des éclairs (de factures Cloud).

Rire nerveux d'un Kubelet Développeur-Sympathisant (Kubelet-a2b5 sur Node-CI-CD-02) :
"Parfois, je vois des requests et limits arriver... et je me dis 'Ok, 
ce dev a clairement utilisé un générateur de nombres aléatoires'. 
J'ai vu des requests plus grands que les limits ! 
J'ai vu des demandes de '0.0001m' de CPU ! 
J'essaie de rester pro, mais des fois, 
j'aimerais pouvoir envoyer un 'LOL' dans les events du Pod."

Conclusion : Rire pour ne pas pleurer (et mettre des métriques)

La gestion des ressources dans Kubernetes, c'est un art subtil. Un mélange de science (monitoring, profiling), de doigt mouillé (estimations initiales) et parfois, de pure chance. C'est une source inépuisable de maux de tête, de crises de nerfs nocturnes, mais aussi, avouons-le, de bonnes tranches de rigolade (après coup, généralement).

Alors la prochaine fois que votre Pod se fait OOMKiller pour la 5ème fois de la journée, respirez un grand coup. Rappelez-vous que vous n'êtes pas seul. Nous sommes tous dans cette galère magnifique qu'est Kubernetes. Et n'oubliez pas : mettez des métriques partout, observez vos applications comme un stalker professionnel, ajustez vos requests et limits avec la précision d'un horloger suisse (ou au moins, avec un peu moins de "YOLO"), et peut-être, juste peut-être, votre Kubelet arrêtera de pleurer la nuit.

Et si ça ne marche toujours pas ? Blâmez le YAML. Ça marche toujours.

Dernier mot d'un Kubelet Philosophe (Kubelet-1c9e sur Node-Zen-Garden-00) :
"Au fond, nous les Kubelets, 
on est juste là pour essayer de maintenir un semblant d'ordre dans le chaos créatif des développeurs. 
On jongle avec des millicores et des mébioctets comme on peut. 
Alors oui, parfois on râle, parfois on throttle, parfois on appelle le grand méchant OOMKiller... 
mais c'est pour le bien du cluster. 
Enfin... on espère."