Trois valeurs à lire séparément
La request sert au placement du pod : le scheduler vérifie qu’un nœud peut accueillir les ressources demandées. La limit encadre la consommation du conteneur. L’usage mesure sa consommation réelle. Ces valeurs répondent à des questions différentes ; lisez-les séparément pour comprendre votre workload.
Une application peut utiliser plus que sa request si les ressources sont disponibles, dans le cadre de ses limits. Une request élevée peut réserver une place inutilisée. Une request trop basse peut fragiliser le dimensionnement lorsque les ressources sont disputées.
CPU : distinguez capacité demandée et débit de travail
Kubernetes exprime le CPU en cœurs ou en milliCPU : 500m représente un demi-cœur. Une limite CPU peut entraîner du throttling lorsque le conteneur veut la dépasser. Regardez donc l’usage, mais aussi la latence et le débit de l’application. Une moyenne faible ne suffit pas à conclure qu’une limite est confortable.
Comparez des périodes de charge similaires et identifiez les tâches qui créent des pointes : démarrage, traitement de lots ou pics de trafic. Choisissez une request qui correspond au besoin observé et une politique de limits cohérente avec votre exploitation. Un chiffre universel ne convient pas à tous les services.
Mémoire : gardez une marge pour les pics
Une limite mémoire peut provoquer une terminaison liée au manque de mémoire, visible notamment sous l’état OOMKilled. La mémoire ne se comporte donc pas comme un simple plafond de débit CPU. Tenez compte du démarrage, des caches et du fonctionnement du runtime avant de baisser une limit.
Utilisez des unités explicites : Mi et Gi sont des unités binaires, différentes de M et G. Examinez les valeurs hautes et les redémarrages sur une période représentative. Le maximum observé n’est pas une garantie pour la prochaine pointe ; prévoyez une marge justifiée par votre application.
Préparez une observation qui représente votre activité
Ne dimensionnez pas un service sur quelques minutes calmes. Votre fenêtre d’observation doit inclure les événements qui comptent pour lui : jours ouvrés, traitements planifiés, déploiements ou clôture mensuelle. Si un événement important n’a pas eu lieu, notez cette limite dans la décision plutôt que de le supposer couvert.
Dans Onicost, rapprochez usage, requests et capacité des nœuds pour repérer les écarts à examiner. Complétez l’analyse avec vos indicateurs applicatifs. Le coût indique où commencer ; la connaissance du service permet de décider jusqu’où aller.
Changez progressivement et vérifiez l’autoscaling
Lorsque le HPA utilise une cible d’utilisation CPU relative aux requests, changer une request change aussi la référence du calcul. Vérifiez vos règles d’autoscaling avant le déploiement. Vous pouvez sinon déplacer la dépense vers davantage de réplicas ou obtenir un comportement différent de celui attendu.
Appliquez un changement limité avec vos outils de déploiement, puis comparez la qualité de service pendant une charge représentative. Préparez un retour à la configuration précédente. Le responsable du workload doit connaître les critères qui permettront de garder ou d’annuler la modification.
- Contrôlez latence, erreurs, throttling et redémarrages.
- Vérifiez le nombre de réplicas et les pods en attente.
- Confirmez que les pics métier restent correctement servis.
Reliez le dimensionnement à une économie réalisable
Réduire des requests peut permettre de mieux utiliser les nœuds déjà payés. Une économie facturée demande ensuite une réduction ou un redimensionnement de la capacité achetée. Vos contraintes de disponibilité et de placement peuvent empêcher cette étape même si l’allocation du workload diminue.
Onicost fournit des recommandations en lecture seule et une estimation mensuelle lorsqu’elle est chiffrable. Votre équipe applique les actions. Suivez séparément la capacité libérée, les ressources retirées et la dépense constatée pour expliquer le résultat sans présenter une estimation comme un gain acquis.
Questions fréquentes
Faut-il donner la même valeur aux requests et limits ?
Il n’existe pas de règle adaptée à toutes les applications. Choisissez vos valeurs selon la charge, les contraintes d’isolation et vos objectifs de service, puis validez leur comportement.
Onicost modifie-t-il les manifests Kubernetes ?
Non. L’agent collecte les données en lecture seule. Les recommandations aident votre équipe à préparer un changement qu’elle applique avec ses propres outils.