Comment Onicost calcule une request
Onicost travaille conteneur par conteneur, sur une fenêtre de 14 jours par défaut, entre 7 et 30. Pour le CPU, il prend le 95e percentile de l’usage par minute et ajoute 15 % de marge. Pour la mémoire, il prend le pic de la fenêtre et ajoute 20 %. La différence vient de Kubernetes : une limite CPU bride le conteneur, alors qu’une limite mémoire peut le faire tuer.
Une request ne baisse que si la valeur actuelle dépasse la valeur recommandée de plus de 20 %. Ce seuil écarte les petits gains qui ne valent pas un déploiement. Une request monte dès que le percentile ou le pic la dépasse.
Ces valeurs sont des réglages. Vous pouvez choisir p90, p95 ou p99, changer les marges et ajouter jusqu’à 20 politiques par namespace. La première qui correspond s’applique : la production peut viser p99 pendant que le développement reste en p90. Une politique peut aussi exclure un namespace de toutes les familles de recommandations sauf Nœuds.
Quelle confiance accorder à une recommandation
Chaque recommandation porte un score de 0 à 100 : jours de données pour 40 points, stabilité pour 25, rafales pour 15, santé pour 10 et saisonnalité pour 10. Il est faible sous 40 et moyen sous 70. Avant 3 jours de données, les règles sur les requests se taisent. De 3 à 7 jours, une recommandation reste provisoire : elle peut encore être retirée, et son économie reste hors du total.
La fiche place les preuves à côté des chiffres : percentiles CPU de p50 à p99, pics de mémoire, OOM kills, périodes CPU bridées, redémarrages et variations de réplicas. Les agents antérieurs à la version 0.6.0 n’envoient ni les pics, ni les OOM kills, ni le bridage. Onicost traite alors ces signaux comme inconnus et ne les compte jamais pour zéro.
Les garde-fous intégrés aux règles
Une baisse de facture payée par un incident n’est pas une économie. Plusieurs règles protègent donc vos services. Le HPA en est un bon exemple : il calcule l’utilisation en pourcentage de la request, et une request plus basse peut donc changer son comportement.
- Après un OOM kill dans la fenêtre, la request mémoire ne baisse pas. Un pic au-dessus d’elle la fait monter.
- Sous un HPA sur l’utilisation CPU, la request CPU reste au moins au niveau où le percentile atteint la cible du HPA.
- Une request recommandée au-dessus de la limite actuelle relève aussi cette limite, car Kubernetes refuserait la request.
- Les règles Requests trop basses, Conteneur tué faute de mémoire et CPU bridé poussent les valeurs vers le haut, sans économie affichée.
- Un workload zombie sort de la liste des requests à revoir : la bonne question est alors de l’arrêter.
De la request à la facture
Une request plus basse libère de la capacité. La facture bouge quand un nœud part. Onicost indique donc la base de chaque économie. Facture désigne le prix catalogue des nœuds ou du volume. Allocation désigne le coût alloué des requests, qui ne baisse la facture qu’une fois des nœuds libérés. Estimée repose sur une hypothèse.
Onicost rejoue ensuite le placement de chaque pool avec tous les rightsizings appliqués, jusqu’à 80 % de remplissage par défaut. Il indique alors la part réalisable en libérant des nœuds. Sur Fargate, GKE Autopilot et les nœuds virtuels AKS, une taille plus petite peut atteindre la facture directement, car le fournisseur facture le pod. L’écart doit atteindre au moins un cran de facturation.
Après le changement, Onicost le détecte et mesure le pool : coût quotidien des 7 jours après l’application, face aux 7 jours avant, ramené à 30,4 jours. Il peut aussi constater qu’aucun nœud n’a été libéré.
Appliquez le changement, ou laissez l’auto-resize le faire
Chaque recommandation donne les valeurs actuelles et recommandées. Le YAML recommandé se copie dans le manifeste ou les valeurs Helm. Sur Kubernetes 1.35 et plus, l’auto-resize applique lui-même les requests CPU puis mémoire, de 20 % au plus par nuit, dans chaque namespace dont le switch reste actif, et revient en arrière au moindre OOM ou throttling. Les autres recommandations restent à appliquer par votre équipe. Le scheduler, lui, arrête et redémarre des workloads sans toucher à leurs requests.
Le Vertical Pod Autoscaler suit une autre voie. En mode Off, il range ses recommandations dans le statut de l’objet VPA. En mode Initial, il pose les requests à la création des pods. D’autres modes mettent à jour les pods. Si VPA gère un workload, gardez une seule source de vérité pour ses requests. Onicost y ajoute le coût, la vue des nœuds et le suivi.
Ce que montre chaque offre
Free montre toutes les recommandations, avec les valeurs à appliquer à la main, et la simulation de l’auto-resize, workload par workload. Team, à partir de 39 € HT par mois, active l’auto-resize et le Scheduler, avec un essai gratuit de 14 jours. Les économies affichées sont des estimations, et aucune n’est garantie.
Questions fréquentes
Onicost applique-t-il le rightsizing à ma place ?
Pour les requests, oui si vous l’activez : sur Kubernetes 1.35 et plus, l’auto-resize les baisse par petits pas dans chaque namespace dont le switch reste actif, et revient en arrière au moindre incident. Sinon, il donne les valeurs et le YAML, et votre équipe les applique avec ses outils.
Au bout de combien de temps ai-je une recommandation ?
Les règles sur les requests parlent à partir de 3 jours de données, à titre provisoire, et se confirment à 7 jours. Un pod BestEffort est signalé dès le premier inventaire.
Pourquoi un percentile pour le CPU et un pic pour la mémoire ?
Un CPU trop serré ralentit le conteneur. Une mémoire trop serrée peut le tuer. Onicost accepte donc de rares dépassements CPU et couvre le pic mémoire.