Des requests Kubernetes élevés paient des nœuds vides

La facture cloud d’un cluster Kubernetes suit les ressources réservées, parce que le scheduler et l’autoscaler de nœuds travaillent à partir des requests. Limits, budgets de namespace et autoscaling n’ont d’effet que couplés à cette réservation. Celui qui maintient des requests élevés paie de la capacité tenue en réserve.

L’essentiel en bref

À lire :L’observabilité ronge le budget cloud en silence  /  EKS 1.36 coûte cher sans discipline FinOps

Que sont les requests Kubernetes ? Kubernetes traite les requests de CPU et de mémoire comme une réservation servant au placement. Le scheduler n’affecte le pod qu’à un nœud où cette quantité est encore libre. Le Cluster Autoscaler retient le même chiffre pour décider s’il faut un nouveau nœud. Celui qui maintient des requests élevés paie de la capacité tenue en réserve. Les limits plafonnent la consommation à l’exécution.

Pourquoi les requests fixent le nombre de nœuds

Kubernetes traite les requests de CPU et de mémoire comme une réservation servant au placement. Le scheduler additionne les requests des pods déjà en cours d’exécution sur un nœud et n’accepte un nouveau pod que si le reste, selon les requests, suffit. L’usage mesuré n’intervient pas à cette étape. Un service peu chargé doté d’un request élevé bloque la même capacité qu’un service qui sature vraiment sa réservation. Les services système et les DaemonSets sont déduits de la même somme du nœud, avant que les pods applicatifs trouvent une place.

Les autoscalers de nœuds surveillent les pods qui restent Pending, faute de capacité de request libre. Un nœud supplémentaire apparaît alors, et avec lui une instance de plus sur la facture cloud. Si les requests croissent à travers de nombreux namespaces et réplicas, la flotte grossit même lorsque le trafic reste plat. Chez les grands fournisseurs, la facture tient aux instances actives, aux Persistent Volumes et au réseau. Après un test de charge, ces nœuds restent en service tant que personne ne rabaisse les requests ou le nombre de réplicas.

Les requests fixent donc la capacité que la plateforme tient réellement en réserve. Celui qui les laisse durablement hauts paie de la capacité tenue en réserve. Celui qui les fixe trop bas crée du Pending, des évictions sous pression et un scale-up qui peut demeurer après le pic. Une plateforme qui commente les factures sans modifier les specs ne tient pas les commandes. La fragmentation aggrave le tableau : quelques gros pods laissent un reste de capacité inutilisable par d’autres requests.

Nombre de modèles internes de refacturation répartissent le coût des nœuds selon les requests. C’est cohérent : ce sont précisément ces champs qui pilotent le packing et, souvent, le nombre de nœuds. Sans requests fiables, chaque échange budgétaire tourne à l’estimation. L’équipe discute alors des parts, pendant que la flotte continue de grossir sans qu’on le voie. Il en découle le premier point de contrôle : la spec dit-elle ce qui lie vraiment les nœuds ?

Les limits cantonnent les dégâts à l’exécution

Les limits plafonnent le CPU et la mémoire dès qu’un conteneur dépasse le seuil. Côté CPU, le throttling apparaît dans la latence de queue des requêtes. Côté mémoire, l’excès finit en général par un OOMKill. Les deux protègent les workloads voisins sur le même nœud et limitent le rayon d’impact local. Ni l’un ni l’autre ne change la facture tant que les requests restent identiques et que les nœuds continuent de tourner.

La classe de Quality of Service se déduit du request et de la limit. Les deux définis et égaux : Guaranteed. Request inférieur à la limit : Burstable. Si aucun des deux n’est défini, le pod tombe en BestEffort et, dès qu’il manque des ressources, est évincé le premier. Les équipes posent souvent le request égal à la limit pour forcer Guaranteed, ce qui fait monter le request avec la limit et baisser la densité de packing.

Une limit sans request crédible renverse le problème. Le scheduler serre le packing, et à l’exécution le conteneur peut aller bien au-delà de la réservation. Sous charge, les voisins subissent du CPU steal et de la pression mémoire. Coûts et stabilité basculent ensemble : le nœud est plus rempli que la logique de packing ne l’avait supposé. Les limits sont un frein d’exploitation.

Le rightsizing exige usage réel et marge de sécurité

Le rightsizing cale les requests sur la charge observée, plus une marge de sécurité choisie sciemment. Il faut des séries d’usage sur plusieurs jours et semaines : un pic isolé, pris dans une fenêtre de déploiement, ne suffit pas comme étalon. Celui qui ne mesure que le midi des jours ouvrés sous-estime le batch de nuit. Celui qui ne mesure que la fenêtre de déploiement surestime le régime permanent. CPU et mémoire n’échouent pas de la même façon : le CPU se bride, pas la mémoire.

Les autoscalers verticaux peuvent proposer ou appliquer les requests. Cela raccourcit la boucle manuelle et reporte la responsabilité sur la fenêtre d’observation, les planchers et la stabilité. Des fenêtres trop courtes font osciller entre classes de taille. Chaque changement de request modifie le packing et peut retirer ou ajouter des nœuds. Un rightsizing qui ignore l’autoscaler de nœuds reste incomplet : l’économie n’existe que lorsque des instances disparaissent vraiment.

La marge de sécurité fait partie du design. Jobs de batch, heaps, caches et pics au démarrage ont besoin d’une marge inscrite dans les requests. La règle doit être explicite, par exemple un percentile d’usage élevé, et contrôlée à intervalle régulier. Sinon la réserve se fige en surprovisionnement sans justification. Une réserve que plus personne ne peut expliquer est, en pratique, un second budget caché.

Des classes de service différentes refusent la formule unique. Frontends sans état, workers de files et runtimes lourds en mémoire ont des profils distincts. La revue porte sur la classe et la forme de sa charge. Une réduction globale sur tous les namespaces crée systématiquement du throttling d’un côté et des nœuds vides de l’autre.

Les budgets de namespace stoppent la hausse silencieuse de capacité

Sans plafond, la somme des requests augmente à chaque déploiement, chaque sidecar et chaque réplica. Les ResourceQuotas sur les requests CPU et mémoire bornent ce qu’un namespace peut réserver au total. Les LimitRanges posent les valeurs par défaut, les minima et les maxima par conteneur. Résultat : moins de pods sans request. L’absence de valeurs par défaut est une source fréquente de réservation silencieuse : un service jugé modeste reçoit ses requests après coup.

Un budget qui ne plafonne que les limits laisse courir la réservation. Un budget calé seulement sur le nombre de pods ignore les specs surdimensionnées. Le quota doit porter sur ce qui occupe les nœuds : CPU en request, mémoire en request, PersistentVolumeClaims et, au besoin, le nombre de workloads. La manière dont un fournisseur le répercute ensuite sur la facture varie.

Sans processus, les quotas se contournent. De nouveaux namespaces, un second cluster et des requests dans des namespaces système partagés passent sous le plafond. Toute hausse se traite dans la même revue qu’une extension de capacité. Une équipe qui demande plus de réservation doit montrer l’usage et les événements de limit. Sinon la plateforme finance un espoir sans assise.

Des budgets séparés, production et hors production, empêchent les tests de charge d’absorber la réservation de production. Un cluster partagé sans quotas séparés en fait exactement la surprise récurrente. La plateforme doit afficher quelle part d’un quota est déjà engagée par les requests. Sans cette visibilité, le rejet d’un déploiement tombe par surprise et l’équipe cherche à contourner le plafond.

L’autoscaling amplifie chaque erreur de la spec

Le Horizontal Pod Autoscaler ajuste le nombre de réplicas selon le CPU, la mémoire ou des métriques personnalisées. L’utilisation relative du CPU est indexée sur le request, donc sur la réservation retenue. Chaque réplica apporte l’intégralité de ses requests au packing. Si le request est trop haut, on obtient des copies coûteuses et un besoin de nœuds plus tôt. Si le request est trop bas, l’utilisation paraît haute et l’autoscaler augmente tôt le nombre de réplicas, alors que le scheduler place mal des pods taillés trop juste.

Un scaling vertical et horizontal sans responsable clair engendre des oscillations. La voie verticale change la taille, l’horizontale le nombre. L’autoscaler de nœuds répond par des instances. Pendant la transition, anciennes et nouvelles tailles tournent souvent en parallèle. C’est précisément là que coûts et files Pending montent ensemble, souvent avec du throttling, la nouvelle taille n’étant pas encore stable.

Les bornes d’autoscaling doivent être cohérentes avec les quotas de namespace. Un plafond haut avec un quota serré produit du Pending, pas de la capacité. Un quota large sans plafond fait grossir les nœuds. La chaîne reste fixe : taille du request, puis nombre de réplicas, puis plafond du namespace, enfin nombre de nœuds. Celui qui saute un maillon ne voit l’effet qu’à la facturation.

Les fenêtres de stabilisation relèvent de la même revue. Trop courtes, elles créent du flapping et un packing sans cesse remanié. Trop longues, elles gardent après le pic des nœuds devenus inutiles. L’autoscaling multiplie la spec déjà présente dans le fichier.

Trois indicateurs à lire chaque semaine

Pour la lecture hebdomadaire des coûts, un petit jeu d’indicateurs suffit, reliant exploitation et facture. D’abord, l’utilisation des requests : usage CPU et mémoire mesuré rapporté au request, ventilé par workload et par namespace, agrégé sur la semaine. Si elle reste très basse, la réservation est excessive. Si elle reste collée à la réservation pleine, la marge manque ou le request est trop juste. CPU et mémoire se lisent séparément : les correctifs ne sont pas les mêmes.

Ensuite, la capacité de request inutilisée dans le cluster. C’est le delta entre capacité réservée, capacité packable et charge mesurée. On le voit dans des nœuds faiblement chargés, un faible taux de packing, ou des namespaces très réservés et peu utilisés. Ce chiffre explique pourquoi la facture ne descend pas avec le trafic. Il offre à l’équipe app et à la plateforme un chiffre commun.

Enfin, les événements de limit : durée de throttling CPU et OOMKills par workload. S’ils augmentent après un rightsizing, la réserve était trop agressive. S’ils restent élevés alors que l’utilisation des requests est basse, request et limit sont mal accordés. Un pilotage des coûts qui ne fait que baisser la facture et ignore ces événements déplace le dégât vers l’incident. Le throttling apparaît comme de la latence sur le parcours utilisateur. Trois indicateurs, un rythme de semaine fixe.

Celui qui peut modifier la spec tient la facture

La mécanique ne fonctionne que si l’on sait clairement qui peut modifier requests, limits et quotas. Les équipes app ont besoin de latitude dans leur namespace. La plateforme a besoin d’un veto dès que la somme des requests force l’ajout de nœuds. Un portail en libre-service délié du quota transforme chaque scaling en commande aux frais de la plateforme.

Les modifications de requests suivent le même circuit visible que les autres specs à effet de production. Un change qui double les requests CPU est une décision de capacité. Il doit être accompagné des séries d’usage et des trois indicateurs hebdomadaires. Sinon une valeur par défaut tirée d’un tutoriel reste des mois en production et bloque une capacité que plus personne ne justifie.

La facture continue de suivre les instances. Celui qui confronte chaque semaine requests, limits et plafonds de namespace aux trois mêmes indicateurs tient le nombre de nœuds et l’étendue des dégâts dans une seule revue. Celui qui le renvoie au ticket d’après le mois de facturation arrive trop tard.

Questions fréquentes

Source de l’image : générée par IA (septembre 2026)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.